eBox configuration management

[Soren Hansen]

On Thu, Jul 26, 2007 at 08:56:35AM +0200, Martin Pitt wrote:
> > 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?

Yes, the LDAP server can be used for authentication from the network, so
a separate instance on a separate port (or similar) is not an option.

> (Unlike the second internal apache server that ebox uses for
> presenting its own UI, and which should be totally independent from
> the system apache).

Right.

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

After I took a closer look at slapd's postinst yesterday, I have seen
the error of my ways and appreciate that argument *so* much more. I'm
*not* going to try to mirror what that script does. Ever. :)

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

I've got a plan that involves checking the existing slapd.conf to see if
it matches what the slapd postinst must have written and only then
attempt to do anything with it.

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

That's a good point.

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

Well.. Yes. The problem just doesn't lie within eBox' configuration, but
rather (e.g.) slapd.conf. The default slapd config does not (AFAICS)
provide any simple means for adding new schemas and/or ACL's. I'm
thinking of adding a "include /etc/ldap/schemas/extras.conf" line to the
default slapd and provide a update-slapd-schemas script that
adds/removes include lines to that file. That would make it trivially
easy for eBox to add/remove new schemas. Something similar would be done
for ACL's.

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

Yes, I was working on a patch that could determine if the
/etc/ldap/slapd.conf on the system was the one the slapd postinst script
had put there (removing the base dn and comparing md5sums), and if not,
refuse to install the base ebox ldap module. That combined with the
above changes to the slapd package would make me sleep well at night, I
think.
> 
> 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



> -- 
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


-- 
Soren Hansen
Ubuntu Server Team
http://www.ubuntu.com/
-------------- 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/498da915/attachment-0001.pgp