[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#4817) modify "replace" command firing conflict error where it shouldn't be
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...
--
-- 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/