daniel@ncsu.edu wrote:
Hrm. Well I don't know what caused it in the first place, but get this... performing this set of operations fixed it altogether:
dn: uid=USERNAME,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, even the original method works just fine:
dn: uid=USERNAME,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
I guess I can just keep an eye on it and see if this happens again, but it's not exactly confidence inspiring. =)
It's too bad you didn't save a copy of the original data for us to dissect, but what you've described so far sounds like these entries actually had two separate instances of the ou attribute. Ordinarily that should never
Ya know what! Now that you said, that, I actually -do- have a copy of the data in ldif dump format. (pulled via slapcat) Is that what would be useful to see?
happen. What commands did you use to initially populate the database? If you
I used slapadd to populate the database initially.
repeat that (on a separate, fresh database) does the same problem recur?
I've test that theory if I can find some resources to try it with. (kinda 'strapped' at the moment so to speak)
Little background, our LDAP service is 100% pulled from other sources. Wiping it and rebuilding it from scratch is always possible. (in other words, no end users make changes directly, the only thing that makes any modifications what-so-ever is the update script we run on the master ldap server which generates ldif files of what -should- be in the database, then via some scripts that come with ... Net::LDAP? some perl module, not remembering off the top of my head... ldifsort, ldifdiff, etc ... I compare the last build to todays build and push the modifications via ldapmodify.
If this occurs again, what all would be useful for me to pull aside before fixing it? I'll make a point of doing so.
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/