This directory collects together some historical items related to lcfg.

"lcfg" is a system configuration tool developed over many years, initially in the Department of Computer Science and latterly in the School of Informatics, and now used widely across the University. It was originally used on Solaris boxes, and later ported to various Linux distributions, including latterly Scientific Linux and Ubuntu. It grew out of the realisation that distributing rc.local fragments which would then be combined somehow on end systems was becoming an unviable approach, as the complexity of the requirements increased.

Instead, the concept of "configuration objects" was developed, these being under the control of configuration "resources". Each host's profile would describe its intended configuration in as much detail as possible. The profiles would be pre-processed on a profile server (using K&R cpp, thus allowing for the easy inclusion of platform, subsystem and use-case header files) and compiled into XML for distribution to the end systems.

Each object had a standard set of methods, Start(), Stop() and Configure() being the most important. At boot time, the standard "rc" mechanism would be used to start a "boot object", which would then Start() the individual objects based on its own configuration, Those objects would interpret their own configuration, and take such action as was required. A daemon was also started, whose job it was to look for profile changes, calling the objects' Configure() methods as appropriate, and those would then take any reconfiguration action necessary. The Stop() method would be called at system-shutdown time. Not all objects required all methods, of course, and stubs were provided by the "generic" object to cover these cases.

The lcfg system was reorganised in the light of experience with the original version, with much of the underlying framework being rewritten. perl was introduced as an alternative to sh for the creation of objects, now renamed as "components", and "spanning-maps" were introduced as a way for one machine's profile to influence others. Support for systemd was introduced for SL7.

Not much remains of the original lcfg. Just about the only original object which can still be found is the "ether object", which was used on Solaris-based routers to ensure that all of the interfaces would have unique MAC addresses (Solaris liked to believe that all interfaces should use the same MAC address by default, while switches liked to see MAC addresses tied to individual ports on the network).

The lcfg home-page can be found here.

$Id: index.html,v 1.2 2021/11/30 09:46:56 gdmr Exp $