[Date Prev][Date Next]
Re: (ITS#7426) contraints blocks syncreplication
> email@example.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.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/