#47422 With 1.3.04 and subtree-renaming OFF, when a user is deleted after restarting the server, the same entry can't be added
Closed: wontfix None Opened 7 years ago by baburaje12.

Here are the steps for reproducing the issue :

1.Install 1.3.04 directory server
2.The subtree rename switch is OFF
3.Configure 2 multi master (M1 and M2)
4.Add a user on M1
5.Restart the M1 instance
6.Remove the user entry and run ldapsearch to confirm the deletion
7.Re-add the user (fails with Already exists)
root@xxx:/usr/sbin# ldapmodify -a -h dirsrv12-xxx -p xxx -D "cn=Directory Manager" -w "xyz123" -f /home/dirsrv12/replication/abc5.ldif adding new entry "uid=abc 5,ou=People,dc=asiapacific,dc=hpqcorp,dc=net" ldap_add: Already exists (68)

The problem is seen only in the case of replication environment and with subtree-rename OFF.

In the case of subtree-rename OFF in a replication environment, it is observed that, after the deletion of the entry, its index is not cleared from the entrydn.db4. This stale entry in the entrydn.db4 seems to be causing the error reported.

static char *protected_attrs_all [] = {PSEUDO_ATTR_UNHASHEDUSERPASSWORD,

Upon further investigation, it has been observed that "SLAPI_ATTR_ENTRYDN" had been included as part of "protected_attrs_all" in entry.c which is causing the "entrydn" attribute to be skipped from writing into the database (id2entry.db4) though the entry in the cache has the same attribute in it. As this attribute is missing in the database, upon restart, cache, which is populated from this database will not have this attribute as part of the entry. Thus the corresponding index in the entrydn.db4 is not cleared when that particular entry is deleted ( after restart).

So, the fix is to not to skip writing "entrydn" attribute into the database, when subtree rename is turned OFF.

The following changes should fix this issue.

Before Fix :

is_type_protected(const char type)
paap = NULL;
for (paap = protected_attrs_all; paap &&
paap; paap++) {
if (0 == strcasecmp(type, *paap)) {
return 1;
return 0;

Fix :

is_type_protected(const char type)
*paap = NULL;

for (paap = protected_attrs_all; paap && *paap; paap++) {
    if (0 == strcasecmp(type, *paap)) {
    /*  Protect SLAPI_ATTR_ENTRYDN only when subtree-rename feature is ON. Or else, when subtree-rename is OFF, */
    /*  the entry from the entrydn.db4 is not removed when the entry is deleted from the database. */
        if (!(entryrdn_get_switch()) && ((strcasecmp(*paap,SLAPI_ATTR_ENTRYDN)) == 0)) {
            return 0;
        } else {
            return 1;

return 0;

Bug description:
1) As reported by baburaje12, regardless of the nsslapd-subtree-
rename-switch, "entrydn" was not stored in the id2entry db. The
attribute value had to be stored in the db file if the switch
was off. Attribute values to avoid storing in the db file are
maintained in an array protected_attrs_all statically. "Entrydn"
should be dynamic depending on the switch.
2) When the switch is off, import was skipping to generate the
parentid index, which leads to skipping to create the entrydn,
as well.
Fix description:
1) Instead of keeping "entrydn" in the protected_attrs_all statically,
this patch introduces an api set_attr_to_protected_list to add or
remove "entrydn" based upon the value of nsslapd-subtree-rename-
2) The condition to create a parentid index is fixed to always
create it if the nsslapd-subtree-rename-switch is off.

Reviewed by Rich (Thank you!!)

Pushed to master:
b23a66b..72a3f9b master -> master
commit 39ba12b

Metadata Update from @nkinder:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.3.3 - 10/13 (October)

3 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/759

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 months ago

Login to comment on this ticket.