Re: searching multiple backends

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

Let me see if I can clarify this a bit.  But before doing so,
let me note that I'm am talking in the hypothetical as OpenLDAP
doesn't just support the meantioned RFCs.

At 01:34 PM 4/27/99 -0700, Howard Chu wrote:
>Perhaps I should look at this new dynamic module support to see if an answer
>lies there, but first:
It doesn't.
>I've encountered a problem which I was all set to tackle, until I realized
>there was a more general problem. I have two DSAs, one X.500 and one slapd.
>The X.500 server operates over o=bar and the slapd is responsible for
>ou=foo,o=bar. I.e., the slapd is subordinate to the X.500 dsa. When the
>X.500 dsa receives a DAP request to LIST the entries under o=bar there is no
>problem, and the names of everything one level below o=bar is returned. This
>request is handled entirely within the X.500 dsa. When it receives an
>equivalent LDAP request to SEARCH, scope=ONELEVEL, it enumerates everything
>it knows about within its own database, and then chains the request on to
>the slapd, with search base o=bar, scope=ONELEVEL. (Yes, our X.500 DSA also
>answers LDAP queries, and yes, it's smart enough to use LDAP instead of DSP
>when necessary to talk to other DSAs. That's not the point.) The problem is
>that the slapd only has a backend configured for ou=foo,o=bar and so is
>unwilling to perform a search based at o=bar.

Yes.  o=bar is not within any of the namingContexts (backends)
known by slapd.

>This brings me to the more
>general problem: suppose I have a slapd configured with multiple backends at
>parallel points in the DIT:
>	#1 ou=foo,o=bar
>	#2 ou=baz,o=bar
>	#3 ou=fiz,o=bar

You would have three distinct naming contexts, one foreach backend.

>Again, if this slapd receives a SEARCH request based at o=bar, the request
>will fail, even though it could/should validly return information for
>ONELEVEL or SUBTREE searches from this base.

The base of the search is not within a naming context, it should fail.

>I would expect it to return information about the base object
>for all three of these backends, but
>currently the do_search function is only capable of invoking a single
>backend.

This is because searches should be confined to one naming context.
Clients should use namingContext attributes within the root DSE
to better structure their searches.

>Fixing this would require modifying all of the backend search
>functions to prevent them from sending a final search result code, leaving
>it to do_search to send instead.

I don't think it's broken, per say, as the specification allows
our current approach.  However, there are likely other approaches
worth considering.

Kurt