Re: (ITS#7426) contraints blocks syncreplication

[hyc@symas.com]

michael@stroeder.com wrote:
> hyc@symas.com wrote:
>> Sascha.Kuehndel@deka.de wrote:
>>> the problem is the order of the sync process.
>>> First the users are sync. At this moment the consumer don't have any group entry.
>>> So the constraints checks the dekanetZielgruppenDN against a not existing subtree.
>>> The result is: the user entry is not added.
>>
>> Yes, but that's irrelevant. Even if the groups were fully replicated already,
>> if the provider sent an invalid user, this constraint overlay on the consumer
>> would correctly reject it and replication would still break.
>
> IMO Sascha says that the group and user entries were written in correct order
> to the first provider, successfully passed the constraints there but are then
> replicated in different order to the second provider which also checks the
> same constraints again. Since the order is significant for the constraint it
> fails on the second provider. (Both are configured with same constraints.)
>
> The solution would be to not check constraints for replicated ops. It's
> similar to the problem space when/whether to apply slapo-refint,
> slapo-memberof etc. in case of replicated ops.

OK, that sounds fine. The corresponding fix is now in git master, please test.
commit b4126863a4443630392afc50de65b0c90de2304f

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/