eBox - the story continues :)

[Soren Hansen]

On Thu, Aug 02, 2007 at 04:29:27PM +0200, Martin Pitt wrote:
> > The most straight-forward solution would be if there existed a
> > special no-conf version of the ntp package.
> I think this is too crackful. We should not try to invent a lot of
> different patterns of how configuration and packaging works in
> conjunction with ebox.

True. That suggestion mostly grew out of my late-at-night frustration.
:)

> My feeling is that this should be handled with /etc/default files and
> a sane default behaviour of packages.

Why is it better to tweak /etc/default files than the program's real
configuration file? Becuase it's (likely) got a simpler syntax?

> E. g. it would make sense for dhcp3-server not to start at all if
> /etc/default/dhcp3-server does not have any value for INTERFACES. I'm
> not sure what the current out of the box default is, but IIRC it
> does not have any default interface there.

Sounds right.

> As per our previous discussion, ebox should only be concerned about
> the default files (at least initially).

Just to be clear: By "default files" you mean "the config files as they
are before the admin starts to tweak them manually" and not "the files
in /etc/default"?

> With ntpd it might be a little different. I haven't checked, but let's
> just say it'd listen to all interfaces by default. I see two
> possiblities here:
> 
>  * If it makes sense to have a service run by default, don't touch
>    anything. ebox will read the configuration, see that it is enabled,
>    and allow you to tweak it.
> 
>  * If a manually installed service shall run by default, but not if it
>    is only pulled in as ebox dependency (such as ntpd), then a
>    workaround would be to have the ebox preinst create the ntp default
>    file (if not present already) and disable it there, so that
>    installation of ntpd will end up with no actual action and daemon.
> 
>    This is still a Gross Hack™, but IMHO still better than diverting
>    configuration files, RC symlinks, and tramping over existing user
>    configuration.
> 
> This does not rule out that some server packages need to be changed,
> of course, but that should happen in a consistent way that doesn't
> break the default behaviour when installing them manually.
> 
> What do you think?

I'm not sure.

I'll try to take a step back.

There are generally three different kinds of entities that would want to
change a package's configuration. These are:

a) configuration helper packages (like eBox, auth-client-setup, webmin
(to some degree), etc.). The common task is to make it easy to
accomplish a limited set of relatively complex tasks.

b) Humans by way of text editors or another class of configuration
systems, such as SWAT and to some degree webmin.

c) packages that need a service from other packages. This includes

  i) packages that use ldap as a service and needs to add a schema and
     perhaps a user and corresponding ACL's. 

 ii) packages that use apache to share a directory of files

iii) packages that use samba to share a directory of files.

 iv) packages that use a superserver to provide network services and
     need to add a line to inetd.conf.


Case c) is well covered by section 10.7.4 of Debian policy, which
explains that the package that needs to be configured (slapd, apache,
samba, and inetd in the examples above) should provide means for adding
these commonly needed things to their configuration. slapd will have
this shortly (pending acceptance from Debian), apache supports it to a
certain degree (you can stick stuff in /etc/apache2/conf.d, but as soon
as you add virtual hosts to the mix, it gets hairy very quickly), samba
has it to a certain degree ("net share" or "net usershare" do this, I
think, but don't provide the same flexibility as you get by editing
smb.conf), (most of) the inet-superservers support it by using the
update-inetd package.

Case b) is also reasonably covered by policy (particularly sections 6.7
and 10.7.3).  Humans are allowed to change their system's configuration
files and dpkg will try to do the right thing on upgrades, etc. SWAT is
your text book example of config file <-> HTML form conversion tool. It
presents you with the entire set of configuration options from samba in
a sort-of GUI.  It doesn't really simplify anything, it just presents
the configuration file to the user in a (for some) more accessible way.
In essence, this is no different than having the user edit the
configuration file directly with a text editor.

Case a) is what is causing me grief. IMO it is not covered by policy at
all. To see it from the perspective of the package that we want to
configure, we take Samba as an example. Now, it's sensible to provide a
simple way to add extra shares or extra users and such to Samba. It's
not very sensible to provide a simple way to change the core behaviour
of Samba, since this is not something most other packages should
reasonably need.  Also, it's in the very nature of these configuration
systems to simplify complex tasks:

eBox can be instructed to use Samba to run as a PDC providing roaming
profiles to users, and all that jazz.  Let's look at this as an example.
Even though the user might have previously manually edited smb.conf to
do something special, he has now told eBox to set it up as a PDC,
providing roaming profiles to users and all that jazz.  Most of you will
know that there isn't a "PDC with roaming profiles and all that jazz =
true" option in smb.conf.  Doing this is a fairly complex process
involving setting samba to use the LDAP user database that eBox has set
up, put up a [homes] share with sensible permissions.  making a
[netlogon] share, setting the logon options, etc.  Certain combinations
of configuration options in smb.conf don't work together at all or may
just cause unexpected behaviour, so it's not just a simple question of
*adding* things to the configuration. It might very well also require
*removing* things to make Samba do as it's been told, which is to
provide a PDC with roaming profiles and all that jazz.

Anyone who has worked with samba knows how difficult it can be to look
at a smb.conf and predict how it will act in the wild. The amount of
variables is huge, so taking a user's smb.conf and only doing the
minimal necessary to get to the point where it acts as a PDC providing
roaming profiles and all that jazz is a task I doubt even the samba
developers would take upon them.

Now, the problem diminishes somewhat if eBox (or a similar tool in a
similar situation) had provided the config file to begin with. It would
be trivially easy to see if the user had made any changes himself and if
so, give the user a choice to manually try to incorporate the changes
eBox would have done, overwrite his changes, or not do a anything at
all. I don't belive it's feasible to intelligently handle this
automatically and still with a clear conscience be able to tell the user
that "Yes, your system is now running as a PDC, because you told me to
make it so". Too many variables.

However, given the way Ubuntu (and Debian) package dependencies work,
it's pretty much impossible for me to tell whether a package has been
installed due to being in the dependency chain of an eBox module, or if
it's been manually installed at an earlier time.  In the former case,
the user is likely to want to use eBox to configure the package.  In the
latter, there's a chance the user had made certain changes to the config
file (or perhaps has chosen that he is happiest with the default
config).

It's also relevant to note that changing a setting in the Samba
configuration in eBox could translate into changing settings in many
different configuration files (libnss-ldap.conf, smbldap.conf, and
smb.conf all in one go).

Samba configuration is a problem due to its complexity.  E.g. ntp.conf
is a different issue: It's a conffile.  A user who has edited it should
be prompted about changes to it on upgrades.  However, in order to stick
to Debian policy, no tool is allowed to touch ntp.conf. This is quite a
conflict of interest.  On one side of the fence, there's the clever
admin who has hand crafted his ntp.conf and wants to take care of it
manually on upgrades and likes the way dpkg does that because it's a
conffile.  On the other side, there's the not quite as clever admin who
wants to use a tool to configure it, but no such tool must be in the
archive since it wants to change a conffile.   This is clearly a
different issue than in the Samba example, but also a *very* relevant
one to me.

In the case of Samba, would it be alright if I just didn't touch
anything at all until the users has actively accepted it in the web UI?
One could argue that he has accepted it already since he installed the
Samba module of a configuration framework, but let's not go there.

In the case of ntp.conf, I have no clue what to do. For anyone not using
a tool to fiddle with it, it's best to keep it as a conffile. For anyone
using a tool... well, noone should be doing that, since it would be
against policy to have such a tool.

Wow, that turned out long. I hope it's a bit more comprehensible than my
last e-mail.

-- 
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/20070803/03f6ae22/attachment.pgp