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). 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.
-- mike