Cfm started in a solaris 24/7 critical systems environment as a set of dc (diff check) tools. These were used to examine changes and restore config files as necessary.
The dc tools initially used one dir tree per host rooted in the cm area on a server. These dir trees were sparsely populated mirrors of the hosts os dirs containing only the config files. The dc tools walked the host's dir tree on the server and presented the sysadmin with detailed info on what changes had been made to its config files.
To insure identical configs on multiple hosts a pseudo `all' dir tree was implemented on the server. Symlinks were used in each host's dir tree to share the same file. This was quickly replaced by deleting the symlinks and modifying the dc tools to look first in the host's dir tree and if no file was present to look in the `all' tree. This scheme was easily extended to accomodate other groupings, eg separate configs for different workgroups. The dc tools simple checked the appropiate sequence of dir tree based on the host's name.
To support documentation of changes and provide recovery capability the server's dc dir tree was made a cvs working dir tree. The sysadmin could now make comparisons and changes against the current set of config files using the dc tools and then document and upload changes to a conventional configuration management system. The doc trail could be used to justify changes and, of course, the cm system allowed rollback when required.
The final embellishment to the dc tools was integration with the SVR4 package contents database. When changes were made to config files the contents database was updated so that the `pkgchk' command could be used to verify the integrity of ownership, permissions, timestamps, and checksums for all installed files including the altered config files.
The dc tools were a major asset in tightly controlling the config of critical systems. The basic idea is to solve a problem locally on a single host, then to share that identical solution uniformly on all hosts where it applies. The devil is in the details. There are two significant problem areas. First, a nuisance problem is that all things must be kept the same even where the differences are trivial and unimportant. Of course its those trivial details that sometimes bite you when you least expect it. There is real overhead here. It goes with tightly controlling any complex system. Second, the many variant config files can be handled by making many different dir trees, but each tree isolates its files and requires separate comparison checks and updates action to incorporate changes.
The cfm name came into being when the dc tools were ported to linux. Cfm is coded in perl. It combines the multiple server dir trees into a single dir tree of rcs versions files. The former dir tree names are used as tag names for separate branches in the rcs files. Cfm refers to these tags as set names as they are useed by sets of hosts to share the current versions of a group of config files just as the dir trees were. The `rpm -V' command with a perl filter replaced the `pkgchk' command as the means for verifying ownership, permissions, size, timestamp, and checksum for all installed files.
Cfm-1 leveraged the rpm database to simplify the management of sets. The rpm name is now the default set name. This is a significant improvement in the effort required to use cfm on a net of differently configured hosts. It's not enough, but it is a major improvement.
cfm-2:
A need exists to track a host's config file against a base version of that config file while allowing deltas for individual hosts. Cfm-2 will address this by maintaining a host specific set of okdeltas which will be applied and removed before comparison to the set's version of the file. This is a significant enhancement for the sysadmin. It should move a great deal of the complexity of monitoring individual config file deviations into cfm code thereby simplifying the task for the sysadmin.
A need exists for wide area network support that will allow the cfm database to be located anywhere. Cfm-2 may use cvs instead of rcs. Putting sysadmin data on the internet will require security. Ssh will be used as the external transport mechanism for cvs connections in cfm-2. Other alternatives may be investigated.
cfm-3:
Performance has not been a major issue for any of the above. On an unloaded system it takes on the order of 1-2 minutes to check the 600 to 1000 config files on an average host. The `rpm -V' checks can take as much as 10 minutes. These times may be significantly improved under some circumstances.
cfmintro, assumptions, overview, examples, design-history