Kolab 2.4 on Mageia

[Jeroen van Meeuwen]

On Tuesday, May 15, 2012 08:18:24 PM Richard wrote:
> Op dinsdag 15 mei 2012 19:05:16 schreef Jeroen van Meeuwen (Kolab Systems):
> > > One thing to add, could the change from 389 to openldap (I read
> > > somewhere, don't remember where though).
> > 
> > Sorry, this doesn't parse... "could the change from (...) to (...)"
> > what?
> 
> The change from the currently used ldapserver "389-*" to openldap be added.

Still doesn't make sense... but I'll speculate a couple of lines of thought on 
the matter of 389 Directory Server vs. OpenLDAP.

Both because I'm intimately familiar with 389 Directory Server, and because it 
offers a variety of features that are relevant to Kolab both as a solution for 
Groupware needs as well as a commercial product, when I needed to re-factor 
(re-implement) the Kolab daemon to become more flexible and allow for better 
integration, I choose Red Hat Directory Server - of which 389 DS is the free-
of-charge version (both are Free Software) - as my reference implementation.

One new daemon, a part of a larger set of code, fewer Kolab LDAP schema 
extensions and a web admin interface later, I'm now in the process of making 
all these things work based on an OpenLDAP directory as well.

I'm closing in, but OpenLDAP is lacking a couple of features. It doesn't seem 
to support persistent search control, and the syncrepl module isn't loaded by 
default (the latter impacts setup significantly). The code is already set up 
so that it uses an ordered list of supportedControls it queries the server for 
(persistent search, syncrepl, paged search and vlv[1]).

OpenLDAP also lacks the required support for effective rights as well, and it 
doesn't expose or doesn't seem to expose access control attributes to entries 
unless looked for in some seemingly arbitrary location in the tree... which 
means all authorizations will need to become group membership based - this 
will cause the web admin for one, to make best effort, faithful decisions when 
offering an interface to add/edit/delete entries, with the risk of things not 
turning out the way it was presented in the first place.

Furthermore, OpenLDAP seems to not support searching with an 
(entryUUID=<value>) filter, it's canonical, persistent unique id.

When I started, OpenLDAP did also not support dynamically creating additional 
root dns for isolated Directory Information Trees (a "hosted" scenario if you 
will), but, trickery aside, it seems that it does today.

Long story short; OpenLDAP support is definitely on the roadmap. So is Active 
Directory support, and support for SQL authentication and authorization 
databases, and PAM support. OpenLDAP is at the top of my list.

If anyone is interested, contributions in any form are obviously very much 
appreciated.

Kind regards,

Jeroen van Meeuwen

[1] 
http://git.kolab.org/pykolab/tree/pykolab/constants.py.in?h=pykolab-0.4#n94

-- 
Systems Architect, Kolab Systems AG

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

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/users/attachments/20120516/644e66cd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/users/attachments/20120516/644e66cd/attachment.sig>