2013/2/28 Jimmy Royer <[email protected]>: > 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/[email protected] > > > 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 >
