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 RFC (NAME; DESC; SUP; (STRUCTURAL|AUXILIARY|ABSTRACT); MUST; MAY) things may break. 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: ( 1.3.6.1.4.1.7165.2.2.5 NAME 'sambaDomain' SUP top STRUCTURAL 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 loaded. 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 directives. Version-Release number of selected component (if applicable): redhat-ds-7.1-2
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.
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.
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: http://www.directory.fedora.redhat.com/download/ol2rhds.pl > > something like this should give you the results that you are looking for: > > > > cat samba.schema | ./ol2rhds.pl > 62samba3.0.20.ldif > > > >
This falls under the category of "improve schema parser"
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.
Upstream ticket: https://fedorahosted.org/389/ticket/153
This was fixed in 389-ds-base-1.3.2.0-1.fc20.