[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Problem with back-sql after update from 2.2 to 2.3



> On Thu, 09 Aug 2007 09:22:59 +0200 Pierangelo Masarati wrote:
>
>> Andreas 'ads' Scherbaum wrote:
>> >
>> > The 'ldap_objectclass_list' table contains the following entries:
>> >
>> > ----- cut -----
>> > OGo=# select * from ldap_objectclass_list;
>> >  oc_map_id |     objectclass
>> > -----------+---------------------
>> >          1 | orgPerson
>> >          1 | inetOrgPerson
>> >          1 | officePerson
>> >          1 | evolutionPerson
>> >          1 | top
>> >          1 | opengroupwareentity
>> >          3 | top
>> >          3 | opengroupwareentity
>> >          4 | top
>> >          4 | domainRelatedObject
>> > (10 rows)
>> > ----- cut -----
>>
>> [...]
>>
>> ldap_objectclass_list is not used by back-sql; I guess you mean
>> ldap_entry_objclasses (unless you modified the source yourself).
>
> ldap_entry_objclasses is a view in this case and is using (among
> others) the ldap_objectclass_list table.

OK.

>
>
>> In any case, I note that the missing objectclasses, namely orgPerson and
>> officePerson, are not standard track types.  Are they defined anywhere
>> in the schema?  One of the differences between 2.2 and 2.3 is a stricter
>> checking of the schema.
>
> The problem seems to be:
>
> slapd is searching the "objectClass" attributes and is getting back 6
> values.
> Since the result is ordered by name, the first one is: evolutionPerson.
> This leads to the following error in the debugging log:
>
> ----- cut -----
> ldap_log_execute_01.log:slapd[10928]:
> backsql_id2entry(opengroupwareid=10101,ou=Contacts,ou=Addressbook,dc=home):
> computed structuralObjectClass evolutionPerson does not match objectClass
> person associated to entry
> ----- cut -----
>
> After removing 'evolutionPerson', 'inetOrgPerson', 'officePerson' and
> 'orgPerson'
> from oc_map_id=1, this error vanished and Thunderbird is getting data
> again.
>
> More tests will follow to make sure, this really was the error.

Probably you set up the meta-data so that persons are based on the
"person" objectClass.  The ldap_entry_objclasses table was intended to add
AUXILIARY objectClasses, not STRUCTURAL ones.  If this is the case (I need
to check the code a little bit more) and "evolutionPerson" is derived from
"person", then the check in back-sql might be sort of overshooting and
needs to be relaxed.  In any case, now that the problem has been narrowed
down, I think you should file an ITS <http://www.openldap.org/its/> so
that we can keep track of its evolution.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it
---------------------------------------