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