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: ( NAME 'myTest' DESC 'This is only a test' EQUALITY caseIgnoreMatch SYNTAX{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.

  • 1
    Can you post your modify.ldif?
    – Sven
    Jan 12 '12 at 22:21
  • I've updated the question with the contents of modify.ldif and some more observations.
    – theJoe
    Jan 13 '12 at 14:10
  • Does the object cn={15}myschema,cn=schema,cn=config exist? It will not be created automatically if you try to create a sub-entry for this.
    – Sven
    Jan 13 '12 at 14:35
  • You can list all schemas with ldapsearch -A -x -h localhost -D "cn=admin,cn=config" -W -b "cn=config" objectClass="olcSchemaConfig"
    – Sven
    Jan 13 '12 at 14:42
  • Thanks for the command. It appears in ldapsearch as "dn: cn={15}mySchema,cn=schema,cn=config ", and also with the same name when I use an LDAP browser. The entry is most definitely there because we have numerous other entries using its objects. It's just seems like it doesn't like being accessed by that name.
    – theJoe
    Jan 13 '12 at 15:40

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.

  • I couldn't get ldapvi to work properly on my system, but I tried using replace in the ldif instead of add, but it shows the same behavior: it reports an error, the changes seem to go through, but are reset when the service is restarted. Here is how I set up the ldif: dn: cn={15}mySchema,cn=schema,cn=config changetype: modify replace: olcAttributeTypes olcAttributeTypes: ... (existing attributes) olcAttributeTypes: ... olcAttributeTypes: ... (new attribute)
    – theJoe
    Jan 17 '12 at 15:34
  • Got ldapvi working, and the same things occurs. When I try to commit the changes (Action? y) it throws the same error: ldap_modify: No such object (32) Error at: cn={15}mySchema,cn=schema,cn=config If I commit ignoring errors (Action? Y), the changes take until the next service restart.
    – theJoe
    Jan 17 '12 at 16:04
  • @theJoe: extended the answer Jan 17 '12 at 19:21
  • Manually editing the files in slapd.d is how I eventually made the changes, but that's not something I want to get into the habit of doing. This being a bug is a likely explanation. I've always just installed OpenLDAP through yum, which uses a slightly older version. (CentOS 6.2 uses 2.4.23; the latest version is 2.4.28.) I'd need a bit of time to set up a new system if I wanted to test the latest version, compiling from source.
    – theJoe
    Jan 17 '12 at 21:14
  • With CentOS you should be able to use the package from Fedora. Anyway, I'd hit openldap mailing list at this point. Jan 17 '12 at 23:12

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:


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 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.