Hello all,
i tried to update an openldap server from 2.2.13 to 2.3.27 but ran into problems. The slapd is using back-sql to get data from an existing PostgreSQL groupware database. This worked fine with the 2.2 version, but after the update the client (Thunderbird in my case) no longer gets data. According to wireshark, no data is sent back to the client.
Testing with a local ldapsearch brings results, but with the following differences:
----- 2.2.13 ----- objectClass: orgPerson objectClass: inetOrgPerson objectClass: officePerson objectClass: evolutionPerson objectClass: top objectClass: opengroupwareentity objectClass: person ----- 2.2.13 -----
----- 2.3.27 ----- objectClass: person objectClass: evolutionPerson objectClass: inetOrgPerson objectClass: opengroupwareentity objectClass: top ----- 2.3.27 -----
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 -----
Has anybody an idea why the ldapsearch returns fewer entries for the objectClass? That should be the reason, why no data is sent back to the client.
Kind regards
Andreas 'ads' Scherbaum wrote:
Hello all,
i tried to update an openldap server from 2.2.13 to 2.3.27 but ran into problems. The slapd is using back-sql to get data from an existing PostgreSQL groupware database. This worked fine with the 2.2 version, but after the update the client (Thunderbird in my case) no longer gets data. According to wireshark, no data is sent back to the client.
Testing with a local ldapsearch brings results, but with the following differences:
----- 2.2.13 ----- objectClass: orgPerson objectClass: inetOrgPerson objectClass: officePerson objectClass: evolutionPerson objectClass: top objectClass: opengroupwareentity objectClass: person ----- 2.2.13 -----
----- 2.3.27 ----- objectClass: person objectClass: evolutionPerson objectClass: inetOrgPerson objectClass: opengroupwareentity objectClass: top ----- 2.3.27 -----
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 -----
Has anybody an idea why the ldapsearch returns fewer entries for the objectClass? That should be the reason, why no data is sent back to the client.
ldap_objectclass_list is not used by back-sql; I guess you mean ldap_entry_objclasses (unless you modified the source yourself).
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.
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 ---------------------------------------
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
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 ---------------------------------------
openldap-software@openldap.org
-
Andreas 'ads' Scherbaum -
Pierangelo Masarati