サーバ関係」カテゴリーアーカイブ

28号機の更改(3期構成→4期構成+各パーツ修繕)

先日…といってもこれもまた結構前なんですが、28号機の更改を終わらせました。28号機は去年の暮れあたりに、Gemini Lake RefreshでJ4125-ITXでASRockJ4105-ITXの置き換え(マザーボード入れ替え)を行い、28号機4期構成となりました。この時はマザーボードのみを取り替えるいつもの手抜き更改をしました。

ただ、ファンと電源は新造時(2015年)から同じものをずっと使っていました。SSDも2期構成からずっと同じです。OSもCentOS7で、建造当時の2015年時点では最新ですが、2024年ではEoSL寸前です。色々と見過ごせないレベルで古いパーツやソフトウェアが跋扈してる状態だったので、これらも全部入れ替えてリフレッシュしました。

28号機の用途は先日書いた39号機の対向側にいるOpenVPNサーバ(L3VPNルータ)です。

マザーボード

28号機4機構成のマザーボードはJ4125-ITXです。

28号機3期ではASRock J4105-ITXでした。ASRock J4105-ITXは16号機3期構成にも搭載されていました。この16号機側のJ4105-ITXは元を辿ると13号機(4期構成)のお下がりなんですが、2022年ごろからHDD LEDの挙動が怪しく、点灯しっぱなしだったり正しい動作したりと非常に気持ち悪く、交換したい気持ち満々でした。

ただ、2023年にもなってJ4105-ITXを新品で買ってくるのはさすがにバカバカしいです(売ってはいました)。そこで、修理したい16号機と同じASRock 4105-ITXを積んでいる28号機3期を更改して、余ったマザボでJ4105-ITXを修理しようとしてできたのがこの28号機4期構成です。

13号機や21号機はJ5040-ITXを積んでるので、28号機もJ4125-ITXの上位版であるJ5040-ITXを入れたかったです。ただ、J5040-ITXは2023年秋の時点では正規販売がなくなっていたので、妥協してJ4125-ITXにしました。

マザーボードだけ入れ替えは2023年の秋にやったのですがその時は、それ以外はそのままでした。

メモリ

メモリはCFD PanramのDDR4 SO-DIMM 8GBx2枚で16GBにしました。3期では4GBx2枚の8GBで、マザーボードを入れ替えて4期構成にした時点ではこれを使い回しましたが、ファンやSSD、電源交換に合わせてメモリも交換して16GB化にしました。

まぁ、ぶっちゃけるまでもなくこのマシンの用途に対して16GBは過剰なんですが、2021年ごろからメモリは最低16GB積むことにしたので16GBです。まぁOSの名前以外はほぼ同じ構成で同じ用途の39号機は32GBなのでそれに比べれば全然控えめです。

CFD Panramなのはまともブランドで安い製品を選んだらこれでした。まぁ個人的にはCFDと言う会社はあんまり好きでは無いのですが、CFD ElixerやCFD Crucial、CFD Panramあたりのメモリに関しては安い割に不良が殆ど無いので楽です。信頼できるんじゃないかなと思います。

ストレージ(SSD)

ストレージはCrucial MX500 120GBから、HP(Hewlett Packard)のS600シリーズのSATA 240GBに置換しました。4期構成にした時はMX500を続投したのですが、ファンや電源、メモリ交換に合わせてSSDも交換しました。3期構成も4期構成も1台構成です。

PCメーカー製(HP)という珍しいSSDです。まぁ、どうせ中身はどっかのOEMでしょうけど、中華製ではないまともなメーカーで、コントローラがSiliconMotion製(SMxxxx)ではなく、TBWが100GB以上ある250GBのSATA SSDで最も安いのはHP S600の240GBでした。

Crucial MX500 120GB自体はまだ全然使えたのですが、中身がCentOS7でアップグレード先が無く、後継で使う予定のAlma LinuxがOpenVPNルータの用途に耐えるかは1ミリも検証してませんでした。さすがにそのまま上書きして入れる勇気は無く、SSDは入れ替えてCentOS7の環境は保持することにしました。

ファン

28号機は実家に置いてあって、夏は50℃近くまで上がる過酷な環境です。そのため、実家に配備しているすべてのマシンに強制空冷ファンが付いて居ます。28号機も同様に強制空冷ファンがついています。

28号機の元のファンは新造時に一緒に買って付けたもので、オウルテック扱いの山洋電気 SF8-S1を2発です。SST-ML06Bは80mmファンが2基と120mmファンが1機付く構成ですが、ファンはすべてオプションで付属品はありません。そのためこの山洋電気のファンも私が新造時に一緒に買ってきて入れました。当初は吸気ファンだったんですが、2期目にしたあたりで天板にフィルタをつけたので、裏返して排気ファンに入れ替えています。

ファンは2発とも内側にグリル(フィンガーガード)をつけています。ケーブル巻き込み防止のためですね。グリルとファンはM4x35mmの皿小頭ビス(黒)とセレート付きフランジナットで固定しています。筐体色と同じでビスが筐体とツライチになるようにしてビスが目立たないようにしてあります。こだわり部分です。ちなみにM4x35mmの皿小頭ビス(黒)はモノタロウで買いました。モノタロウの注文コードは41691377です。ちなみにこの注文コードは普通にモノタロウに出てるので、これを指名買いで買っても私には一銭も一報も入りません。

セレート付きフランジナットは締めると緩みにくくワッシャーも不要で、共回りしにくいため把持用の工具なしでビスを回せるので、ファンを貫通ボルトで止める際のナットとして便利です。

話を戻すと、元のファンはさすが山洋電気製だけあって、温度差の激しい実家で9年近く過ごしても壊れてはいません。ただ、異音は出ていました。交換品を探したところ、新造時に買ったSF8-S1が2024年でもディスコンになっておらず、当時ほぼ同じ値段で買えたので、同一型番の新品で置換しました。

SF8-S1はPWM制御ができない3pinファンなので電圧制御しています。ファンがPMWに対応したところで、どのみちJ4125-ITXのマザーボード側コネクタは3pinなのでどのみち電圧制御でしか運用はできません。

SF8-S1の定格速度は800rpmですか、マザーボード側のファンコンで調整して凡そ400〜500rpmで回してます。ちなみにMBのケースファン側の制御を最低レベルにしたら交換前は回ってたのに交換後のファンは回りませんでした。まぁ、山洋電気のファンは11.4V未満の動作保証は無いのでこれは個体ですね。

28号機はフルパワーでもせいぜい20W程度で、筐体もファンも発熱量に対してはかなり余裕があります。そのため8cmファンをゆるゆる回していれば余裕で排熱出来ます。というか、不必要に高速で回すと埃が早く溜まるので、出来る限り回転速度を落としています。

電源

電源は13/21/33号機と同じに構成にしました。Mini-box picoPSU-120-WI-25 と Meanwell GST90A19-P1Mの構成です。

28号機のSST-ML06BはSFX電源が入るケースで、記憶が怪しいのですが昔はたしか電源付きで売られていました(と思います)。もとの電源はその付属品(たぶん)で、SST-SF300というSilverstone製の80PLUS BronzeのSFX電源(300W)でした。この電源は新造以来一度も交換しておらず、最も故障を懸念していたパーツでした。まぁ懸念しつつも2022年ぐらいから交換の検討してて、19号機同様にFSPあたりのフルプラグインにしたいと思っていました。28号機のようなシンプルな構成で直付けだと使わない電源コード・コネクタが多くて邪魔です。次ぐらいに写真があると思いますが、実際に使わないケーブルは無理やり押し込んでいました。

下の写真はSST-ML06の電源とストレージエリアなんですが、このケースはこの部分の設計がクソで、プラグイン電源は(入る気はしますが)ちょっと収まる自信がありません。写真の電源はSFXの規格サイズ(奥行き100mm)なので特に大型のものを搭載しているわけでは有りません。

28号機の電源・ストレージエリア

28号機は前々からACアダプタ電源化したかったのですが、SFX用DCジャックのホールがあるパネルが2019ぐらいを堺にオリオスペックから取扱いが無くなったので困っていました。仕方ないので、34号機の引退を機に、34号機にから剥がして持って来て、34号機は中国の某有名通販サイトから買った怪しいSFXのアルミグリルのパネルをつけることにしました。

picoPSU-120-WI-25 をSST-ML06B + J4125-ITXにつけると、基板とコネクタ部の屈曲が気にならなくはないですが、まぁそれなりに無難に取付できました。ただ、SST-ML06のSFXパネルとJ4125-ITXのATX24pinコネクタは若干遠いので線はそこそこピン張りになります。J4125-ITXのATX電源コネクタは24pinですが、picoPSU-120-WI-25 はのコネクタは20pinです。しかし、変換せずATX24ピンのコネクタに20ピンだけさしてに挿して使っています。これは13/21/33号機も同じです。なのでマザーボード側のATX24ピンは4ピン分空いています。まぁこの4ピンはPCI/PCIeの電源強化らしいので、何も刺してないに近しい28号機なら問題はありません。

ACアダプタは私の中で採用実績豊かなMeanwell GST90A19-P1Mです。50℃雰囲気での寿命や60W出力を担保できて、最も安いのがこの機種です。DELTAも選択肢にはありましたが、同様の性能で1.5倍ぐらい高い割に温度デグレードが大きいのでMeanwell GST90A19-P1M一択です。

電源を交換したら16W前後食っていたのが14W程度になりました。構成の割には大食いな気もしますが、PCIeの増設カードを積んでるという要素もあるため致し方ないという感じです。

OS

OSは元がCentOS7だったので、Alma Linux 9.4を入れています。インストールはMinimum Installです。ここにEPELリポジトリを追加してOpenVPNをインストールしています。このOpenVPNは先日の39号機同様のディレクトリ分けがあります。

このAlmalinuxはSELinuxを有効にしています。SELinuxはMinimum Installでも有効なんですが、Rocky Linux 9.4ではデフォルトでインストールされるsemanageが、何故かAlmalinuxではデフォルトでインストールされません。まぁ、dnfで普通に入れられますが手間かかって面倒ですね。

39号機的な説明をすると、28号機は21号機のOpenVPNサーバの部分だけ切り出したマシンです。なのでブランチ元の21号機のOSに倣うならUbuntu Server LTSです。実際、28号機は導入当初は本当にUbuntuだったんですが、Intel C1 State Bugを対応している過程でCentOSに入れ替えたのでそのままRHELの流れを汲む方向になりました。

NIC

39号機と同一機種のにtp-linkのNIC(ギガ蟹)が積んであります。tp-linkのNICは新造時からあったものではなく、新造時IntelのNIC(Intel Gigabit CT Desktop Adapter)を積んでいました。しかし、対向側にいる34号機を新造した時に増設NICをtp-linkにしたので、28号機も合わせる形でIntelからtp-linkに交換しました。

Intelからtp-linkにしたのは基板面積や消費電力がIntelより小さかったからです。というか、以前のIntelのNICは2009年ごろに17号機に搭載するつもりで買って6年ほど放置していた余剰品です。2000年代のGbEのNICは今ほど省電力化も進んでいなくて、基板が大きかったです。28号機建造当時は金がなかったのでNICは余り物を入れてましたが、物理サイズと電力消費が嫌で省電力なtp-link(Realtek)にしました。消費電力も若干下がってたと思います。

ちなみにこのIntel Gigabit CT Desktop Adapterは正規流通品を買ったわけではないので偽物かもしれませんが、現物を捨ててしまったので謎です。

コメント

9年近く稼働してて不安要素が多々あった28号機でしたが、ケース以外を総取り替えしたおかげでで不安要素はなくなりました。ただ、所詮はSST-ML06なのでこの役目(OpenVPN)が精々かなって感じですね。まぁ安いケースなので仕方ないんですけどね。

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

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

34号機は紹介のページにもありますが、先代の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の65W電源を使っていました。秋月のGF社製の電源はまぁまぁ静かで可もなく不可もなくという感じですが、秋月のDC電源のバレルプラグは殆どが2.1/5.5mmなのでそのままでは2.5mm/5.5mmのバレルジャックでは挿さりません。なので変換アダプタを咬ませていましたが、この変換アダプタが地味に鬱陶しいので37号機や38号機と構成を合わせる形にしました。

ケースは異なりますが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号機はデータ(所謂ユーザデータ)をほとんど持っていません。そのため耐久性はあまり考慮せず安価なSSDを採用しています。37号機や38号機はシステム用とデータ用(/home用)の2台のSSDを積んでますが、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製を買われた方が(個人的には)無難だと思います。まぁそういってもIntel製のNICは量販店とかになかなか売ってないんですけどね。

ちなみに、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などを引き継いて運用を再開することができました。

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

メールファイルの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を作る可能性があります。事故った時にシャレにならないことになる方は特に注意しましょう・・・。

拠点間OpenVPNはNGN経由で繋ぐと結構速い

 Yuaihoは実家と自宅の両方にPCやネットワークを持っていて、NGN経由のVPNで(ほぼ)常時接続されています。ほぼと言うのはVPNルータはただのLinuxマシンなのでyumとかでOSのメンテナンスした後にリブートかけると切れます。

 VPNで拠点感同士を接続してるNWは昔は実家も自宅もOCN経由でしたが、まだOCNにUpload 30GB制限があった時代に1TBぐらい転送したら怒られたので、2010年代終わりぐらいからNGNで接続しています。今のOCNは転送制限が廃止されているので制限無く垂れ流せますが戻る気はありません。

 まぁ、実際はNGNに行き着く前に、転送制限が無くて安いISPを色々使ってみたのですが、速度に難がありました。色々試してみて、結局NGN経由ならISP不要で維持費がかからないのでNGNに落ち着きました。

 どことは言いませんが、ひどいISPは夜間がADSLより遅くて「これが噂に効く光ナローバンドか…実在するんだな」と思ったことがあります。


 NGNはフレッツユーザであれば漏れなく接続されてます。そして実はNTT東日本管内or西日本管内であれば(IPv6さえわかれば)、ノード同士を直結出来ます。しかも現時点ではNGN内は事実上、帯域制限も転送量制限も無くて流し放題です。

 ただ、NGNはNTT東とNTT西では分断されてますので、東京に実家があって、大阪に自宅があるのでそれをNGNだけでつなぐというのは無理です。

 しかし両拠点がNTT東日本内、またはNTT西日本内であれば両拠点にIPv6オプションつけるだけでノード間をIPv6で接続できます。両拠点のIPv6オプションさえつけとけばそれ以外の申請は不要です。


 このオプションは月額は無料なんですが、フレッツスクエアというIPv4で繋ぐのが結構難しい所経由で申請しないと、(つまり電話などで申し込むと)申請手数料が2,000円ぐらいかかると言う曲者です。

ISP契約は不要ですが以下の制限はありますね。
・NGN網内はIPv6しか使えません。
・IPv6のISP契約がないとNGNだけではIPoEでIPv6でインターネットには接続できない(※)。
※IPoEで出来ないという意味であってPPPoEでIPv6のインターネット接続はできます。

NGNのIPv6はルータが適切に設定されていれば、ルータのWAN側を繋ぐだけで/64がICMPv6 RAで降ってきます。降ってくるIPv6のブロックサイズは電話などの契約してるオプションによっても変わるみたいですが、ほぼ素の契約だと/64が降ってきます。

/64の場合、左側64bitは契約変えるとか引っ越すとかが無い限りほぼ固定です。私も数年変わってません。ユーザが任意に設定できるのは右側64bitのみです。ちなみに<自分に割り当てられた/64>::fffeがNGN側のGWっぽいです。

IPv6の右側の生成はIPv6を使う機器次第ですが、面倒なら機器側で固定してしまうか、SoftEtherで有名な登遊大氏がNGNで使えるDynamic DNSを作られてる(i.open.ad.jp)ので、そちらを使うのも一手です。NGN内のフルリゾルバでも引けますし、Pingで更新できて便利です。


VPNは私の場合、OpenVPNを使っていて拠点同士はL3接続しています。実家側をサーバにしています。

OpenVPNは少なくともトンネル掘る側(WAN側)はIPv6に対応していますので、今までIPv4で接続していたのであればOpenVPNクライアント側のOpenVPNのremoteをIPv6アドレスに書き換えれば、IPv4からそのまま移行可能です。ただ、WAN側をIPv6のTCPで繋ぐ場合は「proto tcp-client」にしないとダメ(proto tcpではダメ)っぽいです。

OpenVPN同士がIPv6で、各拠点のLAN内はIPv4 Onlyでも特に問題なく繋がります。WAN側がIPv6でもちゃんとPeer to PeerのGWはIPv4ですし、向こうの拠点のIPv4で接続出来ます。

NGN経由だとIPoEになりますので、フレッツ接続時とはMTU/MSSが異なります。IPoEは1,500 [Byte]ですが、フレッツはIPv4の場合1,454 [Byte]前後なので基本的にフレッツ接続時よりもMTUやMSSや大きくなります。チューニングされてる場合は見直すと速度が出るかもしれません。

OpenVPNのMTUやMSSの設定は私も色々勉強して、『IPヘッダーが入るから4 or 20 [Byte]引いて〜』みたいに計算してチューニングやりましたが、(24時間帯域いっぱいまで送受信する必要があるとかでなければ)ぶっちゃけOpenVPNによる自動決定が1番楽で、速度も十分です。

1バイト単位でカリカリに詰めてチューンしても、PONなりマンション内のスイッチなり、自分のNWなりの同時接続者の使用帯域変動の方が大きくてまともな効果測定が出来ません。そのため、24時間帯域をいっぱいいっぱい使って最大限効率的に送受信したいとかの需要がないなら、カリカリに詰めるのを頑張るよりも利用者少ない深夜に送る方が断然速いです。

NGN網はセキュリティのことをガン無視なら向こうの拠点のIPv6打ち込めば直結出来ますが、私は一応暗号化しておきたいのでOpenVPNを入れています。OpenVPNのオーバーヘッドは正確に計算したわけではありませんが大体8〜9%です。まぁ小さくはないですね。Wire Guardにしたらどうなんだろう?とは思います。

この方法は応用すると距離による遅延を気にしないなら、実家だけISP契約しておいて、自分はNGN VPN経由で実家のISP使うとかも出来ます。LAN内のDefault GWを全部VPNルータに向けてしまえばいいんですね。通過するノードの経路設定を正しく行う必要はありますが。


NGN網内が素通りできるのはNTTはあまり表立っては言っていませんが、レンタル可能なHGWのマニュアルを見るそういう通信が出来そうだというがちゃんと書かれてます。

IPv6セキュリティのレベル (初期値: 標準)
IPv6セキュリティのレベルを設定します。
「標準」
NTT東日本のフレッツ 光ネクスト網内で折り返す通信(NTT東日本との契約により可能となるもの)を許容します。
「高度」
NTT東日本のフレッツ 光ネクスト網内で折り返す通信(NTT東日本との契約により可能となるもの)を拒否します。
※セキュリティレベルを「高度」に設定し、NTT東日本のフレッツ 光ネクスト網内で折り返す通信(NTT東日本との契約により可能となるもの)を行う場合には、個別に通信を許容するパケットフィルタルールを設定の上、ご利用ください。 

PR-500KI / RS-500KI / RT-500KI 機能詳細ガイド NTT東日本, 2022.09.03閲覧

このマニュアルを初めてみた当時はカッコ内のNTT東日本との契約云々の文言は無かった気がしますが、これは言い換えると「NGN網内では、あなたのサブネット外から入ってくる通信が出来ますよー」ってことなんですよね。で、やってみたら出来たと言うわけです。

まぁ、この「IPv6セキュリティのレベル」の設定、「高度」にしても効いてるのか知らないですけどね。見た感じAtermと同じ、NECAT/NECPF製だと思いますが、このメーカのこの画面が出る似たような機種は/64だとNGNにLayer 2接続してLAN内にIPv6ばら撒きませんでしたっけ?って感じです。

私はL2接続されるのが嫌でOpenWrtを使って、NGNに繋ぐルータにNDP/RA Relay modeを入れて接続してしてるですが、NTTのこのHGWの場合、この設定を「高度」にするとNDP/RA Relayモードになるんですかね?まぁ、私はこのHGWは持ってなくて、ONU/VDSLから先は自前の設備なので知らないですけど。

これが出来るのはフレッツだけの話です。auひかりとかNURO光とか、CATV系はNGN網を通らず、ISPに直結なのでこの技は無理です。