In any case this is not (of course) hopw it works, because, right now, you
cannot select what type of proxying is to be used by the translucent
overlay. In principle, one could use "any" (sort of) backend type to
proxy thanslucent calls, so this could be modified. You would need some
slapo-rwm because there cannot (yet) exist two databases with the same
naming context. I say "yet" because Howard is thinking of "hidden"
databases that have the same naming context of "visible" ones and serve
the purpose of doing internal operations (i.e. they cannot be selected by
select_backend()), but this is not yet available (AFAIK :); in this case,
you would do something like:
# shadow; hidden
database bdb
suffix "dc=example,dc=com" hidden (*)
syncrepl ...
# translucent; visible
database bdb
suffix "dc=example,dc=com"
overlay translucent
translucent relay (*)
relay "dc=example,dc=com" hidden (*)
Commands with (*) are not valid right now; I'm just trying to see how
things could be implemented.
- the "suffix <namingcontext> hidden" would mark a database as "hidden";
since it's a syncrepl, it would sync with some remote one, but it wouldn't
be directly accessible.
- the "translucent relay" would instruct the translucent overlay to use an
instance of back-relay instead of the default back-ldap to proxy
- the "relay <namingcontext> hidden" would instruct the back-relay to
proxy a specific database that is "hidden"; this would allow it to lookup
a database that otherwise cannot be found by regular select_backend().
Operations within the "dc=example,dc=com" naming context would be served
by the second database, the public one, and would pass thru the
translucent overlay to allow local writes before accessing the "hidden"
shadow database.