FreeBSD14.0 アップグレード祭り

いつやるか？じゃなくて、今やるんだよ。

月日は百代の過客にして・・・12.4-RELEASEから、もう1年経ってしまいました。
放置してもいい人はたぶん慌てないほうがいいのかもしれませんが、そうも云っていられない事情は下記に。

14.0に上げる理由

• DNS/MAILの問題がのっぴきならない状況になりました
  FreeBSD 12.4 でも未だに djbdnsで手抜きをしていましたが、流石に20年経ってしまってオリジナルは変わらないままというのが、もはや許されないという(djbdnsがportsから削除される）世界になっています。　MTAにはまだ猶予がありましたとはいえ引導が渡されるのも時間の問題でした。オリジナルのqmailは、perlとはそんなに依存していないのですが、patchを当ててると perlに依存し、Perl5.32が ports からいなくなった今それらを入れ替えるときに大騒ぎになってしまいます。 MTAは postfixにしても、もう熟れていていいだろうし、powerdnsは時々セキュリティで何か出ますが、BINDほどでないし、tinydnsと同じ様式を扱えるので、それで。
• OpenSSLの問題が・・・　1.1.1 依存しているものを排除しないといけません

FreeBSD14.0 に upgrade するのは基本的に難しくはない。

BETA/RCを入れている時点で特に駄目だったことはなかったです。13.x からだと、もう大きな変更はなかった感覚です。寧ろ13.xより性能が上がるということもあります。

ZFSは未だ怖い。ZFS頼りになるけどまだ怖い。

• FreeBSD 14.0p1 が 半月ほどで出たのは、zfs.ko の差し替えが大きいのだと思っています。
• 他のメジャーバージョンでも軒並みパッチが出ました。要注意だと思います。
• https://www.theregister.com/2023/11/27/openzfs_2_2_0_data_corruption/
  この記事に書かれているような理由で壊されたのかはわかりませんが、更地の新品サーバに、しかもなんとFreeBSD14.0 on zfs-mirrorを入れて１日くらいしか経っていないのに rootfs が壊れて起動しなくなるという事故がありました。　実は2023年10月は、いくつかのサーバで rootfsが壊れて起動しなくなる＝再起動後に発覚するというトラブルに遭遇していました。 rootfs であるためユーザデータの喪失がなく復旧も出来て助かったというのはありますが、ことZFSに関しては、FreeBSD14.0リリースのタイミングの時期に何か問題があったのかもしれません。誤操作にしては３台のうち１台はまだ碌々サービスインもしていなかったのもあったので、どう考えても 同時期にbastillebsd でエンバグしていた可能性も高いのですが、jail + zfs の設定をしているので、zfsの操作で何かが起きたのは間違いないかと思います。 gpart bootcode を書き直せというのも、結構以前から警告が出るので、 zpool upgrade 時にしわすれたことはないはず。ちなみに、現在の FreeBSD/ UEFI bootそのものは、どうも幾重に起動プロセスが組まれているので、freebsd-boot パーティションなしで起動できる設定が存在し、管理下に珍しい設定の機材が１つだけありますが、この辺の深堀りはいずれまた。

アップグレード祭り

小職は、FreeBSDサーバを20台以上バラバラに管理しているので、祭りが始まると寝る時間が極端に減ります。メチャクチャ消耗します。 自動化？出来たら良かったんですが、perl/python/rubyを入れ替えると死ぬでしょうアイツラ？ねえ。出来るわけないんですよ。無論100台くらい1サイトに同じような目的で設置してあれば自動化の価値はありますが、さていくつか気がついたことを書きましょう。

• 要注意 resolv.conf を編集しておきましょう ：　(local_)unbound が動かなくなっていたりします。 resolv.conf で 127.0.0.1 に解決させているケースでは、 ssh ログインがなかなか通らず焦ります。　予め、別のマシンやサービスを利用して名前解決出来るようにしておくと、sshなどで苦労しません。

• screen/tmux は入れておけ： screen/tmux がないと後悔と苦労をします。以前に比べると ユーザランドの install時に ssh 周りが死んでしまう事故対策が取られていて、備え付けのスクリプトが自動で sshd を再起動してくれるので困ったことにはなりませんが、何らかの理由でdetach されると freebsd-update そのものがやりなおしになることもあります。そもそも数時間待たされる処理で 端末が切り離せないのが大問題です。

• freebsd-update で実行する mergemaster の改善：　 freebsd-update での mergemaster はかなり進化しており、オペレータが修正した箇所を校了チェックして差し戻しまでやってくれるすぐれものになりました。　恐らく正式なアップグレード経路の一つである /usr/src で行う buildworld/installworld に先立って実施する mergemaser ( -UPiF オプション ) と同じ　 vi での簡単な修正が出来るようになっています。今まで２ペイン editor で左右のどちらを取るのか？という確認させられていたのですが、見慣れない editor ほど苛つかせるものはないし、我々 FreeBSD利用者の大半は、管理作業において viですべてが完結しているというだけで FreeBSD を選んでいるのではないでしょうか？（偏見）

• ユーザランド　/usr/src の更新がめちゃくちゃ遅い。：　これで１日ちょっとかかったりするケースがあります。 /usr/src を空っぽにしておくことを強くおすすめします。性能的に問題がないと思われる機材でも /usr/src だけで8時間くらいはかかってしまうので、夜間アップグレードのメンテナンスが朝になっても終わりません。恐らくファイルを上書きではなく「消して書く」という zfs が不得意なパターンです。

• portsnap はなくなりました: /usr/ports は OS標準コマンドだったportsnap で拾ってくるのが習わしでしたが、大半のユーザは ports を使わないだろうということになったのか？　pkg からインストールする必要があります。 git でも checkout 出来るのでしょうが、 portsnap は楽ですので手放せません。

• pkg bootstrap -f && pkg update && pkg upgrade までは定形作業です。昔のような　FreeBSD-portsだけで完結することは出来ません。

• /usr/include がきちんと更新されない！ : portsで何かをコンパイルしようとしてトラブルになるのは たいてい/usr/include が古いままだったりすることに起因します。 回避策は 14.0-RELEASE 配布の /usr/include を ftp、インストール媒体に含まれる base.txzから持ってきて据えることになります。

• schg でロックされている → https://twitter.com/DLangille/status/1731337471944798447　
  この投稿によりますと　以下ファイル

/usr/bin/opieinfo
/usr/bin/opiepasswd
/usr/lib/librt.so.1

schg フラグが立てられていて書き換わらないそうです。

-r-sr-xr-x  1 root wheel  7416 Dec 14  2022 opieinfo
-r-xr-xr-x  4 root wheel 12192 Dec 14  2022 opiekey
-r-sr-xr-x  1 root wheel 15496 Dec 14  2022 opiepasswd

まあ、なんというか・・・　svnlite　あたりも消えないんですが・・・

後の祭り

• freebsd-update 経由なら、/usr/src は名前変えておくなり、消すなりしとけ。

こんな時間（05:03)に書いているのは徹夜になったからです。泣きそう。

アップグレードは永遠に

ブートしなくなった機材があって焦りましたが、UEFIを疑ったらビンゴでした。

/boot/efi/efi/boot 
/boot/efi/efi/freebsd ←　コレがあったほうが良いです。

• /boot/efi のメンテナンスがきちんと出来ていない、UEFI化が始まった頃にインストールしてそのままのマシンが、boot障害を起こしていました。 gptzfsboot より UEFIを優先するみたいなので、この際 UEFI partationが切ってあるマシンはきちんと入れてしまいましょう。