Christopher B. Browne's Home Page

4. Multiplexing Configuration Managers

4.1. My Blue Sky Thinking

I have made use of Linuxconf and WebMin on both Red Hat and Debian .

The problems with these tools, to my mind, are twofold:

The "menued" tools tend to provide one degree or another of "logging" of changes that may be useful in figuring things out; they do not, by and large, provide anything that is directly reusable.

IBM's SMIT tool provided this sort of functionality, writing out reusable logs of everything it did at least as far back as 1985, so there is certainly precedent for this.

These days, I make moderately extensive use of cfengine to manage my home systems, along with a few scripts written in Common Lisp.

My "Holy Grail" would be to see tools like Linuxconf and WebMin not make updates themselves, but rather for them to write rule scripts for a configuration engine like cfengine. That would provide the perhaps-unexpected-merit that those scripts could be used three ways:

A perhaps even further "blue sky" dream would be for the process of installing software using RPM and dpkg to make use of something like cfengine scripts. Installation of packages tends to involve several major phases, each of which could make use of the facilities of a tool like cfengine:

It should be obvious that in the process of dropping these updates into place, the use of a tool that is able to log this, manage locks, and otherwise manage these things coherently should be fairly useful.

An interesting side-effect of this is that some of the configuration, such as linking files, fixing permissions, setting up system services, and restarting processes, represent processes that might be useful to revisit on a periodic basis:

In effect, this suggests that along with there being some behaviour associated with installation, perhaps resulting in there being a cfengine script, there would be value to there being further behaviour associated with "preventative maintenance," with there being further scripts to that end.

With cfengine, it would doubtless be undesirable to regularly run hordes of tiny maintenance scripts, one for each package. It would make more sense to have those scripts be constructed in such a way that some sort of cfscript-merge tool could merge the "hordes" together to get one larger and more efficiently executable script.

Contact me at