Kolab + GOsa debugging

Mark Pavlichuk pav5088 at internode.on.net
Tue Oct 28 13:55:56 CET 2008


  I'm trying to get GOsa (a GUI to manage LDAP based services) to 
coexist with Kolab.  GOsa ships with its own custom kolab2.schema based 
on v1.22 instead of the v1.27 version that ships with Kolab currently.

  Slapd won't start...  The error message slapd gives is here : 
http://lists.alioth.debian.org/pipermail/pkg-kolab-devel/2008-October/001829.html

  There is more relevant info, file contents etc... in the thread 
following that message.

  Unfortunately my LDAP skills are weak, and although I think I've 
tracked the problem to a particular part of the GOsa supplied schema I 
don't know how to fix things.  The latest post in the thread follows 
(Cajus is the lead GOsa developer) :

Cajus Pollmeier wrote:
> Am Monday 27 October 2008 07:51:06 schrieb Mark Pavlichuk:
>   
>>   Neil Price from the pkg-kolab-devel mailing list has some queries
>> about the GOsa kolab2.schema file :
>>
>> Price,Neil wrote:
>>     
>>>>   I did a grep for 1.3.6.1.4.1.19414.3.2.5 and it's part of
>>>> kolab2.schema.  Fabian Hickert earlier brought my attention
>>>> to the fact
>>>> that I needed to replace the Kolab provided schema with a
>>>> GOsa provided
>>>> version.  The Kolab provided version contains :
>>>>
>>>> objectclass ( 1.3.6.1.4.1.19414.3.2.5
>>>>   NAME 'kolabGroupOfNames'
>>>>   DESC 'Kolab group of names (DNs) derived from RFC2256'
>>>>   SUP groupOfNames STRUCTURAL
>>>>   MAY ( mail $
>>>>         kolabDeleteflag ) )
>>>>
>>>>   The GOsa provided version is slightly different :
>>>>
>>>> objectclass ( 1.3.6.1.4.1.19414.3.2.5
>>>>   NAME 'kolabGroupOfNames'
>>>>   DESC 'Kolab group of names (DNs) derived from RFC2256'
>>>>   SUP top AUXILIARY
>>>>   MAY ( mail $
>>>>         kolabDeleteflag ) )
>>>>         
>>> Thats does not look right. The Kolab one inherits from groupofnames but
>>> the Gosa one inherits nothing. Its also AUXILIARY which means (AFAIK)
>>> that it cannot be used in a DIT, its only intended for creating other
>>> objectclasses.
>>>
>>> You are also not supposed to mess with these definitions, they are
>>> registered with IANA and are supposedly globally unique.
>>>
>>> Maybe go back to Fabian and ask him to explain the logic behind the
>>> change.
>>>       
>
> The modifications are done by reason. The kolab schema doesn't allow bundling 
> with ordinary group of name objects - which is bad from our point of view.
>
> Be sure that you include our schema files (kolab + rfc) and your slapd should 
> start. We're using these for our productive systems - so it works.
>
> Cajus
>   
-- 
Mark Pavlichuk
Strategic IT
ph. (07)47242890
m. 0409 124577




More information about the users mailing list