[Kolab-devel] On the road to Kolab 3.0

[Jeroen van Meeuwen (Kolab Systems)]

On 2011-12-12 10:02, Del wrote:
> Thanks for you comprehensive answer.
>

Hi Del,

> On Monday, December 12, 2011 10:10:04 AM Georg C. F. Greve wrote:
>> As to the two components you were talking about, they are obviously
>> unrelated, so need to be viewed separately. The web admin is 
>> hard-coded
>> against a whole set of assumptions, including a particular LDAP 
>> layout &
>> schema which makes it very hard to use this in the future.
>
> Indeed. There are some patches to include Samba functionality, but 
> that only
> underlines the point. I am pretty sure easy and flexible set-up og 
> LDAP, if
> attained, will be a major selling point for Kolab. Low threshold 
> admin tools
> for LDAP is missing in general.
>

My target is to have Kolab completely "not care" what kind of LDAP tree 
you use. Whether it's OpenLDAP or something Netscape-based like Sun 
Directory Server or 389 / Red Hat Directory Server, Kolab really should 
not care at all.

That is to say, naturally there's parts of Kolab that do care, but it 
should primarily be positioned so that it consumes the directory tree, 
and only consumes it (i.e. perhaps extending to Kolab itself not even 
having any write-permissions).

This would allow Kolab not only to better integrate with existing 
infrastructures, but also allow Kolab to better integrate with solutions 
such as GoSA, which themselves ship a web interface for user/group and 
other administrative tasks. In addition, this level of agnosticity will 
allow Kolab to have the LDAP tree layout (or, better yet, the 
authentication and authorization database technology and model) be 
defined for any use-case (think, for example, "hosted").

In order to achieve this, two things have happened or are happening as 
we speak, both of which allow for great opportunity for people to 
contribute;

1) I have developed pykolab[1], which already includes a Kolab daemon 
to synchronize between one or more LDAP servers and one or more IMAP 
servers in a manner that is compatible with a Cyrus IMAP Discrete 
Murder. One of the next steps is to throw this daemon at a 2.3 Kolab 
server's LDAP tree. This could be a great opportunity for people to 
contribute, in code review, testing, documentation as well as 
development. Part of said documentation is in the form of a draft, 
informational KEP I'm trying to spend some time on every once in a 
while[2].

It also includes an SASL authentication daemon, primarily for 
multi-domain setups, where multi-domain is to be interpreted as multiple 
"hosted" domains more so then a domain example.net corresponding with 
the same LDAP tree in use for example.org (which I consider a 'domain 
alias', and not so much a 'separate domain' if you know what I mean).

Furthermore, a tool-chain is provided

2) The Kolab Web Administration Panel is going to be split in two major 
parts, one of which can be made available to a Kolab Groupware 
deployment separately from the other. These parts are the client-facing 
web interface ("clickydiclick"), which is "optional", and an API[3]. 
These two components are subject to the full flux of design and 
development today, and could also be a great opportunity for people to 
contribute, again in code review[4], testing, documentation[4] as well 
as development.

A third topic is popping up on the horizon as well. Its title is 
configuration management. I want to re-think the template-based 
mechanism, and I want us to consider a series of scalable, secure 
configuration management suites out there, like Puppet, Chef, CFEngine, 
and others. I myself am strictly (biased towards) Puppet, but I also 
want to explore opportunities to make it so that a simple, small, 
single-server Kolab deployment does not immediately require one to get 
familiar with the nitty and gritty details of a fully featured 
configuration management suite. This too is a topic in full flux right 
now, and help in designing, developing, testing and documenting one or 
more solutions could again be great opportunity for people to 
contribute.

Kind regards,

Jeroen van Meeuwen

[1] http://git.kolab.org/pykolab
[2] http://wiki.kolab.org/User:Kanarip/Draft:Kolab_Account_Types
[3] 
http://wiki.kolab.org/index.php?title=User:Bruederli/Draft:Kolab_Webadmin_API
[4] (temporary location) http://git.klab.cc/vanmeeuwen/kolab-wap/
[5] 
http://hosted.kolabsys.com/~vanmeeuwen/kolab-docs/en-US/Kolab_Groupware/2.4/html/Architecture_and_Design/sect-Architecture_and_Design-Administration_Panel-Web_Administration_Panel_API.html

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08