eBox configuration management
soren at ubuntu.com
Wed Jul 25 12:49:41 BST 2007
It seems the design decisions I made for eBox are not as popular as I
would have hoped (hi, pitti :) ), so I'm bringing them up here for
A bit of introduction: eBox is a systems management framework that
provides a web interface for configuring a number of services, e.g.
file and printer services, OpenVPN, DHCP, etc.
In its existing incarnation, eBox does this by a mix of overwriting
existing configuration files, and putting configuration files into a
ebox specific directory hierarchy (under /var/lib/ebox somewhere) (all
of this from maintainer scripts). Case in point: For certain eBox
services, an LDAP server is needed. When installing the base module for
that, eBox overwrote /etc/ldap/slapd.conf, made it point to
/var/lib/ebox/ldap for the ldap database, and finally removed the rc?.d
links for slapd. IOW, the config was overwritten, but the existing ldap
database (if any) wasn't overwritten. (In case you're curious, eBox
needs to make changes to the slapd configuration in order to add new
schemas and ACL's.)
My proposed fix was to (on installation):
* move all configuration files that eBox manages to /var/lib/ebox/conf
* remove rc?.d links for the "real" services (e.g. slapd)
* Install an upstart job description for the service (if possible, and
if not: put a separate init-like script in /usr/share/ebox somewhere)
and manage that from eBox.
The benifits include:
* Installing eBox is *very* easily undoable.
* We don't have to have intimate knowledge of each config file (which
we'd need to be able to make sure that any changes we make to
existing config files will result in e.g. a slapd instance that
behaves the way eBox expects it to).
The downsides include:
* Violates principle of least surprise. The configuration files are no
longer where the admin is used to having them.
* Maintenance overhead (we need to somewhat mirror the "real" init
Currently, once eBox has taken over a config file, it *owns* it. Every
time eBox starts (or a setting is tweaked in the UI), it renegerates the
relevant configuration files to make sure that everything is sane when
it starts. Before gutsy releases, I intend to fix this by either:
1) (the poor mans config management solution) refusing to overwrite any
config that has been changed since eBox last wrote it, unless the user
says "Yes, ignore my changes" or something to that effect.
2) (the bells-and-whistles solution) let the user do a three way merge
between a) the config file eBox wrote last time around, b) the current
config file (which the user apparantly has changed), and c) the new
config file eBox under normal circumstances would have just written.
1) is easy to implement and will also work from a console (very useful
as eBox does this config regeneration stuff on boot as well), 2) is
clearly optimal from a usability point of view, but very hard to
implement (especially if it's supposed to work both from a web interface
and from the console).
The real difficulty, as I see it, is what to do at install and uninstall
time. It seems the case of slapd is not all that bad, actually, since
the only changes made to slapd.conf during its postinst (with debconf
threshold at the default High) is the dn suffix, so if I just extract
those values from debconf and see if the config has been changed, I can
bail choose to bail out in the postinst or just take over the file.
Other packages may be much worse, though, but I'll have to deal with
that as it shows up. Also, I'm not sure what to do at remove and
especially purge time. Should I attempt to remove all the users from
the ldap database that has been added from the eBox UI? What about users
the admin added from outside of eBox? I currently have no simple way to
Ubuntu Server Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20070725/c964fc3d/attachment.pgp
More information about the ubuntu-devel