> Sounds like you're hitting some dead end. I'm not sure I got all the back > references you mention, but in your case it would be much easier if you > can get rid of the gluing and deal with virtual databases only. This is > because back-relay needs per-database rwm, while gluing currently allows > rwm only as global, i.e. before any gluing takes place.
Unfortunately, glue is essential here. What I'm trying to do is to represent several distinct bases (on the same OpenLDAP server) under single, unified virtual naming context. For example, if we have "dc=foo,dc=ru" and "dc=bar,dc=ru" physical databases, and we search some virtual "ou=Domains" base, we want to receive both "cn=John,ou=People,dc=foo,dc=ru" and "cn=Mary,ou=People,dc=bar,dc=ru". This is needed, for example, by Courier mail server. Courier supports LDAP-based authentication and user database storage, but it doesn't support multiple base DN's. Tweaking Courier (multiple authdaemond instances with different configs, and so on) is not desirable; and Courier is not the only one. For now it seems that only Jabberd2 is aware of multiple LDAP base DNs. > Note that with your current setup you would end up, by running a search > for "ou=Domains", with 10+ instances of the __same__ data with different > virtual naming contexts. Could you please explain this? Can't understand now the origin of that 10+ instances _of the same data_. I've also tried to do what I want with back-meta (because it includes glue-like functionality and built-in rewriting facilities), like this: database meta suffix ou=Domains uri ldap://localhost/o=Foo,ou=Domains suffixmassage o=Foo,ou=Domains dc=foo,dc=ru uri ldap://localhost/o=Bar,ou=Domains suffixmassage o=Bar,ou=Domains dc=bar,dc=ru and so on, bud I didn't manage to make back-meta do authenticated bind to "remote" (in fact, local) database, only anonymous bind takes place (anon_bind is disallowed). Any ideas? Thank you! Dimitri
