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 devel
mailing list