Bug 170791 - Schema file parsing overly picky?
Summary: Schema file parsing overly picky?
Alias: None
Product: 389
Classification: Retired
Component: Schema
Version: 1.2.8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Chandrasekar Kannan
Depends On:
Blocks: 389_1.3.0 512820 690319
TreeView+ depends on / blocked
Reported: 2005-10-14 15:50 UTC by Steve Bonneville
Modified: 2015-01-04 23:19 UTC (History)
5 users (show)

Fixed In Version: 389-ds-base-
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-12-18 19:35:54 UTC

Attachments (Terms of Use)
Fix proposal for 10rfc2307bis.ldif provided by Adrien Guillon (9.83 KB, text/plain)
2011-05-03 01:08 UTC, Noriko Hosoi
no flags Details

Description Steve Bonneville 2005-10-14 15:50:49 UTC
Description of problem:

Directory Server is perhaps overly picky about how closely objectClasses
attributes must follow the syntax specified in RFC 2252 section 4.4.  In
particular, if the optional fields are not in the exact order specified by the

In particular, I used the ol-schema-migrate.pl script provided in the
OpenLDAPMigration wiki page at directory.fedora.redhat.com to migrate the Samba
3 LDAP schema (/usr/share/doc/samba-3.0.10/LDAP/samba.schema) to RHDirS format.
 This resulted in the following LDIF attribute for cn=schema:

 objectClasses: (
  NAME 'sambaDomain'
  SUP top
  DESC 'Samba Domain Information'
  MUST ( sambaDomainName $   sambaSID )
  MAY ( sambaNextRid $ sambaNextGroupRid $ sambaNextUserRid $
sambaAlgorithmicRidBase )

Once loaded by Directory Server, however, the 'SUP top' is missing from the
resulting entry in the server's subschema.  Therefore, attempts by Samba to add
entries of this object class to the directory fail with an error that reads
something like "attribute 'objectClass' not allowed by schema".  If the LDIF
file is edited so the DESC directive and its string is moved between NAME and
SUP, 'SUP top' correctly appears in the server's subschema when the schema file

Whether or not this behavior is changed in Directory Server, the wiki page at
http://directory.fedora.redhat.com/wiki/Howto:OpenLDAPMigration needs to be
updated to reflect this issue.  (It says that the schema file is strictly
RFC2252 compliant, but it's not made obvious just how strict the BNF
specification is compared to what OpenLDAP accepts.)  This issue also affects
both Perl scripts referenced on that page, since neither checks ordering of the

Version-Release number of selected component (if applicable):

Comment 1 Steve Bonneville 2005-10-14 16:23:16 UTC
Oh, and I've also mailed the developers of the Perl conversion scripts
referenced above to notify them of this issue, including this bug number.

Comment 2 Rich Megginson 2005-10-14 17:12:30 UTC
Thanks Steve.  Yes, there are several places where the DS is too strict or too
lenient or lacking with respect to RFC 2252 (e.g. no support for EQUALITY,
SUBSTRING, etc.).  We need to visit this area in our 7.2 development.

Comment 3 Vince Worthington 2006-01-29 15:55:15 UTC
Nathan Benson has written an openldap-to-rhds schema conversion script that can
deal with the strict adherence to RFC2252 that Directory Server seems to adhere
to.  I tried it myself on the samba.schema provided with Samba 3.0.20 and it
converts the schema properly.  here's a URL to the script, and also a note from
Nathan on how to use it:


> >  something like this should give you the results that you are looking for:
> >
> >  cat samba.schema | ./ol2rhds.pl > 62samba3.0.20.ldif
> >
> >

Comment 6 Rich Megginson 2009-04-09 18:12:51 UTC
This falls under the category of "improve schema parser"

Comment 18 Noriko Hosoi 2011-05-03 01:08:47 UTC
Created attachment 496415 [details]
Fix proposal for 10rfc2307bis.ldif provided by Adrien Guillon

On 05/02/2011 05:55 PM, Adrien Guillon wrote:
> Today on #389 on freenode we spent some time attempting to understand
> why directory 389 did not load changes to the schema.  I shutdown
> dirsrv, replaced the rfc2307.ldif schema with rfc2307bis.ldif,
> restarted, and noticed that the schema change had not taken effect.
> This was due to the formatting of the rfc2307bis.ldif file itself
> (basically the DESC field was in the wrong place).  I have attached a
> fixed ldif file.

Comment 19 Martin Kosek 2012-01-04 13:50:44 UTC
Upstream ticket:

Comment 20 Nathan Kinder 2013-12-18 19:35:54 UTC
This was fixed in 389-ds-base-

Note You need to log in before you can comment on or make changes to this bug.