Introducing YippieMove '09. Easy email transfers. Now open for all destinations.

How many times have you made a change to a server to only a couple of days or weeks later discover the change you did broke something? It happened to me a bunch of times. Sure, call me irresponsible, but sometimes I’m in a rush and don’t have time to document the change and write nice comments about it. I try to do so, but sometimes I forget.

For quite some time I’ve thought about a simple way to track the changes to my servers, but without coming up with any perfect solution. My ideas have included everything from wikis to blog-style logging to Tripwire. Sure, a change-blog would work, but it would take quite some extra time to write the entry.

One day when I was working with our development tracker a quite brilliant solution stroke me: why not use CVS/SVN on /etc? It sounds like overkill, but it would do the trick. By using this you would be able to:

* Display when the changes were made
* See what change was made
* Revert to a previous version

There are two different ways to go along using a repository for /etc. One way is to create a CVS/SVN tree on a different server and sync the entire /etc directory to that repository. The benefit with this is that you could have the repository on a different server and be to collect all your servers /etc on the same repository. By combining this with a web-interface, one would be able to easily compare and contrast the configurations of the different servers. Moreover, the change logs would be kept in the repository, and not on the individual servers, creating a cleaner file-structure. Another benefit would be that you could easily sync the /etc filesystem with your local workstation and modify/create your config-files there. The drawback with this solution is that you need to make your local changes first, and then upload the files to the repository. Once you’ve uploaded the files from your local workstation you can go ahead and sync the actual server with the repository to commit the changes.

Another solution would be to use a custom file-system. There are two different filesystem that supports version-tracking: CVSFS and Wayback. Between these two alternatives, Wayback appears to be the most developed alternative. Worth noting though is that both these alternatives only targets the Linux-platform.

The benefit for using such approach is that you don’t need to set up a separate repository to keep the files in, as well as that it enables you to make changes in a traditional way on the server. The drawback is that neither of these two filesystems are very well maintained. It appears that both these programs were last updated back in 2004, rendering them both quite obsolete. The question is if you really want to put the faith of your /etc-folder in a program that no one longer maintain.

Regardless of which one of these two alternatives you find most appealing, the concept is very interesting. I have still not tried to use this myself, but I would certainly argue that having a /etc-folder that allows you to keep track of changes is far superior to the traditional way of keeping /etc.

Edit 1: Since the article was published, I’ve found two more file-systems worth mentioning: CopyFS and ext3cow. Both these filesystems appears to be useful for /etc usage. Out of these two alternatives, ext3cow appears to be more sophisticated. However, CopyFS appears to be easier to set up.

Author: Tags: ,


  1. /etc deserves its own filesystem! | rakhesh, deblogged


  1. Little John says:

    Dude, did an apple drop into your head or were you in bath and suddenly yelled “Heureka!”

    Awesome idea anyway.

  2. Hady says:

    Or you could use some ZFS-like filesystem.

  3. Brian says:

    You might want to raise the bar on what you consider “brilliant”.

  4. Viktor Petersson says:

    Good point. I wasn’t aware of ext3cow when I wrote the article. I added a comment about that to the article.

    ZFS appears to be an interesting file-system. Correct me if I’m wrong, but isn’t it only for Solaris?

© 2006-2009 WireLoad, LLC.
Logo photo by William Picard. Theme based on BlueMod © 2005 - 2009, based on blueblog_DE by Oliver Wunder.