Havoc Pennington wrote:
In LCFG (http://www.lcfg.org/) you can do:
Some of the things that _might_ change across canned configurations:
- the package set (the only thing we can change now, via the Workstation or Server split in the comps file for example)
- specific parts of a config file, e.g. enabling xdmcp in gdm
- optimum partitioning scheme
- kernel boot options
.. control all the above in a centrally managed way ...
- ideally, it's dynamic instead of only install-time, i.e. you can change a machine from config A to config B post-install.
Easier for some things than others (e.g. partitioning scheme impossible to change post-install, config files perhaps easier,
package set relatively simple)
.. and that, i.e. it's a dynamic reconfiguration framework.
(I don't think we've ever done dynamic partition changing though).
I was going to reply to specific parts of Havoc's mail in more detail but it's probably best if those that are interested read the docs at http://www.lcfg.org/doc/. Instead I'll give a summary here.
LCFG is the configuration management system that's been used at the School of Infomrmatics (http://www.inf.ed.ac.uk/) for over a decade now. It's based on a lot of research and theory into configuration management systems, but, unlike many research vehicles it's also what we use to configure our 800+ Linux desktops (we eat our own dog food).
It basically allows one to abstract configuration by extracting what is "interesting" about a particular daemon or application into a higher level representation. This higher level representation is a configuration language that is used to describe a host in a central database. One key aspect of this representation is that it is prototype based and declarative (not procedural) i.e. you take a base template and add successive specializations using other templates to describe a machine.
Each host is described on the central configuration server as a composition of templates (see my last post to this list). This composition is evaluated into a profile (XML in our case) that is then sucked over onto the client where the configuration agents (components in LCFG terminology) use this state description to enact the configuration. There is one component for each "thing" that needs to be dynamically configured on the client.
Install time is considered to be just a slightly special case of a "configuration action". To this end we have our own installation technology that uses the same components that are used for day to day dynamic configuration to do the installations (CD or PXE based).
Within our implementation this concept has been extended to not only describe a machine but also, to a certain extent, relationships between machines. Specifically there is the notion of a publisher and subscriber model for maps of resources. The best examples of this are in the network configuration components. For example, while in most networks the definition of what holes should be punched in the firewall are defined in the configuration for the firewall host. In LCFG the definition is in the profile of the host that needs the hole opened. The combination of composition and component (agent) actions then does the rest.
At the moment LCFG is used mainly within our department and other departments within the University of Edinburgh. Various grid research installations and configuration management based research projects are also using it.
It's not something that can be dropped into an existing RH/Fedora network. Our implementation uses RH/Fedora as a base (rpms mainly), but then takes on a life of its own. The learning curve for people wanting to implement a network based on it is tough (although I'm not sure why).
What is worth looking at though are the lessons learned from 10+ years of using a system that already does much of what has been asked for. I'm sure the main authors would be very interested to talk to people on their thoughts relating to this.
Follow the following resources for more info:
http://www.lcfg.org/doc, specifically this paper: http://www.lcfg.org/doc/ukuug2002.pdf
Carwyn
-- Carwyn Edwards Computing Officer School of Informatics University of Edinburgh
