Re: Kolab + OpenLDAP

On 2013-01-22 17:37, Diane Trout wrote:
> On Tuesday, January 22, 2013 12:03:45 Jeroen van Meeuwen wrote:
>> On 2013-01-22 06:31, Diane Trout wrote:
>>> Hi,
>>> 
>>> I made an attempt to run Kolab using OpenLDAP.
>>> 
>>> The kolab.ldif that you're shipping isn't quite compatible with how
>>> openldap
>>> likes their schema files. (I can provide the altered kolab2.ldif if
>>> you'd like)
>> 
>> I'm assuming you're speaking about the .schema vs. the standard .ldif
>> files format. Have you looked at the files we actually provide at
>> http://git.kolab.org/kolab-schema/tree/?
> 
> I definately know OpenLDAP wants schema files to use olcAtributeTypes 
> and
> olcObjectClasses. I modified the dn, and added the objectClass: 
> olcSchemaConfig
> and cn: kolab2 because all their provided schema files used that 
> format.
> 

Right, so do we need an OpenLDAP-specific copy of our schema in 
git.kolab.org/kolab-schema?

>> - That is where we best store enabled domain name spaces for Kolab,
>> - That is where VLV/SSS configuration can be detected.
> 
> What is VLV/SSS?
> 

Virtual List View[1] and Server-Side Sorting[2]

[1] http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09
[2] http://tools.ietf.org/html/rfc2891

>>> I disovered that kolab wanted a domanRelatedObject and I didn't want
>>> to figure out how to create a cn=kolab,cn=config tree. so I attached 
>>> it to the
>>> root object for my ldap tree.
>> 
>> These are actually settings (see
>> http://git.kolab.org/pykolab/tree/conf/kolab.conf#n95), though I 
>> reckon
>> the web administration panel refers to 'domainrelatedobject' in some
>> places.
> 
> I discovered it wanted domainrelatedobject by looking at the LDAP 
> logs, so it
> is doing that search.
> 

Most of pykolab's interactions with LDAP are subject to configuration, 
though.

I think you must have found an LDAP log entry caused by the web admin, 
because other software uses something along the lines of 
(associateddomain=%s) or (associateddomain=*) - associateddomain being 
an attributetype to a domainrelatedobject objectclass though.

One could set up kolabd so that it polls 'ou=Domains' for 
'cn=domain.tld', and it would merely be the webadmin that requires the 
enhancement of allowing the specification of the objectclass(es) to use.

>>> Also it crashes if you set unique_attribute to entryUUID as pykolab 
>>> is
>>> assuming all attribute names are lower cased.
>> 
>> Supply the configuration value in all lower-case, please.
> 
> I figured that out, though it took a while. The error was an key 
> exception
> because it couldn't find entryUUID. It might be nice if some earlier 
> component
> either fixed the case, issued a warning, or there was an occasional 
> assertion
> that would error out on mixed case configuration files.
> 

Sure, I suppose this could be done in check_setting_*() callbacks in 
pykolab/conf/__init__.py, like we already execute them for CLI options.

>>> With all those changes from 0.5.11 packages:
>>> 
>>> kolabd -l debug -d 9 runs without sleeping
>>> kolab-webadmin can login but only shows the "About" button.
>> 
>> Do you have mozldap utilities "ldapsearch" installed, and if so, in
>> what location do they reside?
> 
> I just have the openldap ldap-utils package. I looked in the lxc 
> container
> with your installed packages and discovered the mozldap-tools package.
> 
> I'll have to investigate that.
> 

It's the mozldap-tools that have the necessary extensions to get to 
effectiverights, and it is them the web admin API will want to execute.

>>> roundcubemail seems to work fine (browsed mail, created a contact,
>>> viewed
>>> calendar).
>> 
>> It'd be lovely if we also had your notes on initially installing
>> OpenLDAP, and creating the default tree / setting the appropriate 
>> ACLs,
>> noted that in 389 DS, we can change these aspects in real-time, 
>> whereas
>> I recall OpenLDAP may still require us to put some files on the
>> filesystem and reload/restart the service.
> 
> OpenLDAP switched to configuration in ldap with 2.3. With 2.4 they 
> actually
> include checksums on their plain text configuration files to
> discourage you from
> modifying them by hand. e.g. to add a new schema I did:
> 
>    ldapadd -a -Y EXTERNAL -H ldapi:///  -f /tmp/rfc2739.ldif
> 
> Though they haven't implemented an easy way to delete or renumber 
> schema
> entries through ldap. It appears you still need to rm the file from
> /etc/ldap/slapd.d/cn=config/cn=schema.
> 
> I'll try to make coherent notes once I get enough working.
> 

Thank you, once we have a process that can be automated, it should be 
pretty simple and straightforward to allow a setup-kolab procedure to 
take a --with-ldap=openldap / --with-openldap.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

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

pgp: 9342 BF08