I would like to keep track of changes in /etc/
Basically I'd like to know if a file was changed, by yum update or by a user and roll it back if I don't like the chage.
I thought of using a VCS like git, LVM or btrfs snapshots or a backup program for this.
What would you recommend?
It sounds like you want etckeeper from Joey Hess of Debian, which manages files under /etc using version control. It supports git, mercurial, darcs and bazaar.
git is the VCS best supported by etckeeper and the VCS users are most likely to know. It's possible that your distribution has chosen to modify etckeeper so its default VCS is not git. You should only be using etckeeper with a VCS other than git if you're in love with the other VCS.
I can't give you a final recommendation, but I can share a few thoughts on the subject. Given that /etc is usually rather small, you might just go for a simple compressed tar-ball solution. If you hardly need to go through the history, it might be the easiest solution to set up.
For me it would be to tedious to manage logical volumes just to do keep track of /etc and especially as I don't think that LVM snapshots were designed to be created regularly as means for backup of a relatively small amount of data.
btrfs seems to me to be far better equip for this, but it is still not as stable as, for example, ext{2,3,4} and the fsck tool is also not done yet. But it continuously gets better.
Personally I actually use git to track /etc but you should keep in mind that git doesn't store file metainformation like ownership or permission! And also check that the .git directory has the right permission. There are a few tools that help with these problems though. You might want to take a look at etc-keeper, which was developed exactly for the keeping track of /etc or use at least use something like gitperms or metastore to track the metainformation.
To keep track of "unwanted" changes we use a HIDS - in our case samhain others are tripwire or aide. All these systems will warn you when something unwanted happened.
A yum update should not change anything without leaving a .rpmnew or .rpmold, if the config-file is flagged as such in the corresponding rpm.
Myselv I found it a good practice to make a security copy of the file I am going to modify with cp -p origfile origfileYYYY-MM-DD with the date of the day before.
If everything else fails - I call the backups guys and ask for a restore from the last known "good" backup.
I think you can make a snapshot of files/directories in /etc.
First make a list of files /etc/ directory:
# ls -lha /etc >> /snapshotofetc
And if you make a file in the /etc
# touch testfile
and if you retake a snapshot of /etc like what we ve done before
# ls -lhs /etc /lastsnapshotofetc
and then you can compare the differences between the 2 files like this:
# diff /snapshotofetc /lastsnapshotofetc
Are you looking for configuration management or tracking/monitoring the filesystem changes?
If it is earlier, I would look at puppet or chef. CFEngine exists for commercial purposes. puppet is a popular beast these days.
If it is the later one, its hard you to monitor the filesystem changes however there are instance of programs like inotify and filesystem auditing auditctl or SGI's fam but again, its a monitoring thing and can be expensive implementation (filesystem performance can get deterioriated).
You can check out rsnapshot which keeps hourly snapshots of whatever directories you want... you can set it up to do 24 hours, then X dailies, then X weeklies, etc. As much as you want for disk space. It's smart enough to hard link when files haven't changed (it uses rsync behind the scenes.
You might consider using git. You can It is efficient in tracking changes and very easy to use for something like this.
git status # Show changed files
git diff # Show file differences (paged automatically)
git commit -a # Commit all changes.
I believe the initial setup goes like this. I haven't done it for a while.
cd /etc
git init
git add *
git commit -a -m "Created repository"
This approach works best for a single server, but can be layered with other tools which change the repository. This can be useful on your canary site(s) to ensure the expected changes are occurring.
You may be able to use cloning to handle file common to multiple servers.
I have a script that runs everyday and backs up files that have changed since the previous backup:
#!bin/bash
ext=$(date +"%Y%m%d")_ChangeS
mkdir -p "$1/$ext" && \
ionice -c3 rsync -ah --numeric-ids --inplace --backup \
--backup-dir="$1/$ext" \
--include="/etc" / "$1" && \
rmdir --ignore-fail-on-non-empty "$1/$ext"
You pass in the path where backups would be created and that directory will have a listing similar to this (after a few runs):
20120106_ChangeS etc
$ls 20120106_ChangeS/etc/
cron.d
You could modify it a bit to record changes more often or use inotify to trigger a modified version of the script when changes occur on /etc.
