Buchan Milne wrote: > 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 ... >
...if only I had known that this was the source of the problem ;-) Completely agree here. I should have provided more data in the first place. >> 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 > great tip with the mixed-case hostname, thanks! We're using starttls where other changes to the hostname / IP would not have worked because of slapd's strict certificate requirements. -- mike
