To what extent can Version Control help in system administration?

Question

I'm currently tinkering at an OpenBSD system with a view to building myself a firewall and some other bits and bobs.

As this is fairly experimental (I'm an OpenBSD n00b, and I've already trashed my system 3 or 4 times), I wonder what experience others have of making part or all of the file system (I'm thinking in particular of /etc) a working copy of some VCS or other.

• Is this a good idea?

• I'm particularly interested in which VCS people have used for this. I'm considering subversion, bazaar, and git; this won't be a shared repository, so I'm perhaps more interested in the basic vcs functionality than the distributed-or-not argument.

• I'd also like to hear about imagined or actual pitfalls people have found. I can imagine the preservation of file ownership and permissions needs careful thought!

• And, of course, any alternative approaches not involving VCS

Answer 1

I have read something on that in "Gnu/Linux Magazine France". The guy uses rsync from /etc to root/ then stores it via subversion, without creating a working copy.

I'm gonna quote a little the magazine.

Ok so, in the example, the server runs freeBSD and is "sparky", whereas the machine to be saved is under debian and is "replica". Create an user "replica".

in /usr/local/etc/ssh/sshd_config add:

Match User replica
X11Forwarding no
AllowTcpForwarding no
ForceCommand /usr/local/bin/svnserv -t -r /home/replica/svnrepo -tunnel-user=replica

Createing the repository

sparky # svnadmin create /home/replica/svnrepo

Fix rights:

sparky # chown -R replica:nogroup /home/replica sparky # chown -R o-rwx /home/replica sparky # chown -R g-rwx /home/replica

Now client side:

install subversion

replica # mkdir -p /root/scripts/svnrepo
replica # rsync -av /etc /root/scripts/svnrepo

export SVN_SSH ="ssh -i /root/.ssh/id_rsa"
svn import -m "replica config files" /root/scripts/svnrepos svn+ssh://replica@sparky/home/replica/svnrepo

Now, our folder is not yet a working copy, so we have to make it be. Can you create a .svn file ? He can't :)

cd /root/scripts
mv svnrepo svnrepo.old
svn checkout svn+ssh://replica@sparky/home/replica/svnrepo

Now try to modify a file into etc, like hosts for instance.

rsync again. You should only get the modified file, wich is /etc/hosts copied.

now you can commit :

svn commit -m "backup 1" /root/scripts/svnrepo

There is one last thing. If you want a file to be taken by subversion, it must be added. So for instance, if you create a new file into /etc, it won't be saved by default.

What's to be done?

svn status /root/scripts/svnrepo | grep -e '^!' | awk '{ print $2 }' | xargs -r svn delete 
svn status /root/scripts/svnrepo | grep -e '^?' | awk '{ print $2 }' | xargs -r svn add

Then, you have to make your own script.

Hope this helps.

(gtg, I'll edit later to set titles and so one if nobody does)

Answer 2

Here you have a detailed revision about putting /etc/ under revision control using git.

Another step by step method.

Answer 3

For what you're doing I'd suggest rather than starting from OpenBSD you begin from a distribution where much of the work has already been done like pfsense.

As for the VCS itself you might want to consider mercurial that is being used successfully by these projects

Answer 4

Feedback: What I ended up doing

(@Aif, Thanks for the gentle reminder that my good manners were a bit missing)

I went with /etc as a git repository, but as I'm still a little uneasy with this (me, not git), I'm doing the gitwork manually.

As a side effect, I've started myself on a small project to evaluate, side by side, subversion, git, bazaar, mercurial, monotone, darcs, and fossil, though in a more general version management context (merges and such).

---

My reactions to your answers

Thank you all for your help. I had some difficulty in choosing which answer to accept, so if it wasn't yours, please believe me, I appreciated yours, too.

@Luis Melgratti

Luis, thanks for a couple of excellent references. I have accepted your answer as the most useful.

---

@Conrad

Conrad, I appreciate both your suggestions.

I shall certainly investigate pfsense, though one of my objectives in this is to get my hands really dirty, as well as building a firewall, so "make rather than acquire" is important.

As to Mercurial, I didn't include it in my list because I have tried it (previously), and I felt that I "liked" bazaar better, while git seems at first sight to have a great deal of power (which admittedly I may not need). My "main" VCS at present is Subversion, though I'm not sure it's a good answer for this case. Hence the list of three.

(I've now taken a look at pfsense and fired it up on my network. Very good, but I'm not at all sure I'll get my hands even slightly soiled...)

---

@Aif

Thanks, Aif. I'm definitely going to give that a try, though I suspect I'll end up with git.

---

@tinkertim

Thank you for your thoughts on Mercurial, which I now plan to revisit, though I'm well pleased with Bazaar.

---

@Per Wiklander

Thank you for a very interesting suggestion! I'm definitely going to take a look at etckeeper, when I can get out from under the current workpile.

Answer 5

Everything in /etc on every server that I manage (300 + and counting) is under Mercurial. Why?

• Its easy to use for anyone who has ever used SVN or CVS (if you have not, you have no business doing business in /etc on my production machines)
• It makes it easy to pull changes from one server's config to many others
• I can roll back when other admins have a brain fart, quickly

Git was just too much power for too little of a problem in this instance. As HG is a DVCS, commits and roll backs are clean and easy. I also use HG to manage most of my web sites.

Its not just for source code :) Another more basic option would be to use some kind of versioning file system that takes snapshots on writes (CoW), a DVCS is much easier.

Answer 6

More than just having configuration files in a revision control system, I suggest using a configuration management system such as Chef or Puppet to manage the contents, permissions and other details of the configuration files, such as restarting applications when a config file changes, and manage those files in git/subversion/yourfavoriteVCS.

Answer 7

I don't think anyone mentioned etckeeper yet.

It stores /etc in a repos (git (default), mercurial or bzr). It solves problems with preservation of file ownership, permissions and empty directories. It can integrate with package managemnet (at least with apt) to automatically commit changes to /etc that happens during the install of a new package. Very good if an install borks your own changes, just roll back.

I've been successfully using it in Ubuntu for a while.