From nobody Fri Sep 13 09:06:13 2024 X-Original-To: freebsd-users-jp@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X4pMP33W7z5WSV6 for ; Fri, 13 Sep 2024 09:06:25 +0000 (UTC) (envelope-from zen-freebsd-ml@suzuki.que.ne.jp) Received: from inetd.co.jp (mgate.inetd.co.jp [210.129.88.236]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4X4pMM0cBRz4l2M for ; Fri, 13 Sep 2024 09:06:22 +0000 (UTC) (envelope-from zen-freebsd-ml@suzuki.que.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of zen-freebsd-ml@suzuki.que.ne.jp designates 210.129.88.236 as permitted sender) smtp.mailfrom=zen-freebsd-ml@suzuki.que.ne.jp Received: from localhost (kaga.x.inetd.co.jp [192.168.10.10]) by moon.m.inetd.co.jp (Postfix) with ESMTP id 9AAE680054 for ; Fri, 13 Sep 2024 18:06:13 +0900 (JST) Date: Fri, 13 Sep 2024 18:06:13 +0900 (JST) Message-Id: <20240913.180613.1836747525119143459.inetd@x.inetd.co.jp> From: zen-freebsd-ml@suzuki.que.ne.jp To: freebsd-users-jp@freebsd.org Subject: Re: =?iso-2022-jp?B?RnJlZUJTRBskQiROJWolaiE8GyhC?= =?iso-2022-jp?B?GyRCJTklNSUkJS8la0pROTkkSyREJCQkRhsoQg==?= In-Reply-To: <84A126A0-A888-46B0-AF7A-3350D214E947@gmail.com> References: <20240911.161356.1304132417828656068.inetd@x.inetd.co.jp> <84A126A0-A888-46B0-AF7A-3350D214E947@gmail.com> X-Mailer: Mew version 6.7 on Emacs 28 / Mule 6.0 (HANACHIRUSATO) List-Id: Discussion relevant to FreeBSD communities in Japan List-Archive: https://lists.freebsd.org/archives/freebsd-users-jp List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-users-jp@freebsd.org Sender: owner-freebsd-users-jp@FreeBSD.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Spamd-Bar: - X-Spamd-Result: default: False [-1.34 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_LONG(-0.87)[-0.867]; MV_CASE(0.50)[]; NEURAL_SPAM_SHORT(0.23)[0.226]; R_SPF_ALLOW(-0.20)[+ip4:210.129.88.0/23]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:4694, ipnet:210.129.0.0/16, country:JP]; FROM_NO_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-users-jp@freebsd.org]; DMARC_NA(0.00)[que.ne.jp]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-users-jp@freebsd.org]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4X4pMM0cBRz4l2M 鈴木＠葛飾区です。 皆様、多数のご意見ありがとうございます。 お返事が遅くなったことをお詫びします。 あまり詳細を書かなかったので分かりづらかったかも知れませんが、代表して 引用させていただいた内藤さんの内容がだいたい全貌です。 コストが高いと思っていることは大きくわけて運用上の問題と、技術的な問題 に分かれます。 運用上はお客様が利用されるサーバーですので、バージョンアップ時には次の ような作業を行っています。 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-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 > > >