[Kolab-devel] Extending Kolab

[Gunnar Wrobel]

Bernhard Reiter <bernhard at intevation.de> writes:

> On Monday 19 May 2008 08:42, Gunnar Wrobel wrote:
>> What do people think?
>
>
> At first sight using puppet sounds too complex in itself.
> Its complexity will be a legacy and might eat up the advantages it promisses.
>
> Some of the advantages you gave are not really understood from my side.
> I guess I would need to understand better what the problem with Kolab 
> Server/Gentoo integration is. 
> Simplicity certainly is a big plus for kolabconf.

So let me elaborate...

What is the intended task of kolabconf?

Its purpose is to automatically configure any package that is part of
the Kolab server and requires configuration.

To this aim a central concept has been implemented: Templates are
being rewritten to the final configuration files using parameters from
LDAP or central Kolab configuration files.

As you mention this is a simple concept and thus has certain
advantages. The templating language used by kolabconf is also simple
and can be easily understood by any user.

The question is if simple is enough at this point.

Lets focus on the task of kolabconf. Is "configuring any package for
the Kolab server" actually being delivered by the template concept
realized within kolabconf?

Well, not completely...

If we look at the code we see that there are certain exceptions.

Postfix for example needs rebuilding of its map tables after writing
an updated table. So we have the postfix specific functions
buildPostfixTransportMap() and buildPostfixVirtualMap().

Taking our original aim of "configuring any package" into account this
is clearly a hack as we start implementing a single exception rule
from our main concept.

Of course it is possible to accept a hack once in a while because
there exist many situations where a more general solution to a
structural problem would be too much overhead.

But then again the postfix hack is not the only one.

There are also the OpenLDAP configuration hacks (buildLDAPAccess() and
buildLDAPReplicas()) as well as the Cyrus workaround for the group
definition file (buildCyrusGroups()).

And then there is the problem of service restarts after rewriting the
configuration files. This is less funny as each package providing a
service gets a specific line for restarting the service.

At this point one certainly has collected enough hacks to start asking
if the original concept actually matches the problem at hand.

Nevertheless, I agree, it can be solved that way. The hacks have been
in there for years, they worked and keep kolabconf kind of simple.

But this is only okay as long as one focuses on running Kolab on
OpenPKG.

So let's leave the OpenPKG world and move over to Kolab on Gentoo:

The postfix hack is something that does not work on Gentoo.

The service restart is also something that won't work as the init
system on Gentoo has a syntax that does not match the one of
OpenPKG. I expect there are similar problems on other distributions.

Both problems can be solved with patching and it has been working on
Gentoo for a while.

What cannot be handled with kolabconf is the fact that the user can
choose package versions on Gentoo. A user can for example choose to
install OpenLDAP-2.3.* OR OpenLDAP-2.4.*. For postfix it can be 2.2.*,
2.3.*, 2.4.*, or 2.5.*. 

As said before kolabconf does not know anything about versions and
will always configure for one of the two options. Writing templates
designed for OpenLDAP-2.3.* when OpenLDAP-2.4.* is obviously
problematic.


If one considers package configuration in general it is obvious that
rewriting templates into configuration files is not enough to fulfill
the promise of configuring any package for the Kolab server. Often
there are additional mechanisms required to fully and correctly
configure a package.

That is a problem that we would definitely hit when we try to extend
the Kolab server: Adding additional packages that should be configured
automatically will sometimes face similar problems as postfix, cyrus
or openldap now: Mechanisms beyond template rewriting will be
required.

Puppet provides all that in a clean fashion. None of the hacks
described above would be necessary. In addition puppet would enable us
to do a lot in the area of extensions.

Take munin as a server monitoring tool for example. 

Richard is running Kolab on Suse. One day he is searching for
monitoring tools, finds munin and starts configuring it for his Kolab
server. He establishes it as a small puppet module. Once he is done,
he uploads the module to a central repository.

Gunnar, running Kolab on Gentoo, sees the new module, also requires a
monitoring tool for his Kolab, downloads the module, runs it (maybe
fixes a few Gentoo specific things), resubmits to the repository.

After several months of testing the module is also made available for
the Kolab server on OpenPKG.

This is possible with puppet right here, right now.

Cheers,

Gunnar

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~