Kolab + GOsa debugging

[Alejandro Bednarik]

 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
>


-- 
 Alejandro Bednarik
 XTech - Soluciones Linux para Empresas
 (011) 5219-0678
 alejandro at xtech.com.ar