[Date Prev][Date Next]
Re: Replication errors with slurpd and ppolicy [SOLVED]
Buchan Milne wrote:
> On Thursday 18 January 2007 12:43, Michael Steinmann wrote:
>> On Fri, January 12, 2007 11:03 am, Michael Steinmann wrote:
>>> 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.).
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.