[Kolab-devel] Extending Kolab
Gunnar Wrobel
wrobel at pardus.de
Mon May 19 10:16:42 CEST 2008
Hi Mike,
Mike Gabriel <m.gabriel at das-netzwerkteam.de> writes:
> 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...
I admit I don't know cfengine but I read bits and pieces of puppet
vs. cfengine on the web:
- http://reductivelabs.com/trac/puppet/wiki/CfengineVsPuppet (this
one is from the puppet wiki though so it has to be pro-puppet)
- http://lists.apple.com/archives/macos-x-server/2007/Jul/msg00249.html
- http://watzmann.net/blog/index.php/2006/12/19/puppet_is_not_cfengine_rewritten_in_ruby
There are other reasons that lead me to believe that puppet is the
superior choice.
>
> in general: deploying system admin tools like puppet or cfengine i
> consider to be a really good idea!!!
Good to know :)
Cheers,
Gunnar
>
> 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
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
--
______ 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 <<
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
More information about the devel
mailing list