[Date Prev][Date Next]
Re: Meta directory?
> I'm sorry. Like Howard, I am too busy at the moment. Right now the
> changes I made are sufficient for our purposes, although I know there
> are a few improvements that could be made (as we've talked about
> before). How I wish there were more hours in the day!
OK, guys. Just to keep in sync.
I only wanted to let you know that it works!
I started from the HEAD of back-ldap, but as I'm making a lot
of changes and the handling of each single server is getting
awkward, I think back-ldap could be left "as is" (single target
DS) for proxying purposes, and I should start a new "back-meta"
It is structured as follows:
- it aims at a number of "target" DS, defined by the URI directive;
- the URI directive also contains the dn of the REAL NAMING CONTEXT
each DS is serving;
- the attribute mapping, the binddn and the dn/filter rewriting
is now on a per-target basis.
The rationale (in few words) is:
- the backend has a number of suffixes it can handle.
- each target is defined by the URI directive which
determines the protocol/host[/port] and the REAL NAMING
CONTEXT of the target.
- each operation is characterized by a DN; at the begining
of each operation a pool of candidate targets
is selected, by checking if the DN matches the REAL NAMING
CONTEXT of the target.
two (+ one) scenarios are possible:
1 the REAL NAMING CONTEXT is a suffix for the dn
(an exact match also meets the criterion):
the target is selected (this can happen for
every operation, and should be the only
possibility for operations like bind, compare,
modify, delete; add might be somewhat different);
2 the dn is a suffix of the REAL NAMING CONTEXT:
the target is selected (this should happen
only in case of the search base for a search
operation; the search base is then replaced
by the REAL NAMING CONTEXT). This may lead
to the selection of multiple targets;
(3) in case there is no REAL NAMING CONTEXT that matches
the dn, a NO SUCH OBJECT error may result; in this
case I'm thinking about flagging one target
as the default one, that gets all the stuff
that cannot be resolved. However, this might
an explicitly requested option, not the rule.
I only (partially) implemented bind, search and unbind.
"Partially" means that I still need to take some decisions on how
to handle anomalous situations: what happens if the search
at one target DS, instead of just giving no results, returns some error?
should the error propagate, or should I give the other target DS' a
chance to return thier results? Again, in case there is more
that one failure, which one should be returned? The first that
occurs, the worst one (who decides what's worst?). In case I get
multiple "matched", or multiple referrals, which one should be
I'm not submitting any snapshot because the work is at a very early
stage. However, I'd like to discuss any question that might arise,
if anybody is interested in it.
Pierangelo Masarati mailto:firstname.lastname@example.org
Developer, SysNet s.n.c. http://www.sys-net.it