In part II of my walk through on configuration management, I’m going to work on setting up Subversion (SVN). SVN is a version control system and, just like any version control system, is used to keep track of changes. The most common use is in a development environment with teams of developers so that everybody can work on the code, without having to worry about other people’s work. It’s obviously not limited there, it can be used as a form of backup, keeping a track of what you’ve changed, and when. This is how we’ll be using it for our configuration management.
Installing SVN
I’m going to make the assumption you know how to install Linux. If not, there are plenty of guides on doing so around the internet, and most come with a pretty easy to use installer. With that said, I am starting this off with a completely blank slate. I installed Debian 5.0.4 inside a VirtualBox instance. I’ll be installing SVN on the same server for now, but it could be installed anywhere that supports it.
apt-get install subversion
The above command needs to be run as root. You can do the same as a normal user as long as you prefix the command with sudo.
Creating the repository
Next step is to create the repository we’ll be working with for the configurations.
mkdir /srv/svn
svnadmin create --fs-type fsfs /srv/svn/thebe_config
You can name the repository whatever you want, I used thebe_config, Thebe is the name of the server, and the second part is obvious. Next we’ll create a group for those that will be working on the SVN project, and add the users. As it’s only me, that’s easy…
groupadd subversion
addgroup jonathan subversion
That’s the basic setup done… Now onto more fun stuff.
Using the repository
Generally speaking, SVN requires you to import a project, and checkout in another location. For example, a basic initial import, and check out would look something like this:
mkdir my_test
echo "First import test" > my_test/test_file.txt
svn import -m "This is the initial setup" my_test/ file:///srv/svn/thebe_config/trunk
svn checkout file:///srv/svn/thebe_config/trunk newproject
If you tried to checkout the project on-top of the existing code you already put up, you’d get an error like this:
svn checkout file:///srv/svn/thebe_config/trunk my_test
snv: Failed to add file 'my_test/test_file.txt': an unversioned file of the same name already exists
This isn’t so good for us, because we can hardly delete /etc. That being said, SVN has it covered, with what they document as an “in-place ‘import’”. The really cool thing about this, they document exactly what we’re trying to do, version-control the /etc structure. So instead of importing /etc, we fake it.
svn mkdir --parents file:///srv/svn/thebe_config/trunk/etc
cd /etc
svn checkout file:///srv/svn/thebe_config/trunk/etc .
svn add *
svn commit -m "Initial check-in of /etc"
Whilst it’s not documented in the FAQ there, the –parents option is similar to that of the normal mkdir, it recursively creates the directory structure down to the child we’re making. In this case, trunk/etc. After the last 2 commands, you should see a stream of data zip by you. In the above example, I added the entire content of /etc, you can restrict it to certain directories if you want, say apache2, or samba, or you can go the whole way, and do the above.
Now it’s all checked in, lets see what it looks like:
svnlook tree /srv/svn/thebe_config | more
After that, you should see a nice structured view of your checked in directory structure.
A gotcha with SVN
Before we go messing with these files, and testing everything is working well, we need to note something about SVN, that is important to the /etc directory structure. File permissions. SVN does not record file permissions. This is an issue for some parts of the /etc directory, such as the shadow file, or the group file, or that htpasswd file you created to restrict users access.
SVN allows you to store properties information along side each file, this file can contain all kinds of information, such as copyright data, license information, and all that fun stuff1. A crafty contributor too advantage of that, and created a script called asvn. This script is a wrapper around the usual svn command, and executes some work either before a commit, or after a checkout. So we need to grab a copy of this script:
wget http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/asvn -O /usr/bin/asvn
chmod a+rx /usr/bin/asvn
cd /etc
asvn commit
After the last command, you’ll see a bunch of stuff zoom past, and you will be prompted for a commit message, I did “permissions fixup”, and hit CTRL X and yes. More stuff zooms by, and you should see a message appear that tells you the revision number has incremented. Now to see if it worked…
svn proplist --verbose group
Properties on 'group':
file:permissions : mode=644 user=root(0) group=root(0)
Excellent, now the last test, see what the checkout looks like, and see if it matches…
mkdir /tmp/thebe_config
cd /tmp
asvn checkout file:///srv/svn/thebe_config/trunk /tmp/thebe_config
More scrolling of lots of boring text, but you should notice stuff like “checking {somefile} for symlinks”. This is the asvn script doing it’s work, and rebuilding permissions and symlinks. In my example, I’d checked in everything, which includes the precious “shadow” file (I’d not recommend adding that one, add it to the svn:ignore list). I did so to provide a sample file with differing permissions. The original file is locked down to specific user and group:
$ ls -l /etc/shadow
-rw-r----- 1 root shadow 738 2010-06-27 19:42 /etc/shadow
$ svn proplist --verbose /etc/shadow
Properties on '/etc/shadow':
file:permissions : mode=640 user=root(0) group=shadow(42)
Lines starting with the $ are the commands I executed. The rest is the response from the server. As you can see, the permissions match2. Now the results in our test checkout…
$ cd /tmp/thebe_config/etc/
$ ls -l shadow
-rw-r----- 1 root shadow 738 2010-06-27 20:06 shadow
Permissions match, size matches, so it looks like SVN now has a good copy of the file properties, and the version I have checked in is the same as the one I have in /etc. As a side note, it should be worth remembering that some of the permissions cannot be set by anybody but root, so a lot of this work will probably require root, or sudo access. That being said, you’re editing /etc, so you should already be doing that.
Wrap-up
So far, we’ve covered why we want to use a version control repository for our configurations. We’ve also setup SVN, and got the basics going, including extended SVN to include extra data to handle file properties. Next up is the basics of using SVN, and how it’ll be helping us out here in /etc and configuration land.
If you see any errors, or have any suggestions, feel free to leave them in the comments. Want me to write about something else? Drop me an idea, and I’ll see what I can do.
-
Not sure how the -rw-r—– matches 640? I highly recommend checking out the excellent StandAlone SysAdmin’s great post on numeric unix permissions ↩