yum更新するには？か否か？
このかなり単純な質問を許してください。
まず、私はシステム管理者ではないため、Linuxでの私の経験は多少制限されています。
約3〜4か月前、さまざまな理由で、CentOSサーバーを稼働中に設定しました。私たちはそれを（クライアントがアクセスできる）Webサイトの開発サーバー、Subversionサーバーとして使用しており、内部通信のためにそこにwikiをホストしているため、私たちにとって非常に重要なツールになっています。 （おそらく、私が設定したときよりも重要です！）
Yumが約250のパッケージをリポジトリ内の最新バージョンに更新したいと考えています。
サーバーは正常に動作しているので、これらのパッケージを更新するリスクを負う必要がありますか？セキュリティリスクは、すべてを更新したときにサーバーが破損するリスクよりも重要ですか？
すべてをバックアップしている間は、現在の方法ですべてを設定するには時間がかかること、そして現在のところ、仕事に余暇があまりないことを指摘しておきます。
アドバイスが更新である場合、プロセスをできるだけ安全にするために受け継がれるベストプラクティスはありますか？
アドバイスを事前にありがとう。
更新-皆様のご回答ありがとうございます。みんなを賛成するのに十分な担当者がいたら、そうします。 ;）ハードドライブをゴースト化して更新することにしました。残念ながら、現在のところ、システム管理者をフルタイムまたはパートタイムで確保することはできません。そのため、私はできる限りこの問題に対処する必要があります。
迅速で汚れた（つまり、Battlefield Administrator）ソリューション：
システムをオフラインにし（できることを願います）、2台目のハードドライブにNortonGhostバックアップ（または同様の何か）を実行します。
2番目のハードドライブを起動し（バックアップが実際に機能することを確認するため）、そのドライブでyum更新を実行します。
すべてうまくいったら...おめでとうございます！
それが何かをねじ込んでいる場合...先に進んで、元のドライブに入れて、「プランB」を考え出してください。
更新：
ここで本当の問題は「私の古いシステムを更新し、それを台無しにするリスクがあるか？」または「完全に機能するシステムをパッチを適用せずに放置し、ハッキング/不正使用の危険を冒していますか？」
答えは...上記の手順でシステムにパッチを適用したら...頻繁にバックアップし、頻繁にパッチを適用することで、その上に留まるようにしてください。
次に、両方の長所を持ちます。 ;-)
はい、更新します。
RHEL（したがってCentOS）は、互換性のないバージョンにバージョンを更新しないように注意しており、バグ修正とセキュリティ修正をバックポートしているため、パッケージへの実際の変更は最小限であり、互換性の問題を引き起こす可能性はまずありません。
設定ファイルが変更されている場合、パッケージは、作成される.rpmorigまたは.rpmnewファイルについて通知します。 RPM自体の設定によって異なります。作成中の警告に関する警告を探して、古い設定（ "cp foo foo.bak; cp foo.rpmorig foo "）または.rpmnewファイルを見て、変更を構成に組み込みます。
定期的に更新する場合、問題はあまり目立ちません。
四半期ごと（3か月ごと）に更新されるシステムがたくさんあります。また、パッケージの更新による問題はほとんど見られません。 （SANからLUNにアクセスするために奇妙なカーネル処理を行うシステムを除く）
そうですが、アップグレードには時間がかかります。同じ方法で、何か問題が発生した場合は復元に時間がかかります。そのシステム上のデータがエクスプロイト/ハッキングによって削除された場合、どれほどの痛み/苦痛がありますか？
CentOSベースリポジトリからのアップグレードの大部分は安全にインストールできます。CentOSで更新の問題が発生したのは、外部リポジトリ（DAG、RPMForge、など）を起動または使用する必要があるときだけです。
ベストこの種の設定では、ホットスワップ可能なサーバーを準備して、ライブサーバーに展開する前に更新をテストできます。
実際のシステム管理者が数時間かけてシステムを確認し、更新して、すべてが再度実行されることを確認する必要があるようです。理想的には、あなたはこの人に来て、月に数回あなたのためにこれをしてもらうでしょう。サーバーとはnot一度インストールしたら忘れてしまうものです。定期的なサービスが必要です。
このシステムが非常に重要である場合、セキュリティ更新はさらに重要になります。古くなったパッケージがシステムの侵害を許容する場合（いつ？）再構築のためにそのシステムを停止する必要がある場合の影響を考慮してください。理想的には、最初に更新するのと同じような方法でテストサーバーを構成し、何かが壊れていないか確認します。
アップデートを適用する場合、いくつかのことを確認する必要があります。
- 更新時間は、システムを使用するすべての人に公開されます
- 各アプリケーションを更新およびテストする方法に関する計画がある
- 更新がアプリを壊した場合（いつ？）更新を元に戻す方法の計画があります
- そして、何かが本当にうまくいかない場合に備えて、現在のバックアップが存在します
優れたシステム管理者は、この種の作業の経験があり、とにかくそれらのすべてを行う必要があります。組織に問題がある場合は、今がシステムの管理をダンプする時期かもしれません。または、自分でこれを行うことに不安がある場合は、この種の定期的なメンテナンスを行うために、契約時に誰かを雇うことを検討してください。どちらの場合でも、更新必要が発生します。これは、将来の状況をさらに悪化させる可能性があるためです。
これが、今日、実際のハードウェアで運用システムを実行することがほとんどない理由です。私はそれらを仮想マシンで実行します。次に、短いダウンタイム（5分）の間に、ESX自体からスナップショットを実行するか、カスタムXen/Solaris/OpenVZセットアップを使用している場合は、サーバーイメージのLVMスナップショットを作成します。次に、元のバックアップを起動して、好きなように実行できるコピーを作成しました。
とはいえ、カーネルとApacheの更新から始めて、そこから逆方向に作業します。 yumがレポートする完全なパッケージリストを取得する必要はありませんが、最も早くパッチを適用するのは上位の攻撃ベクトルでなければなりません。
Linuxシステムがハッキングされたことがあるのは、Apache、openssh、またはカーネル自体にパッチを適用していないためです。
セキュリティ関連のパッケージを更新するだけです。
私はその正確なことを1年ほど前に思い付きました...私はCentOSボックスでyum更新を行い、Dellハードウェアで実行しましたが、起動しないカーネルをインストールしました。箱にはまだ何もロードされていませんでした（そうでなければ、私はもっと慎重になったでしょう）。多くの時間をいじくり回していましたが、CentOS/Linuxの新しいカーネルとそのDellボックスの間には互換性がないようです。更新には非常に注意してください。更新することをお勧めするので、更新することをお勧めしますが、システムのゴミから回復する準備をしてください！