[Kolab-devel] Kolab + OpenLDAP

[Diane Trout]

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.

----start of modified ldif----
dn: cn=kolab2,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: kolab2
####################
# kolab attributes #
####################
# kolabDeleteflag used to be a boolean but describes with Kolab 2
# the fqdn of the server which is requested to delete this objects
# in its local store
olcAttributeTypes: ( 1.3.6.1.4.1.19414.2.1.2
  NAME 'kolabDeleteflag'
  DESC 'Per host deletion status'
  EQUALITY caseIgnoreIA5Match
  SUBSTR caseIgnoreIA5SubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
---end example----

> 
> - 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?

> 
> > 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.

> 
> > 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.


> 
> > 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.

> 
> > 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.

Diane