Cosine Jeremiah and his Musings

Ever make a change on that Unix host you manage and need to undo it? Good thing you made a backup, right? You even gave it an extra extension, .bak, so that you would know it was the backup. But wait a minute, this file also has copies with extensions .backup, .20070813, .20051221, and .john. Do we need all these? Looking through them, they seem like copies we can do without, but even so they still contain some interesting historical data. And I really would feel funny about deleting the .john copy without asking John about it. What to do?! Simple, it is RCS to the rescue.

You can use RCS to version control your files. RCS is able to keep a history of previous revisions, and it provides a log for people to note why they made their change. Let us work through an example! A common administrative file that can benefit from RCS is /etc/sudoers. This file is not changed automatically and should only be altered by the Unix administrators. Let us start with a basic sudoers file:

%unixadmins     ALL = (ALL) ALL

We want to add another line for our Oracle administrators, but we want to save the original copy of this file. We first use RCS’s ci (check in) program to create the initial revision of the file:

i_am_root# cd /etc
i_am_root# ci -l sudoers
sudoers,v  <--  sudoers
enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!
>> sudo uses this file to determine permissions
>> .
initial revision: 1.1
done

This creates the revision history file, sudoers,v, in the /etc directory right with the sudoers file. If a directory named RCS exists, then the revision history file will be located there. You can use a symbolic link named RCS to store your revision history files anywhere you want (I put all mine in a centralized location).

Creating your revision history file leaves the sudoers file in a “checked out” state. This is necessary because creating the revision history file without also checking out the file will cause the original file to be deleted (oops). Therefore, you may begin editing the file now, or you might want to just check it in so someone else can edit it, too. The command to check files in, ci, can be used with the -u flag instead of -l to unlock the file instead of locking it:

i_am_root# ci -u sudoers
sudoers,v  <--  sudoers
file is unchanged; reverting to previous revision 1.1
done

Let us check the file back out for editing now. We use RCS’s co (check out) command to perform the task, and co takes -l as an option when locking is requested:

i_am_root# co -l sudoers
sudoers,v  -->  sudoers
revision 1.1 (locked)
done

Now edit the file to add the permissions for the Oracle DBAs. I do not care what your editor religion is as long as it is vi or emacs. 😉

%unixadmins     ALL = (ALL) ALL
%oracledbas     ALL = (oracle) ALL

We can use RCS’s rcsdiff command to see what we have changed:

i_am_root# rcsdiff sudoers
===================================================================
RCS file: sudoers,v
retrieving revision 1.1
diff -r1.1 sudoers
1a2
> %oracledbas     ALL = (oracle) ALL

Beautiful! It does not seem so useful for so small a change, but if you are making a lot of changes to a file then it is more useful. You can also use rcsdiff to view differences between revisions, which is extremely useful if you are trying to figure out when a particular line in the file was introduced (e.g. rcsdiff -r1.1 -r1.3 sudoers). If the standard diff format output is undesired, then try -c or -u (the latter not available on all systems) to change up the output format. As with everything, read the man pages for more details. If your man pages are lacking, use the man pages at OpenBSD because they are the best (they describe OpenRCS, an RCS clone, whereas most systems will have the official RCS; but the basic usage is the same).

We are not quite done, but we are almost there. We have to check in our change.

i_am_root# ci -u sudoers
sudoers,v  <--  sudoers
new revision: 1.2; previous revision: 1.1
enter log message, terminated with single '.' or end of file:
>> added permissions for Oracle DBAs
>> .
done

There are other revision control programs out there, and some of them have their place, too, but RCS is still the best for individual system file revision control. Also be careful in how you use it with ever-changing system files, such as /etc/passwd and /etc/shadow. For files such as those a cron job taking a daily backup by using ci -l will suffice. So get rid of all those extra backup files! The only extra copy you ever need has a suffix of ,v.