eBox configuration management

[Stephan Hermann]

Hi Soren, Hi All,


Am Mittwoch, den 25.07.2007, 13:49 +0200 schrieb Soren Hansen:
> 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.)

Do you think that the old thinking of providing an easy to use server
management web tool to users will solve the problem of real system
administration?

Thinking about the old times, where webmin was da king of webbased
system administration, I would not want that this tool will be
installed. There were and are security holes when you use webbased
tools, disregarding the different implementations of http and forgetting
php usage.

Looking at this problem from the viewpoint of a Provider of Rootservers,
who is providing unsecure solutions like  Plesk or other utitlies, it
could be a nice solution, but then I would advise to override the
original configfiles of the system.

From the viewpoint of the desktop user, I would expect some nice UI
utils for doing all the daily administration work.

From the viewpoint of the system administrator who wants a secure
system, like Ubuntu server is today, I would say, throw it away, it
hurts a lot.


Thinking about the tribe3 announcement and reading this article
(http://people.warp.es/~isaac/blog/index.php/ebox-slated-to-be-the-official-ubuntu-server-management-tool-66) I wouldn't like to see this tool on the default media or in main or as any official supported package at all. It's a wrong way of providing a good centralistic solution of server administration.  

> 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 problem will be, that the admin of these boxes wants to adjust those
files by hand or by the tool (at least, that was the thinking when I was
a young admin and was selling rootservers). Actually, there are too many
things you won't support in eBox or webmin or whateverwebbased utility
you have, but the user want to have (this is real business experience).
Think about the hundreds of configurations you can have in a normal
apache setup.

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

Which could clash with the LPI-199 training/certification. But a real
admin wouldn't want this tool anyways, so it's all about semi-hobby
admins.

>  * Maintenance overhead (we need to somewhat mirror the "real" init
>    scripts, etc.)

Sure: don't touch it. No other tool then update-rc.d/or an upstart tool
should touch the initscripts/runlevels or you set "eBox" as default
system administration utility, which means you have to remove all other
tools from the system who could touch those files too, and this would be
not a good step towards "Ubuntus Domination in server concentrated
environments" like Datacenters.

If this is wrong on this list, please forward it the correct list, but I
think those random thoughts are quite important. 

Please reply as well to me personally, because I read this list very
sporadic.

Regards,

\sh
-- 
Stephan Hermann
eMail: sh at sourcecode.de         Blog: http://linux.blogweb.de/
JID: sh at linux-server.org        
OSS-Developer and Admin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20070725/fdbb8621/attachment.pgp