I am having trouble processing referred MOD requests where the DN contains spaces. It always fails with error 32 (not found).
Instance A is the master. Instance B is a replica, type refreshAndPersist, and contains "updateref ldap://instanceA:389" following the syncrepl. Both A and B are openldap 2.4.33 with identical configuration apart from the sync and referral settings.
Updates to A replicate immediately and correctly to B (including those with spaces in the DN). Updates to B, without spaces in the DN, are referred to A, processed correctly on A, and replicated correctly to B.
But: updates to B, *with* spaces in the DN, are referred to A where they fail with error 32. The client (using Novell jldap 2009.10.07) does not report an error, and of course the change is not replicated.
The MOD to B appears in ldap.log as dn="cn=first second,ou=.......". Note the space between the two words of the CN. (This is also how MODs sent directly to A appear, which do get correctly processed).
A network trace shows B generating a referral to A of the form: ldap://instanceA:389/cn=first%20second,ou=.....
The MOD referral to A appears in A's ldap.log as dn="cn=first%20second,ou=....." with err=32.
I'm at a loss to know where to go from here, or even which component is at fault. Can anyone help?
Many thanks Chris
I posted this a few weeks ago but didn't get any replies at all. Re-posting one more time to see if anyone can give me any advice.
Regards Chris
---------------------------------------------------------------------
I am having trouble processing referred MOD requests where the DN contains spaces. It always fails with error 32 (not found).
Instance A is the master. Instance B is a replica, type refreshAndPersist, and contains "updateref ldap://instanceA:389" following the syncrepl. Both A and B are openldap 2.4.33 with identical configuration apart from the sync and referral settings.
Updates to A replicate immediately and correctly to B (including those with spaces in the DN). Updates to B, without spaces in the DN, are referred to A, processed correctly on A, and replicated correctly to B.
But: updates to B, *with* spaces in the DN, are referred to A where they fail with error 32. The client (using Novell jldap 2009.10.07) does not report an error, and of course the change is not replicated.
The MOD to B appears in ldap.log as dn="cn=first second,ou=.......". Note the space between the two words of the CN. (This is also how MODs sent directly to A appear, which do get correctly processed).
A network trace shows B generating a referral to A of the form: ldap://instanceA:389/cn=first%20second,ou=.....
The MOD referral to A appears in A's ldap.log as dn="cn=first%20second,ou=....." with err=32.
I'm at a loss to know where to go from here, or even which component is at fault. Can anyone help?
Many thanks Chris
--On Monday, February 04, 2013 11:55 AM +0000 Chris Palmer chris.palmer@pobox.com wrote:
I am having trouble processing referred MOD requests where the DN contains spaces. It always fails with error 32 (not found).
Instance A is the master. Instance B is a replica, type refreshAndPersist, and contains "updateref ldap://instanceA:389" following the syncrepl. Both A and B are openldap 2.4.33 with identical configuration apart from the sync and referral settings.
Updates to A replicate immediately and correctly to B (including those with spaces in the DN). Updates to B, without spaces in the DN, are referred to A, processed correctly on A, and replicated correctly to B.
But: updates to B, *with* spaces in the DN, are referred to A where they fail with error 32. The client (using Novell jldap 2009.10.07) does not report an error, and of course the change is not replicated.
The MOD to B appears in ldap.log as dn="cn=first second,ou=.......". Note the space between the two words of the CN. (This is also how MODs sent directly to A appear, which do get correctly processed).
A network trace shows B generating a referral to A of the form: ldap://instanceA:389/cn=first%20second,ou=.....
The MOD referral to A appears in A's ldap.log as dn="cn=first%20second,ou=....." with err=32.
I'm at a loss to know where to go from here, or even which component is at fault. Can anyone help?
Well, %20 is just the space encoded, which I would think would be OK. Do you hit the same issue if you use UnboundID's SDK rather than JLDAP?
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On Mon, 4 Feb 2013, Quanah Gibson-Mount wrote:
--On Monday, February 04, 2013 11:55 AM +0000 Chris Palmer chris.palmer@pobox.com wrote:
...
But: updates to B, *with* spaces in the DN, are referred to A where they fail with error 32. The client (using Novell jldap 2009.10.07) does not report an error, and of course the change is not replicated.
The MOD to B appears in ldap.log as dn="cn=first second,ou=.......". Note the space between the two words of the CN. (This is also how MODs sent directly to A appear, which do get correctly processed).
A network trace shows B generating a referral to A of the form: ldap://instanceA:389/cn=first%20second,ou=.....
The MOD referral to A appears in A's ldap.log as dn="cn=first%20second,ou=....." with err=32.
I'm at a loss to know where to go from here, or even which component is at fault. Can anyone help?
Well, %20 is just the space encoded, which I would think would be OK. Do you hit the same issue if you use UnboundID's SDK rather than JLDAP?
It sounds to me like OpenLDAP is returning the correct URL in the referral, but when Novell's jldap processes the referral it is failing to decode the percent-encoding when generating the new request to the referred-to server, as percent-encoding is not used (of course) in DN field of the actual LDAP request.
Philip Guenther
On 04/02/2013 19:34, Philip Guenther wrote:
On Mon, 4 Feb 2013, Quanah Gibson-Mount wrote:
--On Monday, February 04, 2013 11:55 AM +0000 Chris Palmer chris.palmer@pobox.com wrote:
...
But: updates to B, *with* spaces in the DN, are referred to A where they fail with error 32. The client (using Novell jldap 2009.10.07) does not report an error, and of course the change is not replicated.
The MOD to B appears in ldap.log as dn="cn=first second,ou=.......". Note the space between the two words of the CN. (This is also how MODs sent directly to A appear, which do get correctly processed).
A network trace shows B generating a referral to A of the form: ldap://instanceA:389/cn=first%20second,ou=.....
The MOD referral to A appears in A's ldap.log as dn="cn=first%20second,ou=....." with err=32.
I'm at a loss to know where to go from here, or even which component is at fault. Can anyone help?
Well, %20 is just the space encoded, which I would think would be OK. Do you hit the same issue if you use UnboundID's SDK rather than JLDAP?
I've just had a quick look at the UnboundID SDK, and it does look much better than JLDAP. The API is of course rather different, so I will have to do a test case and then port the program. It's about 7 years old, and at the time JLDAP seemed a reasonable choice...
It sounds to me like OpenLDAP is returning the correct URL in the referral, but when Novell's jldap processes the referral it is failing to decode the percent-encoding when generating the new request to the referred-to server, as percent-encoding is not used (of course) in DN field of the actual LDAP request.
That sounds right to me. A good reason to move away from JLDAP.
Many thanks for the help.
Philip Guenther
openldap-technical@openldap.org
-
Chris Palmer -
Philip Guenther -
Quanah Gibson-Mount