4. Multiplexing Configuration Managers
Web-based Sysadmin tool that works with many Unixes.
It supports a "module" system that allows extending it to help configure additional services. Thus far, this includes several mail servers, including Qmail , Postfix , and such, several DBMSes including PostgreSQL , web servers including Apache , Squid , and plenty of other things such as SAPRouter, APC Smart UPS, VNC, and such. There are over a hundred "standard" modules, and over 300 third party ones to help manage other services one might run.
Modules are typically written in Perl.
An ambitious "system adminstration tools" project, planned to provide the following user interfaces:
Console, based on ncurses
A web interface, where Linuxconf itself speaks the HTTP protocol and behaves as a web server.
Graphical interfaces based on Java and one based on an X library called wxXT.
Some portions of Linuxconf are usable from the command line, and thus may be used for construction of programmed scripting .
Linuxconf is primarily being sponsored by Red Hat, and thus is likely most functional on that distribution. It has also been installable with Caldera , Debian, Slackware , and SuSE.
Spacewalk: Free & Open Source Linux Systems Management
Inventory systems - both software and hardware
Install and update software
Collect and distribute local custom packages
Provision new systems ("kickstart")
Manage deployment of configuration files
Monitor systems (to what degree unclear)
Provision and manage virtual server guests
Uses Oracle or PostgreSQL for capturing system data. Apparently it now supports Section 3 systems as well as Red Hat derivatives.
UPM - Universal Package Manager
Its goal is to help you administer large scale installations with many many (linux) hosts. This way it is quite similar to cfengine , but it uses a very different approach, that is more suitable for todays Unix installations that are usually all package (eg. RPM -packages) based.
The concept of cfengine is considered unsuitable, by the author of UPM, for installing new software releases on a bunch of hosts that use the package concept because it has no knowledge about packages and so is likely to break the package concept. upm in turn will do everything only by manipulating packages. upm can basically deal with any kind of packages like RPM, DEB , etc, although currently there is only code for RPM packages.
upm allows you to keep a bunch of packages in a central point and, by running it on all your systems, to upgrade all your systems automatically. All that is needed is an NFS -mount for upm so that it can find the packages and its config file. Both are kept in one directory hierachy, so you only need one NFS mount.
My own editorializing: While it's true that cfengine doesn't natively "understand" the RPM and dpkg formats, and the relationships between packages, I'm unconvinced that upm is so fundamentally better. If packages that are desired on all systems are, automagically, pushed into a "published" NFS directory, I'd tend to think that cfengine could quite capably try to upgrade systems using the specified packages. RPM and apt-get can fail with reasonable grace if presented with infeasible sets of packages.
System adminstration tool that is written in Java, has a client/server, architecture has a built in object database and support for pluggable Java classes for object management. The database schema is editable using a GUI editing tool. It is not X.500 or LDAP based, and it is only designed to handle on the order of 50,000 records, but it "works well."
CFM -- Configuration File Manager
The idea of CFM is to provide tools for managing configuration files in conjunction with RPM . RPM manages the packages as software, providing capabilities to check versions, compare to original xversions, provide metadata, and such; CFM supplies similar capabilities for the configuration files.
This is a configuration manager for Linux that represents something of a cross between cfengine and the SATAN security analyzer.
The authors seem to intend to license this as "shareware," with a limited edition available gratis, and more powerful editions having more expensive licenses. Obviously not free software, but the approach has merit and could provide some useful insights for fixing problems with distributions. It could be well worthwhile for organizations building Linux distributions to search out problems using this tool...
GAP - GNU Administration Project
Intends to provide a distributed system administration scheme using GNOME libraries and CORBA, with a multiplexor to group together remote objects so that many systems may be configured together.
This project appears to have been inactive for quite a while.
OpenNMS - Java / XML / XSL Distributed Network and Systems Management Software
A project to provide a single unified interface to system configuration data on Linux computer systems
Initiated by Red Hat Software, this is a tool that parses configuration files using an ML-based domain-specific configuration representation language, and transforms them into a tree, which may then be manipulated within the tree structure, and then re-written.
This is likely to be quite a lot more robust than scripting-based methods where tools like sed and awk are used to recognize regular expressions. It also seems likely to be easier to manage than the cfengine approach of rewriting configuration files using a sort of line editor.
Implemented in Python, this manages multi-node systems via SSH.
Func is a secure, scriptable remote control framework, intended to replace the use of SSH scripting to control remote systems. Uses Python.
A Linux installation server
System configuration software often needs to manage some passwords to operate system services, to store and retrieve those passwords in a somewhat secure way. Sekred is a tool, implemented in OCaml, to do this.
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:
While they may be able to lead you (by the nose!) through the configuration of part of the system, they usually do not show you precisely what bits of configuration was changed, nor, more importantly, why.
That may be fine to users that don't care to understand how their systems work; I'd prefer to know so that I understand it better. That can mean that the next time, I can make more intelligent choices, or, at least, choose more quickly.
Thus, a good administration tool must provide feedback as to what it is doing to change system configuration.
The second problem is that these tools typically do not provide any way of "recording" system changes for later reuse.
For instance, I might add a host to /etc/hosts on one machine. To add it on another machine, I'll have to go through the menus and change it a second time, with the associated subtasks of:
Remembering I need to make the change;
Remembering the "menu path" to navigate my way through the change;
Remembering the parameters, and typing them in correctly a second time.
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.
Whenever I find need to change configuration, I ask myself if this can be encoded as a cfengine rule so that the change be applied, reapplied, and perhaps even generalized to run on multiple hosts.
I may need to use something like Linuxconf to search out how to make the change; once I know how, I would prefer to automate the change.
The more of the "system cleanup" that can be managed in automated fashion, the less I need to do by hand.
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:
The gentle user may read them to see what they are doing, to attain a better understanding of how the system works and is configured.
The gentle user may reuse scripts by running them on other hosts in order to repeat the same setup.
The gentle user might regularly reuse the scripts, adding them into the set of events regularly executed as part of a system administration/cleanup regime, so that the configuration changes would become part of the permanent configuration of the system.
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:
Programs, libraries, and documentation are copied into place in places like /usr/bin, /usr/lib , and /usr/share/doc. This may involve some amount of "relinking" of symbolic links, as well as modifications of permissions.
Configuration files are copied into place in places such as /etc . There may need to be an interactive process to request critical configuration parameters in order to start up services.
RPM provides some limited capabilities in this area; DPKG provides a mechanism for setting up some configuration interactively at install time, via the postinst script.
In neither case are the capabilities either terribly sophisticated or terribly widely used.
Processes may need to be restarted; configuration may need to be added to indicate the presence of new services.
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:
Logs need to be rotated regularly to prevent running out of disk space;
Access permissions for security-sensitive services should regularly be verified to diminish the likelihood of breaches of security.
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.