CIT 470 Advanced Network and System Administration: Lab #11: Version Control

Lab #11: Version Control
Date: March 24, 2008
Due Date: March 24, 2008

Experienced system administrators use version control software to manage their configuration files. By this part of the semester, you've made enough configuration file mistakes to realize that keeping a backup of a known good configuration file is a good idea. We've often done this with the cp command:

$ cp -p /etc/ldap.conf /etc/ldap.conf.bak

You could even automate this type of backup in your .bashrc file with a shell function.

save()   { for f in "$@"; do cp -a $f ${f}.bak; done; }

which would reduce the amount of typing you have to do, and avoid potential typos.

save /etc/ldap.conf

However, even the automated version of this solution has some problems. If you modify the file more than once, you have to create multiple backup files with different names. When you do find that something is broken, how do you know which backup file is the one to restore? Even if you made all the backups yourself, this becomes confusing after several revisions have occurred. If other system administrators make backups, then the problem is even more difficult.

Version control software offers a more powerful and consistent solution to this problem. We'll look at a simple, older version control system that's useful for small sites called the Revision Control System. If you're managing a large site, you'll need a more modern and powerful system, like Subversion. The O'Reilly book Version Control with Subversion is available online for free.

If you want to learn about other version control systems, there are several version control comparison guides available online.

RCS: Basic Operations

Be sure that you're logged in as student before beginning this lab.

Create an RCS subdirectory of /etc for RCS to use in managing our versions.
```
su
cd /etc
mkdir RCS
```
Put the hosts file under version control by checking it into RCS with the ci command. It will ask you for a short description of the file, which you can bring up later with other RCS commands.
```
ci hosts
```
View the revision log and description using the rlog command. Note that the first version of the file (the one that you created by checking in the file above) defaults to revision 1.1.
```
rlog hosts
```
Check out the file so that you can modify it. We'll use the -l flag to lock the file to ensure that no one can modify it while we're changing the file. This flag is particularly important in organizations with multiple system administrators, but it can also prevent you from causing problems for yourself.
```
co -l hosts
```
If the DNS servers are down, then your machine will be unable to download software updates. Lookup the IP address for mirrors.centos.org and add that name to IP address mapping to the hosts file so that you can manually download updates even when DNS isn't working.
```
nslookup mirrors.centos.org
vim hosts
```
Check in your change. RCS will ask you for a log message describing your change. While it's tempting to ignore this when you're in a hurry, this is a bad idea as documenting changes is essential to being able to fix problems when you (or another sysadmin) encounters problems as a result of a change. We'll use the -u flag to unlock the file, so others can modify it.
```
ci -u hosts
```
Check the log again to see your changes. Notice that the version number has been updated to 1.2 and your comment has been logged. Notice also that the change is attributed to student, not root, which is essential if more than one system administrator has the ability to modify configuration files.
```
rlog hosts
```

RCS: What if someone doesn't follow the rules?

Modify the file without using version control by adding a junk line to the bottom. Note that RCS has marked the file read-only. However, read-only permissions can't prevent root from writing to a file if the system administrator really wants to. You'll have to use the :w! command in vim to override the read-only permissions.
```
ls -l hosts
vim hosts
```
Verify that you can't check in a file that hasn't been checked out.
```
ci hosts
```
Use rcsdiff to identify changes between the current version of the file and the last checked in version. This should show you the junk line you added.
```
rcsdiff hosts
```
Fix the problem by checking out the last known good version of the file. It will ask you if you want to remove the current version of the file since it doesn't match the one you'll be checking out. In this case, we want to get replace the current version with the last known good version from our repository.
```
co hosts
```

RCS: The Repository

How does RCS store files? Will we run out of disk space if we have too many old versions in our repository? Let's look in the RCS subdirectory to find out how it works.

List the contents of the RCS subdirectory you created at the beginning of the lab. There should be a single file named hosts,v.
```
cd RCS
ls -l
```
Read the contents of hosts,v to see that it stores revisions as diffs, which contain just the differences between each version. Since only the differences are stored, a file with 100 revisions doesn't require 100 times the disk space of the original file.
```
less hosts,v
```
Check in the hosts.{allow,deny} access control files.
```
cd /etc
ci -u hosts.allow
ci -u hosts.deny
```
Check the contents of the RCS subdirectory again. Note that there are now three files. The separate storage make it easy to move a version controlled file from one machine to another. However, it has the disadvantage that if modifications to two files are part of a single change, there's no way to correlate the two files. For example, you may need to modify iptables and hosts.allow simultaneously to enable a new network server, but your change may occur in version 1.18 of one file and version 1.43 of the other. More advanced version control systems like Subversion allow such changes to be managed together.
```
ls -l RCS
```
Submit the hosts,v file for this lab assignment.