[OT] - Best Practices(TM) for Configuration File Changes

Giorgos Keramidas keramida at ceid.upatras.gr
Sun Mar 29 05:11:59 PDT 2009

On Sun, 29 Mar 2009 07:37:27 -0400, Glen Barber <glen.j.barber at gmail.com> wrote:
> Hello, list.
> Before I pose my question, I am not intending to start a flame-war of
> any sort -- I'm just searching for "different" ways of doing things.
> With so many different version control systems available (aside from
> the traditional "keep current backups" solution), I am curious:
> Q: What is *your* favorite/suggestion solution to keep (working)
> versions of configuration files, in case something goes awry?
> I am specifically targeting configuration files because they are what
> I change the most, in avoidance of "It worked 10 minutes ago..."
> situations.

The base system of FreeBSD includes RCS[1].  I regularly use it to
track changes to individual files.  The advantage of RCS is that it is
easy to use from a system that is barely `up', i.e. a system that has
just been brought up to single user mode.  No special daemons or other
sort of service is required, no ports to be installed, and so on.  I
can usually just run something like:

[1] http://www.gnu.org/software/rcs/

    # cd /boot
    # rlog loader.conf

    RCS file: RCS/loader.conf,v
    Working file: loader.conf
    head: 1.5
    locks: strict
    access list:
    symbolic names:
    keyword substitution: kv
    total revisions: 5;     selected revisions: 5
    revision 1.5
    date: 2009/03/27 17:58:59;  author: root;  state: Exp;  lines: +2 -1
    Autoload acpi_ibm.ko for the extra Thinkpad X61s tunables.
    [more output snipped]

Whenever I want to look at a change, I can use `rcsdiff':

    # cd /boot
    # rcsdiff -u -r1.4 loader.conf
    RCS file: RCS/loader.conf,v
    retrieving revision 1.4
    diff -u -r1.4 -r1.5
    --- loader.conf 2009/02/17 20:26:14     1.4
    +++ loader.conf 2009/03/27 17:58:59     1.5
    @@ -9,6 +9,7 @@

     # Autoloaded modules.

The co(1) and ci(1) utilities are relatively easy to learn.  Whenever
a permanent change has to be made, I can use:

    # cd /path/to/file
    # rcsdiff -u filename

If this shows changes they are probably uncommitted changes I have
made without recording when or why.  This is usually an indication of
some sort of 'temporary hack'.  I review the diff, and either commit
it or throw it away.  Then I check out a clean copy of the file, make
the new permanent changes, review the changes one last time with the
`rcsdiff' command, and commit them again.

    # co -l filename
    # vi filename
    # rcsdiff -u filename
    # ci -l filename

As an extra bonus, when a system is fully up and running, there is
very good integration of RCS with GNU Emacs, so I can edit the files
directly from my Emacs session, view diffs with older revisions, roll
a bunch of files back or forward through history, and do whatever else
is supported by the VC mode[2] of Emacs:

[2] http://www.emacswiki.org/cgi-bin/wiki/VersionControl

RCS is not really 'modern', i.e. it does not support changesets with
multiple files (each file has its own separate, per-file history), and
it does not support elaborate file merging techniques (like some of
the modern distributed VC systems).  But it is always there, it does
the Right Thing with file permissions and file ownership, and is well
integrated with my favorite editor.  That's more than enough for now :)

More information about the freebsd-questions mailing list