Greetings,
At work I have an OpenLDAP daemon running. ( 2.4.28, standard ubu 12.04 repo before someone asks ).
For those who don't know: OpenLDAP as of 2.3+ allows the storage of the LDAP schema to reside in LDAP. As a result, you can modify the schema in runtime.
I have been taking full advantage of this feature and adding attributes and classes when I need, rather than planning for production downtime.
I couldn't for the life of me figure out why replacing an olcObjectClass in runtime wasn't working properly. I was getting a "Duplicate objectClass" error. That may seem like a simple fix. It would have been if it actually had been a duplicate.
I spent quite a long time working away, turning OpenLDAP debug up to 9 which is copious in and of itself. In the end this is what I found.
My guess is that I have stumbled upon an OpenLDAP bug, or perhaps that some developer designed it to on SIGHUP refresh its internal structures.
# ldapmodify -Y EXTERNAL -H ldapi:/// -f ./tmp.ldif .. ( snip ) .. modifying entry "cn={5}yst,cn=schema,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: olcObjectClasses: Duplicate objectClass: "1.3.6.1.4.1.40605.1.1.1.1.1"
# /etc/init.d/slapd restart * Stopping OpenLDAP slapd ...done. * Starting OpenLDAP slapd ...done.
# ldapmodify -Y EXTERNAL -H ldapi:/// -f ./tmp.ldif .. ( snip ) .. modifying entry "cn={5}yst,cn=schema,cn=config"
I am inclined to believe this is a bug in OpenLDAP because the first time after a fresh start I am able to make the modification, with the same LDIF.
Thoughts? Is there some face-palming worthy piece of documentation out there that explains this?
Rob