ラチェクラの「返品ポリシー」トロフィーは2周目序盤が簡単
ラチェット＆クランク パラレル・トラブルのトロフィー「返品ポリシー」の取得は、2周目の序盤で挑戦するのが簡単だ。
はじめは先行の攻略サイトに倣ってスカルストゥのコロシアムでやってたんだけど、一向に取れる気がしなかった。んで、知人から以下の情報をゲット。
一般的にはコロシアムっぽいんですが、自分は強くてニューゲームの2周目を始めて、序盤に出てくるピストルのザコで取りました。あいつらその場からほぼ動かないから、弾数無限にして遠くからペチペチ跳ね返して、ある程度倒したらチェックポイントからやり直すを繰り返しました。
— こうひい (@MetalCoffeeX) June 26, 2021
天才か。武器収集トロフィーのために少なくとも2周目序盤のプレイは必須なんだし、確かに1周目にこだわる必要もない罠。
試してみたところ、ネファリウスに襲われ駅に向かう指令が出た後、下図の場所がやりやすいように思う。
理由としては…
- 通路で安全、弾を集めやすい、狙いもつけやすい
- ヴォイドリアクターが弾切れになったらミセスズーコンで補給できる
- 敵が枯れたら落下死でリスポーンできる
ここに至るまでの戦闘でも、リターンショットは随時使える。それらも狙っていけば、さほど時間をかけずにトロフィーがゲットできるかと。少なくともコロシアムでやるより断然楽だろう。言わずもがな1周目の時点でヴォイドリパルサーをヴォイドリアクターまで進化させといてね。
各位のご武運を祈るざます！
代替データストリームの取得はNtQueryInformationFile一択
C#でNTFSの代替データストリーム(Alternate Data Stream)を読み書きしたくなったので調べたことをメモ。正確な部分は把握しきれてないが、非公開関数であるNtQueryInformationFileで列挙するのが確実のようだ。
代替データストリームの取得（列挙）には以下の3つの方法がある。
- BackupRead関数を使う
- FindFirstStreamW関数, FindNextStreamW関数を使う (Windows Vista以降)
- NtQueryInformationFile関数を使う (非公開関数)
正攻法は1, 2で、調べた限りADSの読み書きを行う既存のC#ライブラリは、1のBackupRead/BackupWriteを使っている。
ところがどう言う訳か、BackupReadでは列挙されないストリームが存在しうる。dir /rやNirSoft AlternateStreamViewでは表示されるにも関わらずだ。NTFSによるアクセス権限の問題らしいが、詳しいことは分からない。
NtQueryInformationFileはアクセス権限を無視して情報を取得できるらしく、前述のdirやAlternateStreamViewはこのAPIを使っているのだろう。多分。
2の方法は試してないが、アクセス権を無視するオプションはないらしいので望み薄と思われる。
こちらの記事のC#でNtQueryInformationFileを使ったサンプルで、無事目的のADSが取得できることを確認。というわけで、非公開関数ではあるもののNtQueryInformationFileを使うのが確実っぽい。
参考サイト
TS2TSJ25M3の中身とベンチマーク
PS3のバックアップ用に急遽1TB以上のUSBなHDDが必要になった。手持ちのSATA-USB変換器とHDDの組み合わせは、ことごとくPS3で認識されなかったのだよ…。
今更外付けHDDに金掛けたくないなぁと思いつつ販売サイトを物色してると、じゃんぱらでTranscend StoreJet 25M3 TS2TSJ25M3の中古品が2980円だったので即購入。傷あり、USBケーブルなし、本体のみということで状態は期待できなかったが、USB 3.0で2TBのポータブルHDDがその値段なら、多少の瑕疵を差し引いても割安だろう。まぁ実物はそこまで悪くなかったんですけど。
能書きはこれくらいにして、CrystallDiskInfoの結果はこちら。
製品は2018年製造の個体で、中身はご覧のとおりSeagate ST2000LM007-1R8174だった。使用時間も少ないし大当たりだ。
CrystalDiskMarkの結果は以下の通り。64MBと1GBで計測してみた。
64MBの方はキャッシュが効いてるのか、ランダム4Kがそれなりの結果となっている。それ以外は特筆すべき点はないかな。
certbotでthe following renewal configurations were invalidが出た
吹き飛んだ家鯖の環境再構築の一環でcertbotを再設定し、証明書の更新テストを行ったところ「the following renewal configurations were invalid」なるエラーが発生した。
$ sudo certbot --dry-run renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /usr/local/etc/letsencrypt/renewal/hoge.example.com-0001.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
（略）
Cleaning up challenges
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed without reload, fullchain is
/usr/local/etc/letsencrypt/live/hoge.example.com-0001/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /usr/local/etc/letsencrypt/renewal/hoge.example.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/certbot/_internal/renewal.py", line 70, in _reconstitute
renewal_candidate = storage.RenewableCert(full_path, config)
File "/usr/local/lib/python3.8/site-packages/certbot/_internal/storage.py", line 468, in __init__
self._check_symlinks()
File "/usr/local/lib/python3.8/site-packages/certbot/_internal/storage.py", line 538, in _check_symlinks
raise errors.CertStorageError(
certbot.errors.CertStorageError: expected /usr/local/etc/letsencrypt/live/hoge.example.com/cert.pem to be a symlink
Renewal configuration file /usr/local/etc/letsencrypt/renewal/hoge.example.com.conf is broken. Skipping.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all simulated renewals succeeded:
/usr/local/etc/letsencrypt/live/hoge.example.com-0001/fullchain.pem (success)
Additionally, the following renewal configurations were invalid:
/usr/local/etc/letsencrypt/renewal/hoge.example.com.conf (parsefail)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0 renew failure(s), 1 parse failure(s)
んん－？confファイルのパースエラー？というのは早計で、実際のエラーはその上に書いてある「certbot.errors.CertStorageError: expected /usr/local/etc/letsencrypt/live/hoge.example.com/cert.pem to be a symlink」というやつ。
要は/usr/local/etc/letsencrypt/live/ドメイン/以下のpemファイルは、/usr/local/etc/letsencrypt/archive/ドメイン/のpemファイルへのシンボリックリンクじゃないとダメらしい。liveの方を確認してみたら、確かにシンボリックリンクではなく実ファイルになっていた。
root@example:/usr/local/etc/letsencrypt/live/hoge.example.com # ls -al total 32 drwxr-xr-x 2 root wheel 7 Dec 21 08:06 . drwx------ 4 root wheel 5 May 4 10:36 .. -rw-r--r-- 1 root wheel 692 Aug 17 2019 README -rw-r--r-- 1 root wheel 1834 Dec 21 08:06 cert.pem -rw-r--r-- 1 root wheel 1586 Dec 21 08:06 chain.pem -rw-r--r-- 1 root wheel 3420 Dec 21 08:06 fullchain.pem -rw------- 1 root wheel 1704 Dec 21 08:06 privkey.pem
確かな原因は分からないけど、Boot Environment環境への移行作業でやらかした線が濃厚。
となれば、シンボリックリンクにすれば解決するハズなんだけど、これまた「OpenSSL.crypto.Error」とかいうエラーが発生してダメだった。
そもそも同一ドメインに対して、何で「hoge.example.com.conf」と「hoge.example.com-0001.conf」の2つの設定があるんだ？というか、どちらのconfファイルも作った覚えはない。
色々試してみるとcertbot certonlyコマンドで証明書を取得すると、対応するconfファイルが自動で作られるっぽい。で、同名ファイル（同名ドメイン）が存在する場合、連番付きのconfになる模様。
それならばconfファイルと証明書を全部消し、証明書取得からやり直したところ、無事更新まで通った。confファイル置き場は/usr/local/etc/letsencrypt/renewal/ね。
参考サイト
VMのFreeBSD 13.0Rのrand_harvestqのCPU負荷が高い件
家鯖の消費電力がとある時点から急に増えた。その差は実に30Wで明らかに誤差ではない。
FreeBSDな仮想マシンを起動すると増えるのは明白だったが、原因として思い当たることはなかった。が、ふとProxmox VEのCPU使用率グラフを見たら、FreeBSD 13.0-RELEASEに更新したタイミングでCPU利用率が大幅に上がっているのに気付いた。
FreeBSD内でtopしても特段高負荷なプロセスはなかったものの、よーく見てみるとSystemが4～5%となっており、何かがCPUを使ってるのは間違いない。そこでtop -SPでシステムの個別の状態を見てみると、rand_harvestqが定常的に1CPUの40～80%を食っていた。
プロセス名から察するに、乱数のエントロピー収穫用のプロセスである。エントロピー収穫の詳細は、手前みそながらこちら。
関連するシステム変数を見ても、特に変な個所はなさげ。しいて言えば、乱数源としてVirtIO Entropy Adapter (VirtIO RNG)とIntel Secure Key RNG (RDRAND)の2種類が使われてる点が仮想マシン特有ってところかな。
$ sysctl kern.random kern.random.fortuna.concurrent_read: 1 kern.random.fortuna.minpoolsize: 64 kern.random.rdrand.rdrand_independent_seed: 0 kern.random.use_chacha20_cipher: 1 kern.random.block_seeded_status: 0 kern.random.random_sources: 'VirtIO Entropy Adapter','Intel Secure Key RNG' kern.random.harvest.mask_symbolic: VMGENID,PURE_VIRTIO,PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED kern.random.harvest.mask_bin: 100001001000000111011111 kern.random.harvest.mask: 8683999 kern.random.initial_seeding.disable_bypass_warnings: 0 kern.random.initial_seeding.arc4random_bypassed_before_seeding: 0 kern.random.initial_seeding.read_random_bypassed_before_seeding: 0 kern.random.initial_seeding.bypass_before_seeding: 1
で、まぁ、色々と試してみたら、VirtIO Entropy Adapterが高負荷の原因だった。
その名の通り、VMでホスト側の乱数デバイスを使うための準仮想化デバイスなんだけど、ふつーに考えたら負荷は低くなるハズ。VirtIO RNGの乱数源は/dev/urandomにしてあるので、ブロックすることもないハズだし…。この辺、特にいじってはないんだけどなー、謎。
準仮想化で負荷が高くなっては本末転倒なので、VMからVirtIO RNGを取り除いて運用することにした。FreeBSD側ではIntel Secure Key RNGが動いてるので問題はないでしょう。
これで消費電力は無事元の水準に戻り、お財布の平和は保たれたのであった。