> [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: [EMAIL PROTECTED] ------------------------------------------
