[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: searching multiple backends

At 05:07 PM 4/30/99 -0700, Howard Chu wrote:
>Rather than continue to argue about what we think should happen here, I'd
>like to have a solution that does what I want. Restating the problem:
>> 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
>> 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.
>Currently each backend is treated as an independent naming context, and a
>search can only be satisfied by a single context and backend. The first
>thing I need to solve the above situation is a glue node at o=bar on this
>server. In the case where this server is subordinate to some other server
>that masters o=bar, I also want a way to specify a knowledge reference, such
>that general requests for o=bar can be referred to the superior server. As
>an added feature, the server should be smart enough to recognize that if a
>request was received from the superior server, then the referral should not
>be generated (simple loop avoidance). 
If this server was configured as:
	#0 o=z
	#1 ou=x,o=z
 	#2 ou=x,ou=y,o=z
 	#3 ou=a,ou=b,o=z

then it might make sense to allow a subtree search with a base
of o=bar to recurse into #1 and #2 and into #3 IF ou=b,o=z exists
with in #0.


>It occurs to me that I can add this
>functionality by writing a new "glue" backend.

I've actually hoping somebody would write an LDAP backend...
A server with an LDAP backend would act as a proxy to other
LDAP servers (or itself).