Bug 1403954

Summary:	Replication should not stop and create the inconsistency among replicas even though there are mismatched configurations
Product:	Red Hat Enterprise Linux 7	Reporter:	Noriko Hosoi <nhosoi>
Component:	389-ds-base	Assignee:	Noriko Hosoi <nhosoi>
Status:	CLOSED NOTABUG	QA Contact:	Viktor Ashirov <vashirov>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.3	CC:	gparente, lkrispen, msauton, nkinder, rmeggins
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-08-24 17:29:04 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Noriko Hosoi 2016-12-12 17:18:03 UTC

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/49067

In an environment where memberOf is enabled on a master and disabled on another master the following happens.  

1) Several pieces of data, including invalid data is added to the master with memberOf disabled.  
2) GOOD BAD GOOD data is sent to the master with memberOf enabled via replication with the other master.  
3) The  master with memberOf disabled skips and notes that it skips the BAD data.  The master that is sending the replicated data also notes that it skipped the BAD data. Replication is still shown as good.  

So: 
A) The consumer isn't severing the connection. 
B) The supplier should consider schema validation replication error as a hard error and not skip it.  

More info and a recreation case for this can be found in email "Re: CASE 01751197".  Ludwig was able to reproduce and left these notes


no, I have on the consumer side:

[09/Dec/2016:16:44:34.222683287 +0100] conn=4 op=0 BIND dn="cn=replrepl,cn=config" method=128 version=3
[09/Dec/2016:16:44:34.222905979 +0100] conn=4 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=replrepl,cn=config"
[09/Dec/2016:16:44:34.228996479 +0100] conn=4 op=1 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension"
[09/Dec/2016:16:44:34.229495450 +0100] conn=4 op=1 RESULT err=0 tag=101 nentries=1 etime=0
[09/Dec/2016:16:44:34.229661093 +0100] conn=4 op=2 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension"
[09/Dec/2016:16:44:34.230064532 +0100] conn=4 op=2 RESULT err=0 tag=101 nentries=1 etime=0
[09/Dec/2016:16:44:34.230289566 +0100] conn=4 op=3 EXT oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop"
[09/Dec/2016:16:44:34.279233418 +0100] conn=4 op=3 RESULT err=0 tag=120 nentries=0 etime=0
[09/Dec/2016:16:44:34.437387789 +0100] conn=4 op=4 ADD dn="cn=g1,dc=example,dc=com"
[09/Dec/2016:16:44:34.555185922 +0100] conn=4 op=4 RESULT err=65 tag=105 nentries=0 etime=0 csn=584ad162000000010000
[09/Dec/2016:16:44:34.654083075 +0100] conn=4 op=5 EXT oid="2.16.840.1.113730.3.5.5" name="replication-multimaster-extop"
[09/Dec/2016:16:44:34.674259915 +0100] conn=4 op=5 RESULT err=0 tag=120 nentries=0 etime=0
[09/Dec/2016:16:44:48.012642473 +0100] conn=4 op=6 EXT oid="2.16.840.1.113730.3.5.12" name="replication-multimaster-extop"
[09/Dec/2016:16:44:48.064483314 +0100] conn=4 op=6 RESULT err=0 tag=120 nentries=0 etime=0
[09/Dec/2016:16:44:48.229068063 +0100] conn=4 op=7 ADD dn="cn=g1,dc=example,dc=com"
[09/Dec/2016:16:44:48.360800339 +0100] conn=4 op=7 RESULT err=65 tag=105 nentries=0 etime=0 csn=584ad162000000010000
[09/Dec/2016:16:44:48.372697051 +0100] conn=4 op=8 ADD dn="cn=yyy,dc=example,dc=com"
[09/Dec/2016:16:44:48.513254149 +0100] conn=4 op=8 RESULT err=0 tag=105 nentries=0 etime=0 csn=584ad170000000010000
[09/Dec/2016:16:44:48.651607165 +0100] conn=4 op=9 EXT oid="2.16.840.1.113730.3.5.5" name="replication-multimaster-extop"
[09/Dec/2016:16:44:48.669904404 +0100] conn=4 op=9 RESULT err=0 tag=120 nentries=0 etime=0
[09/Dec/2016:16:45:48.735018262 +0100] conn=4 op=11 UNBIND
[09/Dec/2016:16:45:48.735053744 +0100] conn=4 op=11 fd=64 closed - U1


and on the supplier:
[09/Dec/2016:16:44:48.468835078 +0100] - DEBUG - NSMMReplicationPlugin - repl5_inc_update_from_op_result - agmt="cn=meTo_localhost.localdomain:38942" (localhost:38942): Consumer failed to replay change (uniqueid 5118e701-be2611e6-88d1a1a4-9fa8583b, CSN 584ad162000000010000): Object class violation (65). Skipping.

Comment 2 Marc Sauton 2016-12-12 17:33:40 UTC

linking sf 01751197 (closed) and bz 1403954

Comment 4 Ludwig 2017-01-09 12:15:38 UTC

The test case is:

have two masters in sync
add an entry E not allowing memberof attribute
enable memberof on master2
add a group G containing E as member on master1, it is accepted and replicated
on master2 the replicated add fails because of err=65 raised by memberof plugin
do another change om master1 it will be replicated and G is missing now on master2

about the severity: it is a consequence of a sttange memberof configuration, but on the other hand it leads to inconsistent data and is difficult to find and repair

Comment 5 Noriko Hosoi 2017-01-28 01:36:26 UTC

Since this bug is for the DS team, changing the title and the target milestone based on the team meeting.

Ludwig's comment describes the problem to be solved.
https://bugzilla.redhat.com/show_bug.cgi?id=1403954#c4

Comment 6 Nathan Kinder 2017-08-24 17:29:04 UTC

According to Ludwig, this specific issue has been resolved by auth_add_oc in memberOf.  Closing as NOTABUG since this has already been fixed.