John Hearns wrote:
In an ideal world, someone could maintain the canonical best practice setup for say a locked-down desktop lab, and everyone else just clicks/types "install me a locked down desktop lab system," applies any site-local tweaks, and that's it.
Do things like LCFG http://www.lcfg.org/ help?
Yes, this is exatly what it does (and has been for many many years).
Our technicans only have to define things like this in the master config for a machine:
/* mymachine's config profile */
#include <lcfg/os/redhat9.h>
#include <lcfg/hwbase/dell_optiplex_gx240.h>
#include <inf/sitedefs.h>
#include <inf/wire_c.h>
#include <inf/officedesktop.h>
#include <inf/postgresql_rh9.h>
dhclient.mac 00:06:5B:34:F5:7E
inv.sno <snip> inv.allocated cedward1 inv.location JCMB-<snip> inv.manager cedward1
/* End of file */
.. then shove in a CD or PXE boot. The whole point of it is that _it does_ just "install me a locked down desktop lab system".
The key to LCFG is that its actions work beyond initial install. Any changes made to the config post install are then communicated to the client and acted upon. For example if I remove the line:
#include <inf/postgresql_rh9.h>
Then the machine will remove all the packages associated with being a postgresql server. It might also stop the daemon and do some cleanup depending on how the configration component is written (see the docs for terminology).
Another example is the "dhcpclient.mac" entry above. It does more than associate the mac to the machine for example. Defining it in the _client_ profile makes the dhcp server's profile pick it up and triggers a rewrite of the dhcpd.conf on the dhcp server that's running on the "wire_c" subnet.
I'll reply to Havoc's post in more detail in a minute.
Carwyn
