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