サーバー構成ファイルのリビジョン管理を使用できるようにするためのソリューションは何ですか？
複数のシステム管理者がいる環境で、サーバー構成ファイルをリビジョン管理システムに追加することにはいくつかの利点があります。最も注目に値するのは、変更を追跡したり、変更した人を追跡したりできること、そしてもちろん、既知の動作中の構成にロールバックできることです。
私は主にUnix/Linuxソリューションに興味がありますが、Windowsの実装にも興味があります。
私はこれをしばらくの間自宅（約3台のホスト）でテストし、さまざまなscms（RCS、Subversion、git）を試しました。現在私にとって完璧に機能する設定は、gitの setgitperms フックです。
考慮する必要があること：
ファイルのアクセス権と所有権の処理
- RCS：これをネイティブに行います
- Subversion：最後に試しましたが、これを行うには
svnのラッパーが必要でした - git：
setgitpermsフックはこれを透過的に処理します（ただし、post-checkoutフックをサポートするかなり最近のバージョンのgitが必要です）
また、すべての/etcをバージョン管理したくないが、実際に変更したファイル（私のように）だけにしたい場合は、この種の使用をサポートするscmが必要になります。
- RCS：とにかく単一のファイルでのみ機能します。
- Subversion：これはトリッキーであることがわかりました。
- git：プローブがありません。「
*」を最上位の.gitignoreファイルに入れ、git add --forceを使用して必要なファイルのみを追加します
最後に、/etcの下にいくつかの問題のあるディレクトリがあり、そこにパッケージが構成スニペットをドロップして、いくつかのプログラムまたはデーモンによって読み取られます（/etc/cron.d、/etc/modprobe.dなど）。これらのプログラムには、RCSファイル（cronなど）を無視できるほど賢いものもあれば、そうでないものもあります（modprobeなど）。 .svnディレクトリについても同様です。ここでもgitの大きなプラスです（トップレベルの.gitディレクトリを1つだけ作成します）。
私はgitで非公式にそれをしましたが、より完全で詳細な実装である etckeeper プロジェクトもあります。
私は etckeeper を実験していますが、これはかなりうまくいくようです。集中サーバーは必要ありません。状況によっては重要になる場合があります。いくつかの異なるDVCSバックエンドを使用できるため、最も使い慣れたものを選択できます。それは私には非常にうまく機能しているようですが、私はそれを使い始めるために私が働いている他の技術をまだ取得しようとしていません。
最近シェフを調べています。 templatable （.erb）構成をバージョン管理に保持するだけでなく、アクションを実行できます（構成をノードにアップロードした後に サービスの再起動 など）。 Chefはパッケージ管理を支援するため、インターフェイスとなるノードで 依存関係を検証 できます（つまり、Sudoパッケージをインストールする必要があります）。 ChefはRubyで簡単に拡張できるようです。そのため、カスタムプロセスがある場合は、提供されているフレームワーク内でスクリプトを作成できます。
しかし、まだ試していないので、適切なgemを使用してクライアントとサーバーにRuby）をインストールする必要があります（これはそれほど難しくありません）。一度。
私はインフラストラクチャ全体にPuppetを実装する過程にあり、データをバージョン管理することは非常に助かります。
Mercurialは、いくつかのメタデータが隠しディレクトリに保存されているファイルのコレクションです（管理しやすく、理解しやすく、使いやすい）ので、Mercurialを好みます。
私のPuppetファイルは/ usr/local/etc/puppet /（FreeBSD 7.1）にあります。 Mercurialを追加するために必要なすべてのこと：
> cd /usr/local/etc/puppet
> hg init
すべての変更は、単純な「hg commit」でコミットされます。変更によって問題が発生した場合は、1つのコマンドですべてのサーバーを特定のバージョンのファイル（sudoersなど）にロールバックできます。
管理しているサーバーでSubversionを使用しています。正常に動作します。 Trac インスタンスも設定したので、タイムラインビュー、チケットシステム、ブラウジングなどがあります。
シンボリックリンク、cron、Subversionを使用して、Subversionリポジトリに基づく自動構成配布もセットアップしました。すべてのLinuxサーバーは、スクリプト（ファイアウォールスクリプトなど）でsvn updateを使用してリポジトリを更新します。
これが実際の使用例です。Subversionを使用して、4つの異なるサーバー上の構成ファイルを管理しました。コードで使用するのと同じ理由で、構成ファイルのバージョン管理を使用することをお勧めします。これは、バックアップと元に戻すボタンがすべて1つになっているためです。私がはるかに多くのサーバーを管理していて、それらが構成の点ではるかに近い場合、berberichの回答で詳述されているように、Puppetのようなものを使用します。
アイデアは、サーバー上の特定のフォルダー（例：/ var/named /）をチェックアウトできるリポジトリを1つ持つことができるため、両方に履歴と構成ファイルのバックアップがあります（ミスを犯した場合のバックアップはおまけです）手で編集した追加内容を消去するGUI構成アプリケーションの使用例cough Mac OS X Serverのサーバー管理cough）。その後、テストサーバーでテストしてから、手動でファイルをコピーしなくても機能するファイルで運用サーバーを更新するのは簡単です。
これを正確に行うために、数年前にプロジェクトを作成しました： Savon
Subversionを使用してファイルを保存し、所有権、権限、SELinuxコンテキストの追跡などの追加機能を備えています。また、ファイルシステムの変更をレイヤーで論理的に分割できるため、たとえば、すべてのWebサーバーに個別に送信する必要がある変更を追跡できます。
私たちの変更のほとんどは、日常のメンテナンスタイプのものであっても、ヘルプデスクシステムで管理されます。ドキュメントをゆっくりとwikiに移動して、自分で使用したり、エンドユーザーに公開したりしています。構成の変更を投稿し、その背後にあるディスカッションをイントラネットで公開できてうれしいです。
長年、変更を始めたファイルにrcsを使用していましたが、数年前に/ etc全体をgit制御下に置き始めました。ファイルを細かくまとめてチェックインするにはいくつかの作業が必要です（場合によっては、巨大な「さまざまな更新」チェックインに頼ります）。これを支援するスクリプトをいくつか作成しましたが、etckeeperは非常に興味深いようで、すぐに試してみます。