・・・というと、「それってetckeeperでできるよ」という返答が高確率で返ってくるのですが、etckeeperの場合は、/etc以下を直接、バージョン管理システムの管理対象にして、システム管理者が意識的にコミットする形になります。
そうではなくて、たとえば、標準構成のLinuxの環境を利用者に貸し出して、自由にカスタマイズして使ってもらうのだけど、何か問題がおきて問い合わせがあった時に、サポート担当者が過去の設定変更の履歴を追えると便利じゃない？ というような利用シーンを想定しています。なので、利用者には存在を意識させずに、裏でこっそり差分を記録してけるといいかな、という感じです。
というようなことを３分ぐらい考えて書いたのが下記のスクリプト。
etctrace.sh
#!/bin/sh TARGET=/etc REPODIR=/backup/etcrepo mkdir -p $REPODIR cd $REPODIR if [[ ! -d $REPODIR/.git ]]; then git init fi rsync -a --delete $TARGET $REPODIR/ git add -A git commit -a -m "Committed by etctrace."
事前に「yum install git」しておいて、あとは、このスクリプトを毎晩cronで実行します。
「/etc」を一旦「/backup/etcrepo」以下にrsyncしてから、「git commit」しているので、必要な際は、「/backup/etcrepo」で「git log」なり、「git show」なり、「git checkout」なりすると、設定変更の考古学調査が行えるという寸法です。
対象サーバーが多数ある際は、rsync先をネットワーク経由で専用の管理サーバーにしてもいいですね。これだと、問い合わせがあったサーバーにログインしなくても、管理サーバーの方で調査が実施できます。
3分で考えて30秒で書いたスクリプトなので、実際に使ってみるといろいろ想定外の事が起きるかも知れません。しばらく、自宅サーバーで運用してみます。
