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