[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Backglue + global rwm hang
> 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