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