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

Re: (Was ITS#4333) crash in back meta



Pierangelo Masarati wrote:
I'm not sure I understand what you mean; is it correct that you're trying
to have, in the same slapd, one database (say "o=translucent") and another
database that is actually a translucent overlay which relays operations to
the original one directly via back-relay rather than via back-ldap?

If this is is the case, I'm not sure I understand its usefulness: since
both DBs are in the same instance of slapd I'd assume the smae
administrator is administering both; or, are you trying to allow
augmenting a shadow database with local data?

Agreed, I don't see the usefulness either...
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.

That pretty well sums up what I've been thinking, yes.

--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/