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