Once upon a time some crafty computer engineers put together an assortment of electronics to make a versatile gadget they called a computer. What was especially facinating about the computer was the number of different problems which the computer could be made to solve by giving it different sets of special instructions held in files. Over a period of time so many different sets of instructions were written that the art of installing, configuring, and removing the packages of instruction files became an art in its own right known as system administration. Advances in managing packages were formalized with the advent of SVR4 which included pkg tools for installing, identifying component files, verifing their integrity, and cleanly removing the packages. With ever growing complexity of software, the proper building, controlling, and removing of packages remains challenging. The RedHat Package Manager (rpm) represents the current state of the art in package management tools.
So what's the problem? Packages are written to run on many different hosts. The more the merrier as the cost per host goes down. To maximize the number of hosts that a package will run on and the different features it can provide the package builder includes configuration files. The system admin can alter these during installation to make the package fit a particular host's software and hardware environment. Rpm is a package level tool set which does not address management of these local changes to configuration files.
Cfm is the configuration file manager and monitoring utility. It provides capture, documentation, recovery, comparison and other manipulation capability for config files. It also provides audit capability for all rpm/cfm installed files. The result can be an efficient recoverable, and uniformly implemented system admin policy based on analysis of configuration rather than response to failure. On a complex network you can reduce the system admin workload by an order of magnitude. Some additional utilities useful for sysadmin are included.
The cfm database (cfmdb) holds a master copy of all versions of all config files used by the hosts that use the cfmdb. For each config file the cfmdb holds all current and previous version of the file used by any set of hosts. Each current version is tagged with the set name used by those hosts to id their version of the file. Config files may be grouped into two broad catagories and some special cases.
In the first catagory are config files for a package which a site either does not change, or for which the same changes are used by all hosts. These sets of config files are catagorized as default sets. The config files of each installed rpm form such a set named for the rpm. Additionally, a typical unix system contains a number of files which are dynamically created during OS installation, are common to all hosts on a LAN, and do not belong to any rpm, eg /etc/hosts. Cfm provides the default `all' set to support these files. The all set's configurable file list is CFMROOT/allfiles. The files of the all set are initialized when the cfmdb is created. The last default set is that of the user who is executing the cfm cmds. The set name is $LOGNAME. This supports use of cfm to store config files of individual users.
Config files which are modified to fit the needs of a subset of the hosts at a site are catagorized as preemptive sets. The sysadmin must provide a name for the premptive set when the modified files are captured in the cfm database. With exception of the special sets below the sysadmin must also specify that a host uses the preemptive set as part of that host's setup. For each tested file cfm will use the file version tagged with a host's first populated preemptive set name in the host's preemptive set name sequence. If none are populated it trys the default set names.
Cfm mandates use of three special sets.
All hosts have host specific config files. Examples are name and address files used to identify the host. Aside from being special because it is mandatory this is a normal preemptive set.
Most operating systems support some form of automated configuration (PNP in
windows terms). The OS probes the hardware and stores resulting info in a
config file. The sysadmin may capture these config files in the
$pnp
set for monitoring hardware changes/failures. Ordinarily
these files should never be downloaded. Accordingly the $pnp
set is excluded from the comparison sequence for cmds that allow
non-interactive download.
Cfm provides support for one special `ref' set which is NOT preemptive. It can be used to set aside a version of a file for reference. It is frequently used to store a copy of the distribution version of a config file for later reference. The ref set must be explicitly referenced by the sysadmin. It is never used by default.
NOTE: Explicitly naming and coding the ref set should be viewed as a convention. Nothing requires its use; nothing prevents setting up and using other sets for the same purpose. Future versions of cfm will probably drop explicit use of the ref set.
The cfmdb cmd tends to be database-centric. It is used to initialize a new database, make configuration changes, and to manage things that apply to the cfmdb as a whole or to sets of files as opposed to individual files. You use it to initialize sets and to erase sets.
The cfm cmd tends to be host-centric. That is it executes on a host to deal with config files used by that host. The core function performed by the cfm cmd is an rcsdiff of the host's file to the appropiate controlled version of that file in the cfm database (cfmdb) with optional prompt to take corrective action for match failures.
cfmintro, assumptions, overview, examples, design-history