What is the easiest VCS to use to track /etc with? What are the challenges in storing the etc directory in version control, best practices? Should I use a centralized or distributed VCS?
You could use etckeeper to handle it, which would let you use git, mercurial, darcs, or bzr for the repository.
Use etckeeper to do it for you. There's lot of reasons for this:
- You will forget to use VCS on occasion; etckeeper hooks into package managers, giving you a pre-inst and post-inst state to roll back to
- You will screw up file permissions
- You will screw up handling the shadow passwd file
I find git to be best at this job (although Mercurial would probably work just as well). A simple 'git init' in /etc, and you're on you're way. After that, just add the files you care about, and then any time they change, you can check it in. You can even set up cron to automatically do a checkin every time there is a change (although then you don't get log files). You can also push the repo around if you want to set a second machine that has all the same configs as the first, or just as a backup.
When I started sysadmining, rcs was the method of choice for /etc. Then came CVS, then SVN. I suspect when something new comes around, I'll switch to that. :) But with every new paradigm in VCS, my life has in fact gotten easier.
Without any religious intentions: I can highly recommend using a distributed VCS, preferably Bazaar. This is because:
- Bazaar is easy to install (on Ubuntu and Debian servers it's just a matter of
apt-get install bzr)
- It's easy to setup and get started:
cd /etc bzr init . bzr add . bzr commit . -m "Initial configuration"
- No server setup required. Bazaar can connect and push to a remote repository without any remote Bazaar server running. Will work great with any FTP server or WEBDAV, etc.
Git and Mercurial are the other two contestants (as been pointed out in other answers) but they lack the ability to push to a remote server without setup (at least yet).
I wouldn't manage all of /etc in a version control system. The reason is, most of the contents of /etc probably won't change much over time. Package management tools will manage a lot of files in /etc for you, and upgrading packages may cause interesting conflicts with a VCS.
Instead, I would use a configuration management system that manages various components and packages of my server(s), using templates and static files (where applicable) to configure the services and settings that store files in /etc (and elsewhere). I would store all that in a version control system, and I personally prefer Git, because as a system administrator, 'typical' Git workflows make more sense to me than Subversion (or CVS). Decentralization in Git makes it a huge win for system administration to me.
as an addition to all the advise here before (which all describe pretty much exactly what i do), i just discovered tig for myself. managing etc with git using cmdline was driving me crazy and changes were quickly piling up, without me showing any desire to take care of them. just randomly looking around for git GUIs i noticed there exists this ncurses-based one called tig.
now i'm actually looking forward to managing my /etc!