daniel@ncsu.edu wrote:
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 =) )
Thanks for the report, this now fixed in HEAD and RE23. Just as an fyi, slapcat should never produce a result like this, with attributes interleaved. It's hard to tell from RFC2849 but I'm pretty certain that it's invalid for normal input too, but we accept it anyway (and clean it up, when everything is working right). Unfortunately the grammar in the LDIF spec is inadequate and the text of the spec doesn't make any explicit statements to cover the grammar's deficiencies, so we see a lot of generated LDIF that is questionable...