https://bugzilla.redhat.com/show_bug.cgi?id=170791
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
batch move to milestone 1.3
set default ticket origin to Community
Added initial screened field value.
{{{
918 while( ext ) { 919 for ( i = 0; ext->values && ext->values[i]; i++ ) { 920 printf( "\t %s : %s\n", ext->term, ext->values[i]);
920 921 } }}} looks like this is missing ext = ext->next
This doesn't look right - the new code looks like this? {{{ static void schema_create_errormsg( char errorbuf, size_t errorbufsize, const char prefix, const char name, const char fmt, ... ); static int parse_at_str(const char input, struct asyntaxinfo asipp, char errorbuf, size_t errorbufsize, ...
__attribute__ ((format (printf, 5, 6)));
;
}}} The GNUC attribute thing is supposed to go with the schema_create_errormsg - it allows gcc to check the varargs arguments to make sure they match the format string.
Otherwise, looks good.
revision 0001-Ticket-153-use-openldap-s-schema-parser.patch
Changes made based on Rich's comments.
git merge ticket153 Updating a68952f..305dac5 Fast-forward ldap/servers/slapd/attrsyntax.c | 50 +- ldap/servers/slapd/charray.c | 9 +- ldap/servers/slapd/proto-slap.h | 10 +- ldap/servers/slapd/schema.c | 1776 +++++++++++++++++++++++++++---------- ldap/servers/slapd/slap.h | 40 +- ldap/servers/slapd/slapi-plugin.h | 15 + 6 files changed, 1397 insertions(+), 503 deletions(-)
git push origin master Counting objects: 21, done. Delta compression using up to 4 threads. Compressing objects: 100% (11/11), done. Writing objects: 100% (11/11), 11.03 KiB, done. Total 11 (delta 9), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git a68952f..305dac5 master -> master
coverity fixes 0001-Fix-coverity-issues.patch
Metadata Update from @mreynolds: - Issue assigned to mreynolds - Issue set to the milestone: 1.3.2 - 05/13 (May)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/153
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.