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 f14fb8b

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

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

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

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 d1cb699

and 1.3.5

commit f5f2472

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.