OpenLDAP

[Sergio Talens-Oliag]

El Thu, Mar 05, 2015 at 05:25:54PM +0200, Mihai Badici va escriure:
> On Thursday 05 March 2015 08:55:48 John McMonagle wrote:
> > I know this is a old thread but has anything been done to provide openlap
> > support yet?
> > 
> > I'm still running kolab 2.3.4.
> > We are a debian shop in many cities and 7 ldap servers.
> > Kolab is a small part of our ldap usage and see no rational upgrade path.
> > This is primarily caused by no way to sync between openldap and 389ds.
> > 
> > If I don't hear of a solution I'm going to something else.
> > 
> > John
> 
> If you have your ldap infrastructure it means you have your user's management 
> mechansm.
> You can use elements of kolab but i think even if kolab support openldap by 
> default you cannot use the full suite but instead you can adapt it at yours 
> needs.

As you say, I'm using OpenLDAP with Kolab and Dovecot without the Kolab
administrative tools and I have all I need from LDAP working using only the
schemas distributed with the debian's openldap server package and the ones
provided by Kolab.

My guess is that for a 100% integration between OpenLDAP an Kolab the only
thing needed is one or more additional schemas, but as I'm not using the Kolab
administrative tools with LDAP I haven't looked into that yet and I've just
changed object classes or attribute names for some elements to make things
work.

As an extreme example, when I wanted to test how to manage Resources I looked
into http://docs.kolab.org/architecture-and-design/ldap.html#a-kolab-resource
for the needed objectClasses:

  objectClass: top
  objectClass: kolabsharedfolder
  objectClass: mailrecipient

but there is no 'mailRecipient' objectClass in my schemas and the closest one
('inetLocalMailRecipient') does not include the 'mail' attribute, so I ended
up using the following:

  objectClass: kolabGroupOfUniqueNames
  objectClass: kolabSharedFolder
  objectClass: device
  objectClass: top

With those classes I'm able to set all the required fields without adding
additional schemas.

The problem in this case is that we need a primary objectClass that allows us
to use all the interesting attributes (i.e. the 'mail' attribute) but does not
force us to add additional attributes that we don't want; luckily the 'device'
class fixed that for me, at least for testing (as I'm not using resources in
production right now I didn't dig deeper).

Of course the right fix is to add an schema with the right definition of
'mailrecipient', maybe that can be a goal for kolab 3.5 ... ;)

Greetings,

  Sergio.

-- 
Sergio Talens-Oliag <sto at iti.es>               <http://www.iti.es/>
Key fingerprint = FF77 A16B 9D09 FC7B 6656 CFAD 261D E19A 578A 36F2