additional info: objectClasses: value #0 invalid per syntax

[Jimmy Royer <jimmy.royer@modelsolv.com>]

Hello,

I am starting out with openldap and I don't know it that much. I got
the error mentioned in the title when trying to add an object class,
which is apparently a very common one per my google searches. I've
read that common causes are:

* extraneous white space (especially trailing white space)
* improperly encoded characters (LDAPv3 uses UTF-8 encoded Unicode)
* empty values (few syntaxes allow empty values)

This is the object class file I am trying to add, I picked it as an
example on some website, to have something minimal and make it easier
to test:

# cat exObjectClasses.ldif
dn: cn=schema
changetype: modify
add: objectClasses
objectClasses: ( 2.16.840.1.113730.3.2.2.9
 NAME 'blogger'
 DESC 'Someone who has a blog'
 SUP inetOrgPerson STRUCTURAL
 MAY blog )

I've checked if there was any trailing spaces at the end with the following:

# cat -vte exObjectClasses.ldif
dn: cn=schema$
changetype: modify$
add: objectClasses$
objectClasses: ( 2.16.840.1.113730.3.2.2.9$
 NAME 'blogger'$
 DESC 'Someone who has a blog'$
 SUP inetOrgPerson STRUCTURAL$
 MAY blog )$

I've made sure the file is UTF-8:

# iconv -f ASCII -t UTF-8 exObjectClasses.ldif > exObjectClasses.ldif.utf8

And I don't think there are any empty values defined in the LDIF file.
So when I type this command, I still have the "invalid per syntax
error:

# ldapmodify -x -W -H "ldaps://127.0.0.1" -D
cn=Manager,dc=modelsolv,dc=com -f exObjectClasses.ldif
Enter LDAP Password:
modifying entry "cn=schema"
ldap_modify: Invalid syntax (21)
        additional info: objectClasses: value #0 invalid per syntax

This is the content of the /etc/openldap/slapd.conf file:

# cat slapd.conf
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#

include         /etc/openldap/schema/corba.schema
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/duaconf.schema
include         /etc/openldap/schema/dyngroup.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/java.schema
include         /etc/openldap/schema/misc.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/openldap.schema
include         /etc/openldap/schema/ppolicy.schema
include         /etc/openldap/schema/collective.schema

# Allow LDAPv2 client connections.  This is NOT the default.
allow bind_v2

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral       ldap://root.openldap.org

pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args

# Load dynamic backend modules
# - modulepath is architecture dependent value (32/64-bit system)
# - back_sql.la overlay requires openldap-server-sql package
# - dyngroup.la and dynlist.la cannot be used at the same time

# modulepath /usr/lib/openldap
# modulepath /usr/lib64/openldap

# moduleload accesslog.la
# moduleload auditlog.la
# moduleload back_sql.la
# moduleload chain.la
# moduleload collect.la
# moduleload constraint.la
# moduleload dds.la
# moduleload deref.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload memberof.la
# moduleload pbind.la
# moduleload pcache.la
# moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload seqmod.la
# moduleload smbk5pwd.la
# moduleload sssvlv.la
# moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la

# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by running
# /usr/libexec/openldap/generate-server-cert.sh. Your client software may balk
# at self-signed certificates, however.
TLSCACertificatePath /etc/openldap/certs
TLSCertificateFile "\"OpenLDAP Server\""
TLSCertificateKeyFile /etc/openldap/certs/password

# Sample security restrictions
#       Require integrity protection (prevent hijacking)
#       Require 112-bit (3DES or better) encryption for updates
#       Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:
#       Root DSE: allow anyone to read it
#       Subschema (sub)entry DSE: allow anyone to read it
#       Other DSEs:
#               Allow self write access
#               Allow authenticated users read access
#               Allow anonymous users to authenticate
#       Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
#       by self write
#       by users read
#       by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn.  (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!

# enable on-the-fly configuration (cn=config)
database config
access to *
        by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
manage
        by * none

# enable server status monitoring (cn=monitor)
database monitor
access to *
        by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
read
        by dn.exact="cn=Manager,dc=my-domain,dc=com" read
        by * none

#######################################################################
# database definitions
#######################################################################

database        bdb
suffix          "dc=modelsolv,dc=com"
checkpoint      1024 15
rootdn          "cn=Manager,dc=modelsolv,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoided.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw          SECRET
# rootpw                {crypt}ijFYNcSNctBYg

# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory       /var/lib/ldap

# Indices to maintain for this database
index objectClass                       eq,pres
index ou,cn,mail,surname,givenname      eq,pres,sub
index uidNumber,gidNumber,loginShell    eq,pres
index uid,memberUid                     eq,pres,sub
index nisMapName,nisMapEntry            eq,pres,sub

# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
#     bindmethod=sasl saslmech=GSSAPI
#     authcId=host/ldap-master.example.com@EXAMPLE.COM


I was able to add a few entries in LDAP so far. So I know I am able to
reach the server, the connection is fine, and LDAP is somewhat
functional. But I can't modify the schema with objectclasses.

Is there anything obvious that I am doing wrong? Do you have any
recommendation for debugging further?

Regards,
Jimmy Royer