Prepackaged configurations

Carwyn Edwards carwyn at carwyn.com
Sun May 23 00:02:14 UTC 2004


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





More information about the fedora-devel-list mailing list