Linux configuration files are rather easy to mess up; especially when many system administrators might be working on the same box. A sensible administrator will save a backup copy of files before they are changed; a common technique is this:
cp httpd.conf httpd.conf.old.1
The trouble is, after many revisions to the file the administrator will have to decide between over-writing the backups or creating an increasingly messy collection of backup files to clutter the directories containing the configuration files. Clearly neither of these are desirable.
The LDP Linux System Administrators Guide recommends the use of RCS to manage the changes to configuration files. In a single stroke, RCS avoids this problem and gives the added advantage of being easily able to return the system to an earlier state. Advanced users of RCS can even create a version of the file without certain historical changes, or merge two divergent revisions of the file together.
Those techniques are beyond the scope of this article; all I am trying to persuade you to do is start using RCS for your day to day management - you will discover it's power in the fullness of time!
How to do it:
Any file that you wish to manage with RCS needs to be initialised. This sets a starting point for version 1.0 of the file, and records some basic information such as it's ownership, group attributes etc.
rcs -i filename
Before you edit the file for the first time, you need to check it into the system; that way you can recover if your edits cause the wrong effects:
ci -l filename
(The -l indicates that you wish to lock the file from other people's use - effectively granting yourself permission to change it. Ironically, if you lock a file you can edit it, and if you unlock a file you cannot!)
Once you have finished editing the file you need to check it back into RCS so that it can track the changes you have made:
ci -u filename
(If you omit -u the file will be deleted - the only remaining copy of the file will be within the RCS database. If you used -u , you will notice that the file has now become read-only. That is to signify that nobody has the right to alter until somebody decides to lock it for further change. Do not be a wise ass and attempt to overcome this with the chmod command, that defeats the whole point of using RCS!)
Later when you want to edit the file again you will need to check it out:
co -l filename
(Once again, the presence of -l allows you to edit the file that has been checked out. Don't forget to check the file back in as soon as your edits have been successful.)
When you have finished editing the file for a while, you need to check it in and unlock it again:
ci -u filename
Tip: Comment any change you make to the file - the comments should include what purpose the change was intended to achieve. Later if you have to review changes to your file it will be easier to understand the intent behind each change.
Tip: In any directory that you wish to use RCS, make a subdirectory called "RCS/" - the tool will automatically store it's version files in there, keeping your main folder free of clutter.
Tip: Whenever you initialise or check in a file, RCS will ask you for comments explaining why you changed the file. It's best to provide some descriptive information, that will support your comments - as tiny fragments of changed code can often prove confusing. You do not have to include your name in these RCS comments because (unless you are logged in as root) RCS will automatically keep track of the date and user who made the change.