Revisioning /etc with Git

First and foremost I’m a coder, a coder who strongly believes in revision control. Second I am also a sysadmin; but only by accident. I have some servers and someone has to take care of them. I’m not a good sysadmin because I don’t have any interest on it so I learn as little as possible and also because I don’t want to be good at it and get stuck doing that all the time. What I love is to code.

I’m always scare of touching a file in /etc. What if I break something? I decided to treat /etc the same way I treat my software (where I am generally not afraid of touching anything). I decided to use revision control. So far I’ve never had to roll back a change in /etc, but it gives me a big peace of mind knowing that I can.

In the days of CVS and Subversion I thought about it, but I’ve never done it. It was just too cumbersome. But DVCS changed that, it made it trivial. That’s why I believe DVCS is a breakthru. Essentially what you need to revision-control your /etc with Git is to go to /etc and turn it into a repository:

cd /etc
git init

Done. It’s now a repo. Then, submit everything in there.

git add .
git commit -am "Initial commit. Before today it's prehistory, after today it's fun!"

From now on every time you modify a file you can do

git add <filename>
git commit -m "Description of the change to <filename>"

where <filename> is one or many files. Or if you are lazy you can also do:

git commit -am "Description to all the changes."

which will commit all pending changes. To see your pending changes do:

git status

and

git diff

When there are new files, you add them all with

git add .

and if some files were remove, you have to run

git add -u .

to be sure that they are remove in the repo as well (otherwise they’ll stay as pending changes forever).

That’s essentially all the commands I use when using git and doing sysadmin. If you ever have to do a rollback, merge, branch, etc, you’ll need to learn git for real.

One last thing. I often forget to commit my changes in /etc, so I created this script:

#!/usr/bin/env sh

cd /etc
git status | grep -v "On branch master" | grep -v "nothing to commit"
true # Don't return 1, which is what git status does when there's nothing to do.

on /etc/cron.daily/git-status which reminds me, daily, of my pending changes.

Hope it helps!

Advertisements

13 thoughts on “Revisioning /etc with Git

  1. Juanjo, no, each checkout is a repo in-place so you can just start versioning a directory in-place without ever touching anything outside that directory.

  2. I like your articles and subscribe to your blog via RSS, but the most recent set of RSS entries have a huge ‘share this item’ boilerplate at the end of every post, overshadowing the blog post itself. :-(

  3. Ah, you enabled the summary RSS. Yes, thanks!

    I like your article, btw. I’ve been doing the same, based on Subversion, for /etc and any other config files. I’m currently considering exporting my blog’s database dump into an SVN repository too. Just gotta implement it now. :-)

    • Using git for /etc is good, but I think spending the time to learn Puppet is worth it. I’m now using Puppet and never going back.

  4. How do you handle file ownership? E. g., /etc/shadow is owned by root:shadow, and some configurations are owned by a dedicated user (freeradius, icecast, www-data), but occasionally, changing their ownership makes sense.

    How can we track such changes?

  5. I am now off to see if I can mess with apt-get or dpkg-configure to do an automatic commit on hooks ran on auto updates that modify /etc files in ubuntu/debian.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s