[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
---------------------------------------