約20年前の、動作速度 1GHz 前後のシングルコアCPUのマザーボード、Teir2 となっている FreeBSD/x86 OS をソースビルドしたらどれくらい時間が掛かるか?
32bit FreeBSD はFreeBSD13 から Tier2 サポートとなってしまい、これからも現役で使い続けるとすると、脆弱性が見つかった時、OS自体をソースビルドでメンテナンスし続けるしかありません。
現代世代のマルチコアCPUで動いているFreeBSDでクロスビルドし、リモートアップデートできるなら Tier2 FreeBSD の更新も割と簡単に行えるでしょけど、セルフビルドせざるを得ない環境だと、どれくらい時間が掛かるのか?
古いPCパーツを整理しようとしている今、現実的にできる範囲で実行してみました。
P3B-F
- CPU: Pentium III 700MHz
- メモリ:SDRAM 256MBx4 = 1GHz
- HDD: 160GB SATA HDD, Buffalo IFC-ATS2P2 と接続、起動
オンボードIDEではなく、Buffalo の拡張SATAカードに接続したSATA2 HDDでテスト(拡張ボードは150MB/sec なので SATA I 相当)。これは、約8年前に拡張SATAカードに接続するSATA HDD上にFreeBSD OSを置いた場合、頻繁にOSがクラッシュしていた件が、今はどうなっているかを確認するためも兼ねた環境のため。
GA-7VTXE
- CPU: AthlonXP 1600+
- メモリ:DDR SDRAM 1GB x3 = 3GB
- HDD: 20GB HDD ATA-66
メモリを最大に拡張し、HDDだけ運用中のものを流用した環境。
2024年現在、シングルコアCPUを運用するなら、これくらいメモリを拡張して、出来る限りスワップしないようにしないと。という環境でビルドを実施。特にB3B-Fは、ビルド以外のジョブを動かしてメモリリソースが減ると、スワップしてしまうので、それが起きないように1GB搭載しました。
GA-7VTXEの方は、3GB搭載してあるのでbuildworldくらいは余裕。
build 実行結果計測は、画面上に表示されたデータを目で読み取ることで推測し、細かい実行時間は記録していません。分単位の時間に意味ありませんからね。また、make buildworld → make kernel は目で確認して手動実行。
実行結果
P3B-F での make biuildworld 実行結果は、約97時間。そこから、make kernel でカーネルを更新 に約7時間。更に、make installworld に、約30分。約115時間。5日がかりの作業となりました。
GA-7VTXE の方は、buildとは異なる原因(file system full)で一度再起動が発生したり、日常ジョブが動いたため、ちょっと計測条件が異なりますが、make buildworld に約90時間、make kernel で約4時間。make installworld に約30分。
make installworld は放置プレイになるので、約2時間という数字は適当。ファイルシステムのタイムスタンプから推測しています。
各コマンドの間は、画面を確認してから手動で発行するので、ず~と画面を監視していれば、1,2時間は節約できるかもしれませんが、それは非現実的。時々端末を眺めて、気付いたら次のステップに進むという流れで測定したのが上の結果。
Pentium III 700Mz と Athlon XP 1600+ ではCPU性能がが倍・半分くらい違うので、ビルドに大きな差が出るかと思っていましたけど、ビルド作業はIOアクセスが多発するし、OSも普通に使っていたので、それぞれの終了まで、半日程度の差は付いたものの、日単位の差は付かず。
ビルドに必要なメモリ容量を確保できる場合、
- Pentium III 700MHz で、4.5日
- Athlon XP 1600+ で 4日
というところ。SATA SSD を使えば、もっと短縮できるかもしれませんけど、あくまでも昔から使い続けているハードウェアを、コストを掛けずに使い続けるというのがテーマ。
最大搭載可能メモリが 512MB、CPUクロックが500MHz クラスの環境となると、ビルド中にスワップしまくるのこと確実なので、こういうTier2 となると、また別の考え方が必要なのかも。
運用では、
こういう結果になりましたけど、運用に使う場合どうするの? グローバルネットワークに、Tier2 ハードウェアをつないでおくと、脆弱性が発見されてから、それに気づき、塞ぐまでに4~5日かかるわけで、時間が掛かりすぎることが予想できます。
これでは時間が掛かりすぎるので、リスクを小さくするためには、
- (対策中は、)外部公開サーバーとしては使わない。(恒久的に)内部用サーバーとしてだけ使う。
- OSのリビルドは別の高速なクロス環境で行い、エクスポートされた /usr/src, /usr/obj を使ってインストールだけ行う。(環境を整えて実験することが必要。)
- 毎日、cron で、/usr/src を git pull で更新し、毎週程度「make -DNO_CLEAN buildworld」で、差分を更新し続ける。こうすれば、いざという時、差分だけ追加ビルドすればすぐに終わる。
という感じでしょうか。3がよさそう。
脆弱性が発見された時、バイナリー更新できないのは大変かと考えましたが、対策しておけば何とかなりそうというのが今回の結論。
すでに持っているハードウェアを寿命が尽きるまで使うのであって、わざわざ購入してまで使うハードウェアではありません。この程度のハードウェア性能でも、メールサーバー、DNSサーバー、ファイルサーバーとしてなら十分に機能するわけで、適材適所で使い続けられればと思います。