Bug 428232

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