[Date Prev][Date Next]
Re: searching multiple backends
- To: "Howard Chu" <email@example.com>
- Subject: Re: searching multiple backends
- From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Date: Fri, 30 Apr 1999 17:27:37 -0700
- Cc: <openldap-devel@OpenLDAP.org>
- In-reply-to: <firstname.lastname@example.org>
- References: <18.104.22.168.19990427084421.00a31bf0@localhost>
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:
>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
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