[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: additional info: objectClasses: value #0 invalid per syntax
2013/2/28 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?
>
Hi,
you can't update schema by acting on cn=subschema branch, this is readonly.
As your are using the old slapd.conf file, you need to create a
.schema file and include it in slapd.conf.
If you want to update schema with LDIF file, change from slapd.conf to
cn=config configuration method.
Clément.
> Regards,
> Jimmy Royer
>