eBox configuration management

[Soren Hansen]

On Wed, Jul 25, 2007 at 06:07:47PM +0200, Stephan Hermann wrote:
> 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?

No. What gave you that impression?

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

Let's make this absolutely clear: eBox is not webmin. Sure, both provide
at web interface, and both messes around with your configuration files.
Where webmin essentially is a config-file <-> html-form translator, eBox
simplifies a limited set of tasks and provides a simple interface to
perform these tasks.

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

Why?

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

Yes?  I don't see your point.
 
> 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.

eBox is not a tool for experienced system administrators. It's a tool
for people who are not comfortable with text editors and configuration
files, but still want a file server, a print server, a DHCP and DNS
server, an OpenVPN server, etc. Different tools for different people.

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

There are currently a huge demographic for whom running Ubuntu on a
server is completely out of the question, because the don't have the
expertise to set up these services. What do you propose we offer them
instead?

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

The user is free to change the eBox templates and thus change anything
he wants.

> Think about the hundreds of configurations you can have in a normal
> apache setup.

Sure you can, and I hope you have fun doing it. eBox is not trying to be
an interface that lets you change *every* pointless, little setting in
Apache. In fact, it doesn't even have a module for configuring Apache,
but if it did, I imagine it would provide something that would ask a few
simple questions like: "What's the domain?" "Which users should have
access to put files there?" and then share the DocumentRoot via Samba
and let only the selected users put new files there. The target audience
of eBox is unlikely to have any clue what a SpareServer is, what
mod_negotiation does, or what FancyIndexes means (other than it sounds
shiny). I imagine it possible that eBox perhaps adds an advanced mode
that lets you tweak stuff a bit more, but only time will tell.

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

Training and certification is supposed to match reality, not the other
way around.  

> >  * Maintenance overhead (we need to somewhat mirror the "real" init
> >    scripts, etc.)
> Sure: don't touch it.

Huh?

-- 
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/f4141f34/attachment.pgp