cfengine, debconf and ldap

[Steve Wray]

Hi all,
Well after a delay while getting things under control at my new place of 
employment, I am back working with cfengine and continuing the 
development of integrating cfengine and the debian system.

The way I see it, its like the movie Aliens which, I am sure that you 
have all seen :)

Remember the sentry guns?

cfengine is my sentry gun.

Unfortunately, due to alien infestation, I'd been unable to set my 
sentry gun up; if I'd stopped to concentrate on setting it up an alien 
would have got me.

So I've been spending the last few months clearing out the aliens from 
inside the perimeter so that I can set up the sentry gun without 
worrying about an alien getting me.


Now I have the beginnings of integration of cfengine, debconf and ldap.

If anyone out there in cfengine-land has already done anything like 
this, or is interested in collaboration, I'd be glad to hear from them!


Essentially, what I have now is a set of LDAP databases, one for each 
hosts specific debconf config details and one for the generic stuff.

debconf is set up to query these databases and to *try* not to be 
interactive (sometimes this seems a lot harder than it should be :)

cfengine takes care of the package installation with a dselect-upgrade. 
The package selection state list for each host is maintained on the 
cfserver this list is (currently) manually updated by the sysadmin and 
then a cfrun command issued; the client pulls down its latest selection 
states, runs a dpkg --set-selections from it and then performs an 
apt-get dselect-upgrade. Debconf gets its answers directly from the 
central LDAP database.

Seems to work in the simple test cases so far! Time, as they say, will 
tell :)


Theres plenty of work ahead

- populating the debconf databases using dpkg-preconfigure and having a 
nicer front-end to change the debconf variables in the LDAP database.

- fragmenting the selection states file so that there is a generic 
'fragment' and host/class specific 'fragments', then getting these 
combined on each host at dpkg --set-selections time. At the moment, each 
host has a monolithic selection states file which is a bit of a waste as 
there is so much commonality.

- more LDAP databases for classes of hosts, at the moment theres just a 
generic and one per host. Again, theres plenty of commonality among 
classes of servers to save on wasted effort and duplicated configuration.

Thats for starters.
:)


--
There is nothing more important to good government than good education.