Re: FreeBSDのリリースサイクル変更について

2024-09-17 Thread Suzuki Akihiko 



残念なことにLinux系のカーネルの本は色々出ていますけどね。

翔泳社・技術評論社が結構出してます。

https://amzn.to/3B7Bx7g

https://amzn.to/3z9IIva

（これは7月に出てますね）

On 2024/09/17 17:08, zen-freebsd...@suzuki.que.ne.jp wrote:

吉田さん

鈴木＠葛飾区です。

ご返信ありがとうございます。

ちょっとFreeBSDからは離れますが最近はFreeBSDに限らずOS関連の書籍は非常
に少なくなってきています。
辛うじてRed Hat系の本が2刷程度OSのリリースを追っている感じでしょうか。
FreeBSD向けの本が最後に出たのいつかも、もう分からないです。。

こういった状況ではサービスの運用を行っている会社ではまだしも、社内の情
報システム部門や知っているというだけでサーバー運用を任された方は後継者
を育てるのも難しく、後を考えると外部サービスに移行するのも致し方ない状
況でしょうね。

個人的には寂しいですが。。


セキュリティやら内部統制やら脅威や仕組みばかりが増えて、
マイナーバージョンアップだけでも膨大な手間が掛かるようになってきており、
サーバを1台管理するだけでも最近はうんざりします
第三者検証や責任者承認を求められても、請けてくれる人もお金もないのを
どうしろと

勤務先でももう私一人では面倒を見切れなくなり、無理矢理お金を掛けてでも
管理が楽になる方向へ転換して、システムをいくつも移行してサーバなどの
集中管理対象物をほとんど廃止しました

一年中サーバ運用だけをする仕事ならいいですが、兼務だと不可能ですね
業務負荷は知らないところで勝手にどんどん増やされるのに、
予算はマイナスシーリングとか、やってられません

---
すずき

Re: FreeBSDのリリースサイクル変更について

2024-09-17 Thread zen-freebsd-ml 
吉田さん

鈴木＠葛飾区です。

ご返信ありがとうございます。

ちょっとFreeBSDからは離れますが最近はFreeBSDに限らずOS関連の書籍は非常
に少なくなってきています。
辛うじてRed Hat系の本が2刷程度OSのリリースを追っている感じでしょうか。
FreeBSD向けの本が最後に出たのいつかも、もう分からないです。。

こういった状況ではサービスの運用を行っている会社ではまだしも、社内の情
報システム部門や知っているというだけでサーバー運用を任された方は後継者
を育てるのも難しく、後を考えると外部サービスに移行するのも致し方ない状
況でしょうね。

個人的には寂しいですが。。

> セキュリティやら内部統制やら脅威や仕組みばかりが増えて、
> マイナーバージョンアップだけでも膨大な手間が掛かるようになってきており、
> サーバを1台管理するだけでも最近はうんざりします
> 第三者検証や責任者承認を求められても、請けてくれる人もお金もないのを
> どうしろと
> 
> 勤務先でももう私一人では面倒を見切れなくなり、無理矢理お金を掛けてでも
> 管理が楽になる方向へ転換して、システムをいくつも移行してサーバなどの
> 集中管理対象物をほとんど廃止しました
> 
> 一年中サーバ運用だけをする仕事ならいいですが、兼務だと不可能ですね
> 業務負荷は知らないところで勝手にどんどん増やされるのに、
> 予算はマイナスシーリングとか、やってられません
---
すずき

Re: FreeBSDのリリースサイクル変更について

2024-09-17 Thread zen-freebsd-ml 
坂元 さん

鈴木＠葛飾区です。

> いきなり脇道ですが、
> 
>> 1. 事前の検証(検証マシンで簡単な動作確認)
> 
> は、VMwareのスナップショットを活用してトライ＆エラーしているんですが、
> 今回の値上げ騒動でちょっと頭を抱えています(^^;

私のところではESXiを利用していたのですがHyper-Vに移行することになりま
した。。

ご紹介いただいた手法は坂元さんはfreebsd-updateを各サーバーで実行する際
に工夫をされたようですが、私は各サーバーで手動処理を行いたくなかったの
でスクリプトで書き換え、置き換えをしている感じです。

まぁ、もっと若ければfreebsd-update改造してコミットするといったアプロー
チもあったかも知れません。。。

> Webシステムの開発や保守もやっているんですが、個人的にLTSモデルな環境
> がEoLを迎えた時に、言語もDBも移行ノウハウの情報が全くなくて途方に暮
> れる、という経験をしたことがあるので、いわゆるローリングリリースには
> むしろ好意的な印象を持っています。

この話は世の中ではしばしば聞くのですが、自分のところでは案件ごとにリリー
スから時間が十分経過してEOLが長いOSを順にご提案しているので特定のマシ
ンでは大きな差分が生じるものの、ノウハウとしてはローリングリリースと同
じ状態を維持しています。
(新バージョンリリース → 実験的運用 → X.2あたりのバージョンから案件で
ご提案)
そういうサイクルの中でもちょっとFreeBSDが浮き気味で。。。

FreeBSDのサーバーが大多数であれば問題なかったのかも知れませんがここ10
年でだいぶ減ってしまいました。

思い入れもあり長く使っているOSなので今後も自分のマシンや一部では
FreeBSDも使い続けるのかな？とは思っていますが自分以外のことも考えると
やはり厳しそうです。
---
すずき

Re: FreeBSDのリリースサイクル変更について

2024-09-13 Thread nifty 
吉田です

鈴木さんの気持ち分かります

セキュリティやら内部統制やら脅威や仕組みばかりが増えて、
マイナーバージョンアップだけでも膨大な手間が掛かるようになってきており、
サーバを1台管理するだけでも最近はうんざりします
第三者検証や責任者承認を求められても、請けてくれる人もお金もないのを
どうしろと

勤務先でももう私一人では面倒を見切れなくなり、無理矢理お金を掛けてでも
管理が楽になる方向へ転換して、システムをいくつも移行してサーバなどの
集中管理対象物をほとんど廃止しました

一年中サーバ運用だけをする仕事ならいいですが、兼務だと不可能ですね
業務負荷は知らないところで勝手にどんどん増やされるのに、
予算はマイナスシーリングとか、やってられません

> 2024/09/13 18:06、zen-freebsd...@suzuki.que.ne.jpのメール:
> 
> 鈴木＠葛飾区です。
> 
> 皆様、多数のご意見ありがとうございます。
> お返事が遅くなったことをお詫びします。
> 
> あまり詳細を書かなかったので分かりづらかったかも知れませんが、代表して
> 引用させていただいた内藤さんの内容がだいたい全貌です。
> 
> コストが高いと思っていることは大きくわけて運用上の問題と、技術的な問題
> に分かれます。
> 
> 運用上はお客様が利用されるサーバーですので、バージョンアップ時には次の
> ような作業を行っています。
> 
> 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 
> Subject: Re: FreeBSDのリリースサイクル変更について
> Date: Thu, 12 Sep 2024 09:22:23 +0900
> Message-ID: <84a126a0-a888-46b0-af7a-3350d214e...@gmail.com>
> 
>> 内藤です。
>> 
>> げんなりしている部分は freebsd-update が遅くてそれを管理している
>> マシンの台数分やらなきゃいけないのが負担だからなんですよね、きっと。
>> 
>> 個人的にはそれほど沢山のマシンを管理しているわけではないのと、
>> 個人で使っているマシンばかりなので、自分で適当に更新タイミングを
>> 決められるのでさほど負担には思っていませんが、台数が多くて
>> 他の人に使わせているマシンを止めるとなると面倒なんだろうなと
>> 想像しています。
>> 
>> なんか将来的には freebsd-update 止めて pkg でベースシステムも更新
>> できるようにするつもりらしいのですが、いつになることやら。
>> もしそうなると、ファイルひとつひとつではなく、ある程度まとまった
>> 単位で pkg ファイルをダウンロードして展開になるはずなので、
>> 更新作業はスピードアップするはずです。
>> 
>> そちらに期待してみるのも手かもしれません。
>> 
>>>> On Sep 11, 2024, at 16:13, zen-freebsd...@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.yuich...@gmail.com
>> 
>> 
>> 
>

Re: FreeBSDのリリースサイクル変更について

2024-09-13 Thread hideki sakamoto 

坂元です。

月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...@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 
Subject: Re: FreeBSDのリリースサイクル変更について
Date: Thu, 12 Sep 2024 09:22:23 +0900
Message-ID: <84a126a0-a888-46b0-af7a-3350d214e...@gmail.com>


内藤です。

げんなりしている部分は freebsd-update が遅くてそれを管理している
マシンの台数分やらなきゃいけないのが負担だからなんですよね、きっと。

個人的にはそれほど沢山のマシンを管理しているわけではないのと、
個人で使っているマシンばかりなので、自分で適当に更新タイミングを
決められるのでさほど負担には思っていませんが、台数が多くて
他の人に使わせているマシンを止めるとなると面倒なんだろうなと
想像しています。

なんか将来的には freebsd-update 止めて pkg でベースシステムも更新
できるようにするつもりらしいのですが、いつになることやら。
もしそうなると、ファイルひとつひとつではなく、ある程度まとまった
単位で pkg ファイルをダウンロードして展開になるはずなので、
更新作業はスピードアップするはずです。

そちらに期待してみるのも手かもしれません。


On Sep 11, 2024, at 16:13, zen-freebsd...@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

Re: FreeBSDのリリースサイクル変更について

2024-09-13 Thread zen-freebsd-ml 
鈴木＠葛飾区です。

皆様、多数のご意見ありがとうございます。
お返事が遅くなったことをお詫びします。

あまり詳細を書かなかったので分かりづらかったかも知れませんが、代表して
引用させていただいた内藤さんの内容がだいたい全貌です。

コストが高いと思っていることは大きくわけて運用上の問題と、技術的な問題
に分かれます。

運用上はお客様が利用されるサーバーですので、バージョンアップ時には次の
ような作業を行っています。

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 
Subject: Re: FreeBSDのリリースサイクル変更について
Date: Thu, 12 Sep 2024 09:22:23 +0900
Message-ID: <84a126a0-a888-46b0-af7a-3350d214e...@gmail.com>

> 内藤です。
> 
> げんなりしている部分は freebsd-update が遅くてそれを管理している
> マシンの台数分やらなきゃいけないのが負担だからなんですよね、きっと。
> 
> 個人的にはそれほど沢山のマシンを管理しているわけではないのと、
> 個人で使っているマシンばかりなので、自分で適当に更新タイミングを
> 決められるのでさほど負担には思っていませんが、台数が多くて
> 他の人に使わせているマシンを止めるとなると面倒なんだろうなと
> 想像しています。
> 
> なんか将来的には freebsd-update 止めて pkg でベースシステムも更新
> できるようにするつもりらしいのですが、いつになることやら。
> もしそうなると、ファイルひとつひとつではなく、ある程度まとまった
> 単位で pkg ファイルをダウンロードして展開になるはずなので、
> 更新作業はスピードアップするはずです。
> 
> そちらに期待してみるのも手かもしれません。
> 
>> On Sep 11, 2024, at 16:13, zen-freebsd...@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.yuich...@gmail.com
> 
> 
>

Re: FreeBSDのリリースサイクル変更について

2024-09-11 Thread T.Wakabayashi 
若林です。

On 2024/09/12 9:22, Yuichiro Naito wrote:
> げんなりしている部分は freebsd-update が遅くてそれを管理している
> マシンの台数分やらなきゃいけないのが負担だからなんですよね、きっと。

/usr/srcをmvかrmすると早くなりますがそういうことではない？

# upgrade後に該当のsrc.txzを展開しておけばOK


2024年9月12日(木) 9:23 Yuichiro Naito :

> 内藤です。
>
> げんなりしている部分は freebsd-update が遅くてそれを管理している
> マシンの台数分やらなきゃいけないのが負担だからなんですよね、きっと。
>
> 個人的にはそれほど沢山のマシンを管理しているわけではないのと、
> 個人で使っているマシンばかりなので、自分で適当に更新タイミングを
> 決められるのでさほど負担には思っていませんが、台数が多くて
> 他の人に使わせているマシンを止めるとなると面倒なんだろうなと
> 想像しています。
>
> なんか将来的には freebsd-update 止めて pkg でベースシステムも更新
> できるようにするつもりらしいのですが、いつになることやら。
> もしそうなると、ファイルひとつひとつではなく、ある程度まとまった
> 単位で pkg ファイルをダウンロードして展開になるはずなので、
> 更新作業はスピードアップするはずです。
>
> そちらに期待してみるのも手かもしれません。
>
> > On Sep 11, 2024, at 16:13, zen-freebsd...@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.yuich...@gmail.com
>
>
>
>

-- 
--
-
Tomoyuki Wakabayashi
E-Mail: t...@peanuts.to
-

Re: FreeBSDのリリースサイクル変更について

2024-09-11 Thread non 

On 2024/09/12 9:22, Yuichiro Naito wrote:

げんなりしている部分は freebsd-update が遅くてそれを管理している
マシンの台数分やらなきゃいけないのが負担だからなんですよね、きっと。


hackers で freebsd-update 
が遅いから書き直してみたというのが流れていました。ご参考まで：


https://mail-archive.freebsd.org/cgi/getmsg.cgi?fetch=144191+0+archive/2024/freebsd-hackers/20240826.freebsd-hackers

// 光永

Re: FreeBSDのリリースサイクル変更について

2024-09-11 Thread Yuichiro Naito 
内藤です。

げんなりしている部分は freebsd-update が遅くてそれを管理している
マシンの台数分やらなきゃいけないのが負担だからなんですよね、きっと。

個人的にはそれほど沢山のマシンを管理しているわけではないのと、
個人で使っているマシンばかりなので、自分で適当に更新タイミングを
決められるのでさほど負担には思っていませんが、台数が多くて
他の人に使わせているマシンを止めるとなると面倒なんだろうなと
想像しています。

なんか将来的には freebsd-update 止めて pkg でベースシステムも更新
できるようにするつもりらしいのですが、いつになることやら。
もしそうなると、ファイルひとつひとつではなく、ある程度まとまった
単位で pkg ファイルをダウンロードして展開になるはずなので、
更新作業はスピードアップするはずです。

そちらに期待してみるのも手かもしれません。

> On Sep 11, 2024, at 16:13, zen-freebsd...@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.yuich...@gmail.com

Re: FreeBSDのリリースサイクル変更について

2024-09-11 Thread Tomoaki AOKI 
青木@名古屋です。

On Thu, 12 Sep 2024 07:07:51 +0900
Motoyuki KONNO  wrote:

> 今野です。
> 
> 2024年9月11日(水) 16:16 :
> 
> > 間抜けなことにFreeBSDのリリースサイクルが変更されたことに昨日気づきま
> > した (;_;)
> 
> 
> 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*
> >
> 
> そこに来て半年に1回のマイナーバージョンアップという話を知ってすっかり
> > 心が折れました。。。
> 
> 
> いろいろ理由はあると思いますが、セキュリティが重視される昨今の状況で半年を
> 目安に新しいリリースを出したいということであれば理解できます。
> 
> その上で、各メジャーバージョンは5年間のサポートが明示されていますが、
> 一つのマイナーバージョンがセキュリティオフィサーによってサポートされる
> のは次のリリースが出て3ヵ月しかないので、リリース間隔が半年になっても
> ほとんど影響はないですね。私としては。
> 
> 個人的にはports treeのデフォルトが使い物にならなくなったのが悩みの
> 種で、bindを作るのにpythonからXのライブラリまで入れようとするのは
> 本当に止めて欲しい。pythonは仕方ないかなと諦めましたけど。
> 
> --
> motoyuki

実運用環境自体にビルド時だけの依存物（bUILD_DEPENDA）をインストール
されたくない、さりとてデフォルトオプションは困るので公式pkgは使えない、
という場合、例えばpoudriereを使用する方法があります。

poudriereはビルドに一時的に生成したjailを使用し、依存物をそこに
インストールしてビルド、パッケージを作成したらそのjailはクリア
してしまいますので、実運用環境自体への影響は抑えられます。
試したことはありませんが、おそらくsynthやjenkinsのような他のクリーン
ルーム方式のビルダーも同様と思います。

自分でpoudriereを使い始めてみるにあたって、当時発見できたドキュメントや
事例だと

　・複数Release用だったり複数アーキティクチャ用だったりと大げさな
　　設定事例がほとんど。

　・ビルドしたパッケージを複数のPCで利用するのが前提の事例ばかりで
　　webサーバを立てるのが前提

　・poudrere専用にOPTIONを保存する前提の事例ばかりで既に実機上で
　　ビルド・インストールしたportsで済ませている設定を無視してしまう
　　事例ばかり

ということで1台のPCだけで使えればいいし、全portsのOPTIONの再設定など
したくない私の需要に合わなくて（さりとて一部のメンテナはBugzillaでの
バグレポートに対してpoudriere等のクリーンルームビルダーでビルドした
場合以外は完全無視してしまう場合もある［スクラッチからビルドする
想定以外の不具合まで相手にしている余裕がない］）あちこちに散らばった
情報からなんとかほぼ使えるようにした構成や運用を

　https://brew.bsd.cafe/TomAoki/Tips-and-Tricks/src/branch/main/poudriere

で公開しています。　但し、需要のほぼ全ては海外だろうということもあって
英文のみです。


-- 
青木 知明  [Tomoaki AOKI]

Re: FreeBSDのリリースサイクル変更について

2024-09-11 Thread Motoyuki KONNO 
今野です。

2024年9月11日(水) 16:16 :

> 間抜けなことにFreeBSDのリリースサイクルが変更されたことに昨日気づきま
> した (;_;)


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*
>

そこに来て半年に1回のマイナーバージョンアップという話を知ってすっかり
> 心が折れました。。。


いろいろ理由はあると思いますが、セキュリティが重視される昨今の状況で半年を
目安に新しいリリースを出したいということであれば理解できます。

その上で、各メジャーバージョンは5年間のサポートが明示されていますが、
一つのマイナーバージョンがセキュリティオフィサーによってサポートされる
のは次のリリースが出て3ヵ月しかないので、リリース間隔が半年になっても
ほとんど影響はないですね。私としては。

個人的にはports treeのデフォルトが使い物にならなくなったのが悩みの
種で、bindを作るのにpythonからXのライブラリまで入れようとするのは
本当に止めて欲しい。pythonは仕方ないかなと諦めましたけど。

--
motoyuki

Re: FreeBSDのリリースサイクル変更について

2024-09-11 Thread Tomoaki AOKI 
On Wed, 11 Sep 2024 16:13:56 +0900 (JST)
zen-freebsd...@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までに脱出計画かなぁ。。)
> 
> みなさんはどうされていますか？？
> ---
> すずき

私の場合、FreeBSDで使っているPCがノート1台だけということもありますが、
日常使用は最新のstableブランチ（現在はstable/14）を原則1回/週でソース
から更新（セキュリティ関係や注目すべき更新があった場合は臨時更新も）、
1回/2週間～1ヶ月で別物理ドライブのmainブランチをソースから更新という
運用です。

※つまり、まだ先ですが今後stable/15ブランチが切られたら日常使用の
　環境はそちらに切り替えです。

mainブランチは非常時のレスキュー用 兼 MFCされたときの影響が大きそうな
更新のテスト環境です。　ここで問題になりそうであれば何らかの方法で
（Bugzillaへの不具合情報登録・freebsd-current MLでの注意喚起・
dev-commits-src-main MLの当該コミット分への返信等）フィードバックして
修正又はMFC予定の撤回を求めることにしています。

そういった形で主にstableブランチを使用していますが、

　・portsからインストールしたカーネルモジュールはbaseの更新毎に
　　必ずportsからビルド・インストールしなおす。

　・ZFSを使用し、最悪の場合戻せるようにスナップショットを取っておく。

　・確実に何も使っていないことを確認するまで`make delete-old-libs`は
　　絶対に行わない。

　・mainブランチで問題が出ていないことが確認できていてブランチを
　　切り替えるとき以外はZFSのプールのupgradeは絶対に行わず、
　　行う場合は先にブートコードを更新する。

という運用で、次のstableブランチへの切り替え以外かつビルド・インストール
でエラーにならなかった場合は困ったことはありません。

※portsの更新関係での困りごとのほうが遥かに多いです。


英語ではありますがfreebsd-stable MLを見ていると、同じブランチ
（relengは対応するstableブランチ単位で判断）内で互換性問題が
生じたらたいてい誰かが騒ぎ出しますので、releng（14系での次は
releng/14.2）ブランチが切られる前にある程度対処方法も掴めるかと
思います。

13系なら13系、14系なら14系の中であればいいのですが、このレベルを
乗り換える際はmainブランチの更新頻度を引き上げて安全性を確認する
等の対応はしています。　リスクが段違いになりますので。


-- 
青木 知明  [Tomoaki AOKI]

FreeBSDのリリースサイクル変更について

2024-09-11 Thread zen-freebsd-ml 
鈴木＠葛飾区です。

久々の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までに脱出計画かなぁ。。)

みなさんはどうされていますか？？
---
すずき