<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Greetings,<br>
<br>
At work I have an OpenLDAP daemon running. ( 2.4.28, standard ubu
12.04 repo before someone asks ).<br>
<br>
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.<br>
<br>
I have been taking full advantage of this feature and adding
attributes and classes when I need, rather than planning for
production downtime.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<small><small><br>
<big><big><br>
# ldapmodify -Y EXTERNAL -H ldapi:/// -f ./tmp.ldif<br>
.. ( snip ) ..<br>
modifying entry "cn={5}yst,cn=schema,cn=config"<br>
ldap_modify: Other (e.g., implementation specific) error
(80)<br>
additional info: olcObjectClasses: Duplicate
objectClass: "1.3.6.1.4.1.40605.1.1.1.1.1"<br>
<br>
# /etc/init.d/slapd restart<br>
* Stopping OpenLDAP slapd<br>
...done.<br>
* Starting OpenLDAP slapd<br>
...done.<br>
<br>
# ldapmodify -Y EXTERNAL -H ldapi:/// -f ./tmp.ldif<br>
.. ( snip ) ..<br>
modifying entry "cn={5}yst,cn=schema,cn=config"<br>
<br>
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.<br>
<br>
Thoughts? Is there some face-palming worthy piece of
documentation out there that explains this?<br>
</big></big></small></small><br>
Rob<br>
</body>
</html>