Bug 1390809 - Non tombstone entry which dn starting with "nsuniqueid=...," cannot be deleted
Summary: Non tombstone entry which dn starting with "nsuniqueid=...," cannot be deleted
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.2
Hardware: All
OS: Linux
urgent
high
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 1402030
TreeView+ depends on / blocked
 
Reported: 2016-11-02 00:59 UTC by Marc Sauton
Modified: 2017-08-01 21:12 UTC (History)
8 users (show)

Fixed In Version: 389-ds-base-1.3.6.1-3.el7
Doc Type: Bug Fix
Doc Text:
Bug: Trying to delete a non tombstone entry fails when the generated tombstone is added to the cache. Fix: Create a tombstone dn regardless of the rdn which starts with nsuniqueid or not. Result: No more deleting entries fail.
Clone Of:
: 1402030 (view as bug list)
Environment:
Last Closed: 2017-08-01 21:12:24 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2086 normal SHIPPED_LIVE 389-ds-base bug fix and enhancement update 2017-08-01 18:37:38 UTC

Description Marc Sauton 2016-11-02 00:59:55 UTC
Description of problem:

this is a copy of the RHEL 6 bz 1202062, that was temporarily solved with 389-ds-base-1.2.11.15-60.el6. in the errata
https://rhn.redhat.com/errata/RHBA-2015-1326.html

the problem is the issue recently appeared again with 389-ds-base-1.2.11 on RHEL 6, not clear exactly when, but the upstream ticket 48133 for 389-ds-base-1.3.4 had been re-opened:
https://fedorahosted.org/389/ticket/48133#comment:7

although the recent problem was reported on RHEL 6 via the salesforce case number 01709084, this bugzilla report is to track the issue for RHEL 7.

there is a workaround:
rename those conflict entries with the incorrect DN as "dummy" entries and then delete them.
the difficulty is there has been a lot of such replication conflict entries that cannot be deleted in the salesforce case number 01709084, with 2xMMR 389-ds-base-1.2.11.15-74.el6
the workaround has been scripted, but new conflicts appears again fast, in the thousands in a few hours, depending on the LDAP traffic, the case 01709084 attachment 260 [details]-case_01709084.zip has some samples.


Version-Release number of selected component (if applicable):

was reported on RHEL 6 with 389-ds-base-1.2.11.15-74.el6.x86_64


How reproducible:
N/A
but it is though the many LDAP clients used in the customer's environment do create some interesting situations as there had been other problems:
- replication halt on modrdn conflict, err=53, bz 1382784 (fixed in RHEL 7, no RHEL6 backport possible)
- customer application not aware of replication conflict entries with nuuniqueid creating other conflicts and failures on customer site, long term rfe with bz 747701 to store replication conflicts in dedicated suffix


Steps to Reproduce:
we do not exactly know how those entries appeared
from upstream ticket 48133 comment 7 at https://fedorahosted.org/389/ticket/48133#comment:7

1. create a normal tombstone
2. db2ldif -r
3. edit ldif and remove oc tombstone and parentuniqueid from the entry
4. ldif2db


Actual results:

operation error when trying to delete the "conflicts":

[13/Oct/2016:18:55:38 -0300] conn=2632557 op=1 DEL dn="nsuniqueid=65f2c7a1-580111e6-9ad19ecf-c04433d2,ou=xxxxx,dc=xxxxx,dc=xxxx,dc=xxx,dc=xx"
[13/Oct/2016:18:55:38 -0300] conn=2632557 op=1 RESULT err=1 tag=107 nentries=0 etime=0 csn=580004700006000a0000

replication log:

[13/Oct/2016:18:55:38 -0300] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 580004700006000a0000 into pending list
[13/Oct/2016:18:55:38 -0300] - tombstone entry nsuniqueid=65f2c7a1-580111e6-9ad19ecf-c04433d2,ou=xxxxx,dc=xxxxx,dc=xxxx,dc=xxx,dc=xx failed to add to the cache: -1
[13/Oct/2016:18:55:38 -0300] NSMMReplicationPlugin - conn=2632557 op=1 csn=580004700006000a0000 process postop: canceling operation csn


Expected results:


Additional info:

a few conflicts samples from the customer in sf 01709084 attachment 260 [details]-case_01709084.zip file nodo02.nsds5ReplConflict.log were for those objects only:
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: shadowAccount

but the ineteresting cn like cn=27355767200 did not appear in any of the collected logs from attachment 260 [details]-case_01709084.zip
files
sosreport-ansesrhds01.01709084-20161018115052-de6b.tar.xz/ansesrhds01-2016101811491476802172/var/log/dirsrv/slapd-ansesrhds01/access.20161018-074121
sosreport-ansesrhds02.01709084-20161018115042-b206.tar.xz/ansesrhds02-2016101811491476802142/var/log/dirsrv/slapd-ansesrhds02/access.20161018-081142

Comment 10 Sankar Ramalingam 2017-05-23 11:36:15 UTC
[0 root@qeos-46 tickets]# py.test -v ticket48133_test.py 
=================== test session starts ========================
platform linux2 -- Python 2.7.5, pytest-3.1.0, py-1.4.33, pluggy-0.4.0 -- /usr/bin/python
cachedir: .cache
metadata: {'Python': '2.7.5', 'Platform': 'Linux-3.10.0-663.el7.x86_64-x86_64-with-redhat-7.4-Maipo', 'Packages': {'py': '1.4.33', 'pytest': '3.1.0', 'pluggy': '0.4.0'}, 'Plugins': {'beakerlib': '0.7.1', 'html': '1.14.2', 'cov': '2.5.1', 'metadata': '1.5.0'}}
DS build: 1.3.6.1
389-ds-base: 1.3.6.1-9.el7
nss: 3.28.4-6.el7
nspr: 4.13.1-1.0.el7_3
openldap: 2.4.44-4.el7
svrcore: 4.1.3-2.el7

rootdir: /mnt/tests/rhds/tests/upstream/ds/dirsrvtests/tests/tickets, inifile:
plugins: metadata-1.5.0, html-1.14.2, cov-2.5.1, beakerlib-0.7.1
collected 1 items 

ticket48133_test.py::test_delete_dn_with_nsuniqueid PASSED

================= 1 passed in 26.44 seconds ===================

Based on upstream test results, marking the bug as Verified.

Comment 11 Sankar Ramalingam 2017-05-23 11:42:32 UTC
Verified with the latest 389-ds-base-1.3.6.1-14.

[0 root@qeos-46 tickets]# py.test -v ticket48133_test.py 
=================== test session starts =======================
platform linux2 -- Python 2.7.5, pytest-3.1.0, py-1.4.33, pluggy-0.4.0 -- /usr/bin/python
cachedir: .cache
metadata: {'Python': '2.7.5', 'Platform': 'Linux-3.10.0-663.el7.x86_64-x86_64-with-redhat-7.4-Maipo', 'Packages': {'py': '1.4.33', 'pytest': '3.1.0', 'pluggy': '0.4.0'}, 'Plugins': {'beakerlib': '0.7.1', 'html': '1.14.2', 'cov': '2.5.1', 'metadata': '1.5.0'}}
DS build: 1.3.6.1
389-ds-base: 1.3.6.1-14.el7
nss: 3.28.4-8.el7
nspr: 4.13.1-1.0.el7_3
openldap: 2.4.44-4.el7
svrcore: 4.1.3-2.el7

rootdir: /mnt/tests/rhds/tests/upstream/ds/dirsrvtests/tests/tickets, inifile:
plugins: metadata-1.5.0, html-1.14.2, cov-2.5.1, beakerlib-0.7.1
collected 1 items 

ticket48133_test.py::test_delete_dn_with_nsuniqueid PASSED

================== 1 passed in 24.82 seconds ===============

Comment 12 errata-xmlrpc 2017-08-01 21:12:24 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://access.redhat.com/errata/RHBA-2017:2086


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