[Date Prev][Date Next]
Re: searching multiple backends
- To: openldap-devel@OpenLDAP.org
- Subject: Re: searching multiple backends
- From: Julio Sanchez <email@example.com>
- Date: 01 May 1999 07:59:13 +0200
- In-reply-to: "Howard Chu"'s message of "Fri, 30 Apr 1999 15:23:10 -0700"
- References: <firstname.lastname@example.org>
"Howard Chu" <email@example.com> writes:
> You stated that the directory layout I described was bogus.
Absolutely not. I said that if your X.500 DSA masters o=bar, it
cannot go asking somewhere else asking for a list of things directly
under o=bar and that doing *this* was bogus. It *has* to know *what*
things are below (and since you brought up DNS, that's exactly how DNS
works). If it knows that such and such things are mastered somewhere
else, then these are separate namingContexts. Later I showed with
spec that, beyond my personal opinion, this is exactly what is
supposed to happen. Unless the spec changes, your X.500 DSA has to
make separate searches for each delegated naming context. Because an
LDAP server conformant to the spec is going to return a referral error
result if an attempt to search all of them in the same request is
In a different message you propose a glue entry and quickly hit the
referral loop problem and ask for slapd to break again the spec by not
returning the SearchResultReference entries (this is wrong, read 6.2
in RFC2251 where responsiblity for avoiding referral loops is placed
with the clients).
> If you read
> ITU-T Rec. X.501, section 19.3 "Directory Distribution Model":
> A master DSA's administrator may delegate administrative authority
> for any immediate subordinates of any entry held locally to another
> master DSA.
As you can see, there is no disagreement here. But this says nothing
about the problem above.
> I don't believe I misread you at all. I gave a perfectly good example of
> this exact situation, 3 backends spanning a particular naming
No, your example talks about:
Unless there is also
mastered by that server, it should fail per the spec. But if it
really were there, it seems it would fail too and that should not
happen, *this* is the bug.
PGP Key fingerprint = E5 29 93 6F 41 4E 00 E2 90 11 A1 8C 72 D0 DE 71