#274 Reindexing entryrdn fails if ancestors are also tombstoned
Closed: wontfix None Opened 12 years ago by nhosoi.

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)


Bug description: Inserting/traversing entryrdn fails if a parent
entry is tombstoned and the rdn in the entryrdn index includes
nsuniqueid.

In DIT cn=A,ou=B,o=C, cn=A and ou=B are removed and turned to
tombstone entries. Both of the 2 representations need to be
supported in the entryrdn.
nsuniqueid=...,cn=A,ou=B,o=C and
nsuniqueid=...,cn=A,nsuniqueid=...,ou=B,o=C

Fix description: Support for the second case is added by this patch.
Also, in index_add_mods, code for checking NULL mods is added.

steps to verify:
1. Set up MMR.
2. Add entries, e.g.:
cn=CN0000,ou=OU000,ou=OU00,ou=OU0,dc=example,dc=com
cn=CN0010,ou=OU001,ou=OU00,ou=OU0,dc=example,dc=com
cn=CN0100,ou=OU010,ou=OU01,ou=OU0,dc=example,dc=com
cn=CN0110,ou=OU011,ou=OU01,ou=OU0,dc=example,dc=com
3. Delete ou=OU0 and all the entries under it.
The delete should be done from the leaf entries, then their parents.
4. Test reindex entryrdn
# cd /usr/lib[64]/dirsrv/slapd-ID
# ./db2index -n <backend_instance> -t entryrdn
Following error should not be observed.
entryrdn-index - _entryrdn_insert_key: Getting "nsuniqueid=...,ou=OU##,<suffix>" failed: Successful return: 0(0)
Dump entryrdn using "dbscan -f /path/to/db/<backend_instance>/entryrdn.db#"
and check all the tombstone entries exist.
5. Test export/import
5-1. Stop the server and export the database.
# cd /usr/lib[64]/dirsrv/slapd-ID
# ./db2ldif -r -n <backend_instance>
Exported ldif file: /path/to/<ldiffile>
5-2. Import the file back.
# ./ldif2db -n <backend_instance> -i /path/to/<ldiffile>
No error should be observed.
6. Search tombstone entries.
6-1. Start the server
6-2. $ ldapsearch -LLLx -h localhost -p <port> -D 'cn=Directory manager' \
-w <pw> -b "dc=example,dc=com" "(objectclass=nstombstone)" dn
The command line should return all the tombstone entries.
7. Tombstone reap.
7-1. Stop the server
7-2. Edit the dse.ldif
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
nsds5ReplicaPurgeDelay: 1
nsds5ReplicaTombstonePurgeInterval: 60
7-3. Start the server
7-4. Run ldapsearch as follows and check the count of tombstones periodically.
$ ldapsearch -LLLx -h localhost -p <port> -D 'cn=Directory manager' \
-w <pw> -b "dc=example,dc=com" "(objectclass=nstombstone)" dn | grep dn: | wc -l
Note: you may need to repeat modifying entries on the server to trigger
the tombstone reap.
The count is decreased and eventually goes down to 1 (which is RUV).

Reviewed by Rich (Thank you!!!)

Pushed to master.

$ git merge trac274
Updating 5232b20..e72f4b2
Fast-forward
ldap/servers/slapd/back-ldbm/index.c | 2 +-
ldap/servers/slapd/back-ldbm/ldbm_entryrdn.c | 60 +++++++++++++++++++++++---
2 files changed, 55 insertions(+), 7 deletions(-)

$ git push
Counting objects: 15, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 1.70 KiB, done.
Total 8 (delta 6), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
5232b20..e72f4b2 master -> master

Added test cases bug788729 to mmrepl/accept.

Added initial screened field value.

Metadata Update from @nhosoi:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.2.10.rc1

7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/274

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata