Re: referral mess in HEAD

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Ny suggestion is to focus on getting LDAPv3 working right.
Getting LDAPv2+ working right is impossible as the design
of LDAPv2+ is flawed.  The client cannot tell the difference
between a LDAPv2+ referral and an LDAPv2+ search continuation.

At 02:43 AM 2002-05-02, Howard Chu wrote:
>There are still a bunch of problems with referrals, I still got into a hang
>in ldapsearch waiting in select after all outstanding requests had
>completed. There is also an abort situation, which appears to be due to
>mixing V2 and V3 referrals in response to a single query. (The V2 referrals
>come from the global referral directive in slapd.conf.) Shouldn't slapd be
>returning the global referral in V3 format on a V3 query?

Yes.


>I created this test environment based on email from Stephan Austermühle
>[au@hcsd.de]:
>
>- Server 1 (Port 389):
> Base DN: ou=hamburg,o=eg,o=airbus
> Global Referral: ldap://127.0.0.1:10389
>
>- Server 2 (Port 390):
> Base DN: ou=bremen,o=eg,o=airbus
> Global Referral: ldap://127.0.0.1:10389
>
>- Server 3 (Port 10389):
> Base DN: o=eg,o=airbus
> Global Referral: ldap://127.0.0.1:20389
> This server has two smart referrals set:
> (1) dn: ou=bremen,o=eg,o=airbus
> ref: ldap://127.0.0.1:390/ou=bremen,o=eg,o=airbus
> (2) dn: ou=hamburg,o=eg,o=airbus
> ref: ldap://127.0.0.1:389/ou=hamburg,o=eg,o=airbus
>
> - Server 4 (Port 20389):
> Base DN: o=airbus
> This server has one smart referral set:
> dn: ou=eg,o=airbus
> ref: ldap://127.0.0.1:10389/ou=eg,o=airbus
>
>Here are some results I've obtained so far
> ldapsearch -C -x
> -H ldap://:20389
>   -b o=airbus          returns full tree minus ou=hamburg branch
>   -b o=eg,o=airbus     returns o=eg,o=airbus subtree minus ou=hamburg
>branch
>   -b ou=bremen,o=eg,o=airbus           returns branch correctly
>   -b ou=hamburg,o=eg,o=airbus  returns branch correctly
> -H ldap://:10389
>   -b o=airbus          returns o=airbus, then abort at sockbuf.c:82
>   -b o=eg,o=airbus     returns subtree minus ou=hamburg then hangs
>   -b ou=bremen,o=eg,o=airbus           returns branch correctly
>   -b ou=hamburg,o=eg,o=airbus  returns branch correctly
> -H ldap://:390
>   -b o=airbus          returns o=airbus, then abort at sockbuf.c:82
>   -b o=eg,o=airbus     returns subtree minus ou=hamburg branch
>   -b ou=bremen,o=eg,o=airbus           returns branch correctly
>   -b ou=hamburg,o=eg,o=airbus  returns branch correctly
> -H ldap://:389  same as ldap://:390
>
> ldapsearch -C -x -P 2 produces consistent results for all combinations,
>it's
>the exact same as the "-H ldap://:20389"; case above.
>
>So, my fix for the ldapsearch hang is wrong, and there's something else
>going on as well with V2/V3 mixing, and some referrals don't get chased (due
>to my hang patch I believe). Helpful ideas, anyone?
>
>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support