An example entry that should be allowed to delete.
example.ldif

To test, 389-ds-base needs to be rebuilt with -DUNIQID_DEBUG.
{{{
$ diff -twU4 add.c add.c.uniqiddebug
--- add.c 2015-03-13 16:31:16.460261575 -0700
+++ add.c.uniqiddebug 2015-03-13 16:31:19.328224185 -0700
@@ -915,9 +915,13 @@
{
int i, rc = 0;
Slapi_RDN rdn = NULL;
char value = NULL;
- char type[] = {SLAPI_ATTR_UNIQUEID, "modifytimestamp", "modifiersname", "internalmodifytimestamp",
+ char type[] = {
+#if !defined(UNIQID_DEBUG)
+ SLAPI_ATTR_UNIQUEID,
+#endif
+ "modifytimestamp", "modifiersname", "internalmodifytimestamp",
"internalmodifiersname", "createtimestamp", "creatorsname", 0};

 if ((rdn = slapi_rdn_new())) {
     slapi_rdn_init_dn(rdn, slapi_entry_get_dn_const(e));

}}}
Add a test entry having a DN starting with nsuniqueid and no nsTombstone objectclass:
{{{
dn: nsuniqueid=1f67ee81-d2fd11e2-86b7d507-9f846621,uid=tuser0,ou=People,dc=example,dc=com
objectClass: extensibleObject
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: test user0
sn: tuser1
uid: tuser0
givenName: tuser1
mail: tuser0@example.com
}}}
Then delele it:
{{{
$ ldapdelete -x -h localhost -p 389 -D 'cn=directory manager' -W
nsuniqueid=1f67ee81-d2fd11e2-86b7d507-9f846621,uid=TUser0,ou=People,dc=example,dc=com
}}}
Verify the entry is deleted/turned to be a real tombstone entry.
{{{
$ ldapsearch -LLLx -h localhost -p 389 -D 'cn=directory manager' -W -b "ou=People,dc=example,dc=com" "(objectclass=nstombstone)" objectclass
dn: nsuniqueid=fc86d526-c9d111e4-8463a248-b11b6a2b,nsuniqueid=1f67ee81-d2fd11e2-86b7d507-9f846621,uid=TUser0,ou=People,dc=example,dc=com
...
objectclass: nsTombstone
}}}
The tombstone entry will be the target of the tombstone reap.

git patch file (master)
0001-Ticket-48133-Non-tombstone-entry-which-dn-starting-w.patch

Reviewed by Rich (Thank you!!)

Pushed to master:
3c3fe1b..f14fb8b master -> master
commit f14fb8b6f71d2a87b650064f15099a2cc2dfd38a

Pushed to 389-ds-base-1.3.3:
775997f..ff224e7 389-ds-base-1.3.3 -> 389-ds-base-1.3.3
commit ff224e704752aadee5113f4ee02ca297a225a98f

Pushed to 389-ds-base-1.3.2:
0e31f70..fac457e 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit fac457e813721151a6d081aae6614824769cf12d

Pushed to 389-ds-base-1.2.11:
accb863..3579393 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit 3579393628d9f256613e20d4b1ec248ea3feee2e

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1202062

The fix does not or no longer work. It reuses the entry dn as tombstone dn and if it attempts to add it to the cache it fails (because it is already there)

My test is:

create a normal tombstone
db2ldif -r
edit ldif and remove oc tombstone and parentuniqueid from the entry
ldif2db

{{{
ldapsearch -LLL -o ldif-wrap=no -h localhost -p 30522 -x -D "cn=directory manager" -w secret123 -b "ou=people,dc=example,dc=com" dn
dn: ou=People,dc=example,dc=com

dn: cn=xx,ou=People,dc=example,dc=com

dn: cn=yy,ou=People,dc=example,dc=com

dn: cn=y2,ou=People,dc=example,dc=com

dn: nsuniqueid=12432802-920d11e6-ab8d8005-8430f734,ou=People,dc=example,dc=com

dn: cn=y3,ou=People,dc=example,dc=com

dn: cn=z1,ou=People,dc=example,dc=com

$ ldapmodify -h localhost -p 30522 -x -D "cn=directory manager" -w secret123
dn: nsuniqueid=12432802-920d11e6-ab8d8005-8430f734,ou=People,dc=example,dc=com
changetype: delete

deleting entry "nsuniqueid=12432802-920d11e6-ab8d8005-8430f734,ou=People,dc=example,dc=com"

ldap_delete: Operations error (1)
}}}

but modrdn/delete works

A quick question... Is the behaviour in common with the tombstone leap? Is it failing now!?

Replying to [comment:9 nhosoi]:

A quick question... Is the behaviour in common with the tombstone leap? Is it failing now!?

Oops. Sorry... ^leap^reap^. :p

attachment
0001-Ticket-48133-v2-Non-tombstone-entry-which-dn-startin.patch

Question. Is it possible that the dn of the entry already has a nsuniqueid rdn attribute? Your fix removes the check to see if it does, so if the entry rdn already has nsuniqueid, it will get added again?

For example:

nsnuiqueid=72374738478478,uid=mark,nsuniqueid=72374738478478,uid=mark,dc=example,dc=com

Replying to [comment:13 mreynolds]:

Question. Is it possible that the dn of the entry already has a nsuniqueid rdn attribute? Your fix removes the check to see if it does, so if the entry rdn already has nsuniqueid, it will get added again?

For example:

nsnuiqueid=72374738478478,uid=mark,nsuniqueid=72374738478478,uid=mark,dc=example,dc=com

yes. We want to delete an entry with

{{{
dn: nsuniqueid=72374738478478,uid=mark,dc=example,dc=com
}}}
which is NOT a tombstone entry. I don't know how this entyr could be created, but if it exists, it as a normal entry and the deletion should follow the normal process, no special handling of dns. If we do not change the dn of the entry when turning it into the tombstone we fail to add it to the cache. With th eproposed fix the tombstone would be:

{{{
dn: nsuniqueid=72374738478478,nsuniqueid=72374738478478, uid=mark,dc=example,dc=com
}}}

It can be deleted, it is transformed into a tombstone and it is purged in tombstone reaping

Thanks for clarifying my concerns, ack.

committed to master

commit d1cb6995d00f7cc5cd349dff4de2b0740d7bfb71

and 1.3.5

commit f5f24729388c309210c8741e0da39428b024e4a5

Adding a test in lib389.

The test case looks very good, thanks!
One thing that is good to test also, it is to make search to make sure that entry was really deleted.

Also, I am on PTO next few days, so other team members can feel free to 'ack' the change and push it.

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/1464

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.