[pkg-kolab] Kolab + GOsa debugging

[Mark Pavlichuk]

  Well, I have an answer...  but it's almost midnight here so I'll give 
this a try tomorrow.  BTW, any ideas as to why the cyrus acl stuff is 
commented out?

Alejandro Bednarik wrote:
>  Hi Mark. In /kolab/etc/kolab/templates/slapd.conf.template below
> /kolab/etc/openldap/schema/inetorgperson.schema add
>
> include         /kolab/etc/openldap/schema/nis.schema
> include         /usr/share/gosa/contrib/openldap/samba3.schema
> include         /usr/share/gosa/contrib/openldap/goconfig.schema
> include         /usr/share/gosa/contrib/openldap/gofirewall.schema
> include         /usr/share/gosa/contrib/openldap/gosystem.schema
> include         /usr/share/gosa/contrib/openldap/gofon.schema
> include         /usr/share/gosa/contrib/openldap/goto.schema
> include         /usr/share/gosa/contrib/openldap/goto-mime.schema
> include         /usr/share/gosa/contrib/openldap/gofax.schema
> include         /usr/share/gosa/contrib/openldap/goserver.schema
> include         /usr/share/gosa/contrib/openldap/gosa+samba3.schema
> include         /usr/share/gosa/contrib/openldap/trust.schema
>
> and in /kolab/etc/openldap/schema/kolab2.schem comment this entry:
>
> # cyrus imapd access control list
> # acls work with users and groups
> #attributetype ( 1.3.6.1.4.1.19414.2.1.651
> #  NAME 'acl'
> #  EQUALITY caseIgnoreIA5Match
> #  SUBSTR caseIgnoreIA5SubstringsMatch
> #  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
>
> Also, if after this and run kolabconf, you still have problems, you should
> check in /kolab/etc/openldap/schema/kolab2.schema this entry
>
> objectclass ( 1.3.6.1.4.1.19414.2.2.9
>   NAME 'kolabSharedFolder'
>   DESC 'Kolab public shared folder'
>   SUP top STRUCTURAL
>   MUST cn
>   MAY ( acl $
>         alias $
>         cyrus-userquota $
>         kolabHomeServer $
>         kolabFolderType $
>         kolabDeleteflag ) )
>
> and delete "acl $".
>
> Hope this help. Cheers!
>
> Mark Pavlichuk wrote:
>   
>>   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
>>
>> _______________________________________________
>> Kolab-users mailing list
>> Kolab-users at kolab.org
>> https://kolab.org/mailman/listinfo/kolab-users
>>
>>     
-- 
Mark Pavlichuk
Strategic IT
ph. (07)47242890
m. 0409 124577