Configuration Parameters

The configuration parameters are stored in the form of key-value pairs, inspired by X resources, and similar to the parameters used by COAS. For example:

  mambo.dns.servers localhost

The key specifies the hostname, the subsystem and the parameter. The configuration files are passed through the C preprocessor, supporting simple inheritance by file inclusion:

  #include <standard_laptop.h>
  auth.owner paul
  ....

The machine-specific file need only list those resources which are different from a standard laptop (the first component of the resource keys is generated automatically from the name of the file). Notice that the included class file relates to a high-level concept (standard laptop machine) which may contain resource specifications for many different low-level subsystems. The class files may of course be nested.

Together with the use of preprocessor variables, this simple mechanism provides a powerful way of presenting complex host configurations in a clear way, with very little specialised software. However, it is not sufficiently fine-grained to process information inside the resource keys. This causes difficulties in some cases; for example, a standard configuration might specify that the CD-ROM should have its ownership changed to match that of the user at the console:

  auth.consolepermclass_cdrom
    /dev/cdrom

If we have a second SCSI CD on our machine then we might want to specify:

  auth.consolepermclass_cdrom
    /dev/cdrom /dev/scd0

Specifying this directly for a particular host is not good, because it overrides the specification for the standard machine, so that changes to the standard specification (such as changing the location of the default CD-ROM) would not be reflected on this particular host.

At the same time as porting LCFG to Linux, we added the facility to specify a regular expression for transforming any inherited resource value. This allows us to easily append or prepend items to a standard value:

  auth.consolepermclass_cdrom
    !/(.*)/\$1 /dev/scd0

We call this process mutation. Although it is very powerful, overuse can lead to configurations which are very hard to understand, and we usually restrict its use to a few well-defined macros:

  auth.consolepermclass_cdrom
    ANDALSO(/dev/scd0)

The files containing the configuration parameters for the entire installation are maintained on a central server under RCS control. When changes are made, the parameters are preprocessed into a single table which is distributed to the clients as an NIS map. This provides a replicated database which is easily accessible to all machines and simple to implement, but it was only originally intended as a temporary solution and it has a number of problems. These problems and a possible replacement technology are discussed later (section 6). Since this configuration information must be available at boot time, laptops are all configured as NIS slaves which update their maps on demand.