Bug 1092099

Summary:	A replicated MOD fails (Unwilling to perform) if it targets a tombstone
Product:	Red Hat Enterprise Linux 7	Reporter:	Noriko Hosoi <nhosoi>
Component:	389-ds-base	Assignee:	Noriko Hosoi <nhosoi>
Status:	CLOSED ERRATA	QA Contact:	Viktor Ashirov <vashirov>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	7.1	CC:	nkinder, rmeggins, vashirov
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	389-ds-base-1.3.3.1-1.el7	Doc Type:	Bug Fix
Doc Text:	Cause: If an entry is updated on M1 and deleted on M2, it may happen that the replicated update (from M1) targets a deleted entry (tombstone). Fix 47396 prevents an update of tombstone and returns a failure. Consequence: First consequence is that the replicated updated fails and may break replication. Second consequence is that the tombstone differs on M1 and M2 Fix: Allow update on tombstones if the update comes from replication Result: Replication is not broken Tombstone entries are identical on all servers	Story Points:	---
Clone Of:	1092097	Environment:
Last Closed:	2015-03-05 09:34:28 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1092097
Bug Blocks:

Description Noriko Hosoi 2014-04-28 18:15:39 UTC

+++ This bug was initially created as a clone of Bug #1092097 +++

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

The test case is the following:
1- Create M1-M2
2- Create an entry
3- Disable replication M1<-->M2
4- Delete the entry on M1
5- Modify the entry on M2
6- Enable replication

The MOD (5) fails when replicated on M1, so the test entry differs on M1 and M2.
This is likely a side effect of Ticket 47396.

Test case attached

--- Additional comment from Noriko Hosoi on 2014-04-28 14:14:12 EDT ---

This is a regression introduced to 389-ds-base-1.2.11.15-22.el6 by the fix for "Bug 974719 - rhds90 crash on tombstone modrdn".

Comment 2 Viktor Ashirov 2014-11-21 20:15:48 UTC

I created 2MMR setup.

Added test entry:
$ ldapadd -D 'cn=Directory Manager' -w Secret123  -H ldap://localhost:1189 << EOF
dn: cn=test_bug1092099,dc=example,dc=com
objectClass: inetorgperson
objectClass: organizationalPerson
objectClass: person
objectClass: top
uid: test_bug1092099
sn: test_bug1092099
cn: test_bug1092099
EOF
adding new entry "cn=test_bug1092099,dc=example,dc=com"

It was replicated to M2:
$ ldapsearch -LLL -x -H ldap://localhost:1189  "(cn=test_bug1092099)" -b dc=example,dc=com
dn: cn=test_bug1092099,dc=example,dc=com
objectClass: inetorgperson
objectClass: organizationalPerson
objectClass: person
objectClass: top
uid: test_bug1092099
sn: test_bug1092099
cn: test_bug1092099

$ ldapsearch -LLL -x -H ldap://localhost:1289  "(cn=test_bug1092099)" -b dc=example,dc=com
dn: cn=test_bug1092099,dc=example,dc=com
objectClass: inetorgperson
objectClass: organizationalPerson
objectClass: person
objectClass: top
uid: test_bug1092099
sn: test_bug1092099
cn: test_bug1092099

Pause replication on M1 and M2:
$ ldapmodify -D "cn=Directory Manager" -w Secret123  -H ldap://localhost:1189 << EOF
dn: cn=1189_to_1626_on_rhel7ds.brq.redhat.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
changetype: modify
replace: nsds5ReplicaEnabled
nsds5ReplicaEnabled: Off
EOF
modifying entry "cn=1189_to_1626_on_rhel7ds.brq.redhat.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"


$ ldapmodify -D "cn=Directory Manager" -w Secret123  -H ldap://localhost:1289 << EOF
dn: cn=1289_to_1616_on_rhel7ds.brq.redhat.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
changetype: modify
replace: nsds5ReplicaEnabled
nsds5ReplicaEnabled: Off
EOF
modifying entry "cn=1289_to_1616_on_rhel7ds.brq.redhat.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"

Delete entry on M1:
$ ldapdelete -D 'cn=Directory Manager' -w Secret123  -H ldap://localhost:1189 cn=test_bug1092099,dc=example,dc=com -v
ldap_initialize( ldap://localhost:1189/??base )
deleting entry "cn=test_bug1092099,dc=example,dc=com"

MODRDN entry on M2:
$ ldapmodify -D 'cn=Directory Manager' -w Secret123  -H ldap://localhost:1289 << EOF
dn: cn=test_bug1092099,dc=example,dc=com
changetype: modrdn
newrdn: cn=test_bug1092099_modified
deleteoldrdn: 1
newsuperior: dc=example,dc=com
EOF
modifying rdn of entry "cn=test_bug1092099,dc=example,dc=com"

Resume replication on M1 and M2
$ ldapmodify -D "cn=Directory Manager" -w Secret123  -H ldap://localhost:1189 << EOF
dn: cn=1189_to_1626_on_rhel7ds.brq.redhat.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
changetype: modify
replace: nsds5ReplicaEnabled
nsds5ReplicaEnabled: On
EOF
modifying entry "cn=1189_to_1626_on_rhel7ds.brq.redhat.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"

$ ldapmodify -D "cn=Directory Manager" -w Secret123  -H ldap://localhost:1289 << EOF
dn: cn=1289_to_1616_on_rhel7ds.brq.redhat.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
changetype: modify
replace: nsds5ReplicaEnabled
nsds5ReplicaEnabled: On
EOF
modifying entry "cn=1289_to_1616_on_rhel7ds.brq.redhat.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"

err=53 wasn't observed in access logs. Hence marking as VERIFIED.

Comment 3 Viktor Ashirov 2014-11-21 20:18:36 UTC

I forgot to mention that I tested this on 
$ rpm -qa | grep 389
389-ds-base-1.3.3.1-9.el7.x86_64
389-ds-base-debuginfo-1.3.3.1-9.el7.x86_64
389-ds-base-libs-1.3.3.1-9.el7.x86_64

Comment 5 errata-xmlrpc 2015-03-05 09:34:28 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0416.html