[email protected] wrote: > [email protected] wrote: >> [email protected] 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/
