A powerful (and in some sense dangerous) rewrite engine has been
added to both the LDAP and Meta backends. While the former can
gain limited beneficial effects from rewriting stuff, the latter
can become an amazingly powerful tool.
Consider a couple of scenarios first.
1) Two directory servers share two levels of naming context; say
"dc=a,dc=foo,dc=com" and "dc=b,dc=foo,dc=com". Then, an
unambiguous Meta database can be configured as:
database meta
suffix "dc=foo,dc=com"
uri "ldap://a.foo.com/dc=a,dc=foo,dc=com"
uri "ldap://b.foo.com/dc=b,dc=foo,dc=com"
Operations directed to a specific target can be easily resolved
because there are no ambiguities. The only operation that may
resolve to multiple targets is a search with base "dc=foo,dc=com"
and scope at least "one", which results in spawning two searches
to the targets.
2a) Two directory servers don't share any portion of naming
context, but they'd present as a single DIT [Caveat: uniqueness
of (massaged) entries among the two servers is assumed; integrity
checks risk to incur in excessive overhead and have not been
implemented]. Say we have "dc=bar,dc=org" and "o=Foo,c=US", and
we'd like them to appear as branches of "dc=foo,dc=com", say
"dc=a,dc=foo,dc=com" and "dc=b,dc=foo,dc=com". Then we need to
configure our Meta backend as:
database meta
suffix "dc=foo,dc=com"
uri "ldap://a.bar.com/dc=a,dc=foo,dc=com"
suffixmassage "dc=a,dc=foo,dc=com" "dc=bar,dc=org"
uri "ldap://b.foo.com/dc=b,dc=foo,dc=com"
suffixmassage "dc=b,dc=foo,dc=com" "o=Foo,c=US"
Again, operations can be resolved without ambiguity, although
some rewriting is required. Notice that the virtual naming
context of each target is a branch of the database's naming
context; it is rewritten back and forth when operations are
performed towards the target servers. What "back and forth"
means will be clarified later.
When a search with base "dc=foo,dc=com" is attempted, if the
scope is "base" it fails with "no such object"; in fact, the
common root of the two targets (prior to massaging) does not
exist. If the scope is "one", both targets are contacted with
the base replaced by each target's base; the scope is derated to
"base". In general, a scope "one" search is honored, and the
scope is derated, only when the incoming base is at most one
level lower of a target's naming context (prior to massaging).
Finally, if the scope is "sub" the incoming base is replaced by
each target's unmassaged naming context, and the scope is not
altered.
2b) Consider the above reported scenario with the two servers
sharing the same naming context:
database meta
suffix "dc=foo,dc=com"
uri "ldap://a.bar.com/dc=foo,dc=com"
suffixmassage "dc=foo,dc=com" "dc=bar,dc=org"
uri "ldap://b.foo.com/dc=foo,dc=com"
suffixmassage "dc=foo,dc=com" "o=Foo,c=US"
All the previous considerations hold, except that now there is no
way to unambiguously resolve a DN. In this case, all the
operations that require an unambiguous target selection will fail
unless the DN is already cached or a default target has been set.
Practical configurations may result as a combination of all the
above scenarios.
