Search scope base with a dn of tombstone (from mod_delete) yields no results. The same search with scope subtree operates correctly.
# WORKS ldapsearch -H ldap://localhost:39001 -D 'cn=Directory Manager' -w password -s sub -b 'nsuniqueid=c04c0107-e4a611e7-b5dae1e9-cbd6b25a,uid=testuser,ou=People,dc=example,dc=com' '(objectclass=nsTombStone)' \* + # FAILS ldapsearch -H ldap://localhost:39001 -D 'cn=Directory Manager' -w password -s base -b 'nsuniqueid=c04c0107-e4a611e7-b5dae1e9-cbd6b25a,uid=testuser,ou=People,dc=example,dc=com' '(objectclass=nsTombStone)' \* +
in base_candidates we call find_entry with flags of 0 (missing TOMBSTONE_INCLUDED). However, setting this to TOMBSTONE_INCLUDED did no correct the behaviour (and may cause other issues).
@lkrispen indicated this may be related to the entryrdn index, however a proper investigation is required to the cause and fix.
this is a effect of the specific tombstone dn format chose, where a tombstone technically has 2 rdns and always requires a specila handling. The optimal fix would be to implement #49507 and get rid of special handling.
I did investigate a bit where base searches and modify ops go wrong and have a fix working for these issues, but it looks as if there could be more cleanup (even with the special rdn), and I have not run wide regression tests. I'll attach the patch as it is now for comments
Metadata Update from @lkrispen: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None
<img alt="0001-better-handling-of-tombstone-dns.patch" src="/389-ds-base/issue/raw/files/9332f56dfc1874da5fc625e8dac6824397104fade164e2f4a351ec6a6a83efd6-0001-better-handling-of-tombstone-dns.patch" />
Thanks for the patch for this!
Would you mind explaining to me what the three sections do and why it fixes them as I'm curious about the root cause and the fix?
Otherwise the code looks good, very simple change. I have not yet applied and tested it though, I'll do that shortly.
I can confirm this fixes my issue that I was having. I'm expanding the replication tombstone test case to exercise this patch as well.
The patch looks good and tests are successful. Just a question regarding slapi_is_special_rdn. Now it returns 1 only if the tombstone rdn is not the RUV. I have not found this function in the external doc does this mean it is purely DS core stuff. Also the flag is_tombstone in no more used in _slapi_rdn_init_all_dn_ext, so it could be removed from the callers
Ahh yes, good spot @tbordaz, it would be good to remove another special case flag.
@lkrispen I know you are busy with other patches right now, but I want to say that I have been testing this for a while with replication test suite and some extra cases, and can confirm it works. :) Would be great to have this finished once you are finished your other pressing tasks mate,
@lkrispen Can you merge this? A few weeks of testing from me and I think it looks good.
Metadata Update from @firstyear: - Custom field reviewstatus adjusted to ack (was: None)
Metadata Update from @mreynolds: - Issue set to the milestone: 1.3.7.0
@lkrispen - is this still applicable?
Metadata Update from @mreynolds: - Issue set to the milestone: 1.4.2 (was: 1.3.7.0)
need to check
Metadata Update from @vashirov: - Issue set to the milestone: 1.4.3 (was: 1.4.2)
@elkris - is this still applicable? need to check
@elkris - is this still applicable?
Just checking in again. The doc folks were asking about this one...
Metadata Update from @mreynolds: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1527379
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/2565
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.