title: A character (or more) too far link: https://onemoretech.wordpress.com/2010/12/20/a-character-or-more-too-far/ author: lembobro description: post_id: 97 created: 2010/12/20 12:22:45 created_gmt: 2010/12/20 12:22:45 comment_status: open post_name: a-character-or-more-too-far status: publish post_type: post

A character (or more) too far

Was experimenting this morning with a new custom schema for the OpenLDAP server on my desk. Now this is the shipping version that comes with Red Hat Enterprise Linux (RHEL) 5, so doing that sort of thing is normally pretty straightforward. Of course OpenLDAP is notoriously picky when it comes to schema modifications, so you can usually expect something to go wrong on the first try. And it did.

In this particular case I used my handy ns2oldap.pl script to convert an existing Sun Directory 5 schema into its OpenLDAP counterpart. What followed was a typical adventure in debugging a slapd configuration error that some might find helpful.

After pointing my aforementioned schema converting script at the target Sun directory server and copying the resulting file into /etc/openldap/schema, I stopped slapd (/etc/init.d/ldap start) and edited /etc/openldap/slapd.conf to add the new file to the list of schema files in that config. On starting slapd up again (/etc/init.d/ldap start), I saw the following error message in my console:

[root@myhost schema]# /etc/init.d/ldap start

Checking configuration files for slapd:  /etc/openldap/schema/company.schema: line 698: Unexpected token before
ObjectClassDescription = "(" whsp
  numericoid whsp                 ; ObjectClass identifier
  [ "NAME" qdescrs ]
  [ "DESC" qdstring ]
  [ "OBSOLETE" whsp ]
  [ "SUP" oids ]                ; Superior ObjectClasses
  [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
                                  ; default structural
  [ "MUST" oids ]               ; AttributeTypes
  [ "MAY" oids ]                ; AttributeTypes
  whsp ")"
slaptest: bad configuration file!
[FAILED]

Basically what this meant was that there was something on line 698 that, in the opinion of slapd, wasn't quite right.

What the particular "what" was, wasn't particularly easy to determine. In this case line 698 contained the mother of all "MAY" directives, or at least the longest "MAY" directive I've ever worked with. The schema object was the primary custom object class for users on my directory, so fixing it wasn't at all optional.

After re-writing that particular objectclass declaration a few times, removing and then re-inserting whitespace characters (the "Unexpected token before …", usually indicates either too many or too few whitespace characters in a line of the schema), as well as removing and then re-inserting various attribute names I finally tried breaking up that really long (2,397 characters long, to be exact) "MAY" string into a number of lines less than 100 characters long (I entered a newline between the end of each attribute name falling in the 80 - 100 character range, and the $ for the next attribute. The resulting "MAY" definition, which had all been on one line before, now looked something like this:

MAY(lembolockoutflag $ lemboreporthomefolder $ lemboreportrole&nbsp $ lemboappr
 ole $ lemboextsysid $ lemboappcfg $ lemboassistantname $ lembobigcrole $ lembo
 bldgfloor $ lemboappuserqueue $ lemboexternaltitle $ lemboencryptval $ lemboor
 ganizationalcode $lemboaccountunit $ lemboudcrole $ lemboudccountry $ lemboudc
 region $ lemboudcrole )

That seemed to do the trick, because slapd moved on to barking about one, then another, attribute allowed by my custom objectclass as not being defined in the schema (easily fixed by adding attributetypes definitions in the file for each of the missing attributes). Once those problems were fixed cured the server started up without error. Yay team.

Copyright 2004-2019 Phil Lembo