Re: FreeBSDのリリースサイクル変 更について
Date: Fri, 13 Sep 2024 14:05:58 UTC
坂元です。
月1回の定期保守＋緊急保守（脆弱性対応）といった頻度でFreeBSDを更新する業務をやっています。
いきなり脇道ですが、
> 1. 事前の検証(検証マシンで簡単な動作確認)
は、VMwareのスナップショットを活用してトライ＆エラーしているんですが、今回の値上げ騒動でちょっと頭を抱えています(^^;
さておき、
> ・処理に時間がかかる
> 無負荷に近いマシンでは20分程度で完了するが、相応の負荷のあるマシンで
> は30分以上かかる場合もある。
> (srcは対象にしていません)
> ・実行時にインタラクションが必要で手順が多い
> マイナーバージョンアップの際にも意味があまり無さそうな設定ファイル等
> のマージ処理をやらされる
> (/etc/passwdのコメントなど。。)
の2点は、screenコマンドを使って並列に実行して時間を短縮しています。具体的には、tcshですと、
----------
alias rcmd "screen -X at ':#' stuff '\!*\n'"
alias nohist 'history -S ~/.hst; \!*; sed \$d ~/.hst | sed \$d > ~/.hst.new; history -L ~/.hst.new;rm -f ~/.hst*'
----------
といったエイリアスと、
----------
#!/bin/sh
_IPL="192.168.0.1 192.168.0.2 ...." ← ここに保守対象のIPアドレスを列挙
for _ip in $_IPL
do
_hn=`dig -x $_ip +short | tail -1 | awk -F'.' '{print $1"."$2}'`
if [ -z "$_hn" ]
then
_hn=$(echo $_ip | awk -F'.' '{print $3"."$4}')
fi
/usr/local/bin/screen -t ":$_hn" /usr/bin/ssh $_ip
done
----------
というスクリプト(prep_bulk.sh)を作っておいて、
----------
% screen
[screen]% prep_bulk.sh
----------
と実行すると、保守対象のウインドウがずらーっと立ち上がるので、
----------
% rcmd sudo /usr/sbin/freebsd-update upgrade -r 13.3-RELEASE
(※ あらかじめ全台にsudoersを仕込んでおく)
----------
で freebsd-updateを一斉に実行し、あとはウィンドウを切り替えてちまちまと作業しています。
どうしても手作業が必要な、いわゆるmergemasterの部分も、
・ 極力/etc 以下のファイルは原型を保ち、ホスト固有の設定は /usr/local/etc/... 以下のincludeに退避
・ master.passwd は、/usr/src/etc/master.passwd ファイルの内容に合わせておいて、末尾にローカルなアカウントを記述する
といったあたりに気をつければ、ほぼ自動でマージが進み、100台ぐらいの準備が調子が良ければ半日あれば終わる作業になります。
# なぜか /etc/ssh/sshd_config だけどうしても毎回手作業になるのが不満です
> ・カーネルのみ更新された状態での再起動がある
これは、「FreeBSD Advent Calendar 2016 16日目」の記事に書いた、
https://qiita.com/hs_onsky/items/173dc102cd99d7f838b7#freebsd-update-install--reboot%E3%82%92%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%83%88%E3%81%A7%E8%87%AA%E5%8B%95%E5%8C%96
の、/etc/rc.d/upgrade11 を適宜OSのバージョンに合わせて微調整して、定期保守の時に、
・ upgrade## スクリプトを/etc/rc.d/ の下にコピー
・ /usr/sbin/freebsd-update install を1回実行
・ リブート
という手順で自動化しています。
OSのメジャーバージョンアップ時は、misc/compatXXX をひとまずインストールして、更新前のバージョン用のpkgでまずは動かし、次回の保守で新しいバージョン用のバイナリで一括更新する、といった二段構えにして1回の保守でのダウンタイムを短くしています。
前述のQiitaの記事の2016年時点でこの手順がほぼ確立していて、以降もバイナリアップデートでのトラブルは経験していないので、10年を超えて保守する場合は、FreeBSDの方がいまだ一日の長ありという評価です。
# ユーザーランドもpoudriereで独自にリポジトリ構築して、顧客に保守計画を提示してバージョン管理しています。
Webシステムの開発や保守もやっているんですが、個人的にLTSモデルな環境がEoLを迎えた時に、言語もDBも移行ノウハウの情報が全くなくて途方に暮れる、という経験をしたことがあるので、いわゆるローリングリリースにはむしろ好意的な印象を持っています。
最後に簡単なものですが、今のリリースサイクルが発表された時に作った保守計画表があったので添付します。
EoLまで粘ると次のバージョンの##.3か、2個先の##.0という選択になるので、コンサバに計画立てると、メジャーバージョンの保守年数は今までと変わらないのがいまいち、という印象でしたが、今と変わらないならまあ継続でいいかなと思っています。
ご参考になれば幸いです。
On 2024/09/13 18:06, zen-freebsd-ml@suzuki.que.ne.jp wrote:
> 鈴木＠葛飾区です。
>
> 皆様、多数のご意見ありがとうございます。
> お返事が遅くなったことをお詫びします。
>
> あまり詳細を書かなかったので分かりづらかったかも知れませんが、代表して
> 引用させていただいた内藤さんの内容がだいたい全貌です。
>
> コストが高いと思っていることは大きくわけて運用上の問題と、技術的な問題
> に分かれます。
>
> 運用上はお客様が利用されるサーバーですので、バージョンアップ時には次の
> ような作業を行っています。
>
> 1. 事前の検証(検証マシンで簡単な動作確認)
> 2. バージョンアップ作業のスケジュール調整
> 3. お客様への事前告知(2週間前)もしくは、スケジュールのご相談
> 4. バージョンアップ作業の準備(後段に詳細)
> 5. バージョンアップ実施
>
> 今まで何度となく行ってきた作業ですが大きな更新は何度やってもドキドキし
> ないことはありません。。。心理的負荷が。。。
>
> 技術的な問題についてはfreebsd-updateの仕様に起因することで、通常手順で
> 実施した場合次のような点を問題に感じています。
> ・処理に時間がかかる
> 無負荷に近いマシンでは20分程度で完了するが、相応の負荷のあるマシンで
> は30分以上かかる場合もある。
> (srcは対象にしていません)
> ・実行時にインタラクションが必要で手順が多い
> マイナーバージョンアップの際にも意味があまり無さそうな設定ファイル等
> のマージ処理をやらされる
> (/etc/passwdのコメントなど。。)
> ・カーネルのみ更新された状態での再起動がある
>
> このような点があるため、現在は検証用のマシンでのみfreebsd-updateを実行
> して、各マシンへの配布用のアーカイブを作成して配布、独自スクリプトでの
> 更新処理を行っています。
>
> 1. 検証マシンでOS更新
> 2. 配布用ファイル(更新された/etc以下やその他のバイナリ、ライブラリ)を用意
> 3. 各マシンに配布用ファイルを展開
> 4. 各マシンで更新を実行
> 4.1 /etc/rc をファイル差し替え用シェルスクリプトに変更
> 4.2 再起動
> 4.3 差し替え用シェルスクリプトが各ファイルをmv、cpして更新、再起動
> 4.5 新しい環境で起動完了
>
> 各マシンでのOS更新での停止時間は2分程度で完了しますが、事前の準備は結
> 構手間がかかります。
>
> と、いうことで事前の調整・告知などの手間や実施時の心理的負荷というのが
> もっとも負担に感じている部分です。
>
> 将来的にpkgでの管理に変更されたり、freebsd-update自体の高速化といった
> 試みが行われていたりはするようですが、さすがに年をとりました(;_;)
>
>
> From: Yuichiro Naito <naito.yuichiro@gmail.com>
> Subject: Re: FreeBSDのリリースサイクル変更について
> Date: Thu, 12 Sep 2024 09:22:23 +0900
> Message-ID: <84A126A0-A888-46B0-AF7A-3350D214E947@gmail.com>
>
>> 内藤です。
>>
>> げんなりしている部分は freebsd-update が遅くてそれを管理している
>> マシンの台数分やらなきゃいけないのが負担だからなんですよね、きっと。
>>
>> 個人的にはそれほど沢山のマシンを管理しているわけではないのと、
>> 個人で使っているマシンばかりなので、自分で適当に更新タイミングを
>> 決められるのでさほど負担には思っていませんが、台数が多くて
>> 他の人に使わせているマシンを止めるとなると面倒なんだろうなと
>> 想像しています。
>>
>> なんか将来的には freebsd-update 止めて pkg でベースシステムも更新
>> できるようにするつもりらしいのですが、いつになることやら。
>> もしそうなると、ファイルひとつひとつではなく、ある程度まとまった
>> 単位で pkg ファイルをダウンロードして展開になるはずなので、
>> 更新作業はスピードアップするはずです。
>>
>> そちらに期待してみるのも手かもしれません。
>>
>>> On Sep 11, 2024, at 16:13, zen-freebsd-ml@suzuki.que.ne.jp wrote:
>>>
>>> 鈴木＠葛飾区です。
>>>
>>> 久々のMLへの投稿です。。
>>>
>>> 間抜けなことにFreeBSDのリリースサイクルが変更されたことに昨日気づきま
>>> した (;_;)
>>>
>>> 13.4とか言っているので13.3からまだ半年なのに変則的なリリースだなぁ？と
>>> 思っていろいろ検索していたら7月に今後のマイナーバージョンのリリースは
>>> 半年ごとになりますみたいな決定がされていたようです。
>>>
>>> https://lists.freebsd.org/archives/freebsd-announce/2024-July/000143.html
>>>
>>> www.freebsd.orgのニュースリリースにも特に掲載はなく、まったく気づきま
>>> せんでした。
>>>
>>> たとえば今後の13と14のリリース予定はこんな感じらしいです。
>>>
>>> 13と14抜粋
>>> 13.3: Mar 2024 Dec 2024
>>> 13.4: Sep 2024 Jun 2025
>>> 13.5: Mar 2025 Apr 2026*
>>>
>>> 14.1: Jun 2024 Mar 2025
>>> 14.2: Dec 2024 Sep 2025
>>> 14.3: Jun 2025 Jun 2026
>>> 14.4: Mar 2026 Dec 2026
>>> 14.5: Sep 2026 Jun 2027
>>> 14.6: Mar 2027 Nov 2028*
>>>
>>> 現状FreeBSD13.3のサーバーがそれなりにあるため1台づつfreebsd-updateでの
>>> 更新は現実的ではないため1台で更新して更新後のバイナリを各マシンに配布、
>>> 設定ファイル等は変更の必要なもののみ配布することでバージョンアップを簡
>>> 略化していましたが更新の際にはそれなりに確認等も必要で楽では無い。。
>>>
>>> そこに来て半年に1回のマイナーバージョンアップという話を知ってすっかり
>>> 心が折れました。。。
>>>
>>> Red Hatもマイナーバージョンアップはありますが、多くの場合いつもよりアッ
>>> プデートに時間がかかるな、くらいで設定ファイルもそこまで変更はなかった
>>> です(これまで)。
>>>
>>> 自分的には最早これまでか、、という感じです。
>>> (2026年の13.5のEOLまでに脱出計画かなぁ。。)
>>>
>>> みなさんはどうされていますか？？
>>> ---
>>> すずき
>>>
>>
>>
>>
>> --
>> 内藤 祐一郎
>> naito.yuichiro@gmail.com
>>
>>
>>
>