Hide Forgot
This bug is created as a clone of upstream ticket: https://fedorahosted.org/389/ticket/47422 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.
1. Install directory server $ rpm -qa | grep 389-ds 389-ds-base-debuginfo-1.3.3.1-11.el7.x86_64 389-ds-base-1.3.3.1-11.el7.x86_64 389-ds-base-libs-1.3.3.1-11.el7.x86_64 2. The subtree rename switch is OFF I edited the template to use nsslapd-subtree-rename-switch: off by default: $ sudo sed -i "s/nsslapd-subtree-rename-switch: on/nsslapd-subtree-rename-switch: off/g" /usr/share/dirsrv/data/template-dse.ldif 3. Configure 2 multi master (M1 and M2) 4. Add a user on M1 $ ldapmodify -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 -a << EOF dn: cn=user1,ou=People,dc=example,dc=com objectClass: inetUser objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: user1 sn: user1 EOF adding new entry "cn=user1,ou=People,dc=example,dc=com" 5. Restart the M1 instance $ sudo systemctl restart dirsrv@M1.service 6. Remove the user entry and run ldapsearch to confirm the deletion $ ldapdelete -v -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 "cn=user1,ou=People,dc=example,dc=com" ldap_initialize( ldap://localhost:1189/??base ) deleting entry "cn=user1,ou=People,dc=example,dc=com" $ ldapsearch -LLL -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 -b "dc=example,dc=com" "cn=user1" $ 7. Re-add the user: $ ldapmodify -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 -a << EOF dn: cn=user1,ou=People,dc=example,dc=com objectClass: inetUser objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: user1 sn: user1 EOF adding new entry "cn=user1,ou=People,dc=example,dc=com" $ ldapsearch -LLL -D "cn=Directory Manager" -w Secret123 -H ldap://localhost:1189 -b "dc=example,dc=com" "cn=user1" dn: cn=user1,ou=People,dc=example,dc=com objectClass: inetUser objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: user1 sn: user1 Entry was successfully added, marking as VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0416.html