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