In case this is useful to any of the developers, I'll describe in very general terms what we do now for automated configuration management of Solaris 10 servers and workstations. We don't expect to do exactly the same thing for opensolaris, but the principles will be the same.
Our goal is to use a system of central management of configurations, both for initial installs and for propagation of subsequent changes. This means that once we initiate an install, the entire process will proceed without further intervention, so that when the host reboots it will be fully installed and configured. Likewise, when we make configuration changes later in the central system, we can be assured that these changes will propagate to the hosts for which they are intended. This aspect may require a reboot to complete the procedure. For this system to be convenient, we require the ability to group hosts into classes, so that configurations can be applied to classes rather than individual hosts. Some classes, such as client architecture, can be determined automatically. Other classes, such as `workstation' or `server', have to be established manually. We also require periodic verification of host configuration and periodic updates. The files delivered as part of a product can be divided into four categories: executable, configuration, data, and log files. Only the first two need to be delivered by an installation and configuration system. Executable files, which include command files, library files, and scripts, can be delivered in a package. These will not be altered except by installation of patches or new packages. Configuration files, on the other hand, are expected to be modified after installation, although some will often not be changed. They can be delivered as part of a package, but the integrity of a package must not depend on them. A configuration management system should both install packages and install or modify individual configuration files. The recent trend is to conceal configuration files and make configuration changes with administration commands instead. A configuration management system will need to do that as well. In all cases, it needs a way to verify the configuration on each host. For packages, it can do this by checking the package name and version. For static files, it can simply compare them to the original. For administration commands, it will need to run the same command in verification mode, if that is possible. Our current system relies on Custom Jumpstart with a complex finish script. The configurations themselves reside in an NFS- mounted filesystem that's available to the host as its being installed. These include additional packages, patches, files to be copied, as well as lists of other filesystem objects to be created or deleted. We are certainly willing to look at other ways of accomplishing these changes for opensolaris. -- This message posted from opensolaris.org
