> 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: [EMAIL PROTECTED] ---------------------------------------
