I recently migrated a client's ldap directories to new servers. I
setup replication from the new servers to the old servers to do the
initial build of the directory and to keep up to date with changes
before the cutover.
In the process we also moved from 2.4.12 to 2.4.33.
I've run into an issue since then with an object that was missing a
structuralObjectClass. When we try to commit modifications to that
object, we received an error that says:
ldap_modify: Other (e.g., implementation specific) error (80)
additional info: no structuralObjectClass operational attribute
Doing a search on that object with +, shows that it is in fact missing
a structuralObjectClass. Other users that we can modify, show that
they do have that attribute. I was able to solve this problem by
doing an ldapsearch on the user and saving to an ldif, ldapdelete the
user, then ldapadd the user back from the ldif file. When re-adding
that user, the structuralObjectClass was created.
It looks like about 50% of our objects are missing that attribute.
To get those numbers, I am searching with:
'(&(objectClass=*)(!(structuralObjectClass=*)))' +
VS
'(&(objectClass=*)(structuralObjectClass=*))' +
What would be the best way for me to fix these issues on every object
that is missing the structuralObjectClass?
Also, in the future, would you recommend I do a slapcat/slapadd or
something like that to populate a new database instead of letting
syncrepl load it for me? Would that have fixed this problem from the
start?
Thanks for any suggestions.
- Dusty Doris
