eBox configuration management

[Martin Pitt]

Hi Soren,

thank you for summarizing our recent discussion!

Soren Hansen [2007-07-25 13:49 +0200]:
> Case in point: For certain eBox services, an LDAP server is needed. 

Just for the record, that LDAP server is not needed to store ebox'
internal settings, it should be a real production server that is
merely configured *by* ebox, right? (Unlike the second internal apache
server that ebox uses for presenting its own UI, and which should be
totally independent from the system apache).

> 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.

As already said on IRC, I am not convinced at all by this principle of
maintaining a separate configuration hierarchy which is owned by ebox.
It 

 * does not take any benefit from the existing packaging,
 * creates redundant configuration files (and confusion around it),
 * forces the admin to always use ebox
 * breaks compatibility with every other configuration method (including debconf),
 * breaks backup/restore systems, and
 * breaks every existing documentation for these servers.

IMHO, the only solution that will not cause a lot of pain and grief is
to teach ebox about properly reading and writing the actual
configuration of services.

> The benifits include:
>  * Installing eBox is *very* easily undoable.

I do not see a problem with this. If I use ebox for configuring my
server, and then uninstall it, it should *not* undo all that
configuration. A configuration UI should be, abstractly, 'just yet
another configuration editor'.

>  * 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).

Indeed this is a tricky problem to overcome, but the problems that
we'll get when not doing it are far worse IMHO.

I think there are some ways to mitigate this problem, though. After
all, debconf-based configuration has the very same problem, and the
common practice is to have the package ship static conffiles with
defaults which work everywhere, and factor out the variable bits into
a default file which is managed by the maintainer scripts and trivial
to parse/write. This approach should work equally well for ebox, I
think. 

It is relatively easy to change a package to factorize out a setting
from the central conffile to a separate configuration file. Since our
goal for the server is to provide sane defaults and just provide an
interface for the settings that the ebox server admin will actually
need to change, there won't actually be so many things to change in
packages, I figure.

Given our use case for ebox, I think it is absolutely adequate if ebox
checks for modified conffiles [1] and refuses to change it if it was
modified by the admin (either 'at all', or where possible, 'in a way
that ebox cannot handle').

Thank you,

Martin

[1] dpkg-query -W -f='${Conffiles}' <package>

-- 
Martin Pitt        http://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20070726/e45a12db/attachment.pgp