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.