Version-controlled /etc

In 2009 I migrated the School of Computer Science and Statistics mail server from Solaris to Debian Linux. I made a lot of changes and improvements during the migration; one of the simplest was to keep /etc under version control. I assume most people are familiar with version control from writing code - if you’re not, please spend a couple of hours reading and experimenting with any modern VCS, you’ll be thankful you did. I first set up a version controlled /etc almost 10 years ago when I was Netsoc’s sysadmin, but back then I was using CVS, and it was complicated by Solaris putting binaries and named pipes in /etc for backwards (and I really mean backwards) compatibility. This time I used etckeeper and git. One of the reasons for using git is that it’s distributed: if we added a second mail server, I wanted to make synchronising /etc as simple as possible. It has proven to be very useful:

  • Being able to see the changes I made in previous days, especially during the initial setup, when a lot of services needed a lot of configuration.

  • Finding out when files last changed, so we can assure ourselves and users that we haven’t changed anything that would cause the problems they’re having, or find out that someone else made a change unbeknownst to us that could be responsible.

  • Avoiding directory listings like this:


Setup is explained in /usr/share/doc/etckeeper/README.gz but I’ll summarise here:

cd /etc
etckeeper init
git status
# review the list of files to be added; files can be removed with
#   git rm --cached FILE
# files can be ignored by adding them to /etc/.gitignore
git commit -m "Initial import of /etc"

That’s it - you now have a version controlled /etc. Chances are that you’ll need to ignore some files because they’re generated from others or modified daemons, but that’s easy to do. If you intend cloning the repository, please read the security advice in /usr/share/doc/etckeeper/README.gz to avoid any nasty surprises.