[Kolab-devel] Extending Kolab

Mike Gabriel m.gabriel at das-netzwerkteam.de
Mon May 19 09:35:58 CEST 2008 

hi gunnar,

you probably also know cfengine (which sounds like an alternative to  
puppet). i do not know puppet, but i know cfengine really well and it  
is a powerful tool indeed (www.cfengine.org).

cfengines strenghts are

   (a) the ability to scale well in huge heterogenous networks
   (b) the ability to detect host/network irregularities (cfenvd)

maybe there is someone on this ether-frequency who knows both tools  
and can compare their strengths und weaknesses...

in general: deploying system admin tools like puppet or cfengine i  
consider to be a really good idea!!!

best,
mike



Quoting Gunnar Wrobel <wrobel at pardus.de>:

> 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 <<
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 

das netzwerkteam
mike gabriel, hamburger chaussee 240, 24113 kiel

fon: +49 431 64 74 196
voip/voicemail: +49 431 643 643 6
fax: +49 431 64 74 276
mail: m.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

More information about the devel mailing list