On Thursday 29 June 2006 18:29, Pierangelo Masarati wrote: > > We have a weird legacy DIT which is going to be migrated to a new more > > organised structure by an ongoing project. > > > > In the meantime, we are deploying provisioning tools which we would > > prefer not > > to modify at the time of the migration. > > > > So, back-relay seems to be the obvious solution (provision to the final > > structure, rewrite with back-relay into the old structure). > > > > So, I have added a new database on one of our dev servers: > > > > > > database relay > > suffix "cn=webmail,cn=mail,ou=isp" > > subordinate > > relay cn=webmail,ou=mail,dc=isp massage > > rootdn <rootdn> > > > > There is a bdb database that holds cn=mail,ou=isp (the legacy basedn). > > > > That works great, searches on cn=webmail,cn=mail,ou=isp returns an entry > > I added under cn=webmail,ou=mail,dc=isp ... except that the first search > > on the > > cn=mail,ou=isp suffix kills the relay. Any other search which should find > > anything under cn=webmail,cn=mail,ou=isp returns error 32. > > > > > > I've also tried replacing the relay database with a configurations > > using "database meta" and "database ldap" with rwm-suffixmassage, and > > they do > > the same thing. > > > > It seems I must be missing something here ... > > I suggest you try to design a solution where you don't need the relay > backend to be subordinate to anything. What I have done is remove the back-relay backend, I need the subordinate more at present ... > I suspect some strange interaction > between slapo-glue and back-relay. > > If you can come up with an essential configuration + dataset that > reproduces the problem, I suggest you file an ITS; tis could help > back-relay stabilization. That's the plan, but this will have to wait a bit ... Regards, Buchan -- Buchan Milne ISP Systems Specialist B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)
Attachment:
pgpXNlxK2lkI9.pgp
Description: PGP signature