👹
FreeBSD OS更新の現実
FreeBSDの一般的なVersion更新の流れ
細かく説明をする前に、
FreeBSDハンドブック:
第16章 FreeBSD のアップデートとアップグレード:
を一読されるのをおすすめします。
基本的にfreebsd-update一択です！
ソースコードからのビルドには資源を浪費します。教条主義的なユーザ、基本的に疑い深いユーザ以外には縁がありません。
アップグレードで起こる現実
明確に書かれていない事実としては、以下のことを考えて、作業に入る必要があります。
- 必要なリソースの確保: マイナーバージョン更新は無論、パッチすらギリギリのroot 領域で更新を始めると入りきらずに悲惨な状況になりかねない。
- 再起動が可能である事:遠隔地から作業して万が一の場合駆けつけて対応出来る。
- 作業者の余裕: コンソールに張り付いて作業出来る体力気力
- 現状のユーザ/サードパーティバイナリ環境が安定している、少なくともライブラリ欠損が無い、ある場合には、それが起動再起動に大きく作用し得るものでないと把握出来ていること。
- 特殊な設定がない事: 更に再起動前に現状を反映した rc.conf である事、rc.local があるなら一旦無効にするか、普通に再起動出来ると確実な状況か確かめる事。数年単位で無停止運用して再起動操作をしていないと、かなりかなり重要な変更(ネットワーク周りなど)がきちんとドキュメント化、設定に記述されていないばかりに揮発して二度と再起動しない、リモートログイン不可な設定になっているケースは珍しくはない。LDAP等に認証を移した場合等は単体の健全性は問題なくともネットワーク設定如何で再起動後に操作不可になりうる。
- 利用者に対する配慮: 対象機材の性能や規模から完了迄の時間はかなりかかる場合があり、更にはOSバージョンに依存しがちなセキュリティ周りのライブラリをリンクしたアプリ、FreeBSDのネイティブ仮想ホスト環境であるbhyve 、スクリプト言語など、カーネル差し替えて再起動した際にユーザバイナリのバージョン不一致により意図した動作に至らない場合も多々ある為、更新準備して metgemaster 他の操作を完了して無事に再起動した後にサービス再開出来る場合もあれば、起動しない、しているが不完全な状況にあるままサービス再開している不安定なケースも見られる。
FreeBSD 14.0 の場合
- 繰り返し編集操作を強いられて苦痛すら感じる mergemasterには、いくつか改良点があります。 特筆すべき点は、更新対象設定に不完全な編集をした場合に、内容を簡単にでもチェックされ差し戻しがあります。以前よりはかなり賢くなり問い合わせされる回数は減っている筈です。
- 👎な点があるとして ユーザランド更新には大変な時間待ちが発生しています。/usr/src 以下の更新が以前の数倍は時間掛かります。ユーザランド更新はおそらくカーネルより重い処理になり、書き込み後にチェックしているのかもしれませんが、予想外にサービス再開出来ない事にもなります。
コレはやれ、入れとけ的なモノ
- ユーザランド更新に掛かる時間も相当ありますが、mergemaster作業などに割り込みがあると普通ならおじゃんになります。必ず screen/tmuxの後背援護を付けましょう。
- IP-KVMがあれば怖いモノは減ります。ユーザランド更新時は長い待ちがあり、12.x以前から ssh サービスの変更が発生し、更新が不完全なまま接続が切れるケースは多々ありました。そうなるとリモートでは救えない場合がありますがIP-KVMはコンソールまで生きているなら現地に行く必要がない場合がほとんどになるでしょう。
- 設定バックアップは必ずしましょう。IP-KVMがあっても設定が消えた時点で苦難が待ち受けます。
- zfs は今期 rootfs を失うトラブルが複数あったのですが、ミスオペでその様な事が複数回発生する可能性はなく、大変重大なミスがあったと考えて良いので、2.に加えてユーザデータを必ずバックアップしましょう。
Discussion