解決策 1:
apt-get update -qq; を実行します。 apt-get upgrade -duyq 毎日。これにより更新が確認されますが、自動的には行われません。
その後、監視しながら手動でアップグレードを実行し、問題があれば修正できます。
パッチが適用されたシステムを維持することのセキュリティ上の懸念に加えて、パッチの間隔が長すぎると、大量のパッケージになってしまうことがわかりました アップグレードしたいのですが、それは私を怖がらせます-毎週1つか2つをアップグレードするだけではありません。したがって、私はアップグレードを毎週実行するか、優先度が高い場合は毎日実行する傾向があります。これには、どのパッケージがシステムを壊したかを知るという追加の利点があります (つまり、一度に 2 つしかアップグレードしていない場合)
私は常に、重要度の低いシステムを最初にアップグレードします。システムを修正できない場合に備えて、「ロールバック計画」も用意しています。 (当社のサーバーのほとんどは仮想であるため、このロールバック計画は通常、スナップショット の取得で構成されます 必要に応じて元に戻すことができるアップグレード前)
そうは言っても、アップグレードによって何かが壊れたのは、過去 4 年間で 1 つか 2 回だけだと思います。それは、高度にカスタマイズされたシステム上にあったものです。
解決策 2:
以前の回答に加えて、より具体的な Debian のことをいくつか:debian-security-announce と debian-announce を購読するか、Debian Security ページをチェックしてください。
解決策 3:
Debian の安定版リリースを実行していると仮定すると、ほとんどのパッチはセキュリティまたはバグ関連であり、特定のパッケージのバージョン間で大きな変更があまりないことを意味します。 debian パッチ ポリシーによると、パッチは、メンテナーによって安定版ブランチに移動される前に、しばらくの間テストされている必要があります。明らかに、これはパッチ適用時の破損を止めるものではありませんが、ほとんどの場合、破損を防ぐはずです.
テスト サーバーが最新の状態に保たれていること、およびあなたとサーバーに影響を与えるバグがあるパッケージが最新の状態に保たれていることを確認することが賢明です。パッチが安定していることがわかったら、それらに対するセキュリティ アドバイザリがあるすべてのパッケージを更新する必要があります。
通常、Debian は非常に安定した OS であり、破損について過度に心配する必要はありませんが、更新される前に常に更新されるものを読み、奇妙に思われるものに注意してください。 /etc/ ディレクトリでも VCS を使用して、「git diff」コマンドで構成ファイルの変更を確実に確認できるようにしています。
解決策 4:
何が更新されるかを確認するために、(最初に) 予行演習を行います。時々、ライブラリ (この例では libfoo と呼びます) が API を変更し、自分で作成/インストールしたプログラムが壊れることがあります。重要なライブラリが更新された場合は、ソースを取得し、更新する前にそれに対して私たちのものを再構築しようとします.
また、Apache などの公共サービスの中間バージョンにジャンプしていないことも確認します。更新が重要でない限り、1 年遅れてランダムな破損に遭遇しないようにしたいと考えています。
あなたがシステム管理者であれば、Secunia などのサイトから RSS フィードを取得する必要があります。そうすれば、ディストリビューションがいくつかのパッチをプッシュするかどうかを事前に知ることができます。
やみくもにアップグレード/更新しないでください。残念ながら、特にシステムがプログラマーをサポートしている場合、何が壊れているかを知る作業は、ディストリビューション パッケージ マネージャーではなく、あなたにあります。
解決策 5:
私が働いている場所では、PatchLink と呼ばれるソフトウェアを使用して最も重要なセキュリティ関連の更新プログラムを通知し、テスト後にパッケージごとに適用するという、かなり広範なプロセスがあります。ただし、何千ものサーバーがあります。
サーバーが 2 つしかない場合、プロセスははるかに簡単になります。 「apt-get update/upgrade」を実行することが最善の策だとは思いませんが。
あなたが実行しているソフトウェアのパッチを監視し、それらのリリースの修正に基づいて、いつアップグレードするかを決定します。
テスト サーバーがあるので、更新を適用する前に常にテストしてください。