daniel(a)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(a)unity.ncsu.edu
ncsuPrimaryEMail: XXX(a)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...
--
-- Howard Chu
Chief Architect, Symas Corp.
http://www.symas.com
Director, Highland Sun
http://highlandsun.com/hyc
OpenLDAP Core Team
http://www.openldap.org/project/