私はFreeBSDを約5年間(サーバー/デスクトップ)使用しており、apt-get/yumをすべての習慣に合わせてアップグレードする傾向があります(Debian/RHEL/Centボックスも管理しています-私は知っています、私は知っている...プラットフォームに関係なく、より目の肥えているはずです)。したがって、通常は次のとおりです。
portsnap fetch
portsnap update
portmanager -u
ポート用
時々続く:
freebsd-update fetch
freebsd-update install
システムについて... etc。その後、混乱が発生した場合は、それをクリーンアップします。
これは、非BSDを使って物事を行うにはかなり過剰な方法だと私は理解しています。 BSDボックスに対するあなたの哲学は何ですか?あなたはportaudit/portversionを実行していますか?出力を確認し、慎重に検討した後、更新(削除...など)してください?
私はOpenBSDにかなり慣れていない、と告白します。ポートツリーをcvsupし、「古い」スクリプトを実行してから、重要なポートをアップグレードするだけですが、カーネル/バイナリはそのままにして、6か月ごとにアップグレードします。カーネル、バイナリにパッチを適用/再コンパイル/再構築しますか---なぜですか?
BSDボックスの重要なサービス(かなり重要-これは銀行や病院ではありません)に対する保守的なアプローチは何ですか? Linuxボックスで同様のアプローチを使用していますか?セキュリティ警告が私の心に恐怖を襲わせない限り、私は通常、どのサーバーのカーネルにも触れません。
ええ、たくさんのドキュメントや本があります-あなたは実際に何をしていますか?私たちは基本を知っていると仮定します-知恵は何ですか?利害関係者/利害関係者/ユーザーがそうであるように、ユースケース/環境とシナリオは異なります。本とマニュアルページはツールと使用法をカバーしていますが、実用的なアプリケーションが不足しています。それをカバーするものを知っているなら本をお勧めします!
読んでくれてありがとう!
バブノフ
結論〜この投稿に回答するために時間を割いてくれたすべての人に感謝します。私の全体的な戦略は、現在、両方のBSDのメーリングリストに従い、以前よりも更新を選択的/見極めることです。
FreeBSD〜Portauditは良い答えです。メーリングリストと入念な監査により、これはここでうまく機能すると思います。 OpenBSDとFreeBSDの間でポートに重点が置かれているのは興味深いことです。
OpenBSD〜メーリングリストに従い、重要と思われる場合はパッケージツール(pkg_infoおよびpkg_add -u)を使用します。アップグレード:少なくとも年に1回はアップグレードする必要があるようです。最新のリリースと1つのバックをサポートしているため、現在は4.8と4.7です。
再度、感謝します。
インストールされているポートで脆弱なパッケージを頻繁にチェックするようにしてください:portaudit -Fda
OpenBSDアップデート哲学
これはOpenBSDを更新するための私のアプローチです
以下のセキュリティリリース/パッチに関する最新情報を入手してください。
更新手順:
a。関連する メーリングリスト に従ってください-squish.netの毎日のダイジェストと、TechおよびMiscメーリングリストに示されている一般的な方向性を確認します。
b。 Unix関連のセキュリティ発表Webサイト/メーリングリストに従ってください。
c。 cvsync を使用したローカルCVSコピーを維持する
d。ビルド 上記からの安定したリリース
セキュリティアップデートが公開されると、そのバージョンのOS /脆弱性を備えたマシンのプロファイルを使用して実際のセキュリティ問題を評価します。脆弱性が関連している場合は、「同じバージョンのアップグレード手順」を実行します。
ポート/パッケージのセキュリティ更新を追跡することはより困難ですが、インフラストラクチャ上にあることが十分に重要である場合は、BASEと同様の方法で追跡することが十分に重要です。
特定のアプリケーションのメーリングリストに参加してください(OpenBSDプロジェクトとは関係なく、アップストリームの変更を管理するのは私たちの責任です)。
セキュリティの配布リストに参加することは、アプリなどの脆弱性の調査結果を公開するCERTのようなものです。
明らかに、本番マシンで実行する前に、個別のハードウェア(またはVM)でインストール手順を構築してテストします。幸いなことに、多くのことに対して冗長なホストがあるため、サービスのダウンタイムを最小限に抑えて展開できます。 OpenBSDは幅広いハードウェアをサポートしているため、プライマリマシン用のサーバーグレードの機器と、ローエンドデスクトップを冗長ホストとしてロールアウトできます(または、更新サイクル中にメインマシン用の一時的なボックスを作成するだけです)。
当社の更新手順は、非BASEソフトウェアのポート/パッケージシステムの使用に大きく依存しています。ソースからソフトウェアをインストールする2つのホストは、OSのバージョンアップデート間でアップデートするのが面倒です。
BASE OSの場合、古いバイナリの上に新しいバイナリをインストールするだけで引き続き成功します。できれば、すべてのOSとアプリケーションの構成/データファイルをバックアップし、パッチを適用したOSをフォーマットして再インストールし、パッケージを再インストールします(元のデータを保持します)
私たちが配備したOpenBSDホスト(30以上)と経験では、構成とデータのバックアップは難しくありません。ファイアウォールの場合、すべてのデータは構成ファイルとログファイルにあります。
ポート/パッケージの場合-変更が簡単な場合は、独自のポートを変更し、そこからパッケージを構築します。ポートを更新すると、上記のプロセスが簡単になります。
OSのリリース間で、スケッチからすべてをインストールします。
プロセスには十分なドキュメントがあると思いますが、基本的には、「交換する」システムと同じ構成の参照マシンを構築します。ホストをデプロイする前に必要な同じテストを実行します。
参照ホストから構成をバックアップし、本番ホストにOpenBSDをインストールして、その上に「検証済み」構成を復元します(後で同じ検証テストを実行します)。
この種のことを行うための特定の「BSDの方法」があるかどうかはわかりません。それはすべて、何が更新され、何がテストされているかを知ること、つまり一般的なシステム管理者のものに帰着します。幸いなことに、freebsd-updateおよびportsnapは、「何を知る」ことをかなり簡単にします。
しかし、あなたが詳細を尋ねたので、私が多数のFreeBSDマシンを群がらせたとき、それらはすべてクラスター内のノードでした。スタンドアロンマシンはこれとそれほど変わらないでしょうが、これを漠然と 'devops'にして運用サービスのようにすることができると思います。結局のところ、テスト環境と本番環境を別々にすることは常に良い考えです。
クラスターの状況では:
明らかに、これはシステムとポートの両方のアップデートの場合でしたが、手順はパッケージまたはシステムをアップデートするだけで十分に似ていました。
2台のマシンでこれを行う場合、それぞれを本番またはステージングとして順番に実行するか、ステージングから本番を更新するだけで済みます。
Cvsログから変更を追跡し、/ usr/src/UPDATINGおよび/ usr/ports/UPDATINGで特定の更新を取得したかどうかを確認できます。どちらもcvsupから自動的に更新されます。
cvsupを使用しない場合(そして最近では理由が少なくなっています)、必要な更新を追跡する他の方法を見つける必要があります。 freebsd-updateが自分に加えたい変更のリストをメールで送信し、セキュリティエラッタページを監視することができます。
OpenBSDの場合、少なくとも:
セキュリティ上の問題や機能を妨げるバグがない場合は、そのままにしておきます。おそらく3〜6か月ごとに更新をチェックして、あまり遅れないようにします。
壊れていない場合は、修正しないでください。
ポートのアップグレードにはportupgrade
を使用することを好み、これは絶対に必要な場合、たとえばポートに脆弱性が見つかった場合、または新しい機能が必要な場合。
システムのアップグレードについては、通常、make buildworld
。私はこのアプローチで何の問題もありませんでした。