(ITS#4817) modify "replace" command firing conflict error where it shouldn't be

[daniel@ncsu.edu]

Full_Name: Daniel Henninger
Version: 2.3.32
OS: Solaris 8
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (152.1.4.40)


Using ldapmodify to replace an attribute, 'ou', with it's new settings (in this
case, two ou entries):

dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu
changetype: modify
replace: ou
ou: B A - Physics
ou: B S - Philosophy
-
replace: ncsucurriculumcode
ncsucurriculumcode: PYA
ncsucurriculumcode: LSL

Caused an error:
Jan 26 08:07:18 uni00ds.unity.ncsu.edu slapd[13230]: [ID 588225 local4.debug]
co
nn=62 op=4011 RESULT tag=103 err=20 text=modify/replace: ou: value #0 already
ex
ists

(both are multivalued fields and should be fine)

The way I had to fix it was to remove the attributes and retry:
dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu
changetype: modify
delete: ou
-
replace: ou
ou: B A - Physics
ou: B S - Philosophy
-
delete: ncsucurriculumcode
-
replace: ncsucurriculumcode
ncsucurriculumcode: PYA
ncsucurriculumcode: LSL

After that I can perform the original:
dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu
changetype: modify
replace: ou
ou: B A - Physics
ou: B S - Philosophy
-
replace: ncsucurriculumcode
ncsucurriculumcode: PYA
ncsucurriculumcode: LSL

set as many times as I want just fine.  I've had "one a day" of these since
upgrading to 2.3.32.  (note that we do daily updates)  It appears to have
something to do with the order in which I slapadd'd these.  Here's the LDIF (via
slapcat) from before I 'fixed' it:

dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu
objectClass: person
objectClass: inetOrgPerson
objectClass: ncsuPerson
uid: XXX
cn: XXX
sn: XXX
title: Senior
ncsuTwoPartName: XXX
organizationalStatus: registered
o: NC State University
gn: XXX
initials: XXX
displayName: XXX
ncsuAltDisplayName: XXX
ncsuCampusID: XXX
ncsuClassCode: SR
ou: Physics
ncsuCurriculumCode: PY
ou: B S - Philosophy
ncsuCurriculumCode: LSL
mail: XXX@unity.ncsu.edu
ncsuPrimaryEMail: XXX@unity.ncsu.edu
registeredAddress: XXX
postalAddress: XXX
telephoneNumber: XXX
l: Raleigh
st: NC
postalCode: 27603
ncsuPrimaryRole: staff

Obviously I XXX'd out everything sensitive.  Note the ordering of ou and
ncsucurriculumcode and ou again and ncsucurriculumcode.  (this worked fine in
the 2.2 series which I migrated from, and as far as I can tell is perfectly
legit  =)  )

According to Howard Chu from the mailing list, this appears to have to do with..
well I'll quote him:

I see that slapadd is doing a case-sensitive comparison on its input attribute
names, when it should be using case-insensitive. That's probably the problem.
Once the data's gone into the DB and come out again via slapcat, all of the
attribute names are normalized, so any case differences would have disappeared.