using RCS to track system changes

[blu at vl.com (Tom Metro)]

Rich Braun, in last months thread on "Kernel version 2.6 -- RAID 
performance woes?," wrote:

> One of my beefs about yast2 is that you can modify settings and not
> remember (or be able to go back in and consult a log) what you
> changed or when.  Whenever I make a manual change to a file on my
> system, I make a personal habit of recording the change using RCS
> which creates a complete record.

I also use RCS to track configuration file changes, and I'm not sure why 
this isn't a widely recommended practice.

Last summer when I upgraded a Debian system from Woody to Sarge, it was 
fairly trivial to go through the collections of *-new config files 
created by the upgrade (when the installer spots local modifications, it 
saves the updated config file as whatever-new to avoid clobbering your 
version), and merge in the local changes using the RCS history.

A few exceptions were config files managed by web UIs, such as Webmin 
and SWAT. Same problem as yast2. At least one of those packages does 
actually log changes, but it's not nearly as convenient or easy to find 
as an RCS file sitting along side the config file.

I've also adopted the habit of creating a running log of changes made to 
a system. I create dated files in /etc/log/ that hold comments about 
what was done, as well as the output from rcsdiff if a config file was 
modified, or the output from apt-get/aptitude if packages were altered. 
The log has proven quite useful in determining months later why some 
change was made, or how to reproduce it on another system.

Another useful tool for tracking system changes is a file integrity 
checker. While intended to catch intrusions, I've configured the tool I 
use, integrit, to automatically regenerate the baseline after every run, 
so the reports it produces show only the changes since it was last run. 
As a result, if anything has changed on the system, I get a report that 
night showing the list of files. These dated emails are then easy to 
correlate with the manual change logs, and have provided a useful double 
check that installing a package didn't alter something unexpected.

I recently read about cfengine in "Automate System Configurations and 
Changes with cfengine" from the January Sys Admin 
(http://www.samag.com/current/), which has some overlap with this topic. 
But it seems to be about facilitating the job of propagating 
configuration changes to multiple machines, rather than managing the 
changes on one machine (or the source machine), so it doesn't really 
address the same problem that RCS solves.

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/