NAME

  cfm-info - overview of the Configuration File Manager


BACKGROUND

Cfm is a configuration file manager package of tools for use in maintaining total control of installed system software. It is particularly useful in developing, testing, and deploying critical software systems. When properly used a vendor can guarantee that software products that have been acceptance tested in a controlled lab will perform correctly on installation at a controlled production site.

An average linux system today may contain over 400 application packages which typically use around 800 configuration files with an installed population of about 70,000 files. Providing an application package that works with multiple versions of multiple operating systems is usually the goal of a developer. Managing to make the many different packages all work together on his own systems is the goal of the system admin.


From the Beginning

The many different developers of packages use diverse, complex tools which are frequently not understood by other developers, much less by system admins. It will help to view the application creation and deployment process in three basic steps.


DEVELOPMENT

1. The developer will code a set of files to implement the functionality of his application package using tools appropriate to his needs. He will test and recode these as required to get the application working on his development hosts.

2. The developer will probably want his application to function in customizable ways in a wide variety of hardware and software environments to spread the cost of developing the core application over a large population of users. To do this he will anticipate the slightly different installation requirements and will code working alternatives accordingly. He will provide configuration files in which the system admin can use parameters to select among these alternatives to make the application work on specific hosts.

3. The typical system admin will not like having to deal with the diverse set of developers tools to install an application's files. To ease this burden the developer can use one of the modern package managers (rpm) that accompany an operating system distribution. Rpm is used by the developer to collect pertinent information from a working installation about the set of files to distribute. This info includes location, ownership, permissions, checksums, and timestamps as well as the files themselves. Two other very helpfull items are identification of the config and documentation files. Rpm bundles these pieces of data into a single package file which can be passed to the system admin.


INSTALLATION

1. The system admin accepts the application package file and uses the single rpm interface rather than the diverse set of development tools to install the application, verify the integrity of its files, and when required to cleanly remove them.


CONFIGURATION

Life has been easy for the system admin up to this point.

1. The system admin must read the documentation provided by the developer (he did provide documentation, right?) to determine how to set parameters in the config files. As mentioned above, the package manager can be used to verify that the distributed files are unaltered. But it will be of no assistance in validating config files once they are changed. You need the Configuration File Manager (cfm) for tracking these changes. For each package installed use cfm to initialize its config files in the cfm database (cfmdb). This captures the distribution copy of the files by copying them from their installed location. If things go wrong during the configuration use cfm to recover the originals and start over. When the system admin has the application working he uses cfm to document the reasons for his selection of parameters and to update the cfmdb with the working copy of the config files. The previous copy can still be compared to and/or recovered.

2. A one host network is not especially interesting. But if the system admin now wants to install the same package on an additional dozen hosts he can shotgun the rpm install commands to all, then do the same with cfm checkout commands to download the working copy of the config files from the cfmdb.

3. Daily audits executed in background on each host from inside cfm can use the rpmdb to verify the integrity of non-config files. Likewise, cfm can execute on each host to access the cfmdb across the local network and verify that its config files match the correct copy in the cfmdb. The system admin can compare the current version of a config file on any host to that used on any other host or to any previously captured version of that file in the cfmdb and can view related documentation and recover any of those versions.

4. If a config file on a host must differ from the working copy on other hosts their must be a way to distinguish the different versions. The default tag cfm uses to identify the working version is the name of the rpm that provided the file. To identify a preemptive config file version the system admin simply provides an alternate tag to use instead of the rpm name and re-initializes the config file in the cfmdb from that host. This uploads the host's version of the config file to the cfmdb tagged with the name provided by the system admin. In the most common case the hostname is used as the tag for a file that is host specific. Cfm supports the ability to use a per host list of arbitrary tag names. To select its working copy of a config file cfm sequences thru the host's list to find the first version that is tagged with one of the host's tag names. Putting the hostname before the rpm name in the host's list insures that the host uses its host specific version of the file.


MANAGING CHANGES

If a system admin needs to make a config change for an application that is identically configured on all hosts he can make and test the modification on any host. If the test fails he can easily restore the config from the cfmdb. If it succeeds he can upload the altered file to the cfmdb, documenting the particulars in the process, and issue a single cfm command to all hosts to update the files. Note that only hosts that share the tag used by the the test host will be affected, eg hosts without the application installed will ignore the command. In the event that a host is missed for any reason (shutdown, etc) a nightly audit by cfm will report the discrepancy and that host can be examined and the command reissued on it.


cfm-2, the future

1. If one of the hosts that uses an application requires a config file that differs from that used by the others the system admin can create a new tag to track the config file as indicated above. If a generic change is subsequently needed which should apply to all versions of the config file in cfm-1 cfmdb it is incumbent on the system admin to query the cfmdb for the name of all tags used in that file and to upload the change for each tag. If all these files are hosts specific and there are 100 hosts the task becomes tedious. In cfm-2 the check of config files will become a two step process. First a host specific delta will be removed from the hosts current copy of the config file, then the result will be compared to the cfmdb copy. Cfm-2 will support uploading changes to either the host specific delta or to the base configuration for the application. While this fix will not entirely eliminate the tedium associated with multiple tags it will address the vast majority of the cases.

2. Cfm-2 will use cvs to support secure network access to a repository containing the config file revision information which can be located anywhere on the internet.

3. Cfm-1 uses the rpm verify results with filtering of expected changes to verify file ownership, permissions, and checksums. Cfm-2 will maintain its own database containing this information. This will allow control of how these parameters are altered. It may also result in improved performance.


See Also

cfmintro, assumptions, overview, examples, design-history