TV用の同軸ケーブルを使用してネットワークを接続する

築15年程度の一戸建てに暮らしていますが、LANの配線はおろか、電源関係も配管を通してあるわけではないので、後からLANを引くことが困難。1Fと2FにあるTVでひかりTVを視聴するためWiFiで接続を試みたのですが、一応は写るが時折ブロックノイズが走る。そこで有線接続する方法を検討した。どうやらTV用の同軸ケーブルを使って接続する方法があるらしい。

国内ではTLCモデムという名称で販売されており、殆どの製品は最大でも100Mbps、実効速度は数十Mbps。4K映像を視聴するための必要な帯域幅が30Mbpsと考えると心許ない。DXアンテナがリンク速度1Gbpsまで対応する製品を販売しているが、それでも実効速度は300Mbpsに過ぎない。せっかく数万円をかけるなら、他の機器も有線にして安定化したいじゃないか。

海外だとPLCモデムはリンク速度2Gbps、実効速度は1Gpbs近い製品もあるのだが、いかんせん日本では動作しない(アース線も使って通信をするため)ので、結局のところ600Mbps程度にしかならない。しかも違法だ。

検索する事、数十分。MoCa(Multimedia over Coax Alliance)規格のTV用の同軸ケーブルを使ったLANにたどり着く。現在売られているMoCa 2.5対応の機器を使えばリンク速度2.5Gbps以上、実効速度は1Gbpsで接続する事が出来るという。国内メーカーはない。同軸ケーブルを使うので、PLCのように漏洩電波が問題になることもなく、法的な制約に引っかかる心配も無い。

というわけで早速個人輸入。国内にも販売する業者が居るが、国内サポートがあるわけでもない。米Amazonで買ってきた方が送料込みでも安い。

届いたのはこんなの。

電源、アンテナ線を接続する端子、LANを接続する端子、LED(電源、アンテナ線、LAN線)があるだけのシンプルな代物。図の通りに繋いでしばらく待つと、アンテナ線のLEDが点灯してリンクした。シンプルだ。

だが一応は暗号キーの設定ぐらいはした方が良いらしい。設定はWEBブラウザから行う。出荷時に固定のIPアドレスが振られているので、パソコンのローカルアドレスを固定で設定し、工場出荷時の初期パスワードでログインする。

二台とも同じ初期IPアドレスが振られている。アンテナ線でリンクアップしているとIPが重複してまともに設定出来ないので、1台づつ電源を入れて設定を行う。

暗号鍵は三箇所に設定する。適当に12~17桁の数値を入れる。ついでにIPアドレスもDHCPに変えてやる。これで全ての設定は完了。

検案だったひかりTVの状態もバッチリである。ついでに1Fの無線APにも有線で繋げてやると、1FでWiFiを使ったときの速度も大幅にアップした。

ステータス画面を見ると3.2Gbpsでリンクアップしている。なるほど、そういえばカタログには2.5Gbps以上と書いてあったなぁと。LAN端子が1Gbpsだから実行速度が1Gbpsを超える事は無いが、だいぶ余裕があるようである。速度が2Gbpsに落ちる分、ちょっとだけ安くなるMoCa 2.0機器でも十分だったかもしれない。

MoCa2.5の子機は最大で16台まで増やすことが出来る。私が住んでいる家は、各部屋にアンテナ線が来ているので、書斎にも子機を増やすと良さそうである。

ひとつだけ注意事項がある。使用している周波数が地デジと被っているのだ。同じ同軸ケーブルに地デジの信号も流している場合にはMoCa2.5を使えない。その場合は国内のTLCモデム製品を選択するしかない。

・・・と言う訳でアンテナ線は来ているが、LANを引くのは難しいというお宅には、MoCa 2.5がおすすめである。

バックグラウンドジョブをcronで実行する。(NextCloud+Docker)

ある日を境に、NextCloudにログインすると「ストレージ容量がいっぱいです~」と言うエラーメッセージが表示されるようになった。どうも原因はバックグラウンドジョブが正常に起動されていなかった為のようで、この機会にcronから起動するようにシステム構成を変更することにした。

NextCloudは公式のDockerイメージを使用しているので単純にcronから実行する事はできない。dockerコマンドを使ってcron.phpを実行する命令をcronに登録することにする。

以下のコマンドを実行して編集画面を表示。

sudo crontab -e

以下のコマンドを登録して5分おきに実行。

*/5 * * * * sudo docker exec --user www-data [docker container name] php /var/www/html/cron.php

TP-Link Deco X50 + ひかりTV

結論から言うと動作しない。Deco X50をブリッジモードにするか、Deco X50でIPv6をパススルーに設定すれば動作するような気がするが、実際には動作しないません。

ひかりTVはTV放送データを効率よく配信するためにIPv6 multicastを使用しています。つまり「ひかりTVに対応出来る」=「IPv6 multicastを適切に扱える」に限りなく近いわけです。

TP-LinkのDeco X50は、ルーターモードでもブリッジモードでも、IPv6のファイアウォールがデフォルトで有効になっており、このファイアウォールを無効にする事ができないようです。このファイアウォールによってIPv6 multicastの通信がドロップされているように推測されます。ファイアウォールのルールを設定する画面もあるのですが、設定の制約が厳しく、マルチキャスト通信を許可するような設定を入力する事ができません。マルチキャスト通信は宛先IPv6アドレスがFF00::/8となりますが、このようなIPアドレスの入力を受け付けないのです。

設定に使用するスマホを英語モードにすれば入力できる可能性はあります。ただTP-Linkの英語版掲示板を見る限り、IPv6 multicastが通らないといった相談は度々あがっており、公式アカウントからのログ提出依頼もついていますが解決には至っていません。本質的にIPv6 multicastはMesh WiFiと相性が悪いのかもしれません。

・・・というわけで、あえてメッシュWiFiは使わずに、WiFiルーター+WiFiエクステンダーで構成するのが良さそうです。

寒波でEVの充電できずに立ち往生した話とか

米国の寒波でTESLAの急速充電器が動作しなくなり、充電待ちのEVが電欠で動作できなくなり行列を作っているとニュースになっていました。そういえば日本でも夏に充電できなくなった急速充電器とかありましたね。この手の話し、たまたまEVがニュースソースとして注目されやすいからニュースになっているだけで、-30℃なんていう寒波の中では、EVの急速充電器に限らず色々な機械が止まっているはずなのです。

というのも、世の中の機械は-30℃~40℃でしか動作保証をしていないことが多いのです。例えば「やはりハイブリッドカーが最適」という発言をちらほら見かけるけど、プリウスのマニュアルには-30℃以下だとハイブリッドシステムが起動出来ない場合があると明記されています。なんならガソリンエンジンも通常で-15℃、寒冷地仕様で-30℃を下回ると起動できない場合があるそうです。そもそも内燃機関は急速充電器が止まってしまうような低温下では、ヒーターで温めてからで無いと始動できないのです。

ガソリンスタンドの給油機もやっぱり-30℃~40℃だったりします。ディーゼルだともっと深刻で、-10℃~-30℃ぐらいで軽油に含まれる高分子量の成分が分離して固形化してしまうそうな。灯油の凝固点も-20℃~-46℃なので、燃料が固まっているから石油ストーブも動きません。じゃ北極圏に近いような場所ではどうやって暮らしているのかと言えば、24時間暖房を耐えさせないようにしているわけです。

同様の事は高温時にも起こります。日本でも夏の気温が上がり35℃を超える猛暑日が度々おこるようになりました。直射日光が当たるような場所なら40℃を超えても不思議ではありません。気象条件が変わって寒波が襲来したり、猛暑が到来したり、度々おこるようになっている以上、インフラ関係の機器だけでも-40℃~50℃ぐらいまで動作するように考えなければならないのかもしれません。

某高校の入試申請で話題になってたメールサーバーのこととか

神奈川県の高校入試出願システムで障害、志願者のGmailにメール届かず – 現在は解消

神奈川県下の中学三年生は約7万3千人。予備のメールアカウントも登録しているから、全員に一度にメールを送信しようとすると、約15万通のメールを一度に送信しうるメールサーバーという話になる。

件のメールサーバーではMXテーブルにIPアドレスを指定していたことが原因で、SPFやDKIMが機能していない。その状態で大量のメールを送信したためレピュテーション(評価)が低下、不正中継サーバーと判断されて、メールを拒否されるようになった。Googleが制限しているためメールを受信出来ないという表現は確かにその通りだが、不正メール対策として正しく設定していないメールサーバーからのメールを受信しないのはGoogleに限らず多くのベンダーで行っている基本的な対策だ。正しく設定出来ていなかったメールサーバー側が全面的に悪い。

では正しく設定出来ていたら問題無くメールを送れたかというと、実は送信出来なくなった可能性が高い。新規にドメインを取得して間もなかったり、普段より極端に多くのメールを送信した場合にも、レピュテーション(評価)が低下する。これはSPFやDKIMによる認証が行われるようになる以前から行われていた不正中継対策だ。

もし独自にメールサーバーを立てるなら、ユーザーの利用が集中しないように利用開始時期を分散させつつ、レピュテーション(評価)の状態を確認しながらメールの送信数を調整、時間当たりに送信するメールを少しづつ増やしていく必要がある。運用に常に人を張り付けて微調整が必要になる。そもそも1~2月だけ大量のメールを配信するというのはレピュテーション(評価)を下げやすいので、年間通してメールを送り続けるような仕組みまで考えておく事を求められる。

実際には上記のような運用は手間がかかるし、バッドノウハウの塊なので経験がないものが実施するのは難しい。そこで通常は大量のメール送信を代行する、メール配信事業者に頼むことになる。

1月~3月だけ数十万通のメールを送信するシステムで、自前のメールサーバーから配信しようとしている時点で、発注者側にも受注者側にも適切に設計を出来るIT知識が無かったことがうかがわれる話だったりする。

参考:Google メール送信者のガイドライン

Nintendo SwitchのSDカードを容量の大きなものに交換する

Nintendo Switchに使っているSDカードの空き容量が不足してきたので、サイズの大きなSDカードに交換したいと思う。Nintendo SwitchのSDカードはFAT32フォーマットを採用していて、2TBのSDカードまで対応している。パソコンで単純にコピーできれば早いのだが、Windowsでは32GBを越えるFAT32パーティションを作成することが出来ない。そこで使用するのは以下の二種類のツール。作業を始める前にダウンロードしてインストールしておく。
HDD Raw Copy Tool
MiniTool Partition Wizard 無料版

SDカードリーダーが2台有ればMiniTool Partition Wizardで元となる容量の小さなSDカード、新しい容量の大きいSDカードに直接コピーできる。だがその為だけにSDカードリーダーを追加で用意するのも勿体ない。ここではHDD Raw Copy Toolを使ってSDカードを複製した後に、MiniTool Partition Wizardでパーティションサイズを変更する手順で作っていく。

コピー元SDカード⇒ディスクイメージファイル

最初にHDD Raw Copy Toolを使用してSDカードからディスクイメージフィルを作成する。HDD Raw Copy Toolは日本語化されていないので日本語のフォルダ名やファイル名は文字化けする。保存先などには日本語名が混じらないようにする。

SDカードをリーダーに挿した後にHDD Raw Copy Toolを起動すると認識しているディスクの一覧が表示されるので、コピー元となるSDカードを選択して、Continueをクリックする。

次にコピー先となるディスクイメージファイルを選択する。認識されているディスクの一覧の最後にFILEと言う項目があるので、それをダブルクリックする。保存先の選択ダイアログが表示されるので、保存先のファイル名を入力する。

コピー先となるディスクイメージファイルを指定したら、Continueをクリックする。

以下のような確認画面が表示されるので、Startをクリックして、ディスクイメージファイルの作成が終わるのを待つ。コピーが終わったら100% completeと表示されるので、HDD Raw Copy Toolを終了する。

ディスクイメージファイル⇒コピー先SDカード

コピー先SDカードに差し替えて、再びHDD Raw Copy Toolを起動する。最初にコピー元を選択するが、今度はディスク一覧の最後にあるFILEを選択する。FILEをダブルクリックして、先ほど作成したディスクイメージファイルを指定して、Continueをクリックする。

次にコピー先を選択するので、ディスクの一覧からコピー先となるSDカードを選択して、Continueをクリックする。

コピー確認画面でStartをクリックする。コピー先のパーティションを上書きして良いか警告が表示される。ここでは警告を無視して「はい」をクリックして先に進める。

パーティションサイズの変更

この時点では、コピー先SDカードのパーティションサイズは、コピー元SDカードと同じになっています。この後に、MiniTool Partition Wizardを使用して、コピー先SDカードのパーティション拡張を行います。

MiniTool Partition Wizardを起動してドライブの一覧から対象のSSDにあるFAT32パーティションを選択したあと、右側のパーティション変更からパーティション拡張をクリックします。

パーティション拡張のバーを一番右側までスライドさせ、パーティションサイズを最大まで拡張します。

最後に右下の「適用」をクリックしてパーティションの拡張を実行します。

この手順で、キャプチャした画像はコピー元のSDカードが32GB、コピー先のSDカードが64GBになっていますが、最大2TBまで制限無く拡張できるはずです。

緊急地震速報の誤報報道の滑稽さ

緊急地震速報(警報)で震度7の警報が出たにもかかわらず、有感地震が無かったことが誤報として問題視されている。同様の誤報は数年おきに発生しており、今回が初めてと言う訳でもありません。

緊急地震速報の仕組み自体は気象上の緊急地震速報(予報)発表状況にかなり詳しく記載してあり、なぜ誤報が起こるのかまで記載されています。

緊急地震速報は次の様な仕組みになっています。

2箇所以上の地震計で、地震のP波と思われる振動を捉えると、震源地や最大震度を予測して、その結果を緊急地震速報(予報)として関係諸施設に送信します。一回計算して終わりでは無く、新たな地震計のデータを加えて何度も予測計算を繰り返し、そのたびにより正確な緊急地震速報(予報)を送信します。予測される最大震度が4.5超える場合には緊急地震速報(警報)を送り、スマホからおなじみの警報音が鳴り響くことになります。

ここでお気づきと思いますが、2箇所の地震計の観測データから震源を計算したとしても、その震源は帯状の範囲としてしか予測できません。正確に震源を特定するなら最低でも3箇所、出来れば4箇所以上の地震計のデータが必要になります。それにも関わらず2箇所の地震計のデータで震源を計算しているのだから、誤報が発生して当たり前のシステムなんです。

緊急地震速報は全国に約1700箇所ある地震計を使用しています。日本の陸地面積は378000平方Km。仮に地震計が一様に設置されているとしたら、約222平方Kmに1箇所、およそ15Km間隔で地震計が設置されています。 P波が地中を伝わる速度は約7Km/sだから、3箇所目の地震計からのデータを待つなら最大で2秒程度遅れることになります。現状でも緊急地震速報警報が伝わってから、S波到達までの時間的余裕は数秒~数十秒でしかありません。3箇所目のデータをまつために2秒遅らせたら、緊急地震速報は本震に間に合わず、存在意義を失います。そのため不正確なのを承知の上で、2箇所に地震計のデータで処理を行っているわけです。

緊急地震速報の予測震度が大きくずれる原因はある程度わかっています。
・震源が陸から(地震計から)大きく離れている場合
・地震発生と同時に、周辺の地震計が地震以外の震動や電気的雑音を拾った場合。
・たまたま複数の地震が同時に発生した場合。
・地震計の故障などにより、使える地震計が少ない場合。

今回は大きな地震発生から間もないため頻繁に地震が起きており、また地震計も被害を受けているため使える地震計が少なく、誤報が発生しやすい条件下にあります。

緊急地震速報は、ある程度の誤報を許容する事で、より早く警報を出せるようにしたシステムです。誤報の発生を許容する警報システムそのものを問題視する議論ならわかります。そこを無視して、緊急地震速報に誤報の再発防止だの、誤報を出したことの管理責任を求めたりというのは、エンジニア目線だとわりと滑稽な話です。

2024年1月1日16時移行、13回の緊急地震速報の警報を発表している。震度5を越えても警報が出なかったのが3回になっている。人命や減災を意識するなら、実際の震度が低いにもかかわらず発報してしまった場合よりも、実際には震度5を越えているのに発報できなかった事を問題視するべきはずだ。だが、逆の事をしているあたりが、リテラシーの低さを物語っています。

NextCloudで”一部のファイルは整合性チェックに合格していません。~”

dockerでNextCloudを動作させて居るのですが、バージョン28.0.1への更新移行、以下のエラーが発生する状態になってしまった。監理者設定の画面を開くと、以下の通りに表示されている。

“無効なファイルのリスト”のリンクを開くと、整合性チェックでエラーとなったファイルのリストを確認出来る。

Technical information
=====================
The following list covers which files have failed the integrity check. Please read
the previous linked documentation to learn more about the errors and how to fix
them.

Results
=======
- core
	- INVALID_HASH
		- core/js/mimetypelist.js
	- EXTRA_FILE
		- core/img/filetypes/dwb.svg
		- core/img/filetypes/drawio.svg
Raw output
==========
Array
(
    [core] => Array
        (
            [INVALID_HASH] => Array
                (
                    [core/js/mimetypelist.js] => Array
                        (
                            [expected] => 550ab566d30693bfa24ec4b15d9df87731ae8a3be8f79dabf94757e5b8b20eec6e4b678f17af1718297f2872f6b04519eeb024d1dff11947f29da431c7f11201
                            [current] => 301654cbbe168b8723530db88fd2e40ad688f4e6b0bdaeade5b4fe34bd94d9d3cfe760821e97dc792e585d4b6ccff838597bfd46466bb07d30ff84df4cb79518
                        )
                )
            [EXTRA_FILE] => Array
                (
                    [core/img/filetypes/dwb.svg] => Array
                        (
                            [expected] => 
                            [current] => 43731dd5f17a048112ea5109b40b02ec019b3ee2324385a0f448e3bd2264cb13dc160ab018d893f92f8e2f168fd09009b51578c8c6b97a02a1617c67ac087701
                        )
                    [core/img/filetypes/drawio.svg] => Array
                        (
                            [expected] => 
                            [current] => 92e0974cf869bf8ab969c3442dc2b80d55fde36441d22924db74916a06b407520aa2a9dc39336f9157195ebede697ffac0e639360879255ab91932d406e1897d
                        )
                )
        )
)

core/js/mimetypelist.jsがバージョン不整合を起こしていることが分かるので、NextCloud(https://nextcloud.com/changelog/)から28.0.1のbzip2ファイルをダウンロードし、nextcloud-28.0.1\nextcloud\core\js\mimetypelist.jsをhtml\core/js/mimetypelist.jsに上書きする。

html\core/img/filetypes/dwb.svg、html\core/img/filetypes/drawio.svgはexpected(必要なファイル)のハッシュ値が空欄である事から、そのまま削除する。

監理者設定の画面を開き”再スキャン”をクリックすると、再度整合性チェックが行われる。これで”一部のファイルは整合性チェックに合格していません。~”の表示が消えた。

“468 error in the logs issu”の方も気になるのでログを確認すると、”Temporary directory /var/www/html/temp is not present or writable”との表示が並んでいた。

以下のコマンドを実行してtempフォルダを作成する。

sudo mkdir .\html\temp
sudo chown www-data:www-data .\html\temp

糞コードのリリースは許されるのか?

糞コードをリリースすることの是非みたいな発言をXで見かけたので私見を纏めておく。

糞コードの問題は、理解するのに時間が掛かるとか、改修が困難とか、バグを出しやすいとか色々と言われるけど、纏めるとランニングコストが高いと言うことになる。単純にコードの保守性だけの問題では無くて、処理が最適化されていないために多くのコンピューターリソースが必要となるといった事も含まれます。

ランニングコストが高いと何が不味いのかを、簡易的にグラフにしてみた。

時間経過とともに機能が追加されたりデータが増えたりするため、システム規模は日に日に大きくなり、累積コストは指数的に増加していきます。糞コードは初期コストが安くても運用コストが高くなります。対してクールコードは初期コストが高くても運用コストが低く抑えられています。初期は糞コードの方が運用コストが低く済んでいますが、いずれクールコードと逆転するわけです。

糞コードの収益性が悪いだけなら良いのですが、場合によっては採算ラインを超えてしまう事が起こります。独占企業なら問題にならないかもしれません。ですが競合他社が居る場合、運用コストの高さは長期的にビジネスの継続を危うくするわけです。

糞コードは後で書き換えれば良いという主張もあります。ビジネスとして継続する為に、システムを再構築してクールコードに書き換えるわけです。ですがこれは開発コストを二重に負担しているので、コストが大幅に増えて収益を圧迫します。

特に新規のビジネスの場合には資金的にも人員的にも余裕がないため、実際には糞コードの再構築は後回しになりがちです。再構築が遅延すると、その間にコードもデータも増えていくため、再構築にかかるコストがより大きくなります。最悪の場合、再構築を行うと採算ラインを越えるため出来ないが、このままだと運用コストが採算ラインを越えるため放置も出来ないという、詰んだ状態に陥るわけです。

以上のことから、糞コードのリリースについて三行に纏めておく。

  • 時間的な制約から糞コードをリリースする場合はあり得る。
  • だが糞コードは最小限にし、速やかに改修しておく必要がある。
  • 糞コードの放置はビジネスを終わらせる時限爆弾となり得る。

画像ファイルを開こうとすると「ファイルシステムエラー ファイルを読み込めません」となる。

MicrosoftフォトなどのMicrosoft Store アプリが動作しなくなると中々に厄介です。昔同様の状況になったときには修復できずに終わったのですが、今回はなんとか修復できたので実行した作業を纏めて起きます。

DISMコマンドおよびsfcコマンドでコンポーネントストアの修復を試みます。管理者権限でコマンドプロンプトを開いて、以下のコマンドを順番に実行します。

DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth
sfc /SCANNOW

次に設定→更新とセキュリティ→トラブルシューティング→追加のトラブルシューティングからWindowsストアアプリを選んでトラブルシューティングツールの実行を行います。

設定→アプリ→アプリと機能からMicrosoftフォトを選択して詳細オプションを開く。終了、修復、リセットを純に実行する。

Microsoftフォトが起動するようにはなりましたが、アプリと機能に表示されないなどどこか動作が不自然なのでPowershellからMicrosoftフォトをアンインストールします。

管理者権限でPowershellを開いて以下のコマンドを実行します。

Get-AppxPackage Microsoft.Windows.Photos | Remove-AppxPackage

Microsoftストアを開いてMicorosftフォトを再度インストールします。

参考:ファイルシステム エラー-2147219196の対処法7つ