We currently use RedHat Enterprise Server 4 and openLDAP 2.2.13 to provide a directory service to Mozilla Thunderbird email clients on our internal network. The information is actually stored in a MySQL Contact Database, so we use back_sql with the necessary translation databases.
We are upgrading our servers to RedHat 5.1, and in the process trying to migrate to openLDAP 2.3.27 (the latest version that RH provides). The application does not work in this release. In fact, if a Thunderbird user tries to do a directory search as before, openLDAP fails. When it fails, it does not write anything to the log explaining why.
The databases, ldap.conf, slapd.conf and odbc.ini are identical in both cases.
I have used an LDAP browser to eliminate some of the variables and do some simple testing to help isolate the problem. What I have found is: - One-level searches work in both releases - Sub-Tree searches work in 2.2.13 and fail in 2.3.27 (causing openLDAP to terminate)
I am not familiar with the code, so I can't be very helpful there, but I did notice the following from the logs:
- One-level search: The details of the log entries are somewhat different for the two releases, but the SELECT DISTINCT statements that actually pick entries from the DB are the same
- Sub-Tree search: The SELECT DISTINCT statements are NOT the same. In both cases, testing was done with a base DN like:
ou=Unit2,dc=company,dc=com
Users use a base DN like this to isolate their directory entries to a particular company Unit.
In 2.2.13, the result is:
Mar 21 17:30:12 apps slapd[11205]: ==>backsql_oc_get_candidates(): oc="organizationalUnit" Mar 21 17:30:12 apps slapd[11205]: ==>backsql_srch_query() Mar 21 17:30:12 apps slapd[11205]: ==>backsql_process_filter() Mar 21 17:30:12 apps slapd[11205]: <==backsql_process_filter() succeeded Mar 21 17:30:12 apps slapd[11205]: <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,ou.id,'organizationalUnit' AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,ou WHERE ou.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND ldap_entries.dn LIKE ? AND 1=1 Mar 21 17:30:12 apps slapd[11205]: Constructed query: SELECT DISTINCT ldap_entries.id,ou.id,'organizationalUnit' AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,ou WHERE ou.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND ldap_entries.dn LIKE ? AND 1=1 Mar 21 17:30:12 apps slapd[11205]: id: '2' Mar 21 17:30:12 apps slapd[11205]: (sub)dn: "%ou=Unit2,dc=company,dc=com" Mar 21 17:30:12 apps slapd[11205]: backsql_oc_get_candidates(): added entry id=2, keyval=3 dn="ou=Unit2,dc=company,dc=com" Mar 21 17:30:12 apps slapd[11205]: <==backsql_oc_get_candidates(): 1
In 2.3.27, the result is:
Mar 21 17:33:38 db slapd[7350]: ==>backsql_oc_get_candidates(): oc="organizationalUnit" Mar 21 17:33:38 db slapd[7350]: ==>backsql_srch_query() Mar 21 17:33:38 db slapd[7350]: ==>backsql_process_filter() Mar 21 17:33:38 db slapd[7350]: <==backsql_process_filter() succeeded Mar 21 17:33:38 db slapd[7350]: <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,ou.id,'organizationalUnit' AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,ou WHERE ou.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3 Mar 21 17:33:38 db slapd[7350]: Constructed query: SELECT DISTINCT ldap_entries.id,ou.id,'organizationalUnit' AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,ou WHERE ou.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3 Mar 21 17:33:38 db slapd[7350]: id: '2' Mar 21 17:33:38 db slapd[7350]: >>> dnPrettyNormal: <ou=Unit1,dc=company,dc=com> Mar 21 17:33:38 db slapd[7350]: <<< dnPrettyNormal: <ou=Unit1,dc=company,dc=com>, <ou=unit1,dc=company,dc=com> Mar 21 17:33:38 db slapd[7350]: backsql_oc_get_candidates(): added entry id=1, keyval=1 dn="ou=Unit1,dc=company,dc=com" Mar 21 17:33:38 db slapd[7350]: >>> dnPrettyNormal: <ou=Unit2,dc=company,dc=com> Mar 21 17:33:38 db slapd[7350]: <<< dnPrettyNormal: <ou=Unit2,dc=company,dc=com>, <ou=unit2,dc=company,dc=com> Mar 21 17:33:38 db slapd[7350]: backsql_oc_get_candidates(): added entry id=2, keyval=3 dn="ou=Unit2,dc=company,dc=com" Mar 21 17:33:38 db slapd[7350]: >>> dnPrettyNormal: <ou=Unit3,dc=company,dc=com> Mar 21 17:33:38 db slapd[7350]: <<< dnPrettyNormal: <ou=Unit3,dc=company,dc=com>, <ou=unit3,dc=company,dc=com> Mar 21 17:33:38 db slapd[7350]: backsql_oc_get_candidates(): added entry id=3, keyval=4 dn="ou=Unit3,dc=company,dc=com" Mar 21 17:33:38 db slapd[7350]: <==backsql_oc_get_candidates(): 3
In 2.2.13, openLDAP isolated the ou to the specific one requested, while in 2.3.27, openLDAP is not testing for a specific ou and instead is getting all of them.
I would appreciate any help anyone can give to solve this issue. If more information is needed, please let me know.
xjol0265 writes:
We are upgrading our servers to RedHat 5.1, and in the process trying to migrate to openLDAP 2.3.27 (the latest version that RH provides).
Note that RH's OpenLDAP version is primarily built (and tested) to provide LDAP libraries. They care less about the server - they even link it with Berkeley DB version 4.3, which OpenLDAP configure normally refuses to use because it doesn't work well with OpenLDAP.
So, you are better off building OpenLDAP and Berkeley DB yourself, or you can get a prebuilt bundle elsewhere. Symas offers prebuilts (www.symas.com), and I think Buchan Milne keeps RPMs somewhere but I the URL I found doesn't answer now: http://anorien.csc.warwick.ac.uk/mirrors/buchan/openldap/.
In fact, if a Thunderbird user tries to do a directory search as before, openLDAP fails. When it fails, it does not write anything to the log explaining why.
You didn't say which loglevel.
but when you log anything at all, always include at least loglevel "stats" (256). That logs the requests and the responses - with error codes (check against RFC 4511 Appendix A) and any supplementary diagnostic message and matchedDN sent to the client. That's the default loglevel, and also helps put the info from other levels in context.
Hallvard B Furuseth wrote:
xjol0265 writes:
We are upgrading our servers to RedHat 5.1, and in the process trying to migrate to openLDAP 2.3.27 (the latest version that RH provides).
Note that RH's OpenLDAP version is primarily built (and tested) to provide LDAP libraries. They care less about the server - they even link it with Berkeley DB version 4.3, which OpenLDAP configure normally refuses to use because it doesn't work well with OpenLDAP.
So, you are better off building OpenLDAP and Berkeley DB yourself, or you can get a prebuilt bundle elsewhere. Symas offers prebuilts (www.symas.com), and I think Buchan Milne keeps RPMs somewhere but I the URL I found doesn't answer now: http://anorien.csc.warwick.ac.uk/mirrors/buchan/openldap/.
In fact, if a Thunderbird user tries to do a directory search as before, openLDAP fails. When it fails, it does not write anything to the log explaining why.
You didn't say which loglevel.
but when you log anything at all, always include at least loglevel "stats" (256). That logs the requests and the responses - with error codes (check against RFC 4511 Appendix A) and any supplementary diagnostic message and matchedDN sent to the client. That's the default loglevel, and also helps put the info from other levels in context.
loglevel -1
On Sunday 23 March 2008 18:44:00 Hallvard B Furuseth wrote:
xjol0265 writes:
We are upgrading our servers to RedHat 5.1, and in the process trying to migrate to openLDAP 2.3.27 (the latest version that RH provides).
Note that RH's OpenLDAP version is primarily built (and tested) to provide LDAP libraries. They care less about the server - they even link it with Berkeley DB version 4.3, which OpenLDAP configure normally refuses to use because it doesn't work well with OpenLDAP.
So, you are better off building OpenLDAP and Berkeley DB yourself, or you can get a prebuilt bundle elsewhere. Symas offers prebuilts (www.symas.com), and I think Buchan Milne keeps RPMs somewhere but I the URL I found doesn't answer now: http://anorien.csc.warwick.ac.uk/mirrors/buchan/openldap/.
I don't have access to anorien any more, not even to put up a notice that the packages have moved to: http://staff.telkomsa.net/packages/
2.3.41 and 2.4.8 should appear this week if I'm not stuck in meetings without wifi access too much.
Regards, Buchan
Buchan Milne wrote:
On Sunday 23 March 2008 18:44:00 Hallvard B Furuseth wrote:
xjol0265 writes:
We are upgrading our servers to RedHat 5.1, and in the process trying to migrate to openLDAP 2.3.27 (the latest version that RH provides).
Note that RH's OpenLDAP version is primarily built (and tested) to provide LDAP libraries. They care less about the server - they even link it with Berkeley DB version 4.3, which OpenLDAP configure normally refuses to use because it doesn't work well with OpenLDAP.
So, you are better off building OpenLDAP and Berkeley DB yourself, or you can get a prebuilt bundle elsewhere. Symas offers prebuilts (www.symas.com), and I think Buchan Milne keeps RPMs somewhere but I the URL I found doesn't answer now: http://anorien.csc.warwick.ac.uk/mirrors/buchan/openldap/.
I don't have access to anorien any more, not even to put up a notice that the packages have moved to: http://staff.telkomsa.net/packages/
2.3.41 and 2.4.8 should appear this week if I'm not stuck in meetings without wifi access too much.
Regards, Buchan
So the only suggestion is to install a different (non-RH) version and hope that helps?
On Wednesday 26 March 2008 16:12:04 Admin wrote:
Buchan Milne wrote:
On Sunday 23 March 2008 18:44:00 Hallvard B Furuseth wrote:
xjol0265 writes:
We are upgrading our servers to RedHat 5.1, and in the process trying to migrate to openLDAP 2.3.27 (the latest version that RH provides).
Note that RH's OpenLDAP version is primarily built (and tested) to provide LDAP libraries. They care less about the server - they even link it with Berkeley DB version 4.3, which OpenLDAP configure normally refuses to use because it doesn't work well with OpenLDAP.
So, you are better off building OpenLDAP and Berkeley DB yourself, or you can get a prebuilt bundle elsewhere. Symas offers prebuilts (www.symas.com), and I think Buchan Milne keeps RPMs somewhere but I the URL I found doesn't answer now: http://anorien.csc.warwick.ac.uk/mirrors/buchan/openldap/.
I don't have access to anorien any more, not even to put up a notice that the packages have moved to: http://staff.telkomsa.net/packages/
2.3.41 and 2.4.8 should appear this week if I'm not stuck in meetings without wifi access too much.
So the only suggestion is to install a different (non-RH) version and hope that helps?
No, upgrade to a version that has many bugfixes over the version you are currently running, and for which issues you log on the ITS that will be looked at by the developers. Note that I don't run back-sql myself ...
Or, log support tickets with Red Hat.
Regards, Buchan
Buchan Milne wrote:
On Wednesday 26 March 2008 16:12:04 Admin wrote:
Buchan Milne wrote:
On Sunday 23 March 2008 18:44:00 Hallvard B Furuseth wrote:
xjol0265 writes:
We are upgrading our servers to RedHat 5.1, and in the process trying to migrate to openLDAP 2.3.27 (the latest version that RH provides).
Note that RH's OpenLDAP version is primarily built (and tested) to provide LDAP libraries. They care less about the server - they even link it with Berkeley DB version 4.3, which OpenLDAP configure normally refuses to use because it doesn't work well with OpenLDAP.
So, you are better off building OpenLDAP and Berkeley DB yourself, or you can get a prebuilt bundle elsewhere. Symas offers prebuilts (www.symas.com), and I think Buchan Milne keeps RPMs somewhere but I the URL I found doesn't answer now: http://anorien.csc.warwick.ac.uk/mirrors/buchan/openldap/.
I don't have access to anorien any more, not even to put up a notice that the packages have moved to: http://staff.telkomsa.net/packages/
2.3.41 and 2.4.8 should appear this week if I'm not stuck in meetings without wifi access too much.
So the only suggestion is to install a different (non-RH) version and hope that helps?
No, upgrade to a version that has many bugfixes over the version you are currently running, and for which issues you log on the ITS that will be looked at by the developers. Note that I don't run back-sql myself ...
Or, log support tickets with Red Hat.
Regards, Buchan
Do your RPMs for OpenLDAP-Server include SQL support even thought you do not run back-sql yourself?
Regards
Admin wrote:
Buchan Milne wrote:
On Wednesday 26 March 2008 16:12:04 Admin wrote:
Buchan Milne wrote:
On Sunday 23 March 2008 18:44:00 Hallvard B Furuseth wrote:
xjol0265 writes:
We are upgrading our servers to RedHat 5.1, and in the process trying to migrate to openLDAP 2.3.27 (the latest version that RH provides).
Note that RH's OpenLDAP version is primarily built (and tested) to provide LDAP libraries. They care less about the server - they even link it with Berkeley DB version 4.3, which OpenLDAP configure normally refuses to use because it doesn't work well with OpenLDAP.
So, you are better off building OpenLDAP and Berkeley DB yourself, or you can get a prebuilt bundle elsewhere. Symas offers prebuilts (www.symas.com), and I think Buchan Milne keeps RPMs somewhere but I the URL I found doesn't answer now: http://anorien.csc.warwick.ac.uk/mirrors/buchan/openldap/.
I don't have access to anorien any more, not even to put up a notice that the packages have moved to: http://staff.telkomsa.net/packages/
2.3.41 and 2.4.8 should appear this week if I'm not stuck in meetings without wifi access too much.
So the only suggestion is to install a different (non-RH) version and hope that helps?
No, upgrade to a version that has many bugfixes over the version you are currently running, and for which issues you log on the ITS that will be looked at by the developers. Note that I don't run back-sql myself ...
Or, log support tickets with Red Hat.
Regards, Buchan
Do your RPMs for OpenLDAP-Server include SQL support even thought you do not run back-sql yourself?
Regards
Everything is loadable as a module.
openldap-software@openldap.org
-
Admin -
Buchan Milne -
Gavin Henry -
Hallvard B Furuseth -
xjol0265