Linuxの集中パッチ管理にどのように取り組みますか？

私は、10台以下のLinuxサーバーで構成される小規模な（しかし成長しつつある）Linux環境を実行しています。

この環境は、CentOS 5＆6、およびOracle Linux 5＆6 boxenで構成されています。これらはすべて、適切なyumリポジトリを介して個別にパッチが適用されます。

これらのサーバーのパッチ管理を一元化する方法を誰かが提案できますか？これにはPuppetがよく使用されると聞いたことがありますが、私自身はこれを使用したことがなく、他のシステム管理者からの連絡に興味があります。

ほとんどの構成管理ツールは、これに本当に優れています。 人形とシェフは最も人気のある2つであり、ラドミンドは私が使用するものです。
特定のツールのドキュメントは、パッチ管理を実装する方法のアイデアを提供します-それはツールごとに異なります。

その他のオプションには、集中管理されたyum / apt / whateverリポジトリと、スケジュールされた間隔で（またはオンデマンドで）そこからパッチをプルする自家製のスクリプトが含まれ、一部の主要ベンダーからの商用ソリューションもあります（RedHatのRHN Satelliteなど）。それらがどのように機能するかを学ぶために時間を費やし、実際にそれらの機能を利用する場合に優れています。

だれもまだ指摘していないことの1つは、同質性です。可能な限り、サーバーで同じソフトウェアを実行している交換可能な歯車にします。これにより、パッチ管理が大幅に簡略化され（同じパッチはどこにでも行かなければなりません）、IMHOは環境の拡大に応じて作業を大幅に簡素化します。

私は宇宙遊泳に沿ったものをお勧めします。基本的には、Red HatのSatelliteソフトウェアの無料バ​​ージョンです。

Linuxを検討しているので、Redhatの次のプロジェクト、Pulpをチェックアウトしてください。

Pulpは、問題に対するより現代的なソリューションであり、具体的にはパッケージとパッチの管理、監査などを対象としています。これは、人形/シェフがある程度の労力で自分でできることです。PulpはパッケージとYumのみを実行し、Config管理をpuppet / chefに任せます。スクリプティングなどのためのRest APIがあります。

私はSpacewalk / Satelliteのファンではありませんが、YMMVのファンです。

はい、私たちは大規模なクラスターパッチと管理管理にパペットを使用します。小さなセットのもう1つの代替手段は、ローカルのyumリポジトリを作成し、カスタムRPMパッケージを使用して変更をデプロイすることです。