Bug 170791 - Schema file parsing overly picky?
Schema file parsing overly picky?
Product: 389
Classification: Community
Component: Schema (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rich Megginson
Chandrasekar Kannan
Depends On:
Blocks: 389_1.3.0 512820 690319
  Show dependency treegraph
Reported: 2005-10-14 11:50 EDT by Steve Bonneville
Modified: 2015-01-04 18:19 EST (History)
5 users (show)

See Also:
Fixed In Version: 389-ds-base-
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-12-18 14:35:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Steve Bonneville 2005-10-14 11:50:49 EDT
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 12:23:16 EDT
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 13:12:30 EDT
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 10:55:15 EST
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 14:12:51 EDT
This falls under the category of "improve schema parser"
Comment 18 Noriko Hosoi 2011-05-02 21:08:47 EDT
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 08:50:44 EST
Upstream ticket:
Comment 20 Nathan Kinder 2013-12-18 14:35:54 EST
This was fixed in 389-ds-base-

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