Modifying configuration files is a normal part of system administration and in this document I describe using version control software for managing configuration file revisions. I consider this to be a best practice in system administration.
You’re going to need to modify various configuration files to do something, either to install some new software, or modify some default system behavior. Rather than make manual backup copies of the “original” configuration files, and having lots of copies such as “vfstab-orig”, “vfstab-“, “vfstab–“, “vfstab-old”, “vfstab-Jul17”, etc, you should use some version control software to manage the multiple revisions of such files. This provides a clean system, you’ll only have *one* “vfstab” and with the revision control in place, you can retrieve any previous version. When used properly, you can document each change you make so next week or next year you’ll know why you added/deleted/modified some lines in the configuration file.
I pretty much do this for all files I need to edit, including hosts, inetd.conf, /kernel/drv/sgen.conf, vfstab, dfstab, nsswitch.conf, services, sshd_config, httpd.conf etc. I use RCS and coupled with emacs it’s easy to update files as emacs has built in commands to perform the version control “check in” and “check out”. Emacs will also prompt you for the change comments which will be checked into the system along with your changes. You’ll always have the latest version, and the files are made “read only” (so you should know that you shouldn’t just up and edit the file without first properly checking it out). And if some changes you made don’t work, you can easily retrieve the last (hopefully working) revision and recover your previous configuration.
Some files aren’t edited often, so it’s important to enter the change comments to document what changes were made because it could be weeks, months or years before you need to look at the file again and then you’ll easily know what was done when. If you have multiple people that have system administrator responsibilities, it can be very helpful for the next administrator to track down changes made to a system. But it’s important that everyone with such responsibilities are aware that version control is in place. I’ve come across some administrators that just chmod the file and edit away (the version control software always places read-only copies of the current version on the system), not realizing that they’re not properly editing the file. Coming across a file which is read-only should be a clue that maybe version control might be in place for that particular file.
In RCS, I always add two keywords in the file (in RCS these are known as keyword substitutions): the $Id$ and $Log$ keywords. The $Id$ keyword expands a one line summary of the file name, latest version and date, and the last person modifying the file. The $Log$ keyword inserts the revision history (which includes the change comments) of the file being edited. RCS will automatically expand the log lines with the prefix string used in the $Log$ keyword (such as comments that begin with #, etc). SCCS has similar ID keywords.
Here’s a sample of a vfstab that has these tags.
# $Id: vfstab,v 1.19 2006/12/10 19:02:23 root Exp $
# $Log: vfstab,v $
# Revision 1.19 2006/12/10 19:02:23 root
# moved vpm/domains from c1t14d0s6 to c1t14d1s0 (about twice as large)
# Revision 1.18 2006/07/20 15:41:51 jkwan
# added old system disk
# Revision 1.17 2006/07/19 22:00:15 jkwan
# updated for c0t0 new system disk, updated Solaris 8
# Revision 1.16 2005/10/27 14:46:30 jkwan
# replaced c0t0 disk - was IBM 18g; now Seagate 36g;
# trimmed comments from 1.1;
# removed c0t0 fs from new disk;
# added swap back on on c0t0d0s1
For an initial version control file check in, I use something like:
# comment about this file
Basic RCS commands
Here’s some basic RCS commands you can used. You can use other version control software such as SCCS (I’ve used that myself in the past) but check the appropriate man pages for command syntax.
- co -l file — checks out file for editing (lock)
- ci file — check in file. This is also used to check in the initial file. You’ll be prompted to enter change comments. Important After you’re done you’ll need to do a “co file” to check out the latest version. Be sure to do this otherwise you won’t have the configuration file in place which could cause problems.
Using with emacs
- ^Xvi — checks in the file you’re editing as a new file (initial file)
- ^X^Q — to check in/check out the file you’re editing (toggles)
Sometimes when you’re installing some third party software, during the installation process the installation scripts will make backup copies of files it edits. You should review the standard directories (/etc, /kernel etc) for any files which might have been modified and manually integrate the changes into the version controlled files.
For example, after a Veritas Netbackup software installation, these files were found in /etc:
These are copies of the original versions of these files prior to the software installation (which should be the latest version checked in under the version control system). Do a diff and incorporate the changes into the version controlled configuration files.
bash-3.00$ diff -c inetd.conf.NBU_060107.11\:05\:31 inetd.conf
*** inetd.conf.NBU_060107.11:05:31 Fri Jun 1 13:16:02 2007
--- inetd.conf Wed Jul 18 22:26:27 2007
*** 24,26 ****
--- 24,30 ----
100235/1 tli rpc/ticotsord wait root /usr/lib/fs/cachefs/cachefsd cachefsd"
# TFTPD - tftp server (primarily used for booting)
#tftp dgram udp6 wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot
+ bpcd stream tcp nowait root /usr/openv/netbackup/bin/bpcd bpcd
+ vnetd stream tcp nowait root /usr/openv/bin/vnetd vnetd
+ vopied stream tcp nowait root /usr/openv/bin/vopied vopied
+ bpjava-msvc stream tcp nowait root /usr/openv/netbackup/bin/bpjava-msvc bpjava-msvc -transient
rm inetd.conf.NBU_060107.11:05:31 — configuration prior to software installation
- the file should be the same as the last checked in verion
mv inetd.conf inetd.conf-netbackup — configuration file after software installation
co -l inetd.conf
edit file incorporating changes
rm inetd.conf-netbackup — clean up
Using version control software on configuration files is an excellent way to manage systems. It keeps the system tidy, properly documents changes over time of configuration files, and makes it easier to keep track of changes. It also provides a means to roll back a configuration file to a previous state. Additionally, when doing a system upgrade or installation, you can review the configuration files that were previously configured by looking at the RCS directories or looking for the “,v” files that RCS uses (this is for RCS). It’s important that responsible individuals are aware of version control configuration usage and how to use it. Using version control software only requires a few basic commands and only requires an additional step or two in editing a configuration file.