[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Backglue + global rwm hang



On Wednesday 05 October 2005 00:45, Pierangelo Masarati wrote:
> 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.
>

Sorry for hi-jacking this thread, but I am trying something similar here.

My problem is that we have a number of LDAP installations, with widely varying 
basedn's, with different naming styles etc etc (including "fake" basedn's etc 
to stick with dc=naming for disparate tld's). I would like to migrate to 
using one naming context.

Using 2.3.11, I have something like this:

database        bdb
suffix		dc=isp1,dc=co,dc=za
subordinate
overlay		rwm
rwm-suffixmassage       dc=isp1,dc=co,dc=za,dc=fakesuffix dc=isp1,dc=co,dc=za

database	bdb
suffix		dc=isp2,dc=net
subordinate
overlay		rwm
rwm-suffixmassage	dc=isp2,dc=net,dc=fakesuffix dc=isp2,dc=net

database	bdb
suffix		""


This works fine from the glue aspect, but the suffixmassage isn't working (ie, 
I populated dc=isp1,dc=co,dc=za, searches to 
dc=isp1,dc=co,dc=za,dc=fakesuffix found no entries).

I also tried a similar configuration with a meta backend instead:


database        bdb
suffix		dc=isp1,dc=co,dc=za
subordinate

database	meta
suffix 		"dc=isp1,dc=co,dc=za,dc=fakesuffix"
uri     ldap://localhost/dc=isp1,dc=co,dc=za
lastmod off
suffixmassage "dc=isp1,dc=co,dc=za,dc=fakesuffix" "dc=isp1,dc=co,dc=za"
subordinate

database	bdb
suffix		dc=isp2,dc=net
subordinate

database	meta
suffix 		"dc=isp2,dc=net,dc=fakesuffix"
uri     	ldap://localhost/dc=isp2,dc=net
lastmod off
suffixmassage "dc=isp2,dc=net,dc=fakesuffix" "dc=isp2,dc=net"
subordinate

database	bdb
suffix		""


And, that results in the same (no apparent re-writing).

Am I missing something? I'd prefer not to post the real configs ... but I can 
if someone thinks I've made typos ...

Regards,
Buchan

-- 
Buchan Milne
ISP Systems Specialist
B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)

Attachment: pgpc7T6R6gEmW.pgp
Description: PGP signature