Re: searching multiple backends

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

I was thinking a little more about his problem.  I think
you actually have a configuration problem on your X.500
server.

At 01:34 PM 4/27/99 -0700, Howard Chu wrote:
>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.

Your X.500 server should have chained the search your slapd with a
base of ou=foo,o=bar...   (and it definitely should asking other
servers about bases it masters).

>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.

Which is exactly what it should have done or (given a referral).

>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

These are three separate DITS.

Now, it might be interesting to allow different backend suffixes
to be glued into one DIT, but they MUST form a proper DIT.


A few thoughts...

A configuration scheme would have to be devised to
construct the glued DIT.  This is the easy part (if you
eliminate suffix aliasing).

	suffix o=z
	chain-suffix	[down [o=y,o=z]]

	suffix o=y,o=z
	chain-suffix	[up [o=z]]
	chain-suffix	[down [o=x,o=y,o=z]]

	suffix o=x,o=y,o=z
	chain-suffix	[up [o=y,o=z]]

(the optional information could be used to limit chaining)

To detection a proper DIT during operations, I think one
could extend the referral generation process.  Basically,
when generating a referral, you would check to see if the
referral is to a backend which is glued your current
DIT.  If it is, the server would "chain" the request to
that backend.  If it isn't, the server would send back
the referral.  This would have to be done on each referral
entry.

Sounds easy enough, but it's actually a "can of worms."
Recursive chaining would be required.  And aliases would
have to traversed.  And suffix aliases might make one
cringe (but we eliminated those for ease of specification).

Conclusion:  Implementing this approach would be rough.


Another approach would be to specification of a namingcontect
directive per backend.  That is:
	#1	suffix "o=z"
		namingcontext "o=bar"
	#2	suffix "o=z,o=y,o=z"
		namingcontext "o=bar"

This would glue the #2 backend into DIT of the first #1.
Then you would search all backends within the naming context
to return the entries.   Problem here, you need to make
sure that o=y,o=z actually exists before allowing the
backends to be glued.

Conclusion: No proper DIT detection.


There might be other approaches that are more workable...

Another approach would combine both of these approaches...

Conclusion: Maybe this is why chaining isn't required even
in X.500 land.

Kurt