Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 788729 - Reindexing entryrdn fails if ancestors are also tombstoned
Reindexing entryrdn fails if ancestors are also tombstoned
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
6.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Rich Megginson
IDM QE LIST
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-08 17:03 EST by Rich Megginson
Modified: 2012-06-20 03:14 EDT (History)
3 users (show)

See Also:
Fixed In Version: 389-ds-base-1.2.10.0-1.el6
Doc Type: Bug Fix
Doc Text:
Cause: Reindexing (e.g. using db2index) the entryrdn index when there are deleted entries that were converted to tombstone entries in the database. Consequence: Error messages like _entryrdn_insert_key: Getting "nsuniqueid=ca681083-69f011e0-8115a0d5-f42e0a24,ou=People,dc=example,dc=com" failed are seen. Fix: The server correctly handles these child tombstone entries. Result: The entryrdn index can be reindexed with no errors and searches work correctly.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 03:14:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:0813 normal SHIPPED_LIVE Low: 389-ds-base security, bug fix, and enhancement update 2012-06-19 15:29:15 EDT

  None (edit)
Description Rich Megginson 2012-02-08 17:03:26 EST
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/274

Report by Rich:
I have a situation where I have added several entries under ou=people, then deleted all of those entries and ou=people.  When I reindex entryrdn, I do not see all of the tombstone entries in entryrdn, plus I see the following errors:
[30/Jan/2012:20:06:07 -0700] entryrdn-index - _entryrdn_insert_key: Getting "nsuniqueid=ca681083-69f011e0-8115a0d5-f42e0a24,ou=People,dc=vmhost,dc=com" failed: Successful return: 0(0)
Comment 1 Jenny Galipeau 2012-02-14 10:45:06 EST
See upstream ticket for steps to verify
Comment 3 Rich Megginson 2012-04-16 16:19:30 EDT
mmrepl/accept/accept.sh:
# Reindexing entryrdn fils if ancestors are also tombstoned.
bug788729()
Comment 4 Noriko Hosoi 2012-05-24 19:00:16 EDT
    Technical note added. If any revisions are required, please edit the
"Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content
Services team.

    New Contents:
Cause: In case a non-leaf entry is tombstoned, the RDN starts with nsuniqueid. The special RDN in non-leaf entries was not supported.
Consequence: Inserting/traversing the entryrdn index fails if a parent
entry is tombstoned.
Fix: The special RDN of the non-leaf tombstone entry is supported.
Result: Inserting/traversing the entryrdn index works even if tombstone entries are found among non-leaf entries.
Comment 5 Rich Megginson 2012-05-24 19:30:19 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: Reindexing (e.g. using db2index) the entryrdn index when there are deleted entries that were converted to tombstone entries in the database.
Consequence: Error messages like _entryrdn_insert_key: Getting "nsuniqueid=ca681083-69f011e0-8115a0d5-f42e0a24,ou=People,dc=example,dc=com" failed are seen.
Fix: The server correctly handles these child tombstone entries.
Result: The entryrdn index can be reindexed with no errors and searches work correctly.
Comment 6 Amita Sharma 2012-05-29 07:28:07 EDT
mmrepl mmraccept startup 	100% (2/2) 	  	 
mmrepl mmraccept run 	100% (23/23) 	  	 
mmrepl mmraccept cleanup 	100% (1/1)

Hence marking bug as VERIFIED.
Comment 7 errata-xmlrpc 2012-06-20 03:14:00 EDT
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/RHSA-2012-0813.html

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