eBox configuration management
(``-_-´´) -- Fernando
Ubuntu at BUGabundo.net
Wed Jul 25 16:07:39 BST 2007
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.
> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> -----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
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
More information about the ubuntu-devel