Unable to modify schema in OpenLDAP using run-time configuration cn=config

Question

I'm having trouble modifying the schema of an OpenLDAP installation using the run-time configuration (cn=config). What I'm trying to do is modify existing attributes and add new ones to a custom schema. The error I'm getting when I try to apply the changes is "no such object" or "no such value." When using the JXplorer browser, the error is:

javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name 'cn={15}mySchema,cn=schema,cn=config'

Using ldapmodify on an ldif file from the command line throws the same error:

ldapmodify -h ldap://localhost/cn=config -x -p 389 -D cn=admin,cn=config -W -f modify.ldif
modifying entry "cn={15}mySchema,cn=schema,cn=config"
ldap_modify: No such object (32)

What's odd, though, is that even though this error occurs, the changes are committed for the current instance of the slapd service. E.g., if I added new attributes and modified an object to include those attributes, then those attributes are available in the entries that use that object. I can proceed as if the changes worked. If the slapd service is restarted, however, the changes are reverted.

If I remove the leading {15} of the DN in the ldif file, or the similar prefix on the attribute value, I get the same error (though probably for a different reason):

modifying entry "cn=mySchema,cn=schema,cn=config"
ldap_modify: No such object (32)
        matched DN: cn=schema,cn=config

What's more, I can modify the other entries of cn=config (e.g., olcDatabase={-1}frontend,cn=config) without issue, and changes persist across service restarts. It is only when I try to modify the entries under cn=schema,cn=config that the error occurs.

The server is running CentOS 6.2, 64-bit, using OpenLDAP 2.4.23, which was installed via yum. I've tried multiple browsers (JXplorer, Softerra LDAP Administrator), as well as the command line, all with the same results. The owner/group of the slapd.d directory is ldap/ldap, and there is no change even when the permissions of the schema files are modified to 777. Using TLS over port 636 (either browser or command line) also has no effect.

Can anyone shed some light on this and explain what could be preventing me from modifying the schema through cn=config?

EDIT: Here is the contents of modify.ldif:

dn: cn={15}mySchema,cn=schema,cn=config
changetype: modify
add: olcAttributeTypes
olcAttributeTypes: ( 1.3.6.1.4.00000.2.3.14 NAME 'myTest' DESC 'This is only a test' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

We are using our company PEN in place of 00000, and no other attribute is using that OID. I found that adding a numerical prefix to the attribute value doesn't make a difference, but the prefix is necessary for the DN; without it, the error means what it says and the directory is not modified.

Answer 1

If there are other olcAttributeTypes in the entry then you have to do a replace not add and list all the other attributes already in LDAP.

Try to use ldapvi for editing, it will do it automatically.

EDIT: If that doesn't work, then you'll need to stop slapd and edit files in /etc/ldap/slap.d/ manually. That certainly isn't a solution when the changes are relatively often...

Editing schema in cn=config is a new feature, you may have found a bug (possibly already fixed in newest version). Check OpenLDAP ChangeLog and try using newest version.

Answer 2

I am still seeing this same behavior in OpenLDAP on Ubuntu. I have been trying to replace the SSL certificate on my OpenLDAP instance and found that the directions at the Ubuntu wiki site do not work:

https://help.ubuntu.com/lts/serverguide/openldap-server.html#openldap-tls

Specifically, these instructions:

Create the file certinfo.ldif with the following contents (adjust accordingly, our example assumes we created certs using https://www.cacert.org):

dn: cn=config
changetype: modify
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
-
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap01_slapd_cert.pem
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pem

Use the ldapmodify command to tell slapd about our TLS work via the slapd-config database:

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/ssl/certinfo.ldif

(Note that I have changed the original add commands to replace, but the original add commands did not work on a fresh install either).

I found a techNote at this CentOS site:

https://www.centos.org/docs/5/html/CDS/cli/8.0/Configuration_Command_File_Reference-Core_Server_Configuration_Reference-Accessing_and_Modifying_Server_Configuration.html

2.2.2.2. Restrictions to Modifying Configuration Entries and Attributes

Certain restrictions apply when modifying server entries and attributes:

The cn=monitor entry and its child entries are read-only and cannot be modified, except to manage ACIs.

If an attribute is added to cn=config, the server ignores it.

If an invalid value is entered for an attribute, the server ignores it.

Because ldapdelete is used for deleting an entire entry, use ldapmodify to remove an attribute from an entry.

This note seems to be saying that you can't add attributes to cn=config with ldapmodify. I thought the way you modified cn=config was with ldapmodify.

I have seen other posts that seem to indicate this state of things. I have put in a question on the OpenLDAP mailing list and will update my post with any answers I receive.