2022年11月30日水曜日

ケーブル一つでもシステムにとってかけがえのない存在なことを再認識させられました

 現在使っているPCは、かれこれ足掛け10年の間、週一回程度にビデオカードの差し直しをしないと正常に使えなくなるという爆弾を抱えているものの、ハードウェア的には仮に起きても本当に些細なトラブルばかりで(PT3が壊れた!と思ったら差し直したら直ったとか、20年以上愛用のPS/2キーボードの右CTRLキーがついに押下すると元に戻らなくなったりとか、そんなのばっかりで)びっくりするほど安定(VGAから目を背けつつ)しているのですが、やっとネタになりそうなハードウェアトラブルが発生したので記録する次第です。

まず、HDDのGドライブとして運用中の、このPCの他のハードディスクの中身をバックアップするだけの用途のドライブがあると思ってください。

そのGドライブが、ある日、アクセスされっぱなしになっていることに気づきました。

バックアップ専用ドライブですから、バックアップ中以外にBUSYになっている時点でおかしいのですが、実際にGドライブにエクスプローラーからアクセスしてみると妙に遲いものの各ファイルには正常にアクセスできます。

とりあえず、Windowsにおける最強のトラブル解決手段であるところのリブートを行ってみました。すると、特に問題なさそうな様子をしています。

しかし、実際には何か異常が起きたからこそ奇妙な挙動をしたのですから、原因を知りたい。

そこで、これは10年近い年季のHDDがいかれかけでバッドセクタが出たのかな?と考えてSMART値をチェックしてみました。しかし、SMARTを軽く見てみても、代替処理済みのセクタ数もセクタ代替処理保留中のセクタ数も回復不可能セクタ数もゼロのままで問題がなさそうです。

そこで、念のため chkdsk /r G: をかけてバッドセクタを探させることにしました。

すると、ステージ4である程度の個所でディスクへのアクセス頻度は高いけれど進捗がぱったりと進まなくなる状況になりました。

この辺は場数をどの程度踏んでいるかによるのですが、大容量HDDだから進捗が進まないのか、トラブルが起きているから進まないのかの見極めが必要となります。
ここでは後者、何らかのトラブルが発生しているためにchkdsk が進まないと判断して中断させようとしましたが、CTRL+CもCTRL+Breakも効果なく、やむなくコマンドプロンプトごと終了させました。

当然chkdskによってG:ドライブはアンマウントされているので再マウントしようとしましたがうまくいきません。焦っていると「すわ、壊したか!」と慌てるところですが、ここは、理屈ではここは単純にリブートで行けるはずと踏んでリブートするとG:ドライブが復活しました。

そこで改めてG:ドライブのファイルを閲覧したりすると、やっぱり奇妙に重い。今のところ何の解決にもなっていないことは明らかですので、SMART値を精査することにしました。

すると、「UltraDMA CRC エラー数」が膨大な値になっていることが分かりました。

これらをWindowsのイベントログを見ると
ソース:disk
イベントID: 153
「ディスク 1 (PDO 名: \Device\00000031) の論理ブロック アドレス 0x600870 で IO 操作が再試行されました。」
※論理ブロックアドレスは一定ではありません

というログが記録されています。

以下のようなログもありました
「トランザクション ログへのデータのフラッシュに失敗しました。VolumeId: G:、DeviceName: \Device\HarddiskVolume7 で破損が発生している可能性があります。」
以下HDD型式などの情報

ともあれ、SMART値が示すところでは、HDDとの通信がうまくいかないでエラーが起きてることを示しているので、最悪の場合はマザーボードの故障ですが、まずはSATAケーブルの交換を試してみます。

...正常に稼働するようになりました。

地味だけど重要な仕事をしてくれている伝送路を担うケーブルさんに感謝するためここに記録する次第です。

ここまでお読みいただきありがとうございました。

2022年8月14日日曜日

セキュリティ更新プログラム (KB5012170)が0x800f0922エラーで失敗するのはセキュアブートの設定が原因かもしれません

結論から申し上げますと、私の環境ではセキュアブートをOFFからONに変更するとKB5012170のインストールに成功しました。

その後、再度セキュアブートをOFFに戻しても特に問題なく稼働しています。

結論は以上です。

以下は蛇足です。

さて、当環境では火曜日以来、今月のWindows Updateでこんな問題が発生していました。

週末なので、そろそろ解決しようと思いました。
そこで、そのエラーコード0x800f0922を引き起こしているのは何やつかと尋ねると・・・

何度も失敗していますが、それはすべてKB5012170だそうです。
KB5012170とは何者かと尋ねると・・・

だそうです。

セキュアブートは当環境では無効にしてあるので、まずは有効にしてみることにしました。

そのためにはUEFIの設定を変更する必要があるため、マザーボードごとに用語や手順が異なるかと思いますが、当環境のASRock H87 Pro4を例にしますと、まずはSecure Bootはこんな状態でした。

セキュア起動とか安全起動とか楽しい日本語になっていますが、これらはすべてSecure Bootを意味しています。
上の状態を以下の状態にしてあげます。
上記の画面は、セキュアブートを有効にして、「システムモード状態」を「Setup」から「デフォルト値で初期化した状態」を示しています。

これでセキュアブートが有効になるのですが、保存して再起動する前に、もう一か所だけ確認したほうがいい箇所があります。

それは「CSM(Compatibility Supported Module)」です。CSMはセキュアブートとは「混ぜるな危険」の関係なので、ちゃんとOFFにされているか確認したほうがよいでしょう。

CSMが有効になっている場合、例えばこんな感じになります。
これを、以下のように変更します。
この状態になっていることを確認したら、設定を保存して再起動し、Windowsを起動します。

そして、さっそくWindows Updateをかけてみたところ、
となって、無事KB5012170のインストールに成功しました。
履歴を参照すると、
きちんと「正しくインストールされました」となりました。
なお、よくよく見てみると、驚いたことに、「更新の履歴を表示する」といっているくせに、失敗の履歴はすべて削除されてしまいました。
そんなの履歴じゃないじゃん。
歴史修正主義者マイクロソフトさんなのでした。

おまけ:この問題をイベントビューアで確認すると、次のように記録されています。
インストールの失敗: エラー 0x8024200B で次の更新プログラムのインストールに失敗しました: 2022-08 x64 ベース システム用 Windows 10 Version 21H1 のセキュリティ更新プログラム (KB5012170)。
エラーコードまで違ってんじゃん!!
歴史改ざん主義者マイクロソフトさんなのでした。

さて、愉快なマイクロソフトさんの歴史観はさておいて、当環境の場合は自作のデバイスドライバに私のオレオレ証明書で署名をしています。
セキュアブートの仕事は起動時のドライバやOSのデジタル署名をマイクロソフト以外に許すか許さないかなので、セキュアブートは無効に戻さなくてはなりません。

セキュアブートは一度でも有効にしてWindowsを起動すると、BCD(Boot Configuration Data。Windows Vistaからの伝統で、二進化十進数の事じゃございません)からtestsigning項目がOFFにされてしまいます。
そこで、UEFI画面でセキュアブートを無効にした後、Windowsを起動したら再度testsigning項目をONにしてあげてWindowsを再起動する必要があります。
コマンドは次の通りです。
bcdedit /set testsigning on

以上、どなた様かに役立つかもしれないと思い、記録する次第です。
このような駄文をお読みいただいてありがとうございました。

2022年7月26日火曜日

ケータイ補償お届けサービス(DoCoMo)でXperia A(SO-04E)がXperia 1(SO-03L)に交換となりました。(本編)

2022年7月24日にXperia A(SO-04E)をケータイ補償お届けサービスで交換した際の記録です。

以下、まずは前振りです。

もともと携帯電話を手放すことなど夢にも思っていなかったので、最近の携帯電話機の知識がまるでありません。
そこで、最初はドコモオンラインショップで端末を探したのですが、4GのAndroid端末が一機種も売ってないことに驚きました。5Gの端末ばっかりです。

しかし、5G端末をDoCoMoから買うと料金プランも5Gのものを強制されることを知りました。
そうすると、ガラケー時代にXi(4Gというか3.9G)契約を結んで今日まで来たユーザからすると、自動的に月々の支払いが値上げとなってしまうこともわかりました。

その点を踏まえてなお5G端末を購入すべきかどうか検討したのですが、結果としてドコモオンラインショップでの購入は諦めました。
その理由は、5GのエリアもSub6帯なら割と頑張って拡大できているようですが、肝心の28G帯で通信できるエリアはまだまだ地図上で点で表す程度ですから、現時点では毎月の使用料の値上げを受け入れてまで5G端末を所有すべき理由が見当たらないためでした。

次に考えたのはDoCoMoショップに行くことでしたが、すぐにその考えを捨てました。
理由は、この感染症が蔓延する時期に長居したくないこと、2016年のSO-04Eの連打病の修理に際して手続きにひどく時間がかかったこと、過去の経験から商品知識がひどく乏しい店員さんに当たるとロクでもないことになること(電話機どころかドコモの提供するサービスの概要すら詳細があやふやで、こちらからドコモが提供する役務やサービスについて説明をしなければならないようなレベルの店員さんが多すぎます)などです。

さて、そうなるとSIMフリー機か白ROMか・・・と商品を調べ始めた矢先に、ふと「そういえばSO-04Eっていい端末だったけど、一度連打病で無償修理をしたのも初めてだったし、さらに不具合がきっかけで携帯を変えるのって初めての経験だなあ。」という考えが浮かびました。

そこで、やっとケータイ補償お届けサービスという保険に入っていたことを思い出した次第です。

FOMAのころから加入していて、Xiに変更した際には380円に値上げとなっても再加入までしていたのに、これまで一度も利用したことがないサービスでした。

過去四半世紀を超えるドコモの使用歴のなかでこのSONYの端末以外、故障したことがないのだから使うことがなかったため、間抜けにもすぐには思い出せませんでした。

以上前振りでした。

そこで、さっそくどうやって利用したらいいのか検索したところ、My DoCoMo経由で申し込むと受付時間などにとらわれず、かつ負担金が10%の割引になるとのことでしたので、さっそく手続きを開始しました。

しかし、手続きのステップ1からステップ2に遷移すると、この携帯はオンライン手続きができないから電話してくださいといった旨のエラーメッセージが出て手続きを中断されてしまいました。

最初はFirefoxで手続したのが悪かったのかもしれないと思ってChromeなども使って再挑戦しても同じエラーで、どう頑張ってもオンラインでの手続きを拒否する構えを崩しません。

こんなんじゃDoCoMo側も人件費の削減にもつながらないし、ユーザも時間に縛られるし、折角のメリットが台無しじゃないですか、と思いつつ、結局、その場は諦めて、改めて営業時間内になってから電話することにしました。

さて、電話をして、まずオンライン手続きができなかったから電話を掛けた旨をオペレータの方にお伝えすると、「オンライン手続きを開始した履歴が残っていないので云々」とか言い始めて面食らってしまいました。

いやいや、そういう不具合がありましたよ、って報告しているのに、真正面から否定してくることにちょっと納得がいきませんでした。ユーザから不具合の報告があったことを開発側なり上司なりに報告すれば済む話だろうに、とにかく全力で履歴がないからと否定、否定、否定。
なんでここまで頑なな態度なのかわからなかったので、より事象を詳しく説明してみたものの、とにかく二言目には「履歴が残っていませんから知りません」の一点張り。

そもそも、エラーとして処理した事実が記録されてないこと自体が不具合ではないだろうか、と、よっぽどツッコミを入れようとしたのですが、それは火に油を注ぐように思えたので、相手がこだわる「履歴」に着目して、「履歴が残るような手続き方法を教えてください」と伺ってみました。

すると、「メッセージR(ドコモのキャリアメール)でURLを送るので、そこから手続きを開始してください」とのことでした。但し、確実に残るかは保証しないという保留付きでした。

そこで一度通話を終了して、メッセージRで教えてくださったURLから開始したものの、まったく同じエラーとなってしまいました。この提示いただいたURLにはGETパラメータが付与されていてそれが個人情報を示すものかもしれないので公開は差し控えます。

そもそも最初の時と同じ「この携帯はオンライン手続きができない」というエラーなのですから、そのエラーメッセージが示す通り、オンライン手続きを処理を開始したうえで、所有する携帯電話のチェックを行う処理を行い、その結果に応じて判断を行ったうえで処理をするわけですから、処理を開始した時点で履歴を残していないのは不具合だと思うのですが。

結局再度電話でメッセージRをいただいた後の経緯をご説明した後、同様に「記録に残っていない」の返事をいただいて、結局記録にこだわられてしまいましたので、伝えたい趣旨が伝わらないものと観念して、おとなしく引き続き電話での手続きをお願いさせていただきましたが、その後もずっとなぜ頑なにも否定し続けるのか理解できませんでした。

今は分かった気がします。

それは「一度My DoCoMo経由で手続きを開始した場合、途中で電話対応になっても10%割引は有効である」という事実があることを後で知ったからです。
要するに、電話対応となると結局人件費の削減になってないのだから極力割引を認めたくない。だからシステム的に記録に残すのはなるべく遅らせて、オペレータ対応をする担当の方には「記録がなければMy DoCoMo経由で手続きを開始したことを認めるな」という指示があるとしたら、あの頑なな姿勢は納得ができる気がします。
オペレータの方は「記録に残っていない」と仰っていましたが、ドコモのシステムの設計思想から言えば初期段階で弾いた場合は「記録に残していない」というほうが正確・・・なのかどうか。うがちすぎかな?さて本当のところはどうなのでしょうか。

いずれにせよ、SO-04EはMy DoCoMo経由ではケータイ補償お届けサービスの手続きは開始できないことがあるという知見は(今後どなた様かの役に立つかははなはだ疑問ではありますが)得られました。

さて、冒頭から手続きに躓いてしまいましたが、次の段階としてSO-04Eの在庫はすでにないこと、そのために別の機種を提案することの了解を求められましたので、それでお願いしますと、SC-02のLだったかMだったかをご提案いただきました。

新しいバージョンのOSで数年前に発売された新しい機体ということをアピールくださいましたが、SO-04Eを使い続けた人間には新しさはさほど訴求力を感じませんでしたし、SCといわれてもその時はどのメーカなのかもわかりません。

そこで、そもそもどんな端末なのかをおたずねしようと思ったところ、その前にオペレータの方が「ですが、使い慣れたXperiaのほうがいいですよね?」と仰られたので相槌を打つと、今度はSO-02Lというご提案をいただきました。同時に、先ほどのSCと同様に新しいバージョンのOSで数年前に発売された新しい機体であることをアッピールいただきました。

しかし、こちらとしては型番だけ言われても何ができるのかさっぱりわかりませんし、いくらOSのバージョンが新しくともSO-04Eで利用していた機能が使えなくなるようではあまりうれしくありません。
そこで相手からの折角のご説明をいただいてから検討したり断ったりするのも気が引けますので、こちらからSO-04Eの代替機として何を重視しているのかをお伝えしてご提案をいただこうと思い、「その携帯にはこういった機能がついていますか」と、SO-04Eで利用していた具体的な機能をお伝えしました。

すると、そのSO-02Lという端末(今検索したらこの機種はXperia AceというSO-04Eと同じ読みの携帯だったみたいです。SONYのブランド戦略はよくわかりません)にはいくつかの機能がついていないということで、条件に見合う端末を探してくださるというお申し出があったので、喜んでお願いしました。

その間、xxという機能はもうどの携帯にもついていないからなくてもいいか、4.6インチから画面サイズは大きくなってしまうけど問題はないか、など、一つ一つ丁寧に聞いてくれて随分親切に探してくださった結果、SO-03Lという端末をご提案いただきました。

無論型番を言われたってこちらはちんぷんかんぷんなのですが、あれだけ丁寧に探してくださったのだから不満のあろうはずもありません。ご提案いただいた機種でお願いしました。

次のステップで「SIMのサイズがミニからマイクロにかわるので無償でSIMカードを送るので開通手続きが必要」との事でしたが、私は2016年の故障時に代替機として自前でSIMフリーなMicroSIMのLTE対応タブレット端末を用意した際に、金を払ってDoCoMoショップでSIMサイズを変更済みでしたので、その旨をお伝えしたのですが、なぜかなかなか理解してもらえず、ひたすらSIMを送り付けようとしてくるのにはまいりました。
おそらくユーザーが事前に自前でSIMサイズを変更しているという想定がマニュアルになかったことが、この謎の態度の理由なのではないかと思います。

最終的には意思の疎通に成功したようで、SIMカードそのものは送付されませんでしたが、SIMカードを送付したという書状は送付されてきて、「ああ、DoCoMoという会社は自社が何を顧客に貸出しているのかが把握できてないんだな」ということは勉強になりました。

その一方で、充電端子がUSB-miniBからType-Cになるということで、ACアダプタになるかminiB-Type-C変換アダプタになるかはわからないものの、どちらかをつけてくださるとのことでした。その日から充電できるので大変ありがたいお申し出でしたので喜んでお受けしました。
このとても親切なご対応は、充電口の形状が異なる機体への交換となる場合の手順がマニュアルに存在していたためであったと思われます。

最後に配達予定を教えていただいたのですが、当日中に届くということで大変驚きました。しかも配達予定時刻が夜間なので受け取りをできそうなので喜んでお願いして、手続きを終えました。

その後、本当にその日の夜に届きました。

受け取ってしばらく時間が取れたときにSO-03Lとはどういう端末なのかを調べたところ、2019年のフラグシップモデルだったそうで驚きました。SO-04Eも当時はツートップだとか言って売り出していましたが、10万円を超える端末ではなかったです。
しかし、たった数か月で販売を終了したとのことで、何やら謎めいています。
将来に何か起きることが分かって、市場に出回る数を・・・とか、連打病経験者としては妄想してしまいます。ないとは思いますが。

内容物は、SO-03L本体と、「microUSB変換アダプタB to C」の2点でした。
その代わり、「3.5mmイヤホン変換・テレビアンテナケーブル(SO01)」、「クイックスタートガイド」、「ご利用にあたっての注意事項」の3点は付属していませんでした。

SO-04Eにはワンセグ用アンテナが内蔵されていたので、アンテナが別添だったのには気づきませんでしたが、充電中にチューナを起動すると受信できたので、電灯線がアンテナ代わりになるようだということが分かったので問題はなさそうです。

内蔵電池の充電能力は80%以上で良好という表示です。まあ、良好っていうならそうなんでしょう。

OSのバージョンは11になっていました。9年で4.2.2から11です。アプリを保守する立場からするとしょっちゅうAPIが変わって保守コストがきついですが、便利にもなるわけですから文句も言えません。

SO-04EからSO-03Lへのデータの移行については、Xperia名物のSONYご自慢の「Xperia Companion」アプリは、例によって全く役に立ちませんでした。
SMSの履歴を除いて通話履歴や連絡先などはDoCoMoの「ドコモバックアップ」アプリでSDカード経由で行えました。ついでに壁紙もSO-04Eのデフォルトの壁紙に設定されてしまいましたのはご愛敬でしょうか。
SMSの履歴については、「JSバックアップ」というアプリを利用させていただいたことで、これも無事に移行することができました。

最後に、SO-04Eの初期化処理を行い、黄色い袋に入れて、配達記録照会用のバーコードを控えて発送して、翌日にドコモさんに到着したことを確認しました。

とりあえず申し込み手続きを終えた感想としましては、とても親切に対応してくださいましたことが印象的でした。

一方で、ちょっとでもDoCoMoが想定していない事柄にぶつかると途端に対応がグダグダになるということも、また印象的でした。

また、返送した貨物の配達記録を追跡できるのはありがたいのですが、日本郵政が配達したと主張しても、ドコモさん自身が受領したかどうかを自分自身で認識しているか否かは話が別なので、ドコモさん自身からの貨物の受領の通知がないのはちょっと不満です。

故障で保険を利用したので、ケータイ補償お届けサービスはどうなったのかな、と契約情報をMy DoCoMoで参照すると、保険料もそのままでSO-03Lがケータイ補償お届けサービスの対象機になっており、端末使用年数もSO-04Eを引き継いで継続されていました。

その後はスタミナモードでAirDroidを使うと高熱を発してハングするとかいろいろ楽しんでいますが、表題の件とは無関係ですから、本記事はこれまでとさせていただきたく存じます。

ここまで駄文をお読みいただいてありがとうございました。

2022年7月25日月曜日

ケータイ補償お届けサービス(DoCoMo)でXperia A(SO-04E)がXperia 1(SO-03L)に交換となりました。(前振り編)

今回「ケータイ補償お届けサービス」を初めて使ったので、記録しておきたいと思います。

その前に、今時、SO-04Eを使用している人がどれだけいるのかわかりませんが、まずは交換元となったSO-04Eについて、ちょっと触れさせてください。

以下のスクリーンショットをご覧ください。

このスクリーンショットは、SO-04Eの電池使用量画面を2022年6月10日にとったものです。
この機種は電池交換が可能なのですが、結局一回も交換しませんでした。従って、このSO-04Eを購入したのは2013年8月6日ですから、2016年9月に連打病で修理に出した際には外装と電池はそのまま再利用されて帰ってきましたので、8年と11か月も使い続けた電池なのです。
この電池の持ちには感銘を受けていたので、そのうち記事にしようと思っていたまま7月となってケータイ補償お届けサービスを利用することになってしまいました。

携帯電話の使用用途は通話、Gmailを含むインターネットメール、キャリアメール、SMS、ワイヤレスヘッドホンのBluetooth親局、電子マネーとしてのモバイルSuicaといったものをごく自然に利用していて4日ですからすごいと思います。特に今年は家族に不幸があったので各種通信機能が大いに活躍してくれました。

ただ、ブラウザやマップ、読書などはタブレットを別途持っているのでそちらを使用していましたのでその辺が効果が高かったのかと思います。

また、Google Playブックスとか、アンインストールできない謎のアプリどもは無効化しておかないと、ユーザが使っていなくても常に何かをやっているようで、奇天烈に電池を食うので二日しか持たなくなります。

私にとって、FMラジオとワンセグ(主にデータ放送のほうが便利で映像は別にいらないんですが)の受信が可能で災害時にも心強いし、9年弱使っていても電池は持つし、その4.6インチというサイズとストラップホールがあるおかげで首から下げて胸ポケットにしまっても邪魔にならないとか、挙げればきりがないほど、もう本当にとにかくいい端末でした。

SO-03Lが届いたその日にDoCoMoさんに返送してしまってもう手元にもないので今更どうしようもないのですが、ここにその長年の活躍と貢献に対して感謝の念とともに記録する次第です、

以上、異様に長い前振りをお読みいただいてありがとうございました。

2022年6月10日金曜日

CentOS7.9.2009でDon't Starve Together Dedicated Serverを立ててみた

前振りです。

セールで66%引きの\503だったのでDon't Starve Togetherというゲームを買いました。
でも全然やる気が出ませんでした。

折角買ったのにつまらないな、と思っていると、なにやら独立してサーバが立てられるそうなので、CentOS7でやってみました。そういう手間が好きなので。
実際にやってみると、そこらへんに出回っている情報が古くて、そこかしこで齟齬が生じていることが分かりましたので、現時点(具体的な日付は当ブログの日時をご覧ください)での設置方法をメモしておく次第です。

今回使用したOS及びアプリのバージョンは以下の通りです。

Don't Starve Together Dedicated Serverのバージョン: 510124 LINUX 64-bit版
CentOSのバージョン: 7.9.2009

CentOSはGUIが無効にされています。

なお、現時点でも接続確認のみでゲームはプレイしていません。我ながら馬鹿です。

前準備その1 steamユーザを準備する

ValveさんとKLeiさんを絶対的に信用していない場合は、システムにsteamユーザを追加してください。

# useradd steam -d /home/steam

steamユーザになる
# su - steam

以下の記事は、上記を行っているものとして記述しております。

前準備その2 SteamCMD をインストールする

手順は以下の通りです。

1
2
3
4
5
6
7
$ mkdir /home/steam/steamcmd
$ cd /home/steam/steamcmd
$ wget https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz -O steamcmd_linux.tar.gz
 
$ tar zxvf steamcmd_linux.tar.gz
$ cd linux32
$ ./steamcmd

前準備その3 cluster_tokenを取得する

ゲームクライアントを起動してコンソールから次のコマンドを入力してください。ゲームクライアントはWindowsでも何でもいいです(Linuxである必要はありません)。

TheNet:GenerateClusterToken()

すると、Windows版クライアントの場合、 cluster_token.txt というファイルが以下のディレクトリに生成されます。

C:\Users\<ユーザ名>\Documents\Klei\DoNotStarveTogether\<数字の羅列>\

Documents\Klei\DoNotStarveTogetherの直下ではない点にご注意ください。

またはホームページから取得する方法もあるようですがやったことないので知りません。

以上で前準備は整いましたのでいよいよDedicatedサーバをインストールします。

手順その1 Don't Starve Together Dedicated Serverをインストールする

1
2
$ cd  /home/steam
$ ~/steamcmd/steamcmd.sh +@ShutdownOnFailedCommand 1 +@NoPromptForPassword 1 +force_install_dir dont_starve_together_dedicated_server +login anonymous +app_update 343050 validate +quit

※多くのサンプルでは上記の+loginよりも+force_install_dirを先に記述していますが、その場合は警告が出るので+force_install_dirを先に指定してください。

手順その2 一度起動してディレクトリのひな形を作成する

以下のスクリプトを~/start_servers.shとして保存、実行してください。
スクリプト中でリダイレクトしているテキストはサーバプロセスが出力しているファイルと同様なので不要なら/dev/nullに捨てて構わないでしょう。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
#!/bin/env bash
pushd . >/dev/null
STEAMHOME=/home/steam
DSTSVRDIR=$STEAMHOME/dont_starve_together_dedicated_server
DSTSVR_BINDIR=$DSTSVRDIR/bin64
DSTSVR_LIBDIR=$DSTSVR_BINDIR/lib64
PERSISTENT_STORAGE_ROOT=$DSTSVRDIR
CONF_DIR=conf
CLUSTERNAME=Cluster_1
LOGDIR=$PERSISTENT_STORAGE_ROOT/$CONF_DIR/$CLUSTERNAME/log
SVRPROC=dontstarve_dedicated_server_nullrenderer_x64
SVRPROCOPT=" -persistent_storage_root $PERSISTENT_STORAGE_ROOT -conf_dir $CONF_DIR -cluster $CLUSTERNAME"
 
if [ ! -e $DSTSVRDIR ]; then
  echo サーバがインストールされていない
  exit 1
fi
if [ ! -e $LOGDIR ]; then
  mkdir -p $LOGDIR
fi
 
cd $DSTSVRDIR
# サーバプログラムの更新を確認する
# dedicated_server_mods_setup.luaが上書きされるのを防ぐため、+app_updateオプションに対してvalidateを指定していない
$STEAMHOME/steamcmd/steamcmd.sh \
  +@ShutdownOnFailedCommand 1 \
  +@NoPromptForPassword 1 \
  +force_install_dir $DSTSVRDIR \
  +login anonymous \
  +app_update 343050 \
  +quit > $LOGDIR/app_update.log 2>&1
 
if [ ! -e $DSTSVR_LIBDIR ]; then
  mkdir -p $DSTSVR_LIBDIR
fi
if [ ! -e $DSTSVR_LIBDIR/libcurl-gnutls.so.4 ]; then
  # CentOS7にはlibcurl-gnutls.so.4が用意されていないためlibcurl.so.4を使用する
  ln -s /usr/lib64/libcurl.so.4 $DSTSVR_LIBDIR/libcurl-gnutls.so.4
fi
 
# メインと洞窟サーバを起動する
nohup ./$SVRPROC $SVRPROCOPT -shard Master > $LOGDIR/Master.log 2>&1&
nohup ./$SVRPROC $SVRPROCOPT -shard Caves > $LOGDIR/Caves.log 2>&1&
popd >/dev/null

手順その3 Dedicatedサーバを停止する

10秒くらい経ったら、以下のコマンドで停止してください。

 killall dontstarve_dedicated_server_nullrenderer_x64

正確を期すなら、Master.logを監視して、cluster_tokenがないので起動できないというメッセージを確認してから停止してください。

この一行のコマンドをstop_servers.shとして保存しておくと便利と思います。

手順その4 生成されたひな形に肉付けする

以下のディレクトリが生成されていますので、それぞれのディレクトリに必要な設定を行います。

肉付けが必要なファイルの説明は次のURLが詳しいです。
https://steamcommunity.com/sharedfiles/filedetails/?id=635281092

  1. ~/dont_starve_together_dedicated_server/conf/Cluster_1
    このディレクトリには先ほど取得したcluster_token.txtを配置してください。
    また、cluster.iniを生成して配置してください。
    cluster.iniの内容は以下の通りです。
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    [GAMEPLAY]
    game_mode = endless
    max_players = 16
    pvp = false
    pause_when_empty = true
    vote_enabled = true
     
    [NETWORK]
    cluster_name = クライアントから見えるサーバー名を設定してください
    cluster_description = 何か夢とか希望とか書いてください
    cluster_intention = social
    autosaver_enabled = true
    offline_cluster = false
    lan_only_cluster = false
     
    [MISC]
    console_enabled = true
    ; サーバ用日本語modをインストールする予定なのでjapaneseと指定
    language_code = japanese
     
    [SHARD]
    shard_enabled = true
    bind_ip = 127.0.0.1
    master_ip = 127.0.0.1
    cluster_key = Cluster_1_tokuni_imi_ha_nai
  2. ~/dont_starve_together_dedicated_server/conf/Cluster_1/Master
    このディレクトリにはserver.iniというファイル名で以下の内容を記述してください。
    1
    2
    3
    4
    5
    6
    [ACCOUNT]
    encode_user_path = true
     
    [SHARD]
    is_master = true
    name = Master
  3. ~/dont_starve_together_dedicateCavesd_server/conf/Cluster_1/Caves
    このディレクトリにもserver.iniというファイル名で以下の内容を記述してください。
    1
    2
    3
    4
    5
    6
    7
    8
    9
    [ACCOUNT]
    encode_user_path = true
     
    [SHARD]
    is_master = false
    name = Caves
     
    [NETWORK]
    server_port = 10998

    また、 worldgenoverride.lua というファイル名で、中身が下記のファイルを作成してください。
    このファイルでDST_CAVEを指定して初めて洞窟とみなされますので、このファイルを忘れると森が二つあるサーバとなります。ただし、私はゲームとしては遊んだことがないので、それがどういう動作につながるのかまではわかりません。
    1
    2
    3
    4
    5
    6
    7
    return {
      override_enabled = true,
      preset = "DST_CAVE",
      overrides = {
        start_location = "default",
      },
    }
  4. MastarとCavesディレクトリの両方にmodoverrides.luaというファイル名で以下を記述してください。
    1
    2
    3
    return {
    ["workshop-1636779445"] = { enabled = true } -- 日本語化
    }
  5. ~/dont_starve_together_dedicated_server/mods
    このディレクトリには dedicated_server_mods_setup.lua というファイルがあるはずなので、以下の行を追記してください。ファイルがない場合は、どうせもともとコメントしかないファイルなので自分で作って構いません。
    なお、このファイルはSteamCMDで本サーバアプリをvalidateすると消されてしまいますのでそのあたりは別途コピーを保管しておくなりして料簡してください。
    1
    ServerModSetup("1636779445") --日本語化mod
  6. ここまでで設定はおおむね完了したので、~/start_servers.shでDedicatedサーバを起動してください。
    ゲームクライアントを起動し、オンラインにしてから clustar.iniで定義したcluster_name でサーバを検索すれば接続できる状態になっているはずです。
あとはsystemdで起動できるようにしたりファイアウォールやルータの設定(udp,10999)、logrotateの設定などを行えばおしまいです。

以上、だれの参考にもならない文章ですが、それでもここまでお読みいただいてありがとうございました。

2022年5月18日水曜日

従来型G Suite、無償のまま存続可能へ

色々呼び方があるようで、従来型G Suiteのほかにも、無償版G Suite、Legacy G Suite、はたまた"料金のかからない従来の G Suite"とGoogleさん自身は様々に和名を定義しておられるようですが、要は2012年まで申し込めた「無償で独自ドメインが使えるGmailが使えるサービス」の件です。

このサービスは今年2022年の年頭、1月に廃止されることが発表され、有償版のGoogle Workspaceに移行するか、Gmailが使えない無償版の「Google Workspace Essentials Starterエディション」に移行するか、使用をあきらめるように案内されてきました。
しかし、Google Workspace 管理者ヘルプによりますと、この度、将来的には何らかの制限が加えられるかもしれないが、手続きを踏めばGoogle Workspaceに移行せずに、現在のまま継続して使用することが可能になりました。

手続きというのは、Googleさんに「この従来型G Suiteは非営利目的で個人的に利用しています」ということを伝えることです。といっても、具体的にはボタンというかブラウザ上のリンクを踏むだけです。
早速手続きを終えた後、管理コンソールから確認すると以下のように表示が変わります。
「詳細」をクリックすると以下の画面になります。「個人での利用: 料金のかからない従来の G Suite を引き続き利用」にチェックマークがついていることが確認できます(手続き前はチェックマークの部分が手続き画面に遷移する右向き矢印になっていました)。

なお、すでにGoogle Workspaceに移行した人は、管理コンソールから手続きができません。その場合はサポートに連絡しなければならないそうです。

Google Workspaceに移行する場合も、今回発表された無償版G Suiteのまま使い続ける場合も、いずれも8月1日までに手続きが完了していない場合はアカウントが凍結されます。

まさか無償のまま継続して使用できるようになるとは思ってもみませんでした。
素直にうれしいです。Googleさん、ありがとうございます。

2022年3月25日金曜日

椅子に座ると尾骨が痛い

最近は尾てい骨といわずに尾骨というらしいですね。

結論: 表題の件は、こういうクッションで解決しました。
以上です。

以下、出会うまでの恥の記録です。

もう10年ほどになるでしょうか、ある時、見る見るうちに体重が60kgから30kgほどに一気に落ちてしまいました。現在でもあばら骨が浮いていたりして骨と皮みたいなくせに、(脂肪がないので)腹筋が割れて見える体たらくです。

こうなると、横向きに寝れば浮き出た肋骨がマットレスに当たって痛いし、仰向けに寝ると今度は尾てい骨が当たって痛みます。

寝ている場合は寝返りで何とかなりますが、椅子に座ったときは尾てい骨が座面に当たっている状態で上半身の体重がのしかかります。これが実に痛くてたまりません。これから逃れるすべは椅子から立ち上がるくらいしかありません。

一日軽く14時間くらいは座っていることがざらにある生活ですので、さすがに何か工夫をしなければ、と思いました。

尾てい骨がイタイ、椅子、みたいな文言で検索すると、やれ整体がどうだの骨がずれてるだのああだのこうだのという検索結果ばっかりなので、何の役にも立ちませんでした。

最初に思いついたのは椅子の上に円座を敷くことでしたが、椅子の上で使うとクッション部分が尾てい骨にしっかり当たってしまい、痔でもないので肛門を保護しても何の意味もないことが見えていたので試しもしませんでした。

そこでまず試したのは厚めの座布団を敷いたり複数枚敷いたりして、座面を柔らかくしてみましたが、これでは痛むまでの時間が若干伸びるだけで、解決になりませんでした。

次に試したのは、尾てい骨が宙に浮くように、腿で座ることです。これは座布団を二つ折りにして腿の下に敷いて高さを確保しました。

しかし、これもうまくいきません。上半身の体重をモロに受け止めるべき臀部も宙に浮いているため、長時間座っているとかなり腰に来るのです。

ただ、何もしない場合に比べれば確かに長い時間、尾てい骨は痛まなくなりますので、座布団を折って座っているためにすぐ破れたり、椅子の上の座布団の位置が滑ってすぐにずれてしまうのをごまかしつつ、これで何年も我慢して過ごしてきました。

ところが最近になって、ある別件の要件の商品を探していたところ、本当にたまたまこの記事冒頭のクッションの画像が目に入りました。

その瞬間、これだ!と思いました。ここまで中心近くまで深く切り込みが入っているなら座る際に尾てい骨の位置合わせをする必要もなさそうだし、お尻に当たる背中側のクッションは厚めに見えるので椅子の座面に尾てい骨が届いてしまい当たる懸念もなさそうです。

本来の要件そっちのけで目に入った商品を即注文してしまいました。

こんな形状のクッションがあるなんて知ってから後、暇な時に改めて探してみると、類似品がピンからキリまであるわあるわ。一部界隈ではU字型クッションなんてジャンル名までついているのですね。
こんなにあるのに何年も出会えなかったとはなんて間抜けで愚かだったのかと思います。

入手してからふた月ほど経ちましたが、上半身の重さをおしりでしっかり支えつつ尾てい骨の痛みは一切ないので、お尻そのものが痛むまでずっと座っていられるようになりました。

以上、恥の記録とさせていただきます。

ここまでお読みいただいてありがとうございました。

2022年3月21日月曜日

フレンチプレスやメッシュドリッパーで淹れた後のコーヒー粉の処理

普段コーヒーを飲むなら、インスタントやペーパーフィルターでドリップすると、楽しておいしいコーヒーが飲めて満足なのですが、いかんせん、コーヒーの風味の重要な要素である脂分を味わうことが難しい飲み方です。

そこで、メリタ製のアロマフィルター(ペーパーフィルターにオイルを通すための穴が開いています)を使用するのも手ですが、ちょっと時間があるときなどは、時間と分量だけ守っているだけで何も考えなくていいフレンチプレスを使うと、手軽にコーヒーオイルも含めて味わうことができます。

ステンレスメッシュフィルターでも同様に、淹れる際のお湯の注ぎ方がちょっと技巧が必要ですが、こちらもコーヒーオイルを楽しむことができます。

しかし、フレンチプレスやメッシュドリッパーは、淹れるときはいいのですが、淹れ終えた後の掃除が格段に面倒くさいのが玉に瑕です。

ペーパーフィルターを使用していませんから、コーヒー粉を廃棄するのも手間がかかります。

そのまま下水に流すと覿面に詰まると思います。

三角コーナーに普段から不織布やストッキングタイプの水切りネットを使用している場合はそのままそこに捨ててしまって終了ですが、そうでない場合は、コーヒー粉のために改めて導入しようとすると、不織布やストッキングタイプの水切りネットは割とお高いので、結構ランニングコストがかかります。

そこで、私がお勧めするのが、裏ごし器、または、粉ふるい器です。

タンバリン型のこし器の例

流し台に置いて粉を流しだす先として使用するので、置いたときに安定しやすいタンバリン型やカップ型などで、かつ、水を流しても溢れてしまわないよう、口径や深さを広く深くとれる形状をお勧めします。(この理由により、いかに大型の茶こしでも、やや面倒と思います。)

コーヒー粉を排出する際に水を勢いよく流せるので、流しだす回数が減り、水の節約になるからです。材質はステンレスが扱いやすいと思います。

ステンレスメッシュの細かさは、お使いのフレンチプレスやメッシュドリッパーと同等程度であれば十分です。

某100円ショップで売られているステンレス製こし器が110円で直径が13.5cmで高さが5cm程度のタンバリン型で、粉の挽き具合が中挽きならお漏らしもないメッシュの細かさなので、気に入っています。

これだと、コーヒー粉がこぼれないので、キッチンペーパーやティッシュを敷く必要もなく、水流で紙がずれる心配をしなくていいのもメリットです。水気が切れたらコーヒー粉だけゴミ袋に捨てればごみ処理が終わるので重宝しています。

粉を捨てる際に少し水気が残っていてへばりついてしまっても、どうせごく少量なのですぐ乾きますから、乾いた後にゴミ袋の上で優しく払ってやればすぐに落ちます。

余談ながら、ベトナム式コーヒードリッパーのお手入れの場合にも便利かと思います。

以上、たわごとでした。

ここまでお読みいただいてありがとうございました。

2022年1月22日土曜日

ついにG Suite legacy無償版 G Suite(Google Apps の従来の無償版)が2022/7/1をもって終了へ

初っ端から恐縮ですが、以下タワゴトです。

表題の件、ついに来るべきものが来てしまいました。

メールによる案内はまだ来ていないのですが、メディア各社による報道で数日前に知りました。

こちらのGoogle Workspace 管理者ヘルプによりますと、7/1終了とタイトルに記しましたが、実際には5/1で終了します。

但し、5/1までに有料の Google Workspace サブスクリプションにアップグレードし、かつ支払情報を登録した場合は7/1まで無償で利用が可能ということだそうです。

思えば2011年に発生した東日本大震災における計画停電のため、UPSではカバーしきれない停電時間を、せめてメールサーバだけでもなんとかならないかと思って知ったサービスでした。

それ以来11年もの間、無償で利用させていただいて、感謝の念に堪えません。加えて、無償利用の期限以降も、料金さえ払えばこれまで通り、という点でも感謝です。移行、できません!!とか、移行できます、ただしこれまでのデータは全部チャラ!!、とか結構平気であるので、これはありがたいことだと思っています。

実は、有料化したら震災前の体制に戻せばイイヤという目論見で、すべて機材やサーバソフトウェアなどの準備は常に整えてあり、DNSのMXレコードの振り向け先を変更するだけにはしてはあるのですが、やはり11年という年月は長かったようです。

特に、私だけの事情だけでも、独自ドメインのメールアドレスといっても、GoogleさんからするとGMailの単なる1メールアドレスに見ているようで、例えばこのBloggerさんの登録情報を確認してみると、Google Appsで作成したメールアドレスが、がっちりGMailアカウント扱いされてしまっていました。

まだすべてを調べ切れていませんが、Googleさんのサービスにおいて、この「GMailアカウント(扱い)」ってのが結構重要な意味を持っている場合があるような気がします。

更に確認してみると、その他Google Play Developer ConsoleだのGoogle Cloud Consoleだのその他アレコレで契約メールアドレスを変更することがそもそも行えるのかどうかもわからない状況となっています。多分させてくれないサービスはいくつか出るだろうなとは思っています。

Android端末も、地味に困るのかなという感じです。

こういった数ある事情が、メンバーの数だけあるので、仮に移行するならばよほど慎重に行う必要がありそうです。

それに、GoogleさんのGMailの迷惑メールへの対応能力が素晴らしすぎて、自前で管理するメールサーバに戻したとして、情熱をもって管理しきれるのか、ということも考えなくてはなりません。

ま、要するに、見事にロックインというわけです。

2004年から使っているメールアドレスを、Googleさんにゆだねたまま安易に11年もの間、甘えてきたツケを支払う時がやってきたわけです。

自業自得ですね。

このままGoogleさんにお願いした場合、最安でも一ユーザ毎に税込み年額一人当たり\8,976円。無論人数分かかります。

自前での管理に戻す場合、まさかThunderbirdを今更皆にインストールしろ、なんていえません。WebメールはRainLoopでいいとして、カレンダーツールは?、あれは?、これは?、アップデートの監視は?、セキュリティの監視は?、トラブル対応は?、SPAMの対応は?、サーバが死んだら代替は?(新サーバ導入までの一時的運用ならGoogle WorkspaceかOutlook365でいいかも)

何の利益を生み出さないのにこの価格や労力を支払うことが、果たしてどうなんだという結論もあるかもしれません。その場合は、このドメインを(メール用には)捨てるという決断もありうるかもしれません。

今のところどうなるかわかりませんが、それにしても、本当にG Suite legacy無償版 G Suiteの提供は実にありがたかったです。

選択肢は多いので、ゆっくり考えたいと思います。

ゆっくり過ぎて5/1を過ぎても、お金さえ払えばこれまで通り、という点で大変安心です。
安心しすぎて、結局居心地がよくて支払い続けることになりそうな予感・・・

このような駄文をここまでお読みいただいてありがとうございました。

2022年1月15日土曜日

CentOS 7.9.2009上でHandBrakeCLI を1.2.2から1.5.1へ更新

気が向いたので更新してみました。

/usr/local/src/HandBrake-1.5.1に展開して作業する前提です。

目標はバッチ処理用CLIコマンドの生成です。

なお、HEVCとAACに関係しないにもかかわらずビルドの障害となるものは特に無理をして使えるようにするつもりはありません。

とりあえずビルドしてみます。

1
2
3
4
5
6
7
8
$ ./configure \
        --disable-gtk \
        --enable-x265 \
        --enable-fdk-aac \
        --disable-numa \
        --disable-nvenc \
        --disable-vce \
        --verbose

すると

1
ERROR: minimum required cmake version is 3.16.3 and /usr/bin/cmake is 2.8.12

早速cmakeが古すぎるとかでお冠です。
そこでcmakeをビルドします。ちなみに、HandBrake1.2以前からのアップデートの場合はnasmも必要になります。
さて、cmakeのビルドに必要なパッケージをインストールします。
1
2
3
4
5
6
7
8
# yum remove cmake
# yum install openssl-devel \
        keyutils-libs-devel \
        krb5-devel \
        libcom_err-devel \
        libselinux-devel \
        libsepol-devel \
        libverto-devel

無論、removeせずにalternativesでも何でもいいです。configureオプションにcmakeの場所を指定できないのが残念です。
$ wget https://github.com/Kitware/CMake/releases/download/v3.22.1/cmake-3.22.1.tar.gz -O cmake-3.22.1.tar.gz
ダウンロードしたソースを/usr/local/src/cmake-3.22.1に展開して作業します。
$ ./bootstrap 
$ make
# make install

/usr/local/bin/にcmakeができたので、改めてhandbrakeをビルドしたいところですが、その前にcontrib/ffmpegのビルドに失敗しますのでconfigureの前にcontrib/ffmpegのビルドオプションを変更して置きます。

/usr/local/src/HandBrake-1.5.1/contrib/ffmpeg/module.defsを編集して
--enable-libopus(49行目)を--disable-libopusに
--enable-libvpx(54行目)を--disable-libvpxに それぞれ変更してください。

なお、
libvpx-devel-1.3.0-8.el7.x86_64
libvpx-1.3.0-8.el7.x86_6
opus-1.0.2-6.el7.x86_64
opus-devel-1.0.2-6.el7.x86_64
がインストールされていてもcontrib/ffmpegのビルドが失敗しますが、これらはlibhbでも必要とされていますのでインストールが必要です。

ビルドに必要なコマンド及びライブラリのパッケージ名は以下の通りでしたのでインストールします。
1
2
3
4
5
6
7
8
9
10
11
# yum install \
         meson \
         ninja-build \
         libvpx \
         libvpx-devel \
         opus \
         opus-devel \
         turbojpeg \
         turbojpeg-devel \
         libvpx-devel \
         speex-devel
上記のパッケージ群をインストールしたら、改めてconfigureしてbuildします。
すると、
1
2
3
4
5
6
./libhb/libhandbrake.a(hb.o): 関数 `hb_read_preview.constprop.2' 内:
hb.c:(.text+0x5ba): `tjDecompressToYUVPlanes' に対する定義されていない参照です
./libhb/libhandbrake.a(hb.o): 関数 `hb_save_preview' 内:
hb.c:(.text+0x13c0): `tjCompressFromYUVPlanes' に対する定義されていない参照です
./libhb/libhandbrake.a(hb.o): 関数 `hb_read_preview' 内:
hb.c:(.text+0x1a90): `tjDecompressToYUVPlanes' に対する定義されていない参照です

とか抜かしてコンパイルに失敗します。
CentOS7のturbojpeg パッケージが古すぎるのですかね。

今回のケースではHEVCにもAACにもかすりもしないので、関数を呼び出している2か所をコメントアウトして、戻り値を格納する変数に!0を代入しておきます(この機能が必ず失敗終了するようにするため)。
/usr/local/src/HandBrake-1.5.1/libhb/hb.c の545行目と2441行目の二か所です。
tjAllocとかtjDestroyとかも退屈なら削ってもいいんでしょうが、私は超どうでもいいので古いturbojpegパッケージを入れたままにしてあります。

編集が終わったら、再度makeを続行しますと、HandBrakeCLIのビルドが完了です。

後は目障りなdevelなどのパッケージを削除して終了です。
お疲れさまでした。

HandBrake1.2.2に搭載のHEVC encoder version 2.9は今回の更新でHEVC encoder version 3.5+1-f0c1022b6となりましたが、同一オプションで同一ファイルをエンコードすると、エンコード速度は2fpsほど上昇しましたがエンコード後のファイルサイズが10%ほど増えてしましました。

超やっつけで申し訳ございません。

お読みいただいてありがとうございました。