On Thursday 18 January 2007 12:43, Michael Steinmann wrote: > On Fri, January 12, 2007 11:03 am, Michael Steinmann wrote: > > [snip] > > > To me this looks like the ppolicy overlay and slurpd are both trying to > > update the pwdHistory attribute at the same time but ppolicy kicks in > > faster and thus slurpd cannot see the old value and fails. > > after patching slurpd to not replicate pwdHistory I ran into the same > problem with the accessTo attribute. Both pwdHistory and accessTo are > multivalued which led me down another route and I found ITS#3228 which > corresponds to what I'm doing (using slurpd with multiple replication > agreements to the same slave). It would have helped if you had mentioned this ... > Closer analysis of the slave's logs > revealed that *two* replications actually took place for every change on > the master (as described in above bug). > > I've reverted to replicate the subordinate database only and now > replication works as expected without errors. You can still replicate multiple databases, but you must use the workaround where the replica name is unique (by mixing case etc.). Regards, Buchan -- Buchan Milne ISP Systems Specialist - Monitoring/Authentication Team Leader B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)
Attachment:
pgpfLNE2wHs3M.pgp
Description: PGP signature