Hi Gary,
Thank you for the insight into your environment. Out of curiosity,
what kind of data store is your central configuration management? Can you
generate the XML AI manifests out of it?
One way, which I think is neat, is to use an XML file of machine
data then, via XSLT, automatically generate AI manifests without much
scripting and allowing one to generate manifests against the latest AI
manifest format automatically too.
Thank you,
Clay
On Sun, 3 Jan 2010, Gary Mills wrote:
> 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
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>
