サーバーを安全に保つための自動「yum更新」-長所と短所?


8

yum -qy update定期的なメンテナンスを受けていない一部のマシンで、定期的に実行するcronjobを追加することを検討しています。目標は、そうでなければ適用が遅すぎるセキュリティパッチに関して、マシンを最新の状態に保つことです。CentOSベースのリポジトリのみを使用しています。

質問:

  • あなたの経験では、このアプローチはどのように「安全」でしょうか?たまに更新の失敗を予期する必要がありますか?このアプローチでは、おおよそどのくらいの頻度で再起動が必要ですか?
  • このアプローチの長所/短所または他の落とし穴?
  • 自動化を使用して、マシンをどのように最新の状態に保ちますか?

2
yum -qyを/ usr / bin / yum -R 120 -e 0 -d 0 -y update yum AND / usr / bin / yum -R 10 -e 0 -d 0 -y update
Adam Benayoun

Adam:ご提案ありがとうございます。それが良い理由を説明していただけますか?
knorv 2009

1
最初にyumを更新し、次にパッケージを更新します。-Rは、最大のコマンド待機時間を提供することを意味します。つまり、私が正しい場合はタイムアウトしません。-eと-dは単なるエラー/デバッグレベルです
Adam Benayoun '08

「-R [分単位の時間]」-「yumがコマンドを実行する前に待機する最大時間を設定します-時間とともにランダム化します」についてはわかりません。yumはコマンドを発行する前にrand()*分待機するようです?いいですか :-)
knorv 2009

回答:


6

場合によります

CentOSでの私の経験では、CentOSベースのリポジトリのみを使用しているため、かなり安全です。

たまに更新の失敗が予想される場合...はい...時折、ハードドライブの故障やCPUの故障が予想されるのと同じレベルです。バックアップが多すぎることはありません。:-)

自動更新の良い点は、手動で行うよりもパッチを適用する(したがって、より安全にする)ことです。

手動パッチは常に他の多くのものに押し出されるか、または「低優先度」と見なされるように見えるため、手動モードに移動する場合は、カレンダーのスケジュール時間を使用してください。

私は多くのマシンを(cronジョブを介して)自動yum udpatesを実行するように構成しましたが、ほとんど問題がありませんでした。実際、BASEリポジトリに問題があったことを覚えていません。私が考えることができるすべての問題(私の頭の中で、私の経験では)は、常にサードパーティの状況でした。

それは言われています...私は手動で更新を行ういくつかのマシンを持っています。データベースサーバーやその他の非常に重要なシステムのようなものは、 "実践的な"アプローチをとりたいです。

私が個人的に理解した方法はこのようなものでした...「もしも」のシナリオを考えてから、バックアップから再構築または復元するのにどれくらい時間がかかるか、そして何が失われるか(もしあれば)を考えてみます。

複数のWebサーバーの場合...またはコンテンツがほとんど変化しないサーバーの場合...再構築/復元の時間が最小限であるため、自動更新を実行します。

重要なデータベースサーバーなどの場合...再構築/復元にかか​​る時間の方が時間がかかるため、私は週に1回、それらを確認して手動でパッチを適用する時間をスケジュールします。

ネットワークに配置しているサーバーと、バックアップ/リカバリ計画の実装方法によって、決定が異なる場合があります。

お役に立てれば。


6

プロ:サーバーは常に最新のパッチレベルであり、通常はゼロデイエクスプロイトに対してもです。

短所:サーバー上で実行されているコードのうち、それ以降のバージョンで削除された機能、構文を変更する構成ファイル、および悪用可能なコードの実行を妨げる新しいセキュリティ「機能」を使用しているものは、そのサーバー上で実行されているものをユーザーなしで破損させる可能性があります。問題があると誰かがあなたを呼ぶまでそれについて知っています。

ベストプラクティス:更新が必要なときにサーバーにメールを送信してもらいます。更新をバックアップするか、更新をロールバックする方法を知っています。


+1-centosメーリングリストに登録することを強くお勧めします。彼らは、リポジトリにプッシュされる前に、パッチと優先順位に関する通知をプッシュするのに優れています。
Adam Benayoun、

3
定義により、ゼロデイエクスプロイトに対するパッチはありません。0日間のエクスプロイトは、まだパッチが適用されていないエクスプロイトです。
MarkR 2009

私は、0日を発見/利用/発表した日と見なしています。Redhatは通常、数時間以内に重大な脆弱性にパッチを適用します-偶然にも、発見された日中です。
Karl Katzke、2009

2

ほとんどの人がここで言ったことに加えて、centosメーリングリストにサインアップすることを強くお勧めします。彼らは、リポジトリにプッシュする直前に、パッチとその優先順位に関するメールを常に投稿します。アップグレードする必要があるパッケージを事前に知っておくと便利です。

私のセットアップでは、yumがシステムを1日に1回自動的に更新できるようにしています。パッケージをインストールまたはアップグレードした直後に、yumにメールを送信させます。また、yumが競合し、手動での介入が必要な場合(4時間ごと)にもメールを受け取ります。

これまでは、すべてが順調に実行されています(今から4年以上)、yumが通常のカーネルをアップグレードし(サーバーを仮想化し)、GRUBを変更して通常のカーネルをデフォルトとして2週間プッシュしたときだけでした後でメンテナンス中にシステムが再起動し、手動で介入しなければならないまで、すべての仮想サーバーが数分間停止しました。

それ以外は特に問題はありませんでした。


1

カスタムパッケージがなく、CentOSのBaseリポジトリのみを使用している限り、かなり安全です。

また、これを実現するより良い方法は、yum-updatesddo_update = yessetで使用することです。


1
yum-updatesdサービスは、エンタープライズ環境には十分成熟していないため、サービスによって不要なオーバーヘッドが発生する可能性があります。私は使用します:/ usr / bin / yum -R 120 -e 0 -d 0 -y update yum AND / usr / bin / yum -R 10 -e 0 -d 0 -y update
Adam Benayoun

0

自動バックアップがあれば、サーバーのダウンタイムに耐えられる限り、それほど心配する必要はないと思います。

私はこれを試していません。アップストリームの修正により、何かを壊したり、異常な不明瞭な問題が発生したりする重大なリスクがあるため、個人的にはしたくありません。これがめったに注目されないサーバーである場合、それはさらに悪いことです。

問題のサーバーが停止した場合に、問題が発生したサーバーが一定期間停止し、システムを以前の状態に復元するための対応計画と、ログまたは電子メールを介して更新を送信するシステムがある場合いつ、何が更新されたかを報告する(スタック状態ではない、または介入が必要な何かへの応答を待っていないことがわかる)と、それを試すことができます。それが重要なサーバーまたは重要な何かである場合...私はそれを危険にさらしたくありません。

私のサーバーはあなたのものではありません:-)

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.