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

RE: Can I reuse the back-ldap in my own overlay?

>>Chen, Shi Jun SLC CT PEK wrote:
>>> I want to write a overlay "DirectForwarding" that does not do the
>>> request in local back-bdb, but intercepts the request and forwards it
> to
>>> a remote DSA.
> Howard Chu wrote:
>>This sounds to me like just using back-ldap all by itself. Why do you
> Think this needs to be an overlay?
> Yes, I can configure slapd.conf to use back-ldap as the backend
> database.
> But how can I make back-ldap to select the server dynamically according
> to the concrete content of LDAP request?
> For example, the entries are in the same sub-tree, but are devided in
> three remote DSAs (A, B & C). When the local DSA receives the request on
> entry resided in B, how to use back-ldap to route the request to DSA B?

If the remote DSAs are divided in a hierarchical manner (e.g. each of them
contains a subtree of the common tree) you can use either back-meta or
glued instances of back-ldap (see the "subordinate" directive in
slapd.conf(5)).  If entries are randomly interspersed in the remote DSAs,
you can use back-meta; the overhead is that search requests will be
broadcast to all remote servers even if the right one could be determined
by some rule.

> Obviously, specifying DSA A, B & C in a	single ldapurl argument will not
> work, for back-ldap just uses the first server of the list.

That's the intended behavior.

> And can I configure multiple back-ldap to achieve it? But there is a
> problem that these entries in A, B & C are in the same sub-tree and will
> have the same suffix.
> And another question: can we have other methods to specify the URIs
> instead of configuring them statically in slapd.conf?

It depends on what you mean.  If you mean "dynamically" select the URI
from a fixed pool, then you could define multiple back-ldap, each with its
own separate suffix, and use some rewrite rule in a global slapo-rwm(5) to
select the appropriate one based on the DN of the request.  This might
require two passes of DN rewriting in your specific cases: one prior to
database selection, and one inside the database to restore the original
DN.  See slapo-rwm(5) for details.


Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it