朝、FreeBSD サーバーから届いたセキュリティーレポートを見たら、脆弱性が発見されたという内容が含まれていました。
Checking for security vulnerabilities in base (userland & kernel): Fetching vuln.xml.xz: .......... done 0 problem(s) in 0 installed package(s) found. vulnxml file up-to-date FreeBSD-13.2_4 is vulnerable: FreeBSD -- libc stdio buffer overflow CVE: CVE-2023-5941 WWW: https://vuxml.FreeBSD.org/freebsd/5afcc9a4-7e04-11ee-8e38-002590c1f29c.html FreeBSD -- Incorrect libcap_net limitation list manipulation CVE: CVE-2023-5978 WWW: https://vuxml.FreeBSD.org/freebsd/f4464e49-7e04-11ee-8e38-002590c1f29c.html 2 problem(s) in 1 installed package(s) found.
パッと見た感じ、イントラネット側のサーバーはしばらく放置しても問題なさそう。
公開サーバーのFreeBSD/amd64 の方も、同じレポートが届いているなら更新を掛ける方がよさそう。と、amd64 サーバーの方は freebsd-update を実行してみました。
amd64 の結果は、/boot/kernel は書き換わらず、対象となった主に /lib 下のファイルと /rescue したファイルが更新された模様。なので、即時リブートは必要ないかなと思っています。書き換え対象となったライブラリがメモリに貼りついていると困るので、数日中には再起動しますが、昼間に再起動する必要はなさそう。
問題はソースメンテナンスとなっている 32bit FreeBSD13.2。FreeBSD/arm は、
cd /usr/src; git pull
でソースを新しくしたところ、lib/stdio と libcasper ソースだけ更新されているので、カーネル関係なさそう。
UPDATING | 14 ++++++++++++++ lib/libc/regex/regcomp.c | 8 ++++---- lib/libc/stdio/fflush.c | 27 ++++++++++----------------- lib/libc/stdio/fvwrite.c | 14 ++------------ lib/libc/stdio/wbuf.c | 12 ++---------- lib/libcasper/services/cap_net/cap_net.c | 2 +- lib/libcasper/services/cap_net/tests/net_test.c | 12 ++++++++++++ sys/conf/newvers.sh | 2 +- usr.sbin/freebsd-update/freebsd-update.sh | 2 +- 9 files changed, 47 insertions(+), 46 deletions(-)
一応、make kernel しましたけど、しなくてよかったのかも。（←不要だった。）
make -j3 buildworld
して、
make installworld
すればいい。（-j4 にしなかったのは、1個はMySQL用に空けておきたかったから。）
build に3CPUで30時間くらい掛かり、インストールに更に20分くらい。再起動も不要のような感じですけど、ライブラリがメモリに張り付いていると嫌なので、ビルドとインストールが終わったてRPI2を再起動しました。
そして、セキュリティーレポートの脆弱性部分が消えた。
Checking for security vulnerabilities in base (userland & kernel): Database fetched: 2023-11-12T00:06+09:00 0 problem(s) in 0 installed package(s) found. 0 problem(s) in 0 installed package(s) found.
処置は正しかったようです。
分かったことは、バイナリーメンテナンスがサポートされていないソースビルド32bit FreeBSDでもOSメンテナンスは可能ということ。可能は可能だけど、データベースサーバーとして実際に動いているマシンのOSメンテナンスは、ビルド中パフォーマンスがかなり低下することと、OS再起動で停止させなくてはならず、再起動を深夜の時間にターゲットすると、ビルドが昼間に終了しても、そのあと半日待たなくてはならず、仮に運用パフォーマンスに影響が出ないとしても、作業のスケジュールが大変とわかりました。
ports コレクションなんかは、ビルドするサーバーとパッケージを利用するホストを分けられる（はずな）のですが、OS全部となると /usr/src/Makefile を読んでもやり方はわからない。
あと、WordPress 用に運用する MySQLサーバーに必要なメモリ容量。個人が運用するコンテンツ程度であれば1GB RPI2でも大丈夫。4コアは十分すぎるスペック。炎上しなければ1～2コアでいけるんじゃないかと思います。MySQLとFreeBSDの組み合わせは、メモリが足りていようといまいと、データをスワップに逃がし、メモリを空けるような動作をするようで、数日時間が経過すると、スワップサイズが500MBくらいに膨れます。ソースビルドも同時に行うと、ソースコードによってはビルド関係のプロセスが300MBくらいスワップを使い、MySQLと合わせてピーク時、1.1GBくらいまで膨らみますが、ビルドが別のソースに移ると解放されて、800MBくらいに戻ります。結局スワップサイズは600MB～1.1GBのあたりをフラフラし、スワップがUSB2.0ポートにつながれたHDD上にあっても極端にパフォーマンスに悪影響を及ぼすことはない感じでした。
ただし、RPI2は能力はあっても長期間運用に向いているとは思えず、ちょっとした衝撃でケーブル類が接触不良を起こし電源Off/On のリブートが必要になるケースがあります。SDメモリのシステムで、手順を踏まない電源Offはやりたくないことですが、外からは電源を切るしか手を出せない状況になるとUSB電源ケーブルを抜くしかなくなる。
いろいろやってみなきゃわからないことばかり。