What turnkey solutions exist to put /etc under version control, under various unices? Turnkey doesn't necessarily mean part of the base install, but the following features would be nice:

  • hooks into VCS commands to manage metadata (ownership, permissions);
  • integration with the package manager (run automatically before and after installations, handle upgrades intelligently);
  • treat upstream file versions as a branch;
  • a pre-filled ignore list;
  • support for several underlying VCS (especially distributed ones).

I use etckeeper under Debian and derivatives. It has all the above features except that it doesn't keep track of upstream versions. I would like to learn about alternatives, particularly on *BSD.


Under Gentoo the tool to manage package-induced changes to /etc (called dispatch-conf) supports rcs to track changes but that isn't really powerful.

I tend to version my /etc via git, especially since by using different branches I can keep my /etc as similar as possible over different distributions as possible while keeping as much stuff in one place as possible (for some areas that obviously fails, apache configuration for example is really different across different distributions). It works like this:

I have my master repo with my default configuration files. Now I come in touch with a new distro so I create a new branch based on my master branch based on the distribution's name (in this example debian). Debian keeps some config file in a location different from my master so I do a git mv file new_loc. And everything is fine. I switch back to master and change that file because I added some specific config directive, when I merge master into my debian branch the moved file is changed, so I can basically just change most things within my master branch and just have to merge changes in my "distribution" branches (usually they tend to be more of a mix of distribution and purpose branches, a debian server has some differences to a debian workstation obviously but the features still work).

So basically I have a "generic configuration" in master and (to say it in object-oriented programming terms) inherit those into my branches (who also can inherit from each other).

Apart from that, git's mechanisms to "cherry-pick" commits (in this case changes to /etc/) has been quite helpful to me at times where I only needed parts of a certain configuration.

Now to some of your ideas:

  • If I needed more package manager integration I would probably use wrapper scripts for this (at the moment I don't).
  • treating upstream versions as a branch would work fine with git, it's just another branch that you sometimes merge (partially) into master
  • The ignore list in git is the file .gitignore in your repo so that is covered.
  • I liked cfg-update on gentoo better than dispatch-conf, unfortunately the former is not maintained. Since about a year before I left, and it was a mess of spaghetti perl, imo. – xenoterracide Nov 4 '10 at 0:36

I have used fossil for this with some success. See my post about Fossil for more info. I've also used a tool called etcupdate which is more for moving between upgrades than tracking changes. I believe it was intended to be a companion tool for freebsd-update at one point. I'm not sure of its status currently but it works on my RELEASE-8.* systems.

http://lists.freebsd.org/pipermail/freebsd-current/2010-June/017927.html http://people.freebsd.org/~jhb/etcupdate/


There's a tool called etckeeper I've no idea how good it is.

etckeeper is a collection of tools to let /etc be stored in a git, mercurial, darcs, or bzr repository. It hooks into apt (and other package managers including yum and pacman-g2) to automatically commit changes made to /etc during package upgrades. It tracks file metadata that revison control systems do not normally support, but that is important for /etc, such as the permissions of /etc/shadow. It's quite modular and configurable, while also being simple to use if you understand the basics of working with revision control.

I also don't know if it can be made to work on *BSD I suspect it could, but that it won't be supported with ports out of the box.

  • 1
    Gilles already uses etckeeper. – tante Nov 4 '10 at 1:00
  • @tante oh I missed that – xenoterracide Nov 4 '10 at 9:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.