[Kolab-devel] [pkg-kolab] TODO-list for Kolab in wheezy

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Sun Apr 17 14:16:20 CEST 2011


Mathieu Parent wrote:
> Hi,
> 

Hi Mathieu,

> >> 4. move kolab_bootstrap from slapd.conf to cn=config
> > 
> > can you give me more details about this?
> 
> The long-term solution would be to modify the ldap tree directly
> and/or use "ldap_*" and "slap*" commands. This is [issue3000]. I'm
> cc-ing kolab-devel, as this is where it should happen.
> 

I second the motion to have LDAP configuration move away from file-based 
changes only upon service reload/restart (kill -HUP included).

A common location for application configuration is often cn=<application 
name>,cn=config. This location is usually read-only for the application only, 
as it usually requires to obtain data from this location only, and read-write 
for any administrative security group.

> Pros:
> - compliant with upstream openldap recommendations

And consistent with many -not to say all- other LDAP directory server 
technologies I'm aware of.

> (...snip...)
> 
> Cons:
> - Difficult: how to bootstrap?

Let's consider setting up LDAP and setting up Kolab (perhaps using that LDAP) 
as two separate tasks.

I think the Kolab bootstrapping all of a sudden becomes a lot easier 
(integrate with existing LDAP tree, period).

The question then becomes whether a bootstrapping of OpenLDAP is then really 
so problematic?

> - kolabconf gains complexity (not doing only file-based configuration)
> 

I think it's reasonable to require OpenLDAP >= x.y with a certain X.Y Kolab 
release.

That said, as far as kolab-conf is concerned, wouldn't it want to *consume* 
the settings in LDAP only, whether it writes out a configuration file for LDAP 
or not?

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

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

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/devel/attachments/20110417/a22de121/attachment.html>


More information about the devel mailing list