更新するには？か否か？

このかなり単純な質問はご容赦ください。

まず、私はシステム管理者ではありません。Linuxでの経験はやや限られています。

約3〜4か月前、さまざまな理由で、CentOSサーバーを稼働中にセットアップしました。Webサイト（クライアントがアクセスできる）の開発サーバー、Subversionサーバーとして使用しています。また、内部通信用のWikiをホストしているため、非常に重要なツールになりました。（おそらく、私が設定したときに思っていたよりも重要です！）

Yumが約250個のパッケージをレポジトリの最新バージョンに更新したいことに気が付きました。

サーバーは正常に機能しているため、これらのパッケージを更新するリスクを負うべきですか？セキュリティリスクは、すべてを更新したときにサーバーが破損するリスクを上回っていますか？

私はすべてのバックアップを取っているが、すべてを今のように設定するには時間がかかり、現時点では仕事に余暇があまりないことを指摘する必要があります！

アドバイスが更新である場合、プロセスを可能な限り安全にするために渡すことができるベストプラクティスはありますか？

アドバイスを事前に感謝します。

更新-皆様のご回答ありがとうございます。みんなに賛成するのに十分な担当者がいたら、そうするでしょう。;）ハードドライブをゴースト化して更新することにしました。残念ながら、フルタイムまたはパートタイムのシステム管理者を取得することは現時点では選択肢ではないため、できる限り問題に対処する必要があります！

迅速で汚れた（つまりBattlefield管理者）ソリューション：

1. システムをオフラインにし（できれば）、2台目のハードドライブにNortonGhostバックアップ（または同様のバックアップ）を実行します。

2. （バックアップが実際に機能することを確認するために）2番目のハードドライブを起動し、そのドライブでyum更新を行います。

3. すべてうまくいったら...おめでとうございます！

4. それが何かをめちゃくちゃにした場合...先に進み、元のドライブに入れて、「プランB」を考え出します。

更新：

ここで本当の問題は「古いシステムを更新し、それを台無しにするリスクがあるのか​​」ということだと思いました。または「完璧に機能するシステムにパッチを適用せずに、ハッキング/侵害を受ける危険を冒しますか？」

答えは...上記の手順を経てシステムにパッチを適用したら...頻繁にバックアップし、頻繁にパッチを適用して、システムの最新状態を維持してください。

そうすれば、両方の長所を活用できます。;-)

はい、更新します。

RHEL（したがってCentOS）は、互換性のないバージョンにバージョンを更新しないように注意します。代わりに、バグ修正とセキュリティ修正をバックポートするため、パッケージへの実際の変更は最小限であり、互換性の問題を引き起こす可能性はほとんどありません。

構成ファイルが変更された場合、パッケージは、作成される.rpmorigまたは.rpmnewファイルについて通知します。RPM自体の構成に依存します。作成中の警告に関する警告を探して、古い構成を元に戻す（ " cp foo foo.bak; cp foo.rpmorig foo"）か、.rpmnewファイルを確認して変更を構成に組み込むことができます。

定期的に更新する場合、問題はそれほど目立ちません。

四半期ごと（3か月ごと）に更新されるシステムが多数あります。パッケージの更新による問題はほとんどありません。（SANからLUNにアクセスするために奇妙なカーネル処理を行うシステムを除く）

はい、アップグレードには時間がかかります。同じマナーで、何か問題が発生した場合は復元に時間がかかります。そのシステムのデータがエクスプロイト/ハッキングによって削除された場合、どれほどの痛み/苦しみがありますか？

CentOSベースリポジトリからのほとんどのアップグレードは安全にインストールできます。CentOSで更新の問題が発生したのは、外部リポジトリ（DAG、RPMForge、Ectなど）を使用する必要があるときだけです。

最高この種セットアップは、ホットスワップ可能なサーバーを準備しておくことです。そのため、ライブサーバーに展開する前に更新をテストできます。

実際にシステム管理者が数時間かけてシステムを調べ、更新し、すべてが再度実行されることを確認する必要があるように思えます。理想的には、この人が月に数回来て、あなたのためにこれをやってもらうでしょう。サーバーは、一度インストールすれば忘れることはありません。定期的なサービスが必要です。

このシステムが非常に重要な場合は、セキュリティ更新プログラムがさらに重要になります。期限切れのパッケージがシステムの侵害を許可する場合（いつ？）、再構築のためにそのシステムを停止する必要がある場合の影響を考慮してください。理想的には、最初に更新できるのと同様の方法で構成されたテストサーバーを用意し、何かが壊れていないかどうかを確認します。

更新を適用する場合、いくつかのことを確認する必要があります。

1. 更新時間は、システムを使用するすべての人に公開されます
2. 各アプリケーションを更新およびテストする方法の計画があります
3. 更新プログラムがアプリを壊した場合（いつ？）
4. そして、何かが本当にうまくいかない場合に備えて、現在のバックアップが存在します

優れたシステム管理者は、この種の作業の経験があり、とにかくすべてのことを行う必要があります。組織に何かがある場合、これはそれらのシステムの管理をダンプする時間であるかもしれません。または、自分でこれを行うことに不安がある場合は、契約で誰かを雇ってこの種の定期的なメンテナンスを行うことを検討してください。いずれにせよ、あなたは将来的にもっと悪い状況に自分自身を開放しているので、更新を行う必要があります。

これが、今日、実際のハードウェア上で本番システムを実行することがほとんどない理由です。仮想マシンで実行します。次に、短時間のダウンタイム（5分）の間、ESX自体からスナップショットを実行するか、カスタムXen / Solaris / OpenVZセットアップを使用している場合は、サーバーイメージのLVMスナップショットを実行します。次に、元のバックアップを起動します。これで、必要に応じてコピーを作成できます。

とはいえ、カーネルの更新から始めて、Apacheを実行し、そこから逆方向に作業します。yumが報告する完全なパッケージリストを取得する必要はありませんが、上位の攻撃ベクトルは、最も早くパッチを当てるものでなければなりません。

Linuxシステムをハッキングしたことがあるのは、Apache、openssh、またはカーネル自体にパッチが適用されていないためです。

セキュリティ関連のパッケージを更新するだけです。

その正確なことは1年ほど前に出てきました... Dellハードウェアで実行されているCentOSボックスでyumの更新を行い、起動しないカーネルをインストールしました。ボックスにはまだ何もロードされていませんでした（そうでなければ私はもっと用心していたでしょう）。それをいじくり回すのに多くの時間を費やしましたが、CentOS / Linuxの新しいカーネルとそのDellボックスの間にはいくらかの非互換性があるようです。アップデートには十分注意してください。更新することは正しいことなので、更新することをお勧めしますが、ゴミ箱に入れられたシステムから回復する準備をしてください！