1109337 – Nested tombstones become orphaned after purge

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1109337 - Nested tombstones become orphaned after purge

Summary: Nested tombstones become orphaned after purge

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	389-ds-base
Sub Component:
Version:	6.0
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Noriko Hosoi
QA Contact:	Sankar Ramalingam
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	1109339
TreeView+	depends on / blocked

Reported:	2014-06-13 17:19 UTC by Noriko Hosoi
Modified:	2020-09-13 21:02 UTC (History)
CC List:	4 users (show)
Fixed In Version:	389-ds-base-1.2.11.15-34.el6
Doc Type:	Bug Fix
Doc Text:	Cause: If there are nested tombstone entries, the parents will always be purged first. Consequence: Its child entries are orphaned. Fix: When doing the tombstone purge, process the candidate list in reverse order, which will remove the child entries before the parent entries. Result: No more orphaned tombstone entries are left after purging.
Clone Of:
Clones:	1109339 (view as bug list)
Environment:
Last Closed:	2014-10-14 07:55:23 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Github	389ds 389-ds-base issues 1099	0	None	None	None	2020-09-13 21:02:22 UTC
Red Hat Product Errata	RHBA-2014:1385	0	normal	SHIPPED_LIVE	389-ds-base bug fix and enhancement update	2014-10-14 01:27:42 UTC

Description Noriko Hosoi 2014-06-13 17:19:30 UTC

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

When tombstone purging occurs it will remove a parent tombstone, which leaves any child tombstone entries orphaned.

Comment 1 Noriko Hosoi 2014-06-17 17:52:40 UTC

STEPS:

Set up MMR
Add a tree to the master, e.g.,
  ou=A,<suffix>
  ou=subA,ou=A,<suffix>
  ou=subsubA,ou=subA,ou=A,<suffix>
  uid=user1,ou=subsubA,ou=subA,ou=A,<suffix>

Set small number (e.g., 30 sec) to these config params on all the servers.
nsds5ReplicaPurgeDelay
nsds5ReplicaTombstonePurgeInterval

Restart the servers.
Delete the tree.
Check all the entries in the tree are turned to be a tombstone entry.

Wait for the second set to the purge interval.
Do some modify operation such as add another dummy entry.

Check the tombstone entries which are supposed to have disappeared.
If you see no tombstone entries (especially any orphaned tombstone entry), the fix was verified.

Comment 3 Amita Sharma 2014-07-15 08:33:37 UTC

Set up MMR
==============
[root@dhcp201-155 ~]# netstat -nlp | grep slapd
tcp        0      0 :::13329                    :::*                        LISTEN      25438/ns-slapd      
tcp        0      0 :::30100                    :::*                        LISTEN      25509/ns-slapd      
tcp        0      0 :::30101                    :::*                        LISTEN      25509/ns-slapd      
tcp        0      0 :::30102                    :::*                        LISTEN      25585/ns-slapd      
tcp        0      0 :::30103                    :::*                        LISTEN      25585/ns-slapd      
tcp        0      0 :::30104                    :::*                        LISTEN      25670/ns-slapd      
tcp        0      0 :::30105                    :::*                        LISTEN      25670/ns-slapd      
tcp        0      0 :::30106                    :::*                        LISTEN      25745/ns-slapd      
tcp        0      0 :::30107                    :::*                        LISTEN      25745/ns-slapd 

M1 M2 M3 M4


Add a tree to the master, e.g.,
  ou=A,<suffix>
  ou=subA,ou=A,<suffix>
  ou=subsubA,ou=subA,ou=A,<suffix>
  uid=user1,ou=subsubA,ou=subA,ou=A,<suffix>

ldapsearch after add::
=====================
ldapadd -x -h localhost -p 30100 -D "cn=Directory Manager" -w Secret123  << EOF
# A, example.com
dn: ou=A,dc=example,dc=com
ou: People
ou: A
objectClass: top
objectClass: organizationalunit

# subA, A, example.com
dn: ou=subA,ou=A,dc=example,dc=com
ou: People
ou: subA
objectClass: top
objectClass: organizationalunit

# subsubA, subA, A, example.com
dn: ou=subsubA,ou=subA,ou=A,dc=example,dc=com
ou: People
ou: subsubA
objectClass: top
objectClass: organizationalunit

# 1456, subsubA, subA, A, example.com
dn: uid=1456,ou=subsubA,ou=subA,ou=A,dc=example,dc=com
uid: 1456
givenName: 123
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: 456
cn: 456

# search result
search: 2
result: 0 Success


Set small number (e.g., 30 sec) to these config params on all the servers.
nsds5ReplicaPurgeDelay
nsds5ReplicaTombstonePurgeInterval
Restart the servers.

params set as for all the servers::
====================================
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: nsds5replica
objectClass: extensibleobject
cn: replica
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaId: 4
nsDS5ReplicaType: 3
nsDS5Flags: 1
nsDS5ReplicaBindDN: cn=replication manager,o=fr
creatorsName: cn=directory manager
modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config
createTimestamp: 20140714082219Z
modifyTimestamp: 20140715074050Z
nsState:: BAAAAAAAAAAA28RTAAAAAAAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAA==
nsDS5ReplicaName: e74e637b-0b2f11e4-ab24f43f-6f076c99
nsds5ReplicaPurgeDelay: 30
nsds5ReplicaTombstonePurgeInterval: 30
numSubordinates: 2

[root@dhcp201-155 ~]# service dirsrv restart
Shutting down dirsrv: 
    dhcp201-155...                                         [  OK  ]
    M1...                                                  [  OK  ]
    M2...                                                  [  OK  ]
    M3...                                                  [  OK  ]
    M4...                                                  [  OK  ]
Starting dirsrv: 
    dhcp201-155...                                         [  OK  ]
    M1...                                                  [  OK  ]
    M2...                                                  [  OK  ]
    M3...                                                  [  OK  ]
    M4...                                                  [  OK  ]


Delete the tree.
===================
ldapdelete -x -r -h localhost -p 30100 -D "cn=Directory Manager"  -w Secret123  "ou=A,dc=example,dc=com"

Check all the entries in the tree are turned to be a tombstone entry.
=====================================================================
[root@dhcp201-155 ~]# ldapsearch -x -h localhost -p 30100 -D "cn=Directory Manager" -w Secret123 -b "dc=example,dc=com" "(objectclass=nsTombstone)"
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=nsTombstone)
# requesting: ALL
#

# ffffffff-ffffffff-ffffffff-ffffffff, example.com
dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=example,dc=com
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 53c3933a000000010000
nsds50ruv: {replica 1 ldap://dhcp201-155.englab.pnq.redhat.com:30100} 53c3973b
 000000010000 53c4dc4b000300010000
nsds50ruv: {replica 4 ldap://dhcp201-155.englab.pnq.redhat.com:30106}
nsds50ruv: {replica 2 ldap://dhcp201-155.englab.pnq.redhat.com:30102}
dc: example
nsruvReplicaLastModified: {replica 1 ldap://dhcp201-155.englab.pnq.redhat.com:
 30100} 53c4dc4a
nsruvReplicaLastModified: {replica 4 ldap://dhcp201-155.englab.pnq.redhat.com:
 30106} 00000000
nsruvReplicaLastModified: {replica 2 ldap://dhcp201-155.englab.pnq.redhat.com:
 30102} 00000000

# 52993481-0b3211e4-bc01ffc3-e3d66826, A, example.com
dn: nsuniqueid=52993481-0b3211e4-bc01ffc3-e3d66826,ou=A,dc=example,dc=com
ou: People
ou: A
objectClass: top
objectClass: organizationalunit
objectClass: nsTombstone
nsParentUniqueId: f03f3480-0b2f11e4-bc01ffc3-e3d66826

# 52993482-0b3211e4-bc01ffc3-e3d66826, subA, A, example.com
dn: nsuniqueid=52993482-0b3211e4-bc01ffc3-e3d66826,ou=subA,ou=A,dc=example,dc=
 com
ou: People
ou: subA
objectClass: top
objectClass: organizationalunit
objectClass: nsTombstone
nsParentUniqueId: 52993481-0b3211e4-bc01ffc3-e3d66826

# 52993483-0b3211e4-bc01ffc3-e3d66826, subsubA, subA, A, example.com
dn: nsuniqueid=52993483-0b3211e4-bc01ffc3-e3d66826,ou=subsubA,ou=subA,ou=A,dc=
 example,dc=com
ou: People
ou: subsubA
objectClass: top
objectClass: organizationalunit
objectClass: nsTombstone
nsParentUniqueId: 52993482-0b3211e4-bc01ffc3-e3d66826

# 9a1fc081-0b3211e4-bc01ffc3-e3d66826, 1456, subsubA, subA, A, example.com
dn: nsuniqueid=9a1fc081-0b3211e4-bc01ffc3-e3d66826,uid=1456,ou=subsubA,ou=subA
 ,ou=A,dc=example,dc=com
uid: 1456
givenName: 123
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: nsTombstone
sn: 456
cn: 456
nsParentUniqueId: 52993483-0b3211e4-bc01ffc3-e3d66826

# search result
search: 2
result: 0 Success

# numResponses: 6
# numEntries: 5

Wait for the second set to the purge interval.
===============================================
waited for 30 secs

Do some modify operation such as add another dummy entry.
=========================================================
ldapmodify -x -h localhost -p 30100 -D "cn=Directory Manager" -w Secret123  << EOF
dn: uid=ami,ou=people,dc=example,dc=com
changetype: modify
replace: mail
mail: amsss
EOF

Check the tombstone entries which are supposed to have disappeared.
===================================================================
ldapsearch -x -h localhost -p 30100 -D "cn=Directory Manager" -w Secret123 -b "dc=example,dc=com" "(objectclass=nsTombstone)"

If you see no tombstone entries (especially any orphaned tombstone entry), the fix was verified.
================================================================================
[root@dhcp201-155 ~]# ldapsearch -x -h localhost -p 30100 -D "cn=Directory Manager" -w Secret123 -b "dc=example,dc=com" "(objectclass=nsTombstone)"
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=nsTombstone)
# requesting: ALL
#

# ffffffff-ffffffff-ffffffff-ffffffff, example.com
dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=example,dc=com
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 53c3933a000000010000
nsds50ruv: {replica 1 ldap://dhcp201-155.englab.pnq.redhat.com:30100} 53c3973b
 000000010000 53c4e038000000010000
nsds50ruv: {replica 4 ldap://dhcp201-155.englab.pnq.redhat.com:30106}
nsds50ruv: {replica 2 ldap://dhcp201-155.englab.pnq.redhat.com:30102}
dc: example
nsruvReplicaLastModified: {replica 1 ldap://dhcp201-155.englab.pnq.redhat.com:
 30100} 53c4e037
nsruvReplicaLastModified: {replica 4 ldap://dhcp201-155.englab.pnq.redhat.com:
 30106} 00000000
nsruvReplicaLastModified: {replica 2 ldap://dhcp201-155.englab.pnq.redhat.com:
 30102} 00000000

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Hence VERIFIED.

Comment 4 errata-xmlrpc 2014-10-14 07:55:23 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.

http://rhn.redhat.com/errata/RHBA-2014-1385.html

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