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.
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 184.108.40.206. 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 220.127.116.11. 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.
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.