どのくらいの頻度でLinuxサーバーを更新する必要がありますか？
私は、運用サーバー（メール、Web、データベースがすべて1つのサーバー上にある）とテストサーバーの両方を管理する責任があります。どちらもDebian上に構築されています。しかし、私はシステム管理に非常に慣れていないため、新しい機能を追加してバグを修正できるようにするために、更新が必要なものに遭遇したときのみ、更新をインストールしています。現時点ではかなりアドホックなプロセスなので、少しは減らしたいと思います。
それで、自分が何をしているのかを知っている人々がこれをどのように処理するのか疑問に思っていますか？どのくらいの頻度でサーバーでアップグレードを実行しますか？アップグレードプロセスはテストと本番で異なりますか？常に最初にテストサーバーをアップグレードしますか？また、すべてのソフトウェアを完全に更新しますか、それとも選択した更新のみをインストールしますか？
apt-get update -qq; apt-get upgrade -duyqを毎日実行しています。これは更新をチェックしますが、自動的には行いません。
次に、監視しながらアップグレードを手動で実行し、問題が発生する可能性がある場合は修正できます。
パッチが適用されたシステムを維持することのセキュリティ上の懸念に加えて、パッチの間隔を長くしすぎると、最終的には大量のパッケージになってしまいますアップグレードしたいので、私は怖いです-毎週1〜2回アップグレードするだけではありません。したがって、私は毎週、または優先度が高い場合は毎日、アップグレードを実行する傾向があります。これには、どのパッケージがシステムを壊したかを知るという追加の利点があります（つまり、一度に2つだけアップグレードする場合）。
重要度の低いシステムを常に最初にアップグレードします。システムを修正できない場合に備えて、「ロールバック計画」も用意しています。 （ほとんどのサーバーは仮想なので、このロールバック計画は通常、アップグレード前にsnapshotを取得することで構成されています。必要に応じて元に戻すことができます）
とはいえ、アップグレードによって過去4年間で1、2回だけ問題が発生したと思います。これは高度にカスタマイズされたシステム上にあったため、偏執的である必要はありません:)
以前の回答に加えて-より具体的にはDebianの事柄： debian-security-announce および debian-announce にサブスクライブするか、または Debianセキュリティページ 。
Debianの安定版リリースを実行していると仮定すると、ほとんどのパッチはセキュリティまたはバグに関連しています。つまり、特定のパッケージのバージョン間で大きな変更があまり行われないことになります。 debianのパッチポリシーによると、パッチはメンテナによって安定版ブランチに移動される前に、しばらくの間テスト中であったはずです。明らかにこれはパッチを当てるときに破損を止めませんが、ほとんどの場合それらを防ぐはずです。
テストサーバーを最新の状態に保ち、バグがあなたとあなたのサーバーに影響を与えるパッケージはすべて最新の状態に保つ必要があります。それらに対するセキュリティ勧告があるすべてのパッケージは、パッチが安定していることがわかったらすぐに更新する必要があります。
Debianは通常、非常に安定したOSであり、破損に過度に注意する必要はありませんが、更新される前に更新内容を常に読み、異常と思われるものに注意してください。/etc/dirでもVCSを使用して、構成ファイルの変更が「git diff」コマンドで確実に表示されるようにしています。
何が更新されるかを確認するために、（最初に）予行演習を行います。時々、ライブラリー（この例ではlibfooと呼ぶことにします）がAPIを変更します。重要なライブラリが更新された場合は、ソースを取得して、更新前にライブラリを再構築してみます。
また、Apacheなどの一部のパブリックサービスの中間バージョンにジャンプしないことも確認します。更新が重要でない限り、1年遅れてランダムな破損が発生しないようにします。
あなたがシステム管理者である場合、あなたはあなたのディストリビューションがいくつかのパッチをプッシュするつもりである場合、事前にあなたに方法を知らせる Secunia のようなサイトからRSSフィードをプルするべきです。
決して盲目的にアップグレード/更新しないでください。残念ながら、特にシステムがプログラマーをサポートしている場合は、何が壊れているかを知る作業は、ディストリビューションパッケージマネージャーではなく、あなたにあります。
手動での更新は、何が起こっているのかを確認できるという意味で、ここで述べたように最適です。ただし、実用的でなくなる可能性のある非常に多数のサーバーの場合。予行演習は標準的な慣行です。実際、ほとんどのパッケージマネージャーは続行する前にあなたに尋ねます。
定期的に更新するのが最善の傾向ですが、多少のバランスを取る場合もあります。頻繁な更新は、一度に少なく、一度に間違ってしまうことを少なくします。問題が発生した場合、検査する候補者は少なくなります。パッケージはまた、小さなステップでの更新がわずかに優れています。一般に、プログラマーが最終バージョンから次のバージョンに移行するときに更新を確認するとき、最終バージョンを超えて注意を払うかどうかはさまざまですが、これは重要になる傾向があります主に急速に進化しているソフトウェアのために。
すべてのアップデートが無停止であるわけではありません。あなたはこれに気をつけたいでしょう。一部は、ダウンタイムにつながるサービスを再起動します。
理想的なセットアップでは、次のようになる可能性があります。
- 一見サーバーを切り替える方法（A/Bまたはtick tock）。つまり、ベンチ上で更新してから、現在のトラフィックから新しいトラフィックにトラフィックを交換するだけです。データベースなどのサービスの場合、これはさらに複雑になる可能性があります。
- 更新をテストする機能。実際には本番環境のクローンであるテストサーバーが必要です（ただし、本番環境サービスには接続していません）。これらにより、最初に更新をテストできます。
- 優れたバックアップ戦略であるインクリメンタルが理想的です。あなたは、決して知らない。申し訳ありませんが常に安全である方が良いです。
- 最も多くのアクティビティが発生する時間と、許容できるダウンタイムのレベルに注意してください。
- 更新または特定のパッケージをロールバックする方法を知っています。
- 独自のパッケージミラーを用意して、更新がサーバー間で一貫していて予測可能になるようにします。これは、信頼できるまともな無人システムに向けた最初のステップです。つまり、ミラーを更新し、1つ以上のテストマシンで更新を実行して、それが適切であれば自動的に終了することができます。私は約800台のEPOSマシンを適切に管理する素晴らしい時間を過ごしました。
- 何かがここで機能する場合、そこで機能することを知ることができるように、良好なレベルの一貫性。
これらのいくつかは、小規模なセットアップではさまざまな程度でやり過ぎになる可能性がありますが、覚えておく必要があります。
一般的に言えば、サーバーディストリビューションにとって、更新は通常比較的簡単です。これは、ほとんどの場合、バグの修正とセキュリティの更新のみを行うためです。ただし、システムに奇妙なことをしたり、パッケージソースを追加したりすると、問題が発生する可能性があります。
中程度のまれですが、それらは時々間違いを犯し、マイナーパッケージバージョン間の互換性を壊します。
私が作業している場所には、PatchLinkと呼ばれるソフトウェアを使用して最も重要なセキュリティ関連の更新を通知するかなり広範囲にわたるプロセスがあり、テスト後にパッケージごとに適用します。しかし、何千ものサーバーがあります。
サーバーが2つしかない場合、プロセスははるかに単純になります。 「apt-get update/upgrade」を行うのは最善の策だとは思いませんが。
実行しているソフトウェアのパッチを監視し、それらのリリースの修正に基づいて、いつアップグレードするかを決定します。
テストサーバーがあるので、適用する前に必ず更新をテストしてください。
Cron-aptと同じ行に沿って、unattended-upgradesパッケージを確認してください http://packages.debian.org/lenny/unattended-upgrades 。
設定が非常に簡単で、セキュリティアップデートを自動的にダウンロードして適用することができますが、手動でアップグレードするために他のアップデートを残すことができます（またはあなたの裁量ですべてをアップグレードしてください！）。
公式Ubuntuサーバーガイドには、無人アップグレードパッケージの使用をカバーするかなり詳細なセクションがあります https://help.ubuntu.com/9.04/serverguide/C/automatic-updates.html
注：注意/パラノイアのレベルに応じて、最初にテストサーバーのグループでローリングアップグレードを実行し、問題がない場合は、運用環境のボックスを更新することを許可しますが、私は個人的にセキュリティ更新で問題に遭遇していませんこれまでのところ、大混乱（木材をたたく）...
適用後、各セキュリティアップデートの結果をメールで送信する設定オプションもあります。また、更新中に表示されたダイアログやインタラクティブプロンプト（システム管理者による手動の調整が必要なもの）がある場合は、それらについても説明します。
私はcron-aptでこのプロセスを自動化するのが好きですが、 更新に関する別の質問で@dinomiteが指摘したように セキュリティ関連の更新を自動化するように具体的に設定することは非常に賢明なアイデアです-手動で更新できますあなたが必要なもの。私はすべての更新にcron-aptを使用していましたが、実際には彼の回答に基づいてこれを変更しました。気に入ったら、おそらくこれよりも 彼の答えを投票する にするべきでしょう。
Debianにcron-aptをインストールし、設定ファイルを編集して、変更がある場合はメールで通知します。このようにして、システムに更新がある場合に通知を受け、手動で更新を行います
私は個人的に自動更新をオフにし、以下の場合を除いて、環境内のサーバーでパッケージの更新を定期的に実行しません。 （b）特定の理由で個々のパッケージをアップグレードする必要があります。 （c）OSまたはパッケージはサイクルの終わりに近づいており、それらはサポートされなくなり、サポートを継続する必要があります。私の考えは、何が変更されているのか、または何かが壊れる余地が多すぎる理由を知らずにアップグレードすることです。このようなことを14年間続けてきましたが、うまくいきます。
言及されているものに加えて、更新を通知するために、ある種の監視ツール（Nagiosまたはボートをフロートさせるもの）を使用する必要があります。
どのくらいの頻度で：アップデートが利用可能になり次第！