エレクトロニクス

　このサイトを置いているレンタルサーバー会社さんから従来の10倍以上のアクセス処理性能！Webサイトの高速化・同時アクセス数の拡張を実現する「Xアクセラレータ」機能提供開始のお知らせ(https://www.xserver.ne.jp/news_detail.php?view_id=4753)というのが届いたので設定してみました。

　が、タイトルの通り失敗しました(原因は追記参照)。トップページは問題なく表示されましたけど比較的アクセスが多いcategoryや過去記事へのリンクなどがすべて404になり大急ぎで切り戻しました。さらに困ったのが設定メニューでOFFにしただけでは404から回復せずバックアップしておいた.htaccessを上書きしてようやく復旧しました。

　代わりというか、上記XアクセラレータをOFFにしようとしたところONにした時点で先週お知らせが来ていたExpiresヘッダで表示速度を向上！「ブラウザキャッシュ設定」機能提供開始のお知らせ(https://www.xserver.ne.jp/news_detail.php?view_id=4744)の機能も有効になっていたらしくOFFへの設定変更反映待ち(最大15分らしい)になっていました。改めて説明書きを読んでこちらの機能だけならばヘッダの送信だけで.htaccessを破壊することは無さそうですし、破壊しても再度上書きするだけなのでブラウザキャッシュ設定のみ推奨のすべての静的ファイルに適用しました。.jpgが多いのでそれなりに効くと思います。

というわけで、本日の設定変更は上記画像のブラウザキャッシュ設定のみにしました。

　翌日追記)この件についてメールが来ました。内容はほぼ本日PM3:40～PM10:10までのXアクセラレーター機能における特定条件下での不具合について(修正済み)(https://www.xserver.ne.jp/information_detail.php?view_id=4754)の通りでこのサイトは特定条件に当てはまったようです。.htaccessのコードなど(すべてコメント内のため)気にしていなかったです。念のために切り戻し用に保存したファイルを確認したところEUCでした。UTF-8ならば問題なかったらしいのでUTF-8N(BOM無し)に変換した上で再度上書きしました。正直、コメントの文字コードで挙動が変わるほうがおかしいです。

　よって、不具合が直ったと連絡されても不信感は拭えないためXアクセラレータの利用は当分見送ります。ついでに書くと、不具合動作時にキャッシュで404になった分のログが無かったのでキャッシュ分のログはもらえない(.jpgだけ持っていくようなアクセスが記録に残らない)懸念も残っています。

　非常に素早い対応には感謝しています(404の異常な多発で事故に気づかれたか？運用の監視能力は良さそうです)。ただ、新設定はもう少し検証してからリリースしていただきたいです。

　既に現行では古いモデルになっているはずのZE520KLに最近はよくアップデートが降ってきます。帰宅してから画面を見ると以下のお知らせが表示されていたのでVDSL回線に繋がっていることを確認してダウンロード。

あいかわらずシステムパフォーマンスやGoogleモバイルサービスが具体的に何を指しているのかは不明ですけどセキュリティパッチだけでも更新する必要があると思いますのでとりあえず更新しました。

更新作業は成功したようです。が、ここ最近の更新は毎度ですけど特に変わった感じはしません。ひょっとしたらETWSなどで変更が入っているのかもしれませんけど深く調べている時間もありません。

　台風21号の接近で出勤したと思ったら即帰宅指示で帰りました。PCのデータでも片付けたり下書きのまま放置している記事を処理しようと思っていたら午後になって突風が吹き荒れ14:00ごろには瞬断が連続しました。auひかりのVDSL回線が14:30頃の少し長い(数秒？)瞬断の後から通信不能となりモデムの電源をOFF→ONしても赤ランプのまま復帰しませんでした(建物ごとダウンした模様です)。幸い完全に停電したり携帯のLTE回線はdocomo/au共に切れなかったので固定回線(巻き添えでauひかり電話サービスを使った固定電話)だけがダウンしました。UPS無しでのデスクトップPCでの作業継続は危険と判断してシャットダウンしました。
　あちこちで停電などが多発していたようですし、固定回線が落ちただけで携帯回線でバックアップできていたのでジタバタせず復帰を待つことにしました。
翌日追記) DynamicDNSサービスのメールによると
Connection lost: 2018-09-04T14:30:08+0900
Connection resumed: 2018-09-05T14:09:22+0900
のほぼ丸一日ダウンしていたようです。

　台風やらなにやらで遅くなりましたがWP用テーマLuxeritasを3.3.1.1→3.3.2へアップデートしました。細かい変更(レベルダウンの修正*2点+仕様変更*1点)だけでこのサイトへの影響は無さそうです。詳細は開発元のLuxeritas 3.3.2 リリース(https://thk.kanzae.net/wp/release/t6079/)を見てください。

　ちなみに、このサイトでは以下の画像のようにXSERVERのmod_pagespeedはOFFにしています。

理由は画像の再圧縮が余計なお世話だからというのが最初で、より重要なのは”ONで必ずしも速くなるとは限らない”からです。こんなモジュール使わずとも(少なくとも旧サイトに比べて)十分速いと思っています。

　定時後にメールをチェックしたところ、珍しくはてなダイアリーについてのお知らせが届いていました。内容は、2019年春「はてなダイアリー」終了のお知らせと「はてなブログ」への移行のお願い(http://d.hatena.ne.jp/hatenadiary/20180830/blog_unify)の要約版でした。私は既にXSERVER+WordPress+Luxeritasに移行しているので直接の影響はありません。具体的なスケジュールがまだわからないため、はてなダイアリーの旧サイトはここへの移行のお知らせを載せたまま放置します。既にはてなダイアリープラスの料金を今年末まで払っているため削除するのは損した気がして嫌なだけです。
　むしろ、メールのタイトルを見た瞬間「やはり維持できないのか」というのが正直な感想でした。

　大阪北部地震(6/18)以来の緊急警報をZE520KL(イオンモバイルデータ専用SIMドコモ版)で受信しました。より正確に書くと夜中に受信していたようなのですけど朝起きて画面を見るまで気づきませんでした。以下の画像のように10回も受信していたようなのですが…。

　ちなみに今回はauのMNO VoLTE SIMが入っているSHF32では受信しませんでした。7月上旬の豪雨の時はSHF32だけ鳴ってZE520KLは鳴らず7/13にSIMをZE520KLにも取り付けましたのでSIMの有無で受信するかどうかが変わるのかもしれません。
　今のところ、SHF32とZE520KL両方ほぼ同時に警報を受信したのは大阪北部地震だけです。どうやらETWSでも地震の扱いは優先度が高いようなのですけど実際にどういったパラメータで送信・受信しているのかは分かりません。いずれにせよ今後も災害が多発してほしくありません。

　早い方は5月ぐらいに表示されていたようですが稼働時間が関係しているのか？私は今更ですけど1.3.2へアップデートしてしばらくしてから以下の注意画面が表示されました。

要するに台数分購入しているかどうかライセンス認証をしろということらしく、How to verify ethOS Panel with ethOS Panel Authentication Token (“token"):(http://ethosdistro.com/auth/)に書いてある手順で/home/ethos/token.authにviでトークン番号を書き込んだところもとのテレメトリ表示に戻りました。とはいっても、まだまだ気温が高すぎるため(電気代を転嫁できる)ヒーターとしての本格稼働は先です。

　気温が高すぎで7月上旬に掃除後の動作確認やcurlのチェックを行ってからethOSはずっと止めっぱなしにしていました。そのため、7/31にリリースされた1.3.2への更新作業が2週間ほど遅くなりました。(AMD?NVIDIAについては下の追記参照)GPUドライバ周りが中心でcurlはアップデートされていないようです。

　NVIDIA GPU向けにgloballed disabledという機能が追加されたようなので設定してみましたけど、既に外せるLEDイルミネーションは物理的に外している(GPU1 GK-GTX1070-E8GB/WHITE 2枚めの改造&実装(https://kadono.xsrv.jp/2017/12/20/3597)参照)ためか効果はありませんでした。ファンに付いているLEDはハンダで物理的に外すしか無さそうです。
ファンのLEDは点灯しっぱなし。

　追記)nvidia-smiコマンドでみるとNVIDIAのGPUドライバは384.90のままで更新されていないようです。私はまだ32bit版のWindows7も使っているのですがそのドライバは391.35で更新が止まっていてNVIDIAのSupport Plan for 32-bit and 64-bit Operating Systems(https://nvidia.custhelp.com/app/answers/detail/a_id/4604/kw/release%20390/session/L3RpbWUvMTUxMzkwNjMzMy9zaWQvZlV4aDdfUDZZVFZsNkFIQ0NYeHliSSU3RUJSekU2bzNPeXBLN2NzeWI3UFQ4eE1OdkxyaF90Zk1zbHpibGY2UGp0VnZBUUF0Z1JicW1xZzRZWDlDb2p4N0JOcnh3eXNoNGo0ZXlGaVlBRTdOeGtBdlByVVFsQVlZclElMjElMjE%3D)によると32bit版は2019年1月までで Critical security updatesも終了予定とのことです。日本語の記事ではNVIDIA，32bit版OSのサポート終了を予告。Release 390世代のGeForce Driverからは64bit版のみの対応に(https://www.4gamer.net/games/022/G002210/20171223001/)というのを見つけましたけどセキュリティアップデートが来年1月までという部分は翻訳されていません(ゲーマー向けのサイトなのでしょうがないでしょうか)。

　この前SHF32のストラップが壊れたと思ったら今度は3年ぐらい使っていたmicroUSB側のコネクタが接触不良を起こすようになりました。一瞬端末側が壊れたかと疑いましたけどSHF32<->MR05LNで差し替えて安いケーブル側が不良と分かり一安心でした。
新しいケーブル。
　プリウスにつけているカーオーディオMVH-790のUSB端子からmicroUSBの充電専用ケーブルでSHF32やMR05LNを充電しています。ケーブルの種類も豊富にあるのでいろいろ探しましたけど値段と実績から同じメーカーで1.0mの製品RC-UHCM10R2を購入しました。過酷な車内置きで3年保てばいいかというのと、充電専用でなければカーオーディオや端末がデータ通信をして反応してしまい毎回キャンセルするのが面倒だからです。
SHF32を充電。
早速動作確認をして特に問題は無さそうです。徐々にtype-Cが増えると思っているのですけど、まだ時間が掛かりそうです。

　プリウスから降りる時にSHF32を引っ掛けてストラップが本体側で切れました。ポケットからシート下に落ちていたのに気づかずそのまま引っ張ったようです。
本体側の紐が内側のプラワイヤーから破断。
　ストラップのケーブル本体はスチール製でよほどのことが無い限り切れたりはしないと思っていたのですけど本体との接続部は弱かったです。とりあえず、耐候性タイラップで応急処置をしました。

タイラップが太いので先端を若干削って本体に通しています。