Description of problem: Version-Release number of selected component (if applicable): current CVS How reproducible: Every time Steps to Reproduce: 1. Attempt to rename cn=ldaptestuser3,cn=users,DC=samba,DC=example,DC=com into cn=ldaptestUSER3,cn=users,DC=samba,DC=example,DC=com Tested using Samba4 LDAP backend onto Fedora DS. Test was ldap.js against Samba4 Actual results: Could not rename cn=ldaptestuser3,cn=users,DC=samba,DC=example,DC=com into cn=ldaptestUSER3,cn=users,DC=samba,DC=example,DC=com: LDAP error 68 LDAP_ENTRY_ALREADY_EXISTS - <LDAP error 68 LDAP_ENTRY_ALREADY_EXISTS - <> <>> <> Expected results: Success Additional info: Rename with same case (ie identical) also fails. Samba4 would work best if this was handled in the same case, allowing a rename to the same value, as well as any equivalent value. http://www.OpenLDAP.org/its/index.cgi?findid=5319
Created attachment 312887 [details] cvs diffs Files: slapi-plugin.h dn.c back-ldbm/ldbm_modrdn.c Description: added additional checks if the original DN and the to-be-updated DN are different in terms of the cases. If the cases do not match, instead of returning LDAP_ALREADY_EXISTS, continue the modrdn process.
Created attachment 312890 [details] modrdn test program How to verify: 1. Replace the modrdn.c in the mozilla ldap client's examples and compile it. 2. Prepare a suffix "dc=example,dc=com" on the test server. 3. run the program $ ./modrdn <port> <directory_manager_password> Added entry "cn=Jacques Smith, dc=example,dc=com". Calling modrdn: "cn=Jacques Smith, dc=example,dc=com" => "cn=Jacques SMITH" The modrdn operation was successful. Entry "cn=Jacques Smith, dc=example,dc=com" has been changed to "cn=Jacques SMITH, dc=example,dc=com".
The code for the fix looks fine, but it seems like Andrew also wanted a MODRDN where the case matches to go through as well. I guess the only reason we'd want to return an error 68 is if the new DN is a different entry that already exists.
(In reply to comment #5) > The code for the fix looks fine, but it seems like Andrew also wanted a MODRDN > where the case matches to go through as well. I wonder which is better "go through" or "return SUCCESS"? > I guess the only reason we'd want > to return an error 68 is if the new DN is a different entry that already exists. That's true! Let me reconsider it some more...
(In reply to comment #6) > (In reply to comment #5) > > The code for the fix looks fine, but it seems like Andrew also wanted a MODRDN > > where the case matches to go through as well. > > I wonder which is better "go through" or "return SUCCESS"? Letting the operation go through would ensure that the modifiedTime gets updated properly, which a client may expect.
Created attachment 312925 [details] cvs diff ldapserver/ldap/servers/slapd/back-ldbm/ldbm_modrdn.c Thanks to Nathan for his suggestions, which were very useful. The new proposal is much simpler. If an entry which share the dn was found, regardless of the case difference, it continues the modrdn process. Note that by checking the original dn and new dn are identical after normalizing them, we could avoid the case that an entry having the original dn does not exist but the one with the new dn already does.
Created attachment 312926 [details] test program modrdn.c As suggested previously, replace modrdn.c with the attachment in mozilla/directory/c-sdk/ldap/examples/, compile it. # first, there is no "cn=Jacques Smith, dc=example,dc=com". This program adds the entry and rename it to "cn=Jacques SMITH, dc=example,dc=com": $ ./modrdn <port> <directory_manager_password> Added entry "cn=Jacques Smith, dc=example,dc=com". Calling modrdn: "cn=Jacques Smith, dc=example,dc=com" => "cn=Jacques SMITH" The modrdn operation was successful. Entry "cn=Jacques Smith, dc=example,dc=com" has been changed to "cn=Jacques SMITH, dc=example,dc=com". # Now "cn=Jacques SMITH, dc=example,dc=com" exists, the test program renames it to itself, which does not fail. $ ./modrdn <port> <directory_manager_password> Entry "cn=Jacques SMITH, dc=example,dc=com is already in the directory. Calling modrdn: "cn=Jacques SMITH, dc=example,dc=com" => "cn=Jacques SMITH" The modrdn operation was successful. Entry "cn=Jacques SMITH, dc=example,dc=com" has been changed to "cn=Jacques SMITH, dc=example,dc=com".
Created attachment 312931 [details] cvs diff ldap/servers/slapd/back-ldbm/ldbm_modrdn.c Thanks, Nathan, for finding out the obsolete comment. I removed it.
Created attachment 312932 [details] cvs commit ldbm_modrdn.c Reviewed by Nathan (Thank you!!!) Checked in ldbm_modrdn.c into CVS HEAD. Note: The test program is attached to verify the fix.
fix verified DS 8.1 RHEL 5 [root@jennyv2 jenny]# ldapsearch -x -h `hostname` -p 389 -D "cn=Directory Manager" -w Secret123 -b "ou=people,dc=bos,dc=redhat,dc=com" "(uid=mmouse)" dn # extended LDIF # # LDAPv3 # base <ou=people,dc=bos,dc=redhat,dc=com> with scope subtree # filter: (uid=mmouse) # requesting: dn # # mmouse, People, bos.redhat.com dn: uid=mmouse,ou=People, dc=bos, dc=redhat, dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@jennyv2 jenny]# ldapmodify -x -h `hostname` -p 389 -D "cn=Directory Manager" -w Secret123 -a -f modrdn.ldif modifying rdn of entry "uid=mmouse, ou=people, dc=bos, dc=redhat, dc=com" rename completed [root@jennyv2 jenny]# ldapsearch -x -h `hostname` -p 389 -D "cn=Directory Manager" -w Secret123 -b "ou=people,dc=bos,dc=redhat,dc=com" "(uid=mmouse)" dn # extended LDIF # # LDAPv3 # base <ou=people,dc=bos,dc=redhat,dc=com> with scope subtree # filter: (uid=mmouse) # requesting: dn # # MMOUSE, People, bos.redhat.com dn: uid=MMOUSE,ou=People, dc=bos, dc=redhat, dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0455.html