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