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

["Pierangelo Masarati" <ando@sys-net.it>]

> [moving to -software because now I'm asking usage]
>
>> Furthermore, it __should__ be more efficient to use back-relay +
>> slapo-rwm
>> for the purpose of binding to a local database with a virtual naming
>> context.
>
> I'd love to move this to back-relay and not have the network involved, but
> I don't see how to do "translucent with back-relay" behavior without quite
> a few rewriteRules (and even then I'm not sure it would work).
>
> I mean, take the test034 "remote" example, essentially
>
> database        bdb
> suffix          "o=translucent"
> overlay         translucent
> translucent_no_glue
> uri             ldap://localhost:9011/
>
> obviously making a superset of o=translucent on 9012 (relative to original
> o=translucent 9011).
>
> Say I wanted a translucent on the :9011 server in slapd.1.conf. I'll
> concede to "suffix o=translucent_new" being required (:9011 can't serve
> two different o=translucent). How would I specify:
>
> database bdb
> suffix "o=translucent_new"
> overlay translucent
> relay "o=translucent"
>
> is that actually valid?

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?

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.

p.



Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it
------------------------------------------