[Kolab-devel] Extending Kolab

[Gunnar Wrobel]

Gunnar Wrobel <wrobel at pardus.de> writes:

> Bernhard Reiter <bernhard at intevation.de> writes:
>

[...snip...]

>
>>  Of course I am still looking forward to your proposal. :)
>
> Will come in few weeks ;)

A while ago I mentioned that I am working on a suggestion on how to
solve Kolab server extensions. By now I am convinced that this
solution would work fine and so it is time to discuss this in detail.


Let me give you some background first:

The native Kolab Server port to Gentoo has always been problematic in
two areas: 

 1) The Kolab specific patches to imap c-client, php, as well
    as cyrus-imapd 

 2) kolabconf.

The patch situation has been resolved by now but kolabconf is still
something that simply does not work on Gentoo.

The Kolab server has been established for OpenPKG because the
developers were able to control many crucial parameters within the
OpenPKG system while still being able to install the server on many
different base distributions. A crucial point about OpenPKG is the
ability to specifically fix the version of a package. The user is
bound to use the package version prepared by the developers and the
installed package will provide all required features.

Concerning that point Gentoo is living on the other side of the
spectrum. As a more developer oriented distributions it allows its
users to choose between different versions of a package and provides
the means to easily switch package features on or off.

It is a dangerous game to configure such a system with kolabconf since
it is agnostic of package versions and assumes that the base system is
providing a defined set of features.

While it still worked surprisingly well for educated users I know I
will never be able to bring this kind of system into the main Gentoo
CVS system as I'd be violating a number of reasonable quality
constraints.


A possible solution:

p at rdus has had its own configuration system for the last couple of
years. I actually intended to marry this system with kolabconf as the
combined solution would have solved most of the problems I see with
kolabconf.

Luckily I blogged about this and got a comment that this would be a
stupid idea as such a tool is already availble:

 puppet (http://reductivelabs.com/trac/puppet)

During the past months I have been working on converting major parts
of the Kolab server configuration into puppet and by now I am
convinced that it solves my problems for Kolab2/Gentoo.

In addition - and that is why I am writing this mail - it would solve
most of the problems with extending the Kolab server configuration. As
a bonus we would get rid of the FAQ "I did modify
/kolab/etc/apache/apache.conf and suddenly all my changes are gone."


What does puppet do?

puppet provides a language for specifying system configurations. That
also includes a templating machinery and so some basic concepts of
kolabconf remain.

The tool itself has been written in ruby which allows to easily extend
it and write plugins for it. In fact you have to do that to cater for
all aspects of the Kolab server.

I will not go into detail as puppet is really complex and I will not
be able to give a complete overview. You can however rest assured that
puppet can do everything kolabconf was able to do. In fact much more
than that.


Some benefits of using puppet:

 1) External tool that the Kolab developers do not need to work on.

 2) Archives old configuration files instead of overwriting them (see
    mentioned FAQ above).  

 3) Support for restarting services as well as running complex
    commands associated to system events.

 4) Would probably allow to integrate automatic upgrade actions.

 5) Stronger templating language.

 6) Much better support for templating across the different native
    Kolab server projects

 7) Works on Kolab2/Gentoo ;)

 8) Full support for Kolab configuration extensions, tweaks and hacks

Let me be a little bit more specific about 8) as this was the main
topic of this thread.


Extending the Kolab server when using puppet:

Kolab2/Gentoo-2.2 will use puppet so let me use that as an example. In
order to use puppet you will have to install the tool itself and in
addition you will need a package that holds the specific Kolab server
configuration (pretty much like kolabd now).

This package is something I am currently establishing at 

 http://pardalys.sourceforge.net/

The relevant puppet modules are at

 http://pardalys.svn.sourceforge.net/viewvc/pardalys/trunk/pardalys/modules/

Right now only "services_ldap" is in there as I'm just starting to
convert my recent hacks into more decent code. Things like
"service_postfix", "service_amavisd" etc. will follow for the other
Kolab server components.

It is quite easy to have additional modules like "service_munin" and
"service_nagios" (which are packages I actually already have in raw
format) which could be provided as experimental packages and would not
get used by the standard Kolab server. It would however be easy for
users to use, develop and share such extensions.

The same holds true for extensions like greylisting. These require
modifications to core Kolab server templates. With the puppet way of
configuring the system it would be trivial to mark these as
experimental and still distribute them to the users.


What do people think?

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