以前は保守されていなかったサーバーRHEL5.7を更新するためのベストプラクティス
新しいRedHat EL5.6サーバーが最近私の管理下に置かれました。過去12か月間、パッケージの更新にはまったく注意が向けられていなかったことは明らかです。
通常、私はそれが壊れていないかどうかの考え方を持っています-修正しないでください。ただし、サーバーをRHNに登録し、yum-securityプラグインを使用してセキュリティ更新をチェックした後は、1100を超える「セキュリティ」更新が利用可能です。
誰かが同様の状況にありましたか？何が更新されているのか、それがボックスで実行されているものに影響を与える可能性があるかどうか（これが本番サーバーです）を知りたいので、私はすべてを更新することに消極的です。ただし、この方法に沿っていくと、1100パッケージの正誤表を1行ずつ確認する必要があるようにも見えます。より効率的なソリューションはありますか？
一般的に言えば、セキュリティ更新は、特にRedHatのような目標を持つディストリビューションでは、ある程度安全であると考えられています。彼らの中心的な焦点は、一貫した動作環境を作成することです。そのため、メンテナはパッケージのバージョンを選択し、長期にわたってそれらに固執する傾向があります。意味を理解するには、kernel、python、Perl、httpdなどのパッケージのバージョンを見てください。また、上流の開発者からのセキュリティパッチをバックポートします。そのため、Apache httpd 2.2.xのすべてのバージョンにセキュリティの脆弱性が見つかった場合、Apacheファウンデーションは修正済みのバージョン2.2.40をリリースしますが、RedHatはローカルでパッチを適用し、修正済みのhttpd-2.2.3-80をリリースします。
また、現在RHEL5.7システムについて話していることを覚えておいてください。現在のリリースは5.9です。一部のソフトウェアベンダーは、特定のサブリリースのみをサポートします。たとえば、最近、ソフトウェアの1つに遭遇しました。たとえば、ベンダーは5.4でしか動作しないと言っています。 しないは5.9で動作しますが、しないが機能する場合、サポートを提供しない可能性があります。
それほど長い間パッチが当てられていないシステムの大量更新を行うことにも懸念があります。私が遭遇した最大の問題は、実際には構成管理の問題であり、大きな更新によって悪化する可能性があります。構成ファイルが変更されることがありますが、管理者はサービスを再起動しません。これは、ディスク上の構成がテストされたことはなく、実行中の構成が存在しない可能性があることを意味します。そのため、カーネルの更新を適用するとサービスが再起動した場合、実際には再起動しないことがあります。または、異なる動作をする場合があります1回再起動します。
私のアドバイスは、更新を行うことですが、それについては賢明です。
- メンテナンス期間中に計画を立てます。サーバーを再起動する必要がある場合以外は、いくつかのカーネルアップデートがあり、それらを適用するには再起動する必要があります。
- 何かを行う前に、必ず完全バックアップを取ってください。これは、これがVMの場合、スナップショットであり、ツールが何であれフルバックアップをトリガーし、
/を（別のシステムに）ターリングし、ドライブのddイメージを取得します。復元できるものである限り。 - 計画を立てる方法アップデートを適用します。単に
yum update -yを投げて立ち去りたくないだけです。 yumが行うすべての優れた点について、依存関係に従って更新を適用するときにnotの順序で実行されます。これは過去に問題を引き起こしてきました。私は常にyum clean all && yum update -y yum && yum update -y glibc && yum updateを実行します。これにより、潜在的な順序の問題のほとんどが処理されます。
これは、再プラットフォーム化する絶好の機会かもしれません。 RHEL6はかなり前からありました。このサーバーの動作によっては、新しいインスタンスを並行して起動している間、このサーバーをそのまま実行することは理にかなっています。それがインストールされたら、すべてのデータをコピーして、サービスをテストし、カットオーバーを実行できます。これにより、システムが標準化され、クリーンで、十分に文書化されていること、およびすべてのジャズについても、ゼロから知ることができます。
どんなことをしても、現在のシステムに慣れることがとても重要だと思います。あなたはあなたの仕事と完成した製品を信頼できる方法でそれを行うことを確認する必要があるだけです。
私の経験では、RHELは同じリリースの更新の後方互換性を壊しません。
ただし、rpmの外部にインストールされているものには適用されません。
rpm -qf疑わしいファイルが外部でコンパイルされていることを確認するには、「どのパッケージにも所有されていない」と返された場合、アップグレードに問題がある可能性があります。
私はサーバーのイメージを取り、アップグレードを行いますが、私はほとんどの人より少し悪魔かもしれません。