Tracking configuration changes with rcs

After installing linux, I usually make a few configuration changes to adapt the system to the way that I wish to use it.  Those changes are often to configuration files in “/etc” or in a subdirectory of  “/etc”.  I have previously mentioned that I use “rcs” to keep track of those changes.  Now that I have discussed how to use “rcs” it is time to give more detail.

Recall that “rcs” is a system for keeping track of changes to a file, and that is what makes it well suited to tracking configuration changes.  It us usually best to have a directory named “RCS”, where the change record is kept.  Due to the wonders of symbolic links, it is possible for that “RCS” directory to be on a different file system, such as “/home”.

I have a directory “/home/RCS.etc” on my home partition.  It is owned by the root user, and writable only by root.  I put it on my home partition, because I usually preserve that when installing a newer version of opensuse.  In order to make that appear to be the directory “/etc/RCS”, I do:

cd /etc
ln -s ../home/RCS.etc RCS

I use a relative path in that symbolic link, to make it easier to access if I am mounting the system from a repair boot.  In practice, though, a repair CD probably won’t have the “rcs” software installed, so using a relative path is not essential there.

I’ll add a quick note here.  For a while, I was running fedora on my test machine.  For that, I created a directory “/home/RCS.fedora” and I symlinked that to “/etc”.  This allowed me to keep my record of configuration changes for fedora separate from the record I have been keeping for opensuse.

Tracking changes

Now “/etc/RCS” acts as if a directory, and I can use it for tracking changes to files in “/etc”.  One of the files that I change is “/etc/hosts.allow”.  I’ll use that to illustrate how I do things.

The first time that I ever do this, I would check in the “hosts.allow” file.  I would normally use:

cd /etc
cp hosts.allow RCS/.  ## copy to the RCS directory
pushd RCS             ## change to the RCS directory
ci hosts.allow        ## check in the file
popd                  ## get back to /etc

I could have checked in with “ci -l hosts.allow”.  That would check it in, then check it out again.  For various reasons, I have come to prefer the method that I have detailed above.

I now go ahead and make a few changes that I want to the file.  I can use “rcsdiff” to check what changes I have made.  When I am satisfied, I will check in the modified version of the file:

cp hosts.allow RCS/.
pushd RCS
ci -r1.1.0 hosts.allow
rcs -b1.1.0 hosts.allow
popd

I actually created a branch in the rcs archive for the file. The base version (the version that came with the system) is branch 1 (the main branch), with the actual distributed file as version 1.1 My changed file is branch 1.1.0, and checked in as version 1.1.0.1. The command “rcs -b1.1.0” makes branch 1.1.0 the default branch. If I make future changes, they will go to branch 1.1.0, perhaps as version 1.1.0.2. And if opensuse comes out with an update that modifies the file, then the new distributors version will be checked into the main branch, perhaps as version 1.2.

After an updated install

When I next update to a newer version of opensuse, I will recreate the symbolic link, so that again “/etc/RCS” contains the “rcs” history of file changes.  After creating the symbolic link, a quick look in “/etc/RCS” will remind me of which files I have changed.

I can use

rcsdiff hosts.allow   ## compare version previously used
rcsdiff -r1 hosts.all ## compare version previously installed

to compare the current version of the file with what I had previously used, and to merge in any needed changes.

If the distributed version is the same as for the previous opensuse release, as checked with the second of the above commands, then I can simple checkout my updated version to re-apply my changes.  If the distributed version has changed, then I may open another xterm session, and in that session, do:

cd /etc/RCS
rcsdiff -u -r1 -r1.1.0 hosts.allow

That allows me to see the changes that were made, and merge them into the current version.  I could try using “rcsmerge” for that, but I usually prefer to do it by hand.  Before merging in any changes, I will again copy the distributed new version of the file to “/etc/RCS”.  That way, after making my changes, I can check in the newly distributed version and the newly updated version.

Files in other directories

There are two methods that I use for configuration files not in “/etc”.  One method is to create a similar “RCS” directory for those files.  For example, I use:

cd /etc/RCS
mkdir RCS.ssh
cd /etc/ssh
ln -s ../RCS/RCS.ssh RCS

and this creates, in effect, an “RCS” subdirectory for “/etc/ssh” where I can track changes to configuration files there.

I use a different method most of the time.  For example, I modify the file “/etc/rsyslog.d/remote.conf” so as to accept logging from my router.  When I first want to check in the file, I use

cd /etc/rsyslog.d
cp remote.conf /etc/RCS/.
pushd /etc/RCS
ci remote.conf
popd

When prompted for a description of the file, I give the path where the file was found. I can later use

pushd /etc/RCS
rlog -t remote.conf
popd

to remind myself where that file came from.

At my next update, when I am wanting to compare versions, I can use:

pushd /etc/RCS
x=`pwd`   ## set $x to the "/etc/RCS" directory
popd      ## get back to the original directory
rcsdiff $x/remote.conf,v remote.conf
rcsdiff -r1 $x/remote.conf,v remote.conf

It is a nice feature of “rcs” that the commands allow you to give both the path of the archive file and the path of the current file.  This is very useful when they are not in the same directory. I typically will have selected the file name (“remote.conf” in this case) with my mouse, so a middle click on the mouse scroll wheel retrieves the file name, and reduces the risk of a typographical error.

Summary

I have found it very useful to track changes this way.  Looking in “/etc/RCS” reminds me of what I need to update, and then the “rcs” commands aid me in doing that updating.

If I installed using the DVD, then I make sure that I included “rcs” among the packages to install.  If I install with a live KDE disk, then “rcs” won’t be there.  So I will install that from the repos at the first opportunity.

Advertisements

Tags: ,

About Neil Rickert

Retired mathematician and computer scientist who dabbles in cognitive science.

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

%d bloggers like this: