Re: Replication errors with slurpd and ppolicy [SOLVED]

[Michael Steinmann <msl@calivia.com>]

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