寒波で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