Red Hat Bugzilla – Bug 1092099
A replicated MOD fails (Unwilling to perform) if it targets a tombstone
Last modified: 2015-03-05 04:34:28 EST
+++ 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".
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.
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
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