Re: Meta directory?

[Pierangelo Masarati <masarati@aero.polimi.it>]

> 
> Pierangelo-
> 
> 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" 
backend.

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 
returned?

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.

Regards, Pierangelo. 

--
Pierangelo Masarati      mailto:ando@sys-net.it
Developer, SysNet s.n.c. http://www.sys-net.it