If Unix-like systems were being designed today, they probably would have been planned with some sort of revision control for configuration files. But the system of keeping plain-text configuration files under /etc was designed in a simpler time. Times have changed, and we need a little assistance in keeping up. If you’re managing a set of Linux servers for a small business, a tool like etckeeper can help a great deal.
Etckeeper is a set of tools that lets you keep your /etc directory (and all the configuration files under it) in a revision control systems. You can use it with Git, Mercurial, Darcs or Bazaar. Note that you’ll need to know the basics of whatever system you choose to use because etckeeper doesn’t have special utilities for restoring older versions of files.
You could easily set up /etc with revision control without etckeeper. However, the advantage of etckeeper is that it’s designed specifically for tracking /etc, including the file permissions and metadata that the revision control systems do not track.
Etckeeper should be packaged for most major distributions, so all you need to do is download
apt-get install etckeeper or
yum install etckeeper. If you don’t have a revision control system installed, you’ll also need to grab Git, Bazaar, Mercurial or another package revision control package of choice. (I was actually surprised to see that the package for etckeeper doesn’t include one of these as a requirement.)
Setting Up etckeeper
Note, if you’ve installed etckeeper on Ubuntu (rather than Debian) it’s been configured to use Bazaar instead of Git. You can install Bazaar if you would like, but I already use Git with other projects, so I decided to stay with it for etckeeper as well.
To change this, head to the /etc/etckeeper/etckeeper.conf file and change VCS=”bzr” to VCS=”git”.
Be sure to look around and see if there are other options you want to change. You can add additional options to git (or whatever version control system you like), and change etckeeper’s behavior. For example, by default it will commit changes once a day automatically. If this is undesirable, you can add AVOID_DAILY_AUTOCOMMITS=1.
If you don’t want to automatically commit the files before running an installation, add AVOID_COMMIT_BEFORE_INSTALL=1. Otherwise, etckeeper works with the package manager to commit files prior to installation. Etckeeper also commits files immediately after install, so you’ll have all the new configuration files (if any) checked in as well.
Once etckeeper is installed, run
etckeeper init to start the repository.
Working With Etckeeper
Etckeeper is a really light utility for managing configuration files. I default to using Git because I don’t feel like learning the Bazaar commands necessary to manage my configuration files.
The etckeeper documentation recommends cloning a repository and working from the clone rather than working directly in /etc. You can also use this to back up your configuration to a new server or to set up a new server with a copy of your existing configuration.
Remember, Git doesn’t keep the file permissions. This is where etckeeper comes in very handy: It tracks the metadata and can “fix” the permissions when you run
etckeeper init again. This probably seems a bit counter-intuitive, since you might think of
init as something you’re going to use only when you start a repo — but you also use it when you’re going to be checking out files stored in Git (or whatever).
Hence, if you revert to an older version of a configuration file (for example) you must run
etckeeper init again.
If you make any manual changes to a configuration, you'll want to use git commit -m "comment" (where "comment" explains the changes) to add the change immediately.
I wouldn’t recommend etckeeper for large businesses. If you’re managing hundreds of servers, then you’re going to want something like Puppet or Chef. That gets a bit more complicated, but you also have the option of doing much more with Puppet (or any other IT automation tools) than you can do with Etckeeper.
In the next column, we’ll overview Puppet and look at using Puppet for some common administration tasks across multiple servers.
Joe ‘Zonker’ Brockmeier is a freelance writer and editor with more than 10 years covering IT. Formerly the openSUSE Community Manager for Novell, Brockmeier has written for Linux Magazine, Sys Admin, Linux Pro Magazine, IBM developerWorks, Linux.com, CIO.com, Linux Weekly News, ZDNet, and many other publications. You can reach Zonker at firstname.lastname@example.org and follow him on Twitter.