[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:
>> Hi Howard!  As much as I hate to say this, it did not solve the problem
>> I
>> was running into.  =(  I rebuilt openldap with the entry.c patch and
>> rebuilt the LDAP database from scratch (pulling from sources and using
>> slapadd).  Then I ran the following statement via ldapmodify (as always,
>> XXX'd out sensitive info):
>
> The slapcat output you provide shows that the attribute was already
> slapadded
> incorrectly. Please provide the "pulling from sources" input you used with
> slapadd for this entry.

dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu
objectClass: person
objectClass: inetOrgPerson
objectClass: ncsuPerson
uid: XXX
cn: XXX
sn: XXX
title: Sophomore
ncsuTwoPartName: XXX
organizationalStatus: registered
o: NC State University
gn: XXX
ncsuMiddleName: XXX
initials: XXX
displayName: XXX
ncsuAltDisplayName: XXX
ncsuCampusID: XXX
ncsuClassCode: SO
ou: Political Science - Int Politics Conc
ncsuCurriculumCode: LIP
ou: B A - History
ncsuCurriculumCode: LAH
mail: XXX
ncsuPrimaryEMail: XXX
registeredAddress: XXX
postalAddress: XXX
telephoneNumber: XXX
l: Graham
st: NC
postalCode: XXX
ncsuPrimaryRole: student

Note that I have not changed anything to add the ou's as a group and the
ncsuCurriculumCode's as a group, but from what I understood, this should
work fine for openldap, even if it may or may not be truly legit based off
the RFCs.  And again, I have not changed anything in this code and have
been adding things like this for the past 2 years with OpenLDAP 2.2 and
earlier.  I mean sure I can go edit my code to add those ou's and
ncsucurriculumcodes in the correct order (ie, bunched together), but if
you are saying openldap should be able to handle this, I'd like to stick
with it and see it resolved instead of letting it be a dangling difference
behavior since 2.2.  If you want to make an official-like statement that
what I'm doing there is not proper and not supported, then so be it, I'll
take that as golden and adjust my code.  =)  (in other words, would you
rather it be that this is flat out not supported? .. of course if it's not
supported it would be nicer if openldap yelled about it instead of
accepting it and just being mad afterwards)

I moved away from 2.2 because it looks like you all don't support it
anymore  and I started running into stability problems.  (which we have
not narrowed down to be OpenLDAP's 'fault'..  just upgrading OpenLDAP was
a good first and easy step 1, and actually seems to have helped)

Daniel


> --
>    -- 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/
>