Bug 1092099 - A replicated MOD fails (Unwilling to perform) if it targets a tombstone
Summary: A replicated MOD fails (Unwilling to perform) if it targets a tombstone
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.1
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On: 1092097
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-28 18:15 UTC by Noriko Hosoi
Modified: 2015-03-05 09:34 UTC (History)
3 users (show)

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
Clone Of: 1092097
Environment:
Last Closed: 2015-03-05 09:34:28 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0416 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

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


Note You need to log in before you can comment on or make changes to this bug.