[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.
> 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.
Thank you for your help
--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)