39号機稼働開始(34号機更改リプレース)

24、25号機に続き、34号機も更改しました。39号機となりました。

34号機は紹介のページにもありますが、元々建造計画がなく、障害対応として急造したマシンです。予算も無かったので暫定構成と割り切り、ケース以外は寄せ集めのパーツで建造しました。暫定と言う割にはどこぞの某元暫定CEO(故人)の如く3年以上運用していましたが、建造当初から更改なりリプレースなりすることだけは決めていたマシンです。

39号機は37、38号機の異母兄弟機みたいな構成で、ケースとSSDは異なりますが、マザーボード、メモリは同一という構成です。

ケース・電源

ケースはSilverstoneのSST-SG13Bです。

先代の34号機のLian-Li PC-Q21のフォルムは結構気に入っていたのですが、PC-Q21は耐タンパ性がゼロなのが課題でした。色々考えましたが、買い換えたほうが安いのでSST-SG13Bにしました。

SST-SG13Bが高耐タンパかと言うと微妙ですが、ロックされたSST-SG13Bは、ノーガードに近くてツールレスでSSDを持っていけるPC-Q21に比べれば面倒です。

曲がりなりにもロック出来て、PCI/PCIeカードが付けられる小型ケースは少なく、(19号機で採用している)SST-SG05BとSST-SG13Bとその後継機しかありませんでした。19号機と全く同じケースを約15年も経ってまた買うのも芸がありませんし、SST-SG16などは交流電源専用みたいな構成で、ACアダプタ運用がしにくいと感じたので、SST-SG13Bとなりました。

SST-SG13BはATX電源ですが、搭載しているN100DC-ITXはACアダプタ直結構成なのでそのままだと電源部が開口します。それはまずいのでM8のDCジャックが入るホールが付いた、アルミ製のグリルパネルを入れてあります。この手のDCジャックを取り付けできるパネルは、昔ならOliospecで買えたのですが、今はOliospecでは売ってないので海外から通販で買いました。

電源は37・38号機と同じGST90A19-P1Mです。

先代の34号機は秋月で売ってたGo Forward (GF)社製のGF65I-US1934という19V 3.4Aの60W電源を使っていました。秋月のGF社製の電源はまぁまぁ静かで可もなく不可もなくという感じですが、秋月のDC電源のバレルプラグは殆どが2.1/5.5mmなのでそのままでは2.5mm/5.5mmのバレルジャックでは挿さりません。なので変換アダプタを咬ませていましたが、この変換アダプタが地味に鬱陶しいので37号機や38号機と合わせる形でACアダプタごと取り替えました。

ケースこそ異なりますが37号機、38号機同様ゼロスピンドルのファンレス機です。

マザーボード・メモリ

マザーボードとメモリは37、38号機と全く同じです。N100DC-ITXにCFD Crucialの32GBが入ってます。32GBは用途的には過剰ですが、メモリとしては予算内だったで37号機や38号機と合わせてあります。

CFD Crucialの32GBは37号機や38号機と同じもので、2枚セットの片割れを使っているのも同じです。39号機のもう片割れは予備のマザーボードに実装しています。

SSD

SSDはTeam CX2 256GBの1台構成です。

39号機はデータ(所謂ユーザデータ)をほとんど持っていないので耐久性はあまり考慮せず安価なものを採用しています。37号機や38号機はシステム用とデータ用(/home用)としてSSDを2台積んでますが、39号機はシステム用とデータ用のSSDを分けていないので1台構成です。

39号機は元を辿るとCentOS5で運用していた14号機から派生したマシンで、その派生機・後継機である29-30-34号機ではCentOS7が入ってました。そのためその後継の39号機でもRed Hat Enterprise Linux(RHEL)系統のOSであるRocky Linuxを入れています。

RHEL系はOSのメジャーアップグレードが難しく、メジャーアップグレードは事実上SSDを入れ替えて新規インストールでしか対応出が来ないので、安いSSDにしました。また、39号機はVPNルータ専用機で何かべつの用途を兼任させるつもりが無いので250GBもあれば必要十分です。先代の34号機も2020年新造ですが、SSDは当時にしてすでに8年落ちの2012年製のIntel 320 シリーズのSSD入れてましたしね。どうでもいいですが、このIntel 320シリーズは160GB、300GB、600GBという今にしてみれば結構珍しいラインナップです(参考リンク)。

OS

OSは前述の通り、Rocky Linux 9.4です。最近はRHELでも個人用途なら16本ぐらいならタダで使用可能です。なのでRHELも少し考えましたが、ライセンス管理が面倒なのでやめました。まぁ正確に言うと管理が面倒というより、管理するものを増やしたく無いのでフリーのRocky Linuxにしました。Alma Linuxと悩みましたが、Alma Linuxは実家の28号機に入れることにしました。

このマシンはOpenVPNとNTPしか動かさないので最小インストールにして、EPELリポジトリからdnfでOpenVPNを入れました。

RHEL8系は知りませんが、RHEL9系のEPELのOpenVPNの設定は/etc配下がserver(/etc/openvpn/server)とclient(/etc/openvpn/client)に分かれています。systemctlで呼ばれるUnit名で、設定ファイルを探すディレクトリが変わります。

openvpn-server@hogehoge.serviceでサービス起動すると、/server(/etc/openvpn/server)の設定ファイル(ここではhogehoge.conf)が読まれ、openvpn-server@hugafuga.clientでサービス起動すると、client(/etc/openvpn/client)側の設定ファイル(ここではfugafuga.conf)が読まれます。

例えば、systemctl openvpn.server@y17でOpenVPNを起動すると、/etc/openvpn/server/y17.confを探しに行くようになってます。同様にsystemctl openvpn-client@y17でOpenVPNを起動すると、/etc/openvpn/client/y17.confを探します。

まぁ、openvpn-server@.serviceで起動しても、openvpn-client@.serviceで起動してても、どちらもUnitファイル内のExecStartでは(引数は若干違うものの)同じ /usr/sbin/openvpn が呼ばれています。なので、実際のOpenVPNの動作(クライアント動作かサーバ動作か)に関わらずをどっちにどっちを入れても動くは動きます。実際、39号機は28号機に繋ぎにいくクライアントモード(tcp-client)で動作していますが、設定ファイルは/etc/openvpn/server/に放り込んであります。

と、言うか、サーバとして動作する設定を/etc/openvpn/server/に入れてopenvpn-serverで起動したからといって、firewallやsemanageをいい感じにやってくれたりすることは一切ありません。なので、個人用なら好きな方に入れてくださいって感じがします。

ちなみに、Alma Linux 9.4のEPELでも同じように分かれています。

NIC

このマシンはPCIeスロットにNICを増設しています。増設NICを刺すために37号機や38号機とは異なったケースを採用しています。

NICはtp-linkのREALTEKチップのやつです。所謂蟹チップです。ギガ蟹です。このNICでNTTのNGN(IPoE)のIPv6網に接続して、実家とLayer 3 VPNを組んでいます。

ギガ蟹使ってるのは消費電力・発熱の問題もありますが、正直蟹でも十分なので蟹にしています。まぁ、蟹がいいと言うより、(私の場合は)Intelの値段なりの価値を見出せなかったというのが正しいです。Intelは良いかもしれませんが、(自宅のブロバン環境がクソなのもあって)私はRealtekで特に困っていません。

蟹NICは上級者には割と不評なんですが、最近のギガ蟹であれば殊更に不安定や遅いとかはまずありません。ただ、Realtekのドライバはハズレがまじっており、ものによっては速度以前に不安定だったりします。今時RealtekのドライバはOSで標準で添付されてたりしますが、特にFreeBSD添付のものはクソでしたね。

あと、RTL8111系やRTL8168系のチップはRHEL7系とかだと何故かRTL8169系のドライバが入ることがあります(参考リンク)。何故かRTL8169系でも8111や8168がそれっぽく動くんですが気持ち悪いです。またドライバが良くてもオフロード系(gsoやgro等)を正しいチューニングしないとまともに速度出ないことがあります。難しいと言えば難しいチップです。

この辺を勘案すると、上級者に不評な蟹NICですが、運用は自体は上級者向けですね。値段は断然素人さん向けなんですが、ポン付けでもまぁまぁ動くIntel製の方が(個人的には)素人さんには無難だと思います。

ちなみに、M.2 E Key (iCNV Wi-Fi用のM.2はEキー)から有線Ethernetを生やす怪しいNICを買ったのですが、MACからして怪しかったので使うのをやめました。

チューニング

37号機や38号機同様、電力設定はチューニングしています。チューニングは37号機と同じでPL1=10W, PL2=25W Autoから、PL1=6W, PL2=10W 10sにしています。この状態で44℃前後です。

39号機はファンレスですがケースがスカスカガバガバなためデフォルトでも実は大きな問題はありません。そのため別にチューニングしなくても温度的には全然問題ありません。ただ、N100DC-ITXはコイル鳴きが結構喧しく、スカスカガバガバなケースではコイル鳴きの音が結構よく通ります。

コイル鳴きは電流変動が小さい方が音を小さくできるので、発熱よりもコイル鳴き対策で電力設定をチューニングしています。性能的にはもっと制限を厳しくしても大丈夫なんですが、設定値を管理(記憶)したくなので37号機や38号機と同じ設定を入れています。

そのため、ケースは触っても動いていることがわからないぐらいの温度になっています。

建造所感

39号機はOpenVPNを積んだルータ相当のサーバですが、正直OpenVPNを動かすだけなら今や独立したx86のPCでなくてもOpenWrtを積んだBBルータやNanoPiなどのSmall Board Computer(SBC)などでも充足出来ると思ってます。

ユニットコスト面でもx86で新造すると200USD前後(30k円)かかるのに対してSBCなら大体170USDぐらいでなので、x86で作るメリットってなんだろうと思わなくはありません。まぁ、もう組んでしまいましたけど。

38号機稼働開始(25号機更改リプレース)

先日(と言いつつ結構経ちますが)、24号機に続き、25号機の後継として38号機の稼働を開始しました。購入後約11年弱、運用自体は2016年からですが、トラブルはありつつも8年近い運用にピリオドを打ちました。

38号機の主な構成

Silverstone SST-ML10のケースにASRock N100DC-ITXを組み込んだものです。メモリはCFD Crucial DDR4-3200の32GBx1です。これにMeanwellのGST90A19-P1Mという19V 90WのACアダプタで電力供給しています。

先日稼働した37号機とはSSDとOSを除き全く同じ構成です。というか、37号機と38号機でハードウェア的に違うのはSSDだけです。それ以外はブザーやSATAケーブル、後から付けた縦置用のゴム脚に至るまで同一構成です。

置き換え元となる25号機(と24号機と34号機)はすべてゼロスピンドル機で、静粛性と耐衝撃性の向上、並びに通常運用中のメンテナスフリー化を志向したマシンです。38号機もこの志向を引き継ぎいでゼロスピンドル機としました。Twitterでは120mmファンを搭載しようかと呟いていたのはこの38号機のことなんですが、メンテナンスフリー化は捨てがたいのでゼロスピンドルで組みました。

ケース・電源

ケースは前述の通りSilverstone SST-ML10です。前述の通り37号機と全く同じです。シリアル番号までほぼ同じで、最後の桁以外は全く同じです。37号機と同じ構成ですが、37号機側が流用で38号機側オリジナルです。

プラットフォームはMini-ITXを採用し、電源もボードタイプやpicoPSUいずれでも行けるように配慮した構成にしてあります。これは、故障が頻発してマザーボードの予備をすべて失っても最悪その時に売ってるMini-ITXのマザーボードを使えるようにしてあります。また、2.5インチSSDを2台搭載出来る構成にしてあります。

電源は実家で稼働実績にあったMeanwell社のGST90A19-P1Mです。37号機と同一機種で、37号機同様にDigikeyで買いました。Efficiency Level VI対応です。

カタログスペック上の効率は90%です。Efficiency Level VIが嘘でないなら、90Wクラスの電源であれば少なくとも87%はある筈です。最近流行りのGaNトランジスタを使用しているかは不明です。GaNトランジスタの採用を謳ってる機種と比べると90Wという容量の割に嵩張ります。ただ、表面積が大きい方が放熱、つまり寿命面では有利です。まぁ、とは言え、13W程度の消費電力でも電源が入っていることがわかる程度には発熱します。

GST90A19-P1Mはファンレスですが本体に青色LEDの通電ランプがあり、これがなかなかの光量で光ります。夜中は目に刺さるのでLightDimの減光用のシールを2枚重ねで貼っています。

マザーボード・メモリ

マザーボードはN100DC-ITXです。マザーボードも37号機とは製造番号が一つ違いのものを使用しています。ちなみに製造番号は隣り合ってましたが、MACアドレスは第5 WORDは同一だったものの、第6 WORDは隣り合っていませんでした。

37号機でも買いた通り、マザボはデスクトップ用のDDR4-DIMMを1枚だけしか搭載出来ないので、CFD Crucialの2枚セット品を買ってそのうちの片割れを使っています。もう片割れは37号機で使っています。

SSD

SSDは2台構成なのは37号機と同一ですが、2台とも37号機とは異なるモデルを搭載しています。

38号機のSSDはTranscendのSSD470K (以下、SSD470K)というシリーズの1TBと250GBを採用しました。これは産業用で、書き込み寿命が250GBモデルは591TBW (推定)、1TBモデルでは2,365TBW (推定)ある製品です。(DPDW2.16@3年から計算)。

コンシューマー用のTBWは250GBのSSDで100〜200TBW程度、1TBだと400〜600TBW程度で、DPDW@3年の値は大体0.7前後ぐらいが相場なのでコンシューマ用と比べると2.5倍以上の書き込み耐性があります(2024年現在)。

Transcendの産業用のSATA SSDには他にSSD422Kというのがあり、こちらも検討はしました。比較は下記です。SSD422KはDPDWが2.6とちょっと高いぐらいですが、アクティブ時の消費電力が470Kの約1.5倍、値段が470Kのざっくり2〜2.5倍と色々コストが高いので470Kの方を買うことにしました。ちなみにSSD470Kは112層の3D-NAND構成ですが、SSD422Kは2D-MLC NAND構成みたいです。その所為か定かではありませんがカタログ上のIOPSはSSD422Kの方が低いです。

Transcend SSD470Kの消費電力、TBW
https://jp.transcend-info.com/embedded/product/embedded-ssd-solutions/ssd470k-ssd470k-i (2024.06.09閲覧)
Transcend SSD422の消費電力、TBW
※2D-MLCとTBWの多さが絶対的正義ではないならSSD470Kの方がお買い得。
https://us.transcend-info.com/embedded/product/embedded-ssd-solutions/ssd422k (2024.06.09閲覧)

SSD470KもSSD422Kも産業用ですが、普通にAmazon上でAmazon販売で売ってるので買えます。ただ、レビュー見るとサポートソフトウェアとかを手に入れるには大口クライアントにならないとダメみたいなことが書かれています。

SSD470Kのアイドル消費電力1.35Wは、昨今のSSDとしては大食いです。昨今のコンシューマー用SSDのアイドル時の消費電力は数百mW、製品によっては100mWを切ってます。そんな中470Kはカタログで1.3Wあり、実機でもPD+20VトリガーケーブルをAVHzYのCT-3経由で見た感じ、だいたいカタログ値通りの電力を消費しています。

正直なところ、このSSD470Kは過剰スペックだと思ってます。欲しかったのはSamsung 860 ProぐらいのスペックのTBW(250GBで300TB前後)なので、250GBで600TBWに迫るTBWは明らかに過剰です。

ただ、860/870系統のSamsungのPro版SATA SSDは検討時には既にディスコンのようで、Amazonでの価格が異様に高く(50K超)、2台で10年間都合1.3W×2=2.6W分の電気代を垂れ流してもまだSSD470Kの方が安いのでSSD470Kにしました。購入費用は2台で約35k円でした。

ちなみに、先代の25号機のSSDは2台で8万円近くしました(※)。そのため2013年の導入当初は更改時も使い回す気満々でした。ただ、25号機に更改するとき、UEFI+GPTにしたつもりが後からBIOS+GPTでOSが入ってたらしいことに気づいたのと、25号機で採用したSSDであるCFD HG6dもIntel 335もTBWが不明(非開示)で残余寿命がわからないので続投しないことにしました。

容量は25号機の頃は512GB+240GBでしたが、38号機では13号機と構成を合わせる形で1TB+250GBにしました。

OS

OSは、先先代(15号機)、先代(25号機)に続きOSはFreeBSD(amd64)です。今回の更改はこのFreeBSDのインストール・運用がなかなか安定せず難航しました。

Intel N100はEコアだけ積まれてる12世代プロセッサですが、どうもFreeBSD14はEコアしか無いのは想定外なのか、デフォルトで起動するとファイルシステム(UFS)操作でクラッシュします。mysql80-serverを/var/db/mysqlを削除してクリーンスタートすると割と簡単に再現します。

なかなか原因と対策が突き止められなくて、IOが怪しいところまではわかったんですがそこからCPU不良を疑ってマザボ変えてみたり、SSD変えてみたり、M.2 PCIeをSATAに変換する基板入れてみたりしても再現してました。

クラッシュする瞬間をiPhoneでスロー撮影したりして色々調べていたら、FreeBSDのMLで/boot/loader.confに「vm.pmap.pcid_enabled=0」を入れると直るかも的な記事をここ(https://www.mail-archive.com/users-jp@freebsd.org/msg00203.html)で見つけました。それで実際に/boot/loader.confに「vm.pmap.pcid_enabled=0」を入れたら嘘のように安定したので、やっと移行作業が出来るようになりました。

このN100DC-ITXはNICにRealtek RTL8111Eが搭載されています。FreeBSD標準添付のドライバがクソなのかなんなのかわかりませんが、SCPするだけでもNICがよくこけるのでRealtekの公式ドライバらしいrealtek-re-kmodのpkgを入れてあります。

移行

移行は15号機や25号機でもやってきたように、新しいマシンを傍らに置いて、ルータでNAPTを止めての移行作業です。1発勝負です。終わった時に脳汁(ドーパミン)が最も出るやり方です。まぁ失敗して戻したことは無いのですが、どのマシンの移行でもトラブルが無かったことも皆無という残念な方法です。

移行で面倒なのは設定ファイルのレビューですね。実はOSやソフトウェアは安定版ではありますが最新版を追ってて、リリース用ML等で新バージョンのアナウンスが出ると速攻で入れてます。しかし、バイナリとは対照的に設定ファイルはインストールしたときからほとんど変わっていません。

現に動いている設定ファイルなので、次のマシンに持っていても動きます(たまに動きませんが…)。ただ、長年使った設定ファイルと最新の設定ファイルを比較すると、今設定していない値に値が定義されていたり、わざわざ定義している値のデフォルト値等が変わって定義が不要になったり、定義している値が非推奨な値になっていることがちょくちょくあります。

このため、更改時には旧設定と新設定を見比べて、古い設定ファイルから新しい設定ファイルに適切に設定を移行する必要があるのですが、これがなかなか面倒な作業でした。ちなみに、今回の一番設定が違ってたのがmysql.cnfでした。FreeBSD10.0で入れたMySQL5.6の設定ファイルでもMySQL8.0でも動くのかーとは思いましたが、結構Deprecatedな設定があったのでそのまま持っていくのは流石にやめて、サンプルConfigから作り直しました。

チューニング

37号機同様、電力設定をチューニングしています。チューニングは37号機と同じでPL1=10W, PL2=25W Autoから、PL1=6W, PL2=10W 10sにしています。38号機はPL2=15W 20sぐらいは欲しいなぁと言うのが正直なところです。ただ、37号機と比べるとSSDの発熱が大きく、安定的に性能を出せる電力はこの辺りかなーって感じで37号機と同じPL1=6W, PL2=10W 10sにしています。

逆に言うと、37号機は38号機よりSSDの発熱が低いのに38号機と同じ設定なので、もっと上げられると言えます。ただ、面倒なので合わせています。

この設定でFreeBSD 14.0で、常温下に縦置きで概ね63〜67℃程度を推移しています。SSDの発熱のせいか37号機よりも10℃ほど高い温度になっています。ただ、先代の25号機もこんな感じの温度だったので、マザーボードなどでハズレ個体引いていなければそうそう壊れることも無いと思っています。

37号機稼働開始(24号機更改リプレース)

先日、24号機(Shuttle XS35V3L)の後継として、37号機の稼働を開始し、24号機の運用を停止しました。24号機は購入後10年、2016年から7年以上運用していましたが、その歴史にピリオドを打ちました。

主要な構成

37号機の主要構成はこちらです。

SilverStone SST-ML10のケースにASRock N100DC-ITXを組み込んだものです。メモリはCFD Crucial DDR4-3200 32GBx1です。N100DC-ITXはSO-DIMM対応ではないので、普通のDDR4メモリです。これにMeanwell社のGST90A19-P1MというACアダプタを繋いでいるのが主要部分となります。

この主要な構成は25号機の後継となる38号機(予定)も全く同じですし、34号機の後継となる39号機(予定)もケース・SSD以外は同じです。

置き換え元の24号機(と25号機と34号機)はすべてゼロスピンドル機です。ゼロスピンドルによる高い静粛性、機器清掃作業の排除(メンテナンスフリー化)、地震等による転倒・落下に対する耐衝撃性の向上を志向したマシンです。

37号機もこの志向を引き継ぎいでゼロスピンドル機としました。Twitterでは120mmファンを搭載しようかと呟いてましたが、メンテナンスフリー化はやはり捨てがたいでゼロスピンドルで組みました。

ケース・電源

ケースは前述の通りSilverstone SST-ML10です。近年のITXケースは、拡張スロット(PCI/PCIe)使用が前提となっています。そのため、ミニタワーみたいな近いケースか、ShuttleやSST-SGシリーズのようなキューブ型、小型化を追求したものであればThin-ITXかDeskminiのようなMini-STXだったりが主流になっています。そのためSilverstone SST-ML10のようなMini-ITXで、かつMorexの血を引く基盤型電源を使用可能なケースは、現代においては希少です。

ファンは50mm x3と、120mm or 140mm x1のファンを設置できますが、前述のようにゼロスピンドルにしたかったため結局は設置しませんでした。そもそもゼロスピンドルでなくても50mmは入手性の問題、120mmはSSDを積むとクリアランスの問題が厳しいので搭載は難しかったです。

電源は実家で稼働実績にあったMeanwell社のGST90A19-P1Mです。Digikeyで買いました。実家で動いているものは1USD≒100JPY前後の時代だったので3,500円程度で買えましたが、昨今の円安で5,500円しました。

この電源、一般的なACアダプタと比較すると安くはないです。しかし、50℃以上の雰囲気でも稼働できて、PSEが付いてて、稼働温度範囲が広く、最高雰囲気温度下(70℃)でも60W出力を担保できる電源がそれなりの値段で1個から買える。ということを考えれば十分に安いとも言えるな選択です。ちなみにMeanwellは台湾の企業ですが、電源本体は中国製です。

マザーボード/メモリ

マザボはN100DC-ITXで、SATAが2ポートあるモデルにしました。m.2のNVMeにしたい気持ちはあるのですが、障害時にデータを抜くのはSATAの方が楽なので今回もSATAです。

N100DC-ITXがJ5040などの従来のASRock製のSoC ITXマザーと大きく異なるのは電源・CPUと、メモリがSO-DIMMでないこと、メモリスロットが1つしかないこと、SATAが2ポートしかない(ASmediaのSATAコントローラがないこと)があげられます。

あと、実用上は問題ないのですが、N100DC-ITXはBoot Beep(起動時のピッの音)音がやたらと汚いです。また、SATA電源はマザボから供給されるのですが、この供給される電圧は12Vと5Vレールのみで3.3Vレールはありません。まぁ、今時SATA3.3V使うストレージはレアですが、ストレージ以外の電源として使う場合は注意が必要です。

このマザボはデスクトップ用のDDR4-DIMMを1枚だけしか搭載出来ません。そのためCFD CrucialのDDR4-2400の32GB/枚のモジュールを買ってきて積みました。N100はIntel ArkではMax 16GBと書かれてますが、ASrock N100DC-ITXの仕様上は32GBと書かれていますし、書いてある通り、32GBモジュールを認識します。

ただ、N100DC-ITXのメモリスロットは1つしかないので(※)、メモリーインターリーブアクセスの機構(≒デュアルチャンネル)は物理的にありません。従って、メモリ不足でないなら無駄に増やしてもパフォーマンス向上は見込めません。私はDDR4はオワコン寸前で、今後は今ほどは安く買えなくなると思ったのでほぼ使わないであろう32GBにしました。私はメモリ積みたがり星人なので大量に詰んでますが、過剰かと言えば一般的には過剰だと思います。

※メモリスロットが1つ: そもそもN100自体のメモリチャネルが1chしかありません。

メモリはマシン4台分を安価に調達するため、CFD Crucialの2枚セット品を買ってそのうちの片割れを使っています。

CFD Crucialは安価ですが、ロウハンマー耐性はちゃんとありました。

SSD

SSDは先代の24号機からそのまま載せ替えました。先代の24号機の導入当初はCentOS6を入れて使っていました。このCentOS6が2020年11月にEoSLを迎えた際、24号機の更改機を新造した暁には新造機ににそのまま載せ替える前提で、24号機のSSDは新しいSSDに交換して、OSをUbuntu LTSに切り替えました。こう言った経緯があったので(だいぶ期間は空きましたが)SSDは載せ替えとしました。

まぁ、これはCentOS6からCentOS7への所謂上書きインストールが結構手間で難しい上に、頑張っても約3年半でCentOS7のEoSLが来るからと言うのもあるんですが、CFDのHG5dというTBW不明のSSDで(すでにGPT+UEFIの時代に)GPT+MBR+BIOSブートしてたのも大きい理由です。

SSD載せ替え後はNICの名前がenpからensに変わりましたが、/etc/netplanの設定ファイルのインターフェース名の名前の一部をenpからensに変えたらIPをそのまま引き継いで普通に動作しました。ついでに、netplanのgatewayキーワードは2020年時点は問題ありませんでしたが、2023年ではdepricateらしいので、routeに直しておきました。

チューニング

電力設定はチューニングしていて、PL1=10W, PL2=25W Autoから、PL1=6W, PL2=10W 10sにしています。デフォルトでもシャットダウンするとかはありませんが、更改前でも性能不足はなく、そんなに熱くしても寿命に響くだけなので下げてあります。

この設定でUbuntu 22.04 LTSで常温下で概ね50〜55℃程度を推移しています。

37号機はハズレのマザーボードを引いていなければそれなりの寿命が期待できると踏んでいます。

ASRock N100DC-ITX

023年の12月の暮れにAlderlake NのSoCオンボードマザーのASRock N100DC-ITX (ASRock公式サイト)を買いました。24、25、34号機の更改のためです。予備含め4枚買いました。

買った理由ですが、2019年頃に立てたJasper/Elkhartlake更改という計画を実行に移すためです。計画名と買ってるマザーボードが若干違う気がしますが、前述の通りCeaderView/Braswell機である24、25、34号機を更改(リプレース)するための計画です。

元々は名前の通りの計画で、自宅に跋扈しているCeaderViewやBraswell等の老朽機をJasper lakeかElkhart Lakeで一掃する計画でした。2020年頃には予算・資金も確保し、準備万端となりました。しかし予算は付いたもののパーツ調達フェーズで3年ぐらい計画が止まっていました。計画の要となるコンシューマー向けの Jasperlake や Elkhartlake を搭載したMiniITXマザーボードが一向に出て来ない状態が延々と続いてました。

出ないものは仕方ないのですし、Gemini Lakeはありましたが、Gemini Lake系統は実家で使ってて、できればGemini Lake一色には染めるのは避けたかったので、自宅ではD2550とかN3050という2010年代前半の古い機材で運用を続けていました。D2550の方はShuttleのベアボーン機で予備機を持っていたのですが、2020年に25号機が壊れてしまい、予備機の在庫がなくなったためまさに薄氷を踏むような運用でした。

そんな中、2023年中頃にようやくAlderlake-NでITX SoCが出ました。これがASRockのN100DC-ITXです。そして、更改のために購入したのがこのAlderlake Nのマザーボードです。

マザーボードの要件は下記の通りで、若干妥協はありますが、N100DC-ITXは概ね要件を満たしていため購入することにしました。

  • Mini-ITXであること。
  • ファンレスであること。
  • SATAが2本あること。
  • PCI EXpressスロットがあること。
  • ATX20ピン、または24ピンで給電されること。

要件1: Mini-ITXであること。

更改対象の24号機と25号機はShuttleの超小型ベアボーンどと言うプロプライエタリなプラットフォーム(以下、プロプラPF)でした。プロプラPFのベアボーンは電源とマザーボードと筐体が一式でセットになっています。

このお陰でMiniITXより小型化出来るのですが、調達も一式単位になるので予備機材が高く付きます。しかもマザーボードだけ入れ替えて更改みたいな芸当ができないので、壊れると一式交換となります。一式交換しかできないのでプロプラPFはメーカで一式がディスコンになると立ち行かなくなるデメリットがあります。

と言うか、実際に立ち行かなくなったので、オープンプラットフォーム(以下、オープンPF)であるMiniITXで建造することにしました。Mini-ITXの規格自体は(提唱したメーカは消えそうな勢いですが)、Intel/AMDも支持はしているのでここ10年ぐらいでは消えないかと思います。なので最悪はその辺のIntelなりAMDのデスクトップマザーを入れれば運用できます。

ここまでがプロプラPFからオープンPFに移った理由で、Mini-ITXにしたのは単純に置き場や運用の問題です。更改対象機はどれも専用機で、構成もシンプルで、運用期間中に増設も無ければ、高いエアフローが求められるマシンでもありません。

そして、私の家は狭く、大型マシンがメンテしやすい環境ではありません。そういう状況で大型機を買っても無駄で、邪魔で、メンテナンスがしにくいだけです。そう言う理由でMini-ITXにしました。

要件2: ファンレスであること。

ファンレスが実は超重要でした。

2010年以降の機材で、運用予定寿命が10年未満なら、埃の溜まる期間orファンの寿命<運用寿命です。一方、ファン以外のパーツは概ね、パーツの寿命>運用寿命です。つまり、ファンレスにすればマシンの運用寿命が来るまでほぼメンテフリーになり、PCの物理メンテナンスから解放されるのが大きな理由です。

強制空冷はどうしても埃が入ってきます。そして埃は最も通気しやすい部位の、抵抗の大きいに溜まってやがて詰まり、次に通気しやすい部分の抵抗の大きい部分に溜まってどんどん詰まっていきます。つまり、定期的に清掃が必要になります。吸排気を調整しても、セミファンレスでない限り大体3年ぐらいで詰まってきて内部温度が上がり、騒音レベルも上がってきます。

運用寿命が10年なら3年に1回は運用断を伴う掃除が必要です。私は台数が多いのでメンテそのものが面倒ですし、清掃期間の管理も面倒です。清掃せずに済むならやりたくないです。

そして、電動ファンはPCパーツの中では寿命が短いパーツで、これもまた、正しく動いているかの定期的な確認と、NGの際はサーバを停止して交換が必要になる面倒なパーツです。加えて電動ファンは小型のもの(〜60mm)は同一シリーズでもカタログスペックの時点で大型のもの(120mm〜)より寿命が短く、体感的にも故障しやすい傾向があります。

こんな感じで、24、25、34号機はファンレスにしたので更改後もファンレスにすることにしました。

要件3: SATAが2本あること。

SATAは結構重要で、OSが起動しない状況でデータを引き抜いたり移す際はNVMeよりSATAの方が色々便利なのでSATAにしています。

SATAよりNVMe m.2のが断然高速なんですが、SATA以外の部分が同じなら、その性能差が如実に出るような使い方をしない限り、スペック差ほど使用感に差は無いです。阿部寛のホームページを1Mbpsでも見てめ10Gbpsの回線で見ても1万倍の差を感じないのと同じです。

実際、私のマシンだと32号機のMacや36号機のhpのノートPCのSSDはNVMe/PCIeで、最も使う23号機はSATAなんですが、速度差を実感する用途は殆ど無く、いつの間にかSATAに変わっていてもしばらく気づかないと思います。。

要件4: PCI Express (PCIe)スロットがあること。

PCIeスロットはVPNルータの34号機の更改でNIC増設をするためPCIeスロットは必須です。

まぁ、PCIeスロット無くてもPCIeが生えてるM Key のM.2やE Key M.2のiCNVioからEthernetを生やす怪しい基板はあるにはあります。まぁ実際に買ってみたんですが、怪しいMACで、積んでる蟹チップすら正規品か怪しいぐらいです。

まぁ、怪しい云々の前にPCIeのEthernetカードを買う方が普通に安いですし、iCNVioもE Key M.2用の怪しいEthernetもなんていつまであるかわからないので、普通のPCI Expressスロットにしました。

ちなみにNICは蟹(Realtek)にしました。Realtekは Checksum オフロード関係がダメダメだったりしますが、ethtoolでOFFにしてしまえば終わりですし、初期コストも消費電力も低いです。また、N3050すら持て余しているマシンでやっていたことを、Skylakeクラスの性能が出るという謳い文句のCPU詰んだ専用機にやらせるのでCPU負荷が少々高くても特に気にならないので蟹で妥協です。

というか、対向にある実家の28号機なんてIntelから蟹で置き換えてますしね。

要件5: ATX電源

これは妥協しました。

最後のATX電源だけは待ってても出るアテもなく、妥協しても(4台ぐらいまとめ買いした)picoPSUの出番がなくなるだけで、それ以外はデメリットが無いので妥協としました。

ACアダプタはどうせ買いますし、picoPSUは次の更改で必要になれば使えばいいですからね。

これらを使って更改をしていきます。まぁ書いてる時点ではほぼ終わってるんですけどね。

33号機2期構成 ASRock J4125-ITX @ Morex Cubid 2799

先日、33号機の更改作業を行ってきました。2期構成となりました。作業としては新造時に入れたGemini LakeのマザボであるASUS J4005I-Cを、Gemini Lake Refreshの積んだASRock J4125-ITXへと置き換えました。

33号機はコロナの初期にあたる2020年6月に新造したマシンです。当時はGemini LakeのASRock J4105-ITXが家の中で跋扈していたので、一応製造元分散としてASUS J4005I-Cで自作したものです。

33号機のケースはMorex社のCubid 2977というケースを使っています。Morexのケースはここ10年ぐらいは日本ではまともに取扱が無いようで、2000年ぐらい以降生まれの方には馴染みのないメーカーだと思います。今でこそMiniITXはメジャーな自作プラットフォームですが、2000年代初頭のMiniITXは全然マイナーな規格で、VIA Technologiesというx86互換CPUメーカー(※)の独自規格みたいな時代がありました。

※VIA Technologies自体は2024年現在でも存続してますが、x86互換CPUメーカーとしてのVIAは今の兆芯がそれに該当します。

そんなマイナーな時代のMiniITXのケース事情はMorexのケース以外はほぼ選択肢がありません、みたいな状態で、初期のITXプラットフォームではITXといえばMorexみたいなポジションに近いケースメーカーでした。と言っても、MiniITX自体はMicroATXケースと互換性がありましたし、MiniITXはケースとセットでベアボーンとして売られていたことが多かったような気がするので、当時でもMorexが有名かというと疑問ですが。

しかし、このMorexのケースでよく採用されていた12VからATXを生成する電源基板は、基板サイズとビス位置がACアダプタ用の電源基板のデファンクトスタンダードみたいになってて、SST-ML10の電源基板もこれに準じた大きさやビス位置になっています。(ただ、Morexが主導したのかは存じません)

なお、正しくはMorex Information社で、コネクタハウジングの名門であるMolex社とは別の会社です。

33号機と13号機21号機の上にスタック(平積み)して置いています。下に置いている13/21号機も古いMorex のケースで、これらの上にスタックしたいがためにわざわざ在庫のあるEU圏から輸入してきました。2020年当時でも売っていること自体ある意味奇跡だと思いました。

このCubid 26xx/27xxシリーズ、個人的には好きなんですが、PCのケースとしては前時代的な設計です。フロントパネルは今だにUSB2.0のみで、IEEE1394(FireWire)がフロンパネルにあったり、ライザーは(Expressではない)PCIしか無いなど、20年間から何一つ進化していない感が見て取れます。フロントパネルオーディオにAC97のコネクタが残っているのも時代を感じますね(HD Audioのコネクタもちゃんとあります)。理由がない限り、今時このケースで新造するのはお勧めできません。

電源はACアダプタも付属していて、2000年代によくあった12VのACアダプタ+電源ボード式です。付属の電源は60Wです。ただ、電源基板は瞬間に取り外し、新造時から13号機や21号機と同じMeanwell GST90A19-P1M + Mini-Box picoPSU-120-WI-25の構成にしています。これは2期構成でも続投です。

と、まぁ、こんな感じで自作したまではいいんですが、構成がよく似ている13号機、21号機と比べると消費電力がどうチューニングしても4W程度高い状態が続いていて、正直初期構成で使い続けるのも微妙だなーと思っていたのが更改理由です。

今回置き換えに使用したJ4125というAtomの血を引くGemini Lake RefreshコアのCPUで、J5040の廉価版です。置き換え元のJ4005はJ5005の廉価版ポジションにあたりますが、J4005のJ5005に対する見劣り具合はJ4125のJ5040に対するものよりよりだいぶ大きいのも気になってました。

J4125はJ5040とCPU部分を比べるとコア数やスレッド数、ベースクロックは同じで、Turboboostのシングルコアの吹き上がり方が違う程度でした。が、J4005はコア数まで違います。この差は結構気になるところでした。

実作業は私が度々やってマザボ一式(マザボ+CPU+メモリ一式)を置き換えてそれ以外のパーツは続投のやり方です。このやり方はSSDをそのまま引き継ぐのでOS回りの作業が少なくて楽なんですが、更改した時の感動は薄いですね。ドーパミンが出ません。。

このケース、PCIeにブラケットを付けるとブラケットの先端がマザーボードのオーディオコネクタにつっかえてマザーボードを引き出せないので、地味に面倒です。PCIeは何も実装してません(※)が、40mmファンを無理やり付けてて、エアフロー確保のためにグリルタイプのスカスカのスロットカバーをつけています。ちなみにケース、PCI用のライザーカードは付属しますが、PCIe用は無いのでPCIeカードの実装はあまり現実的ではありません。

ファンは40mmが2つ、60mmが1つついてて、いずれも10mm厚です。すべてアイネックス社のOMEGA TYPHOONシリーズを使ってます。劣化傾向が見られないので続投にしました。Duroベアリングを採用するアイネックスのGlobe fanは60mm以下に限って言うと耐久性と静粛性を高いバランスで備えていると思います。まぁSanyoやNoctuaと比較すると劣るのかも知れませんが、少なくとも同一価格帯のファンの中では頭ひとつ飛び抜けた耐久性があると思います。

まぁ、これはアイネックスでもGlobe FanのCFZ-4010とかCFZ-6010とかに言えることで、同社が出してるCFY-40SAなんかは全然持ちませんでしたね。CFY-40SAは値段の割に2BB軸受ということで、耐久性に期待を込めて13号機に付いてたことがあったんですが、スリーブと見紛うぐらい勢いでそそくさと逝き、私の予備品在庫から消えて行きました。CFY-40SAの方が100円ぐらい安いですが、お値段以上に寿命の差があるので、耐久性が欲しい場合は手を出してはダメです。

電源も前述のとおり続投です。MeanwellのMTBF 38万9000時間は最強です。まぁこれ、25℃雰囲気下でのスペックなので、アレニウス則下だと55℃なら48,000時間程度なんですけどね。まぁ、実家の断熱は無いのと同義で、5℃とかも時も普通にあるので、実質プラマイゼロで普通に20年程度は期待できるのではないかなと思ってます。

SSDはSamsung 840 EVOとTranscendのSSD370です。このTranscend 370はググっても370Sばっかりヒットするんですが、370と370Sとは別物で、370はdevsleep非対応でTBWも370Sと比べると若干少なめです。まぁ、devsleep非対応なこともTBWが若干少なめもS.M.A.R.Tの稼働時間が再起動のたびにリセットされることに比べれば実に些細なことです。Transcendの稼働時間は起動からの時間だ、と思いたいところですが、これ、同じTranscend 370ですらファームが違うと普通に総稼働時間だったりするのでマジで意味不明です。早く置き換えたいです。

J4005I-CもJ4125-ITXもEthernetはRealtekのものなので、デバイスシンボルは/dev/re0から変更がありませんでした。よって、FreeBSD14では何も設定することなくIP/Default Gatewayなどを引き継いて運用を再開することができました。

何年運用するかはわかりませんが、次の更改か、運用終了時に電源を切るまでまで問題なく動いて欲しいものです。

Silverstone SST-ML10B

購入後10年が経ち、老朽化著しい24、25号機の後継機用として買ったのがこのケースです。Silverstone製のSST-ML10Bです。AntecのISK-110も候補でしたが、ISK-110は電源がこのケースの専用基板で単体販売はされていないため、SST-ML10Bを選びました。

ISK-110用の代替電源としてデザインしてみたPicoPSU用変換基板

実は上にあるように、ISK-110の予備(代替電源)を、PicoPSU使う前提で変換基板をKiCADでデザインしたことがあります。しかし、左上のDCジャック部分からPicoPSUに電源供給するための部分が難しく、高い電流値を担保可能な配線幅を確保するのは基板スペース、私の技能は困難でした。

そんな感じで色々考えた結果、SST-ML10Bで妥協になりました。まぁ、妥協というか、GeminiLake以降のマトモなSoC iTXマザボの販売を待ってたらISK-110は終売になってしまって、SST-ML10Bを選ぶしかなかったというのが実際のところです。

Silverstone社のSST-ML10のマニュアル
V1のVESAマウンタ
https://www.silverstonetek.com/upload/downloads/Manual/case/Multi-MILO10-Manual.pdf より引用
V2のVESAマウンタ
https://www.silverstonetek.com/upload/downloads/Manual/case/Multi-MILO10-Manual-V2.pdf より引用

SST-ML10はAmazonには末尾B付き(SST-ML10B)とB無し(SST-ML10)のモデルがありますがその差は謎です。またマニュアルを見るとRevisionがあって、V1とV2があるらしいです。私のは箱にはV2.2と書かれていました。V1とV2はVESAマウンタの構造に違いがあります。コスト面の改良って感じですね。V2のケース裏側の中央線付近にはV1であったネジ穴はなくなっているので、V1とV2でマウンタの使い回しは無理そうです。このバージョンは外箱のラベルに書かれています。マイナーバージョン間の差は謎です。

ケースは購入時はElevatedの状態で入ってて、Nov-Elevated用のフロントパネルと上面蓋が入っています。。Non-Elevatedにしたい場合はフロントパネルと(横置き視点での)トップパネルが必要です。

フロントパネル

フロントパネルは如何にも金属のヘアライン加工に見えますが、実際には樹脂のヘアライン加工です。手の込んだコストカットですね。

LEDはPWR LEDもHDD LEDも白です。ギラギラとした下品な感じは無く、上品な光り方です。まぁ、単にN100DC-ITXのLEDのドライブ性能が低いだけな可能性もありますが。

LEDは電源とHDDで形状も変えてあって色覚特性の異なる人にも配慮されてる気がします。私自身は正常色覚ですが、こういうユニバーサルデザインは好感が持てます。まぁ、LED表示の形状を変えてて同じ白LED使うぐらいだったら電源とHDD LEDの色は緑LEDと赤LEDでも別に良くね?って感じもします。

LEDはリード付の砲弾型LEDや角型LEDが所定の場所に頭からブッ刺してある構造ではなく、ボタンも含めて基板に実装されたのがフロントパネルに取付されている構造なのでポン付け交換は出来ません。

フロントのボタンは電源ボタンのみです。リセットボタンはありません。フロントパネル向けのコードがリボン状なのは好感が持てます。

フロントUSBはType AのUSBが2ポートで、どのGenまで対応しているかは知りませんが、一応2つともUSB3対応です。マザーボード側は普通の19ピンです。ケース内部はフラットケーブルです。狭いケースなのでフラットケーブルは好感が持てます。

SilverstoneのSST-ML10の商品紹介ページ

このUSBコネクタ、USBコネクタの上側がケース外側(平置きした時に向かって左側)を向いています。つまり、上記のように商品紹介のように電源ボタンを上側にして縦置きすると、USBコネクタを逆さにしないと刺さない、というなかなか設計センスを疑う構造です。見にくいですが、上記画像でも見にくいですが、USBコネクタが上下逆になっています。USBコネクタはメスの場合は凹んでる部分が下になれば上下正しいですが、商品紹介の縦置きは凹部分が上になっているのでコネクタとしては上下逆です

まぁ、Silverstoneのケースは過去3つ使ってますが、どのケースも何故この設計で良しとしたのかよくわからん要素が1つぐらいはあるので気にしたら負けだと思います。どのケースもロングセラーなのできっと正義なんでしょう。

まぁ、USBがこれだからというわけではありませんが、縦置きする場合で、N100DC-ITXみたいにメモリをノース側に実装するMBをファンレスで搭載する場合、電源ボタンを下側にくるように設置するとメモリがCPUの熱に炙られません。ただ、50mmファンはケースの向かって右側につけますので、つける場合は商品紹介みたいに置いた方がいいです。

マニュアル

取扱説明書は同梱されてません。詳しくはWebで、って奴です。そして、この説明書は付属品の扱いが結構雑です。何が入っているかは書かれていますが、いくつ入っているかは書かれていません。なので員数確認のためだけに見るなら見る価値は限りなく低いです。

説明書の付属品に関する項目。

どこにどう使うのか謎なものもあって、ゴム脚が入ってるんですが、数はもちろんの貼り付け位置は書かれてません。極め付けはMBの下に貼り付けると思しき絶縁シート?で、未貼り付けで同梱されているのですが、マニュアルには同梱されている事実すら記載されてません。もちろん補足の紙もないです。「PC自作してんなら見りゃわかんだろ」というの地で行くKOTY的ストロングスタイルな感がありますね。嫌いじゃないですが不親切です。

この絶縁シート?ですが、ネジ穴のクリアランスの余裕が少ない上、全面で両面テープなのでミスると貼り直しは難しいです。そのため雑に貼ると泣きを見ます。私は下記の写真のようにして養生テープで取っ手を作って慎重に貼りました。

SST-ML10の絶縁シート貼り

まぁ、このシート、貼る意義も必要性も特に感じないですが、貼るならフロントパネルも外してからやった方がが無難です。このフロントパネルなんですが、底面のネジだけNo.1のドライバが必要です。これもあんまりセンス感じない造りですね。

ここのネジだけNo.1です。外さないとフロントパネルが外せません。

ケースはケンジントンロック用のホールが付いてて、Kensington純正品かシリンダー付きの互換品なら一応ケースが開かないようになると思います。ロックバーでフタと本体を貫通させてくくりつけてるわけではなく、単にロックのシリンダーの円筒部分でトップカバーのスライドを妨害してるだけの構造です。よってケチくさい会社や事務所が買うようなやっすい互換品だと効果無さそうですね。

ファン

ファンは10mm厚の50mm角のファンが3つと、120mm/140mmのファンが1つ付けられます。120 mmか140mmかは排他ですが、これと50mmは別に排他ではないので両方とも付けられます。50mm側外側から内側に向けて皿穴があいてます。ただ、ケース自体にはファンもネジの付属もありません。「ファンをつけたければ全部自分でご用意しな。」というスタンスです。

この50mmというのは結構曲者で、国内においてそこら辺で変える50mmファンを出してるマトモな正規流通はアイネックス社のものだけです。アイネックス社の大口径ファンはラインナップも品質もやる気のを感じませんが、小口径のラインナップは神そのものですね。通販だとモノタロウでRS Pro(中はどうもOrionFanっぽい)も買えます。

ちなみに、大御所のNoctuaや山洋は何故か50mm自体のラインナップがありません。よってPWM対応が欲しい場合はDigikey漁ると出てきます。やはり種類少ないですが、Wakefield-Vette社のDC0501012シリーズが適合すると思います。ただ、自作向けとして取り扱っているわけではないので、データシート見てどれ買えばいいのかよくわからないのであれば、素直に120mm/140mm積むかアイネックスあたりで手を打つのが無難です。私はファンレスにしたいので買いませんでした。

Elevatedにすれば2.5インチSSDをつけてても120mm/140mm口径の25mm厚のファンが入りそうですが、実はNon-ElevatedからElevatedの蓋に交換して増える高さ(外寸)は実測で23mmしかありません。なので、2.5インチSSDと25mm厚のファンを入れると干渉すると思います。

電源部

電源はACアダプタを使用する想定で、既製品が使えるように考慮されていると思います。一応専用の純正品が販売されていますが、PicoPSUや2000年代前半のITXケースによくあった電源基板も使えるようになってます。壊れてもどうにか出来るあたりはこのケースの好感が持てる部分です。

DCジャック用のホールはPicoPSU純正ののバレル型DCジャックが入ります。PicoPSUの純正バレルジャック部分はM8ネジですので、PicoPSU以外でもM8に近い構造なら入るとは思います。ケース側はネジの切ってない単なるバカ穴です。尼のレビューにもあるんですが、位置的にはファンに干渉するのでファンガード(グリル)必須ですね。付ける余裕あるのか知りませんが。いまいちな部分ですがここは仕方ない要素があるかなぁって感じです。

Morex(≠Molex)のケースに採用されていたCUI PJ-039AHのようなパネル取り付けのバレル型DCジャック(※)も寸法的には合ってるので付けられると思います。ただ、Power DINは無理だと思います。というかMini DINのPower DINでも無理だと思います。

※(免責)Morex Cubid 26xx/27xnシリーズのバレルジャックはCUI PJ-039AHと見た感じは同一形状ですし代替品として嵌りますし、実際私も代替品として使っています。ただ、このシリーズがCUI PJ-039AHを実際に使っているのか、単に互換性があるだけのパーツなのかは不明です。ちなみに末尾AHは内径2.5mm、末尾BHは内径が2.1mmです。

電源基板部

SST-ML10Bにある電源寸法
https://www.silverstonetek.com/upload/downloads/Manual/case/Multi-MILO10-Manual-V2.pdf P.9より引用
AD120-DCの電源寸法
https://www.silverstonetek.com/upload/sstedm/ad120-dc/AD120-DC-Product_Sheet-JP.pdf より引用
Morex Cubid用に作ったPicoPSU用変換基板

画像一番上がSST-ML10Bに適合する電源基板、真ん中がこのSST-ML10B用に設計・販売されている純正電源、下が私が昔、古いMorex Cubidシリーズ用に設計・製造したPicoPSU用の変換基板です。基板サイズ、ネジ位置はほぼ同じなので、Morexなどの古いものをそのまま使うこともできるはずですし、逆にAD120-DCをMorexなどのケースに使い回すこともできると思います。

ただ、マザーボードとのクリアランスは広くなく、フロントパネル部分はUSBやボタン、LEDなどのパーツがあるので、これらのパーツ、あるいはマザーボードと電源基板上のパーツが干渉しないかは現物合わせが必要です。

今回はマザーボードに電源アダプタを直結するタイプのマザーボードなので使いませんが、更改時には役にたってくれると思います。

総評

叩いている部分もありますが、どうにかなる部分がほとんどで、総じて言うと好感の持てるケースです。わかる人には高いポテンシャルを感じられるケースです。

ただ、マニアックな口径のファン、員数・取付位置が不明なパーツ、存在意義の謎なパーツ類など、わかる人向けに作られてる感は否めません。そういう点ではパワーユーザー向けだと思います。

2023年あけましておめでとうございます!

2023年あけましておめでとうございます。

このサイトは2000年開設ですので今年で開設23年になります。
23年前は2020年代もこのサイトが続いていると微塵も思ってませんでしたが、特に閉鎖も何もせず、放置に近い運用していたらいつの間にか22年経ってしまいました。

月並みな表現で芸がありませんが、23年目となる本年もよろしくおねがいします。

今年の初詣

鏡餅を飾ったりとか、雑煮をたべたりとか、正月らしいことを何一つしないYuaihoですが、毎年1月1日に初詣だけはやっています。

今年の初詣は虎ノ門の金刀比羅宮というところです。いわゆる都市型の神社でビルとビルの間にあります。神社の周りにビルが建ったと言うのが正確な表現なんでしょうけど。

未だに鈴を物理でじゃらじゃら鳴らせて陽気なところでした。
初詣先としてはあまり人気がないのか、ほぼノーウェイトで参ることができました。



メールファイルのOS上のタイムスタンプをメールヘッダ内のタイムスタンプに変更するサンプルプログラム

先日書いたiPhoneのメールアプリのタイムスタンプが狂う問題を修正を目的とした、Yuaiho作成のサンプルプログラム(Perlスクリプト)を配布します。サンプルを名乗ってますが、一応Yuaihoが実際に使っているスクリプトです。

配布用にコメントやメッセージ出力は割と手直しはしていますが、アルゴリズム的にはそのままです。


配布先

※免責事項は本記事の下部にあります。
ダウンロード from yuaiho.com
ダウンロード後、拡張子をplなどに変更して、実行権限を与えてください。

年月日時分秒からEpoch秒を求めているため、Timelocalモジュールが必要です。

メールファイルのファイルリスト一覧を標準入力で送り込むと、メールファイルを1つづつ開いて読み込み、Receivedヘッダ、もしくはDateヘッダからタイムスタンプを取得します。


使い方

使い方は下記の一番上の行のように、タイムスタンプが狂ったメールファイルが存在するメールボックスのcurディレクトリから呼ばれることを想定しています。

$ find ./ -type f | /tmp/dateperse.pl --debug --commit
$ ls -1 | /tmp/dateperse.pl --commit --noinfo
$ cat <filelist> | /tmp/dateperse.pl --debug --commit
$ cat <filelist(Abusolute file path)> | /tmp/dateperse.pl --absolute

引数に--commitをつけて実行すると、本当にファイルシステム上のタイムスタンプを書き換えます。--ommit引数がない場合は、タイムスタンプ書き換えは行わず、&#45;&#45;commitで実行する際のコマンドがテキストで表示されます。

引数に--debugをつけるとDEBUG:メッセージが出力され、より詳細な情報が出ます。ただ、私がデバッグ用に使用していたものそのままなので内容は不親切です。

引数に--noinfoを追加するとINFO:メッセージが出ません。--noinfoを追加してもエラー(ERROR:)が出るとエラーメッセージが出力されます。--commitと--noinfoを組み合わせると、エラー発生時以外は何も表示されなくなります。

標準入力から送られてくるファイルリストが絶対パスの場合は引数に--absoluteをつけてください。送られてくるファイルリストは絶対パスとして処理します。送られてくるパスをそのまま開きます。

引数に--absoluteが無い場合は標準入力から送られてくるファイルリストを相対パスとみなします。標準入力から送られて来たファイルリストの頭に、スクリプト実行時のシェルののカレントディレクトリを付け足してからファイルを開きます。

引数に-h --usage --helpを入れるとAboutメッセージと使い方が表示されます。

ファイル内に処理すべきタイムスタンプを含むヘッダが見当たらないファイルは--commitを入れて実行しても時刻変更の処理はされません。

下記は引数なしの出力例です。緑が--commit時に実行されるコマンドです。これがファイル数分出力されます。

$ find ./ -type f | /path_to_app/dateperse.pl
-----
INFO: Executing file "/path_to_maildir/cur/./1486390265.M692487P75574.mail.yuaiho.net,S=1962,W=2000:2,S"
INFO: Header read: 2003-08-02 12:58:24+0900 -> Final destinaiton time: 2003-08-02T12:58:24
/usr/bin/touch -d 2003-08-02T12:58:24 "/path_to_maildir/cur/./1486390265.M692487P75574.mail.yuaiho.net,S=1962,W=2000:2,S" >> /dev/null
-----
※ファイル名は一部架空のものです。

動作の前提となる条件

メールは下記を満たしていることを前提に作っています。下記を満たさないファイルを食わせると、不正確なタイムスタンプが生成されたり、プログラムが落ちたりします。微妙に文字色が違う部分の処理はかなり雑に書かれています。

  • タイムスタンプの年表記は西暦4桁表記であること。
  • タイムスタンプの月表記はJan/Feb/Marのように大文字開始の半角英字3文字であること。
  • タイムスタンプの時刻はhh:mm:ddの0フィル有り24時間制表記であること。
  • Date:はヘッダ内に必ず存在し、そこにはタイムスタンプが必ず書かれていること。
  • Received:ヘッダのセミコロンの後には必ずタイムスタンプが存在すること。
  • 時差表記は+hhmmまたは-hhmmで、hhは0〜19でmmは00から15分刻みであること。
  • タイムスタンプは0以上のEpoch秒の範囲で、かつ実在する有効な日付・時刻で、整数表記であること。
    (つまり2000年08月32日とか、25:05:00とか、13:75:00とか、12:00:00.000はダメです。)
  • ヘッダ内に空行が無いこと。
  • ヘッダと本文の区切りは必ず空行であること。

MUA(Mail User Agent/メーラ)を変更しても問題なく読めるメールであれば、基本的に上記を満たしていると思います。たぶん。


主な仕様

使用可能なヘッダ

採用するタイムスタンプは「Received:ヘッダのみ」「Dateヘッダのみ」「どちらか先に見つかった方」の3つを選べます。「$g_pref_mode_header」で設定します。デフォルトでは「どちらか先に見つかった方」です。

Received:ヘッダのみを参照する場合、参照範囲をヘッダ内に絞る設定があります。絞らないと、Received:ヘッダがヘッダ全体を探しても見つからない場合、本文や添付中に書かれたものを拾う可能性があります。これは「$g_pref_mode_parse_headeronly」で設定できます。デフォルトでは絞っています。

Received:ヘッダは1番上にあるもののみを自動的に拾います。そのファイル内にReceived:で始まる行が1つでもあったか(マッチしたか)を検査してるので、最初のReceived:ヘッダより行頭側にタイムスタンプがあっても反応しません。

タイムスタンプの拾い方はかなり手抜きをしてるので注意が必要です。例えば、Feb 31とか26:58:57とかも拾ってしまいます。

あり得ないタイムスタンプを検知して除外するような機能は実装していません。あり得ないタイムスタンプを拾ってしまうとプログラムがエラーで止まります。

ファイル内に利用可能なタイムスタンプが見つからない場合、そのファイルは何も処理されません。処理されない代わりに「ERROR: File “ファイル名” has no valid hedear.」と表示されて次のファイルを処理します。


時差補正

どちらのヘッダを利用していても、最終的なメールサーバの設置場所の時差を勘案したものとなるよう時差補正をかける処理を入れています。

例えばReceived:なりDate:なりのタイムスタンプに00:00:00+0000(UTC)と書かれているメールは、時刻やタイムゾーン設定が正確なら日本時間では09:00:00に受信してサーバのディスクに書き込まれたことになります。

タイムスタンプの時分秒をそのまま信じると00:00:00ですが、UTCの00:00:00であって日本時間の00:00:00なわけではないので、時差を考慮してサーバ設置場所の正しい時刻(ローカルタイム)に補正する必要があります。

このプログラムは読み込んだタイムスタンプを一旦UTCに戻し、そこからプログラム内で設定した時差を追加することで、サーバ設置場所のローカルクロックの示す時刻になるような処理を入れています。この修正用の時差は時差は「$g_pref_tz_sec」で秒単位で設定できます。

私のサーバはUTC+0900(日本)、にありますのでデフォルトは+0900に補正する設定になってます。

この補正値は任意の時間に設定出来ますが、タイムスタンプの日付や時刻によって補正値を変えるような処理には対応してません。つまりDST(夏時間)には非対応です。DST実施国にお住まいの方は適宜改造してくださいです。

+0900 (JST)のように後ろにタイムゾーンや標準時名とかが付いてる場合もありますが、各国の標準時はたまに変わるのでこのプログラムではカッコ内のタイムゾーン名や標準時名は無視しています。というか、たまに付与されてないし。

ちなみに日本標準時であるJSTは1951年から変わってませんが、例えばここ20年のUTC+9だけ見ても2015年に北朝鮮やロシア(イルクーツク)、モンゴルに異動にあり、UTCとの時差が変更になってます。

余談ですが、古いメールだとGMT+0900とかあったと思います。UTCとGMTは厳密な定義の上では異なる存在ですが、時差を示す場合においては同一のものと考えて差し支えありません。


免責事項

サンプルプログラムの利用・改造・転載は公序良俗に反しない限り自由です。事前・事後の連絡も不要ですが、必ず利用者の自己責任で行なってください。再配布の際はオリジナルのAuther名を残していただけると作者としては嬉しいです。

意図的に有害コードを含むようなことはしておりませんが、意図しない不具合を内包している可能性があります。

Yuaihoが実際に使ったプログラムですが、一般の使用に耐えうるような充分なテストがされてるわけではありません。例外処理などももほとんどされていないか、されていても激甘です。そのため実環境に適用される際はよく検証してからご自身の責任で適用してください。間違いや事故があっても責任は取れません

コードが汚い系の批判は、頂いてもたぶん直さないと思います。

サイドチャネル的に作ったので参考文献は特にありません。

iPhoneのメールアプリのタイムスタンプが狂う問題

iPhoneのメールで表示されるタイムスタンプはDateヘッダではなくエンベロープの到着日

理由は知りませんが、iPhoneのApple純正のメールアプリ(※)に表示されるタイムスタンプは、IMAP4を使ってる場合、メールヘッダのDate:ヘッダの中身では無く所謂エンベロープの到着日を表示しているようです。

※インストール時点で入っているApple公式の青いアイコンのメールアプリのことです。

エンベロープの到着日というのはIMAP4のINTERNALDATEに相当するタイムスタンプです。IMAPサーバにloginコマンドでログイン後、SELECTコマンドでメールボックスを選択して「fetch <メール番号> INTERNALDATE」みたいなコマンドを送りつけると返ってくるタイムスタンプです。

a FETCH 1 INTERNALDATE
* 1 FETCH (INTERNALDATE "18-Mar-2010 01:36:12 +0900")
a OK Fetch completed (0.013 + 0.000 + 0.012 secs).
a FETCH 1 SAVEDATE
* 1 FETCH (SAVEDATE "21-Oct-2022 05:38:12 +0900")
a OK Fetch completed (0.031 + 0.000 + 0.030 secs).

このエンベロープのタイムスタンプは私のメールサーバ(※)の場合、下記に示すようにファイルシステム上で、上記のメールに該当するメールファイルの属性値であるBirthかModified属性のいずれかのタイムスタンプがそのまま入っていました(※※)。ちなみにSAVEDATEコマンドの方はChange属性が入っているみたいです。

$ stat -x 1268843772.*****.mail.yuaiho.net:2,S
  File: "1268843772.*****.mail.yuaiho.net:2,S"
  Size: 654          FileType: Regular File
  Mode: (0600/-rw-------)         Uid: (yuaiho/515)  Gid: (yuaiho/515)
Device: 0,112   Inode: 19423***    Links: 1
Access: Fri Oct 21 05:07:10 2022
Modify: Thu Mar 18 01:36:12 2010
Change: Fri Oct 21 05:38:12 2022
 Birth: Thu Mar 18 01:36:12 2010
※ファイル名の一部(FQDN部分)やInode番号、UID/GIDは架空のものですが、それ以外はオリジナルのデータです。タイムスタンプ変更もこのファイルに関しては変更していません。

※FreeBSD13.1+Postfix3.7.3+Dovecot2.3.19.1。投稿日時点の安定版の最新Versionです。互換モードは無効化。
※※BirthかModified属性のいずれか
: BirthとModifiedのどっちを採用してるかは不明です。freebsd-ufs上ではModifiedもBirthも同じタイムスタンプになるため、どちらを見てるのかわかりません。

まぁ要するにMTA(Mail Transfer Agent)やMRA(Mail Retrieval Agent)の独自DBだったりMaildirだったりのどこかに、エンベロープのタイムスタンプが書かれているファイルが別途存在する、というわけでは無いと言うことです。

他のMTAやMRAの組み合わせまでは存じませんが、少なくともPostfix+Dovecotでは前述の通りです。

MRAはMUAからIMAPコマンドでINTERNALDATE相当の問い合わせを受けると、それに該当するメールファイルのファイルシステムのModified or BirthのタイムスタンプをOSに問い合わせて、その結果をエンベロープのタイムスタンプと(いうことに)して送って来てるだけと言うことです。

iPhoneの純正のメールアプリはこのエンベロープのタイムスタンプ、つまりメールファイルがサーバのファイルシステムに書き込まれた時点のタイムスタンプメール受信日として取り扱っています。


iPhoneのメールのタイムスタンプがおかしい理由

と、いうわけで、ファイルシステム上のメールファイルのModified属性のタイムスタンプが狂うと、iPhone上のメールアプリの受信日もその狂ったタイムスタンプになります。

他のメールソフトで見るとタイムスタンプがそれっぽいものがちゃんと表示されているのに、同じメールをiPhoneで見るとタイムスタンプがおかしい場合、たぶんこれが原因です。他のメールソフトはDate:ヘッダをParseして表示していたりするんですが、iPhoneのメールアプリはDate:ヘッダを使って無いっぽいです。

メールファイルのタイムスタンプが狂う起因ですが、例えばメールサーバのシェルなどでメールファイルを直接操作するときに、tar cfpやcp -pとかの属性保存オプションの使用を忘れて雑にcpやtarをしたりすると、コピー先でメールファイルのタイムスタンプがファイル操作実行時点のものに書き変わってしまいます。

エンベロープのタイムスタンプの実態はさっき説明したように、実態はメールファイルの置いてあるディスク(ファイルシステム)に記録されたModified属性です。

そのため、メールファイルのModifiedのタイムスタンプが変更されるような操作をすると、本当のエンベロープのタイムスタンプが虚空に消えると言うわけです。

そして、そんな正しいModifiedのデータが虚空に消え、”管理者が雑にファイルを操作した日”とかいう利用者からするとわけのわからんタイムスタンプが入ったメールファイルを含むメールボックスをiPhoneのメールアプリから見ると、その謎の日付が表示されることになります。


修正方法

さて、リストアする方法ですが、きちんとタイムスタンプが保存されているバックアップが無いなら基本的にはありません。

しかし、メールヘッダ内にあるタイムスタンプが信用できるか、(信用できるかどうかに関わらず)信用することにするなら、メールヘッダに入ってるタイムスタンプを元にしてModified属性の日付時刻に修正することは出来ます。

使用出来るタイムスタンプが入ったヘッダは2つあり、Received:ヘッダとDate:ヘッダです。

具体的には、Received:ヘッダのうち最も行頭に近いところにあるReceived:ヘッダの末尾に付いてるタイムスタンプと、Date:ヘッダに含まれるタイムスタンプのいずれかです。1つのReceived:ヘッダが複数行渡って書かれている場合、その1つのReceived:ヘッダ全体の末尾に書かれたタイムスタンプを使用します。

後述しますが、どちらのヘッダを使っても信頼性はケースバイケースです。特に昔の牧歌的な時代のタイムスタンプはReceived:ヘッダであっても正直怪しいです。

そしてReceived:ヘッダを使う方法は1つだけ制限があって、MUA(Mail User Agent/メーラ)が送信時に直接IMAPフォルダに書き込んだメール、つまりSentフォルダや送信済フォルダの中身には使用できません。これらのメールはSMTPサーバを経由しておらず、Received:ヘッダがヘッダに付与されていないので、Date:ヘッダしか使用できません。

Received:ヘッダ

もっとも行頭に近い部分にあるReceived:ヘッダは、メールリレーの終着点である自分のサーバが付けるので、送信者側から詐称が難しく、適切な時刻管理がされていればかなり正確なのが期待できます。この「適切な時刻管理がされていれば」と言うのがミソで、本当に正確かは終着点のサーバの管理次第です。

自営SMTPサーバを持ってて、そのSMTPがメールリレーの終点であれば1番上のReceived:ヘッダは自分のサーバが付与したヘッダになります。

エンベロープのタイムスタンプは終点のメールサーバにファイルが書き込まれた時刻です。MTA内部でメールスプールがふん詰まったりしない限り、通常はSMTPでメールを受信したら即座にMaildirのあるディスクに書き込まれますので、ヘッダ上の自分のサーバへの到着日をエンベロープの到着日とみなすのは一定の合理性があります。

まぁ、実際のところファイル属性値はミリ秒まで書かれているらしいんでが、SMTPのヘッダは1秒未満(=ミリ秒)の情報が無いのでミリ秒の情報はヘッダから復元出来ません。

そのため時刻管理が正しく行われているサーバのReceivedヘッダを使って修正したとしても実は若干不正確なんですが、それでも±1秒レベルぐらいの精度では合うので、秒以前に年月日すら合ってないようなわけわからんタイムスタンプに比べれば全然マシです。

仮に終点が自分のサーバでなくても、読み込んで時差補正さえかければまぁそれっぽい時間にはなります。

ただ時刻管理が杜撰なメールサーバでは、下手するとDate:ヘッダより不正確です。私の場合、過去のメール調べてみると2000年代前半のものはDate:ヘッダや先頭のReceived:ヘッダとその1つ前のReceived:ヘッダに乖離があるものが結構ありました。

まぁ2000年代前半(5号機時代)の私のサーバは時刻同期(NTP)の管理が杜撰そのものでした。当時はメインで使ってるマシンぐらいしかまとも時刻同期してませんでしたし、合わせ方もNTPではなくSNTPで気が向いた時にたまに合わせるぐらいでした(※)。

※今のモダンなOSは特に設定してなくても明確に止めない限り、w32tmなりntpdなりchronydなりsystem-timesyncdなりのNTPが動きます。

Real Time Clock Due to oddities of the Macintosh hardware interrupt priority scheme, NetBSD/mac68k keeps very poor time. Under a high interrupt load (e.g. SCSI or serial port activity), a machine can lose several minutes per hour. A consequence of this problem is that attempting to run ntpd is generally rather pointless.

https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.3/mac68k/INSTALL.html#Known%20hardware%20issues%20with%20this%20release

ちなみに私の場合、杜撰な時刻同期管理に加えて、5号機で使ってたNetBSD/mac68kは上記のようにIO処理が重いと時計が狂う仕様らしいので正確な要素が全く見当たりませんね。実際、SNTP (ntpdate)で合わせると毎回1〜2時間ぐらいズレてて修正かかってました。

しっかりしたISPなら大丈夫だと思いますが、時刻管理が杜撰なサーバの古いメールだとReceivedヘッダの時刻は怪しいかもしれません。

たた、終点が自分のサーバなら、仮にそのサーバの時刻同期が杜撰で多少ズレていたとしても、1番上のReceived:ヘッダは「サーバに到着した時のサーバの時刻」が書かれてます。その時にサーバはその時刻だったのは間違いはないので、目を瞑れる程度のズレならスルーするしてしまうのがいいと思います。

前述したように、Received:ヘッダを採用する方式の弱点は、MUAから直接IMAPサーバに書き込まれたメール、つまり「Sentフォルダ」や「送信済メール」の中身には適用出来ません

これらのメールは基本的にReceivedヘッダが1つも無いことが多いのでReceived:ヘッダの時刻を適用する方法では修正出来ません。これらのメールに対してはDate:ヘッダを使う必要があります。

Date:ヘッダ

Date:ヘッダはReceived:ヘッダと異なり、メールファイル内で付いていないということはまず無いというメリットがあります。

ただ、Date:ヘッダは送信者の自己申告も容易に出来ます。つまり詐称しやすいヘッダです。よって、必ずしも信用できる値が入ってるわけではありません。これが最大のデメリットです。

ただ、これは私の主観にはなりますが、明らかにおかしいタイムスタンプが付いているケースはゼロではありませんが、実際のところはほとんど見かけません(※)。

また、Date:ヘッダを受信時刻として扱うMUAの実装もあるので、「管理者がファイル操作した時刻」というメールの中身と無関係なタイムスタンプよりは、Dateヘッダのタイムスタンプを使う方がまだマシとは言えます。

※たぶんですが、Date:ヘッダは明らかに詐称してるものがあるのでiPhoneは Date:ヘッダでなくエンベロープを見てるのだと思います。

基本はReceived:ヘッダから時刻を引っ張ってきて、なんらかの理由でReceived:ヘッダのタイムスタンプが明らかにおかしいか、SentフォルダなどでReceived:ヘッダがない場合はDateから復旧すれば良いと思われます。


修正の流れ

具体的な流れはメールファイルのヘッダから読み込んだReceived:なりDate:なりにあるタイムスタンプをParseして、整形して、時差を修正して、touch -dコマンドの引数として利用可能なYYYY-MM-DDThh:mm:ss形式(例:2000-05-15T21:15:09)にします。Yuaihoの場合はtouch -dの引数に入れる時刻はローカルタイム、つまり時差修整を含む日本時間を指定しています。

ちなみに、Date:ヘッダのタイムスタンプはYuaihoの持ってるメールだけでも下記のように割とバラエティがあってParseするが割と面倒でした。もし自分でコードを書くのであればReceived:ヘッダを使う方が楽だと思います。Receivedヘッダの方がバラエティが少ないです。

1. Fri, 28 Apr 2006 15:44:57 +0900 (JST) ※PostfixのReceivedヘッダ
2. Fri, 18 Jul 2003 17:58:36 +0900 ※よくわからんMTAのReceivedヘッダ
3. Thu, 18 Sep 2003 08:00:00 +0900 (JST) ※Dateヘッダ/Receivedヘッダと同じ
4. 18 Jan 2006 15:24:58 +0900 ※Dateヘッダ/曜日がないパターン
5. Wed, 5 Apr 2017 18:02:17 +0900 (JST) ※Dateヘッダ/日の0フィル無し(こっちが一般的)
6. Mon, 03 Mar 2008 12:01:34 +0900 (JST) ※Dateヘッダ/日の0フィル有り
7. Wed, 25 Jan 2006 01:52:30 +0900 ※Dateヘッダ/タイムゾーン名なし

上記は私の古いメールを漁って、タイムスタンプがどんな表記をしているのか確かめた実物です。上記の1と2はReceived:ヘッダのパターンで、3〜7はDate:ヘッダのパターンです。

具体的には1がPostfix、2が自宅サーバで受信していないメールから持ってきた詳細のわからないMTAです。3〜7はDate:ヘッダから目に付くものを持ってきたものです。

Received:ヘッダはJSTなどのTZ名の有無ぐらいしか差がありませんが、Date:ヘッダは曜日がなかったり、TZ名がなかったり、日にゼロフィルがあるなど意外とバリーションがあるのがわかります。

上記をうまくParseして、YYYY-MM-DDThh:mm:ss形式のタイムスタンプ文字列が出来たら、touchコマンドでメールファイルのModifiedを下記のように書き換えます。コマンドを実行するとメールファイルのファイルシステム上のタイムスタンプが変更されます。

[yuaiho@yuaiho.net cur]$ touch -d 2000-05-15T21:15:09 <メールファイル>

こうするとエンベロープのタイムスタンプ、つまりINTERNAL DATEをメールヘッダから読み込んだタイムスタンプに修正できます。

ファイルシステムのタイムスタンプを書き換え終わったら、シェルで書き換えたcurやnewフォルダの上位にあるのdovecotのキャッシュファイルを消します。具体的には dovecot-uidlist dovecot.index.log dovecot-keywords dovecot.index.cache の4ファイルです。curやnewなどのディレクトリを消さないようにしてください。削除後のDovecotの再起動は不要です。

-rw-------   1 yuaiho  yuaiho     15 Jan 14  2021 dovecot-keywords
-rw-------   1 yuaiho  yuaiho   2109 Sep 26 12:11 dovecot-uidlist
-rw-------   1 yuaiho  yuaiho  13332 Sep 29 11:56 dovecot.index.cache
-rw-------   1 yuaiho  yuaiho   3484 Sep 29 11:56 dovecot.index.log

ここまで終わったら、iPhone上でそのフォルダを読み直せばさっき修整した日付になる筈です。全ファイル読み直すので時間はかかります。

iPhoneのメールのメールボックスのリスト上では修整されたのに、メールを開いた際に出てくる日付が修整されてない場合はiPhoneの「設定」→「メール」→アカウントでそのメールボックスを含むアカウントを消してから、iPhoneを再起動し、アカウントをもう一度登録すると直ります。

アクセス制御リスト(ACL)の勘所

多くのNW機器やFW、OS、サーバソフトウェアにはアクセス制御(機構)が実装されています。

このアクセス制御機構は多くの場合、Allow list(ホワイトリスト)やDeny list(ブラックリスト)あるいはその両方を含むルールリスト、俗にいうACL(Access Control List)をもってて、アクセスして来たクライアントのIPやポートと、ACLに書かれているルールを比較して、OK、NGを判別しています。

1つのACLの実装しか扱ってないと中々気がつかないんですが、実はACLの評価方法は実装毎に異なります

実装毎の具体的な仕様は必要になったらその場で調べればいいんですが、少なくとも「実装ごとに評価方法は違う」と言うことだけは知っておかないと、慣れてない実装でACLを操作した時に嵌ります。

ポイント

新しいシステムのACLを操作するなら下記はの3つは確認した方が良いと思います。特にハマりやすいのが最初の2つです。新しい実装を触る場合は確認しておきましょう。

  • デフォルトの挙動(デフォルトポリシー)
  • マッチ後の挙動(ファーストマッチかラストマッチか)
  • ステートフル型かステートレス型か

デフォルトの挙動(デフォルトポリシー)

デフォルトの挙動とは「ACL内で明示したルールにマッチしなかったもの」に対する扱いです。例えば、下記のようなACLのところに10.0.5.15のIPが来た場合ですね。

192.168.0.0/24 → 不許可
172.16.0.0/12 → 許可

たまに勘違いしてる方がいるんですが、「ACLにルールを書いてない=暗黙のDeny(Block)」とは限りません。そう言う実装もありますが、全てではありません。

例えばLinuxで使われてるiptablesやnftables、FreeBSDのipfやpfのデフォルト設定は「暗黙のAllow (Permit)」です。ブロードバンドルータの簡易的なFirewall(FW)もデフォルトはAllowだったりします。Apache HTTPdなんかは自分で定義したOrderで、デフォルトのポリシーがAllowかDenyかが決まります。

まぁ、こんな感じでデフォルトAllowの実装は意外とあります。

デフォルトの動作についてちゃんと確認しとかないと、Allow List(ホワイトリスト)で作ったつもりのFirewallが、Default Allowの所為でガバガバになってて、全くアクセス制御されてなかった。とか言う事故に繋がります。

ちなみに、nftablesやiptablesに関してはデフォルトポリシーをDENYやREJECTに変更出来ます。BSDのpfやipfilterもたぶんできると思いますが知りません。


評価後の挙動(ファーストマッチかラストマッチか)

評価後の挙動とはマッチしたあとどうなるかと言うことですね。言い換えるとファーストマッチ型かラストマッチ型ということです。

下記の例で192.168.0.1のIPアドレスを持つクライアントがアクセスして来た時にどうなるかを考えます。

192.168.0.0/24 → 不許可
172.16.0.0/12 → 許可
192.168.0.1/32 → 許可
※DefaultはDenyとします。

ここで、「192.168.0.1は192.168.0.0/24に含まれるからブロックされる」と解釈するのは早計です。実装や書き方に依存しますので、もちろん正しいこともありますが常に正解とは限りません。

ルールにマッチするとACLの評価が終わって、その後ろに書かれてるリストは無視する実装だと上記の「192.168.0.1は192.168.0.0/24に含まれるからブロックされる」という解釈は正解です。

しかし、一度マッチしても評価が止まらず、最後までリストを舐めて、最後にマッチした条件(ここでは192.168.0.1/32の部分)で許可される実装もあります。中には行末に明示的に書いおいたDefault denyがマッチして結局ブロックされる場合もあります。

これも実装に依存します。特に主流らしい主流も無い気がしますし、BSD PFやipfilterのように、実装によってはルール毎(行毎)に当該行以降の評価をやめる/続けるを制御出来るものをあります。

例えばBSD PFは下記の上の行のようにquickを入れない場合はマッチしても評価が終わらず次の行が評価されます。下側のようにquickを入れるとルールマッチした時点でルールの評価が終了し、後ろのルール群は評価されません(無視されます)。

pass in log proto tcp from 172.16.0.1 any to any port 25
block in log quick proto tcp from 172.16.0.0/12 any to any port 25

※上記の場合172.16.0.1からSMTPへのアクセスはブロックされます。

許可した筈なのに許可されない、ブロックしたはずなのにブロックされてないというケースは、(その製品等にバクが無いなら)この評価の継続性やデフォルトの挙動をちゃんと把握してないか、認識を誤ってます。


ステートフル型かステートレス型か

ネットワーク通信はほぼ全てが双方向ですので、サーバであれば入ってくる方だけでは無く、出ていく通信も許可する必要があります。

例えばIPが192.168.5.15のメールサーバ(SMTPサーバ)で、Source 172.16.0.1:5555⇨Destination 192.168.5.15:25という通信が発生した際に、逆方向の通信、つまりサーバから見てSource 192.168.5.15:25⇨Destination 172.16.0.1:5555の通信を、Inbound通信のSourceやDestinaionを見て自動的に許可するのがステートフル型、そういういいい感じの許可をステートレス型のFWです。かなり雑な説明ですが。

どちらかを採用してるかは実装によりますし、ステートフル型でもあってもステートフルに許可する設定が入ってないと機能しないことがあります。例えばnftablesだと「ct state established related accept」みたいなワードを入れてあげないステートフルに動作しません。

ステートフル型はコネクションテーブルを管理する都合上、必要なメモリや処理量がステートレスより重くなりがちで、CPUやメモリをそれなりにリッチに必要とします。そのため、CPUやメモリがリーンな組込系のシステムでは、ステートレス型のアクセス制御機構を採用していることがあります。

ステートフル型はテーブルを持ってるので逆方向の通信は通信終了かタイムアウトまでは許可されます。逆に、ステートレス型は明示的に逆方向の通信を許可しないと通信が出来ません。

ステートレス型は所謂許可された通信の戻りの通信かどうかを見ていませんので。そのためステーレス側のACLにDefault Denyみたいなの強力なブロック性能を持つルールをステートフル型のノリで入れると、外に向けて提供していたサービスがブロックされて止まったり、目の前のコンソールが固まることがあるので注意が必要です。

ただ、サーバの場合、設計者や運用者によってはOutboundがガバガバの場合なケースがあります。こう言う場合はあまり気にすることはありませんが、Outbound側もより適切にフィルタリングしたい場合は注意が必要になります。

その他の勘所

そのほかにYuaihoが思うACLのハマりを紹介します。

IP重複の可否

これはnftablesなんかが該当するんですが、ACL内部でIP重複を認めない実装もあります。実装にもよりますが、host単位(/32や/128)だけはなく、レンジとして重複してるのもダメな実装もあり、例えば下記のようなルールはnftコマンドで同一セットに入れることはできません。

192.168.0.0/24
192.168.0.1/32

一方、nftablesの前世代にあたるiptablesはIP・IPレンジの重複を許容しています。

そのため雑に作ってて重複管理なんかしていないiptablesの中身を、何も考えずにnftablesに移植してくるとハマります。

どうなるかというと、リストの後ろ側で重複してるものが弾かれて、nftの再起動に失敗するなどしてハマります。というか、私はハマりました

ブロックポリシー・Denyポリシー

ブロックポリシー/DenyポリシーというのはルールなどによってDenyされた時、その後Denyされた通信をどう始末するかです。

よくあるのはDROP(静かにパケット破棄して無視する)するかREJECT(拒絶した旨の応答を返す)するかですね。

REJECTはIP FWだとTCP RST等を返したり、Webサーバ等のアプリケーションの場合は403(Forbidden)のような拒絶を示す応答を返したりすることです。

DROPとREJECTのどちらかが良いかは考え方次第で、結局は自分が何を良しとするかです。これについては他のサイトに説明を譲りますが、いずれにしても下記の3要素は考慮したほうが良いです。

1つめはルータやFWなどのOSの前段でもACLを用いてパケットフィルタリングをしてる場合、前段にあるルータやFWと、後段のOSのIP FWのDenyの挙動は合わせた方がいいです。

前段と後段でDenyの挙動を変えると、「特定のポート以外はREJECTで何か返ってくるのに、特定のポートは何も返ってこない」みたいに挙動になります。

これそのポートには何らかのサービスがあることを暗示することに繋がります。これは管理用のSSH等、隠蔽したいサービスやポートを開いている場合は適切ではありません。

2つめはIP FWでDROPを行うとクライアントがTCP SYN等を再送してくることがあります。FWでSYNの時点でログ出力する設定をしてると、DROPの場合この再送によってログの行数が無駄に増えます。大体2〜3回再送してくるので、これに伴ってDROPログも2〜3倍無駄にに増えます。

体感的な傾向では、攻撃観点ではIP FWの場合はREJECTにしてTCP RST送っておくと即座に諦めてくれることが多いです。ただ、REJECTされてもめげないIPはちょくちょくいます。まじでクソですね。またアプリケーションが行うREJECT場合、REJET(Webなら403 Forbidden等)を出しても諦めてくれるのは期待薄です。

ちなみに、YuaihoはIP FWではDROP派です。上記は一見REJECTを推してますが、Yuaihoが所有する機材はDROPしてることの方が圧倒的に多いです。

3つ目はアプリケーションの場合、DROPを返すと何も方法を与えないことができますが、REJECT応答を返すとそのサービスが稼働してること自体はわかってしまいます。ここでバナー隠蔽などの設定が漏れていると、OSやソフトウェアバージョンなどもわかってしまうことがあります。

最後に

ACLはこんな感じで実装ごとに動作挙動が異なります。

某C社の「暗黙のDeny」は結構有名ですが、「暗黙のDeny」は別にACLの標準仕様でもデファクトスタンダードでもありません。これまで見てきたように、本当に実装ごとに違いますし、なんなら暗黙のAllowも普通にあります。

初めて触れるアクセス制御機構を設定するときは、少なくとも「デフォルトの挙動」「マッチ後の挙動」ぐらいは確認しないとガバガバACLを作る可能性があります。事故った時にシャレにならないことになる方は特に注意しましょう・・・。