[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Backglue + global rwm hang
On Wed, 2005-10-05 at 01:43 +0400, Mitya wrote:
> > 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.
I'm not 100% sure I do understand. If you need your mail client to see
all the databases with a common root, you can use the empty suffix "",
provided your client accepts it, so you don't need to rewrite anything:
database bdb
suffix dc=foo,dc=ru
rootdn cn=Manager
subordinate
database bdb
suffix dc=bar,dc=com
rootdn cn=Manager
subordinate
database bdb
suffix ""
rootdn cn=Manager
rootpw secret
Note that in all your examples, "dc=ru" is a common root; in my example
I rooted one database at "dc=com" so that only the empty suffix can be a
common base.
> > 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_.
Never mind...
>
> 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?
If you're fine with back-meta binding to each remote database with an
administrative identity, you can use the pseudoroot identity feature of
back-meta: if binding with back-meta's rootdn, the administrative
identity is used instead; do something like
database meta
suffix ou=Domains
rootdn cn=Manager,ou=Domains
rootpw secret
uri ldap://localhost/o=Foo,ou=Domains
suffixmassage o=Foo,ou=Domains dc=foo,dc=ru
pseudorootdn cn=Manager,dc=foo,dc=ru
pseudorootpw foo-secret
uri ldap://localhost/o=Bar,ou=Domains
suffixmassage o=Bar,ou=Domains dc=bar,dc=ru
pseudorootdn cn=Manager,dc=bar,dc=ru
pseudorootpw bar-secret
Note that the same trick as above applies here: if you need to glue
together heterogeneous naming contexts but you don't necessarily need to
mask naming contexts you may use the empty suffix as the common suffix:
database meta
suffix ""
rootdn cn=Manager
rootpw secret
uri ldap://localhost/dc=foo,dc=ru
pseudorootdn cn=Manager,dc=foo,dc=ru
pseudorootpw foo-secret
uri ldap://localhost/dc=bar,dc=ru
pseudorootdn cn=Manager,dc=bar,dc=ru
pseudorootpw bar-secret
although your example might have used "dc=ru" as a common suffix.
2.3.8 will have some improvements in this area (ITS#4056, 4057)
If you can live with the empty suffix, I favor the glue option instead
of the back-meta one.
p.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497