eBox configuration management

[(``-_-´´) -- Fernando]

Is there a way to do a trial with eBox?
What kind of precautions should I take?

On 7/25/07, Soren Hansen <soren at ubuntu.com> wrote:
> 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
> wider discussion.
>
> 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
>   scripts, etc.)
>
> 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.
> or
> 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
> distinguish them.
>
> --
> Soren Hansen
> Ubuntu Server Team
> http://www.ubuntu.com/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQFGpzjVonjfXui9pOMRAo/mAKCCXtOLm//ixp3wQoZh4/ue+GhOPgCfe81l
> K29nPlOPAEu9vbnh2RnslVg=
> =DYmv
> -----END PGP SIGNATURE-----
>
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
>


-- 
BUGabundo  :o)
(``-_-´´)
Linux user #443786    GPG key 1024D/00967685
The body of this email is licensed under a Creative Commons
Attribution-Noncommercial-Share Alike 3.0

http://BUGabundo.net  -- http://BrinKadeiraS.BUGabundo.net