Red Hat Bugzilla – Bug 479753
Update core schema to latest defined in LDAP RFCs
Last modified: 2015-12-07 11:43:47 EST
Much of our core schema needs to be updated to match the current (4xxx series) LDAP RFCs. We should update our schema to match the latest RFCs in the next major DS version.
Be sure to look at RFC 4519, 4523
Created attachment 353910 [details]
This patch updates and reorganizes our core schema to follow
the most recently defined standards. The layout of the core
schema files is as follows:
00core.ldif - RFC 4512, RFC 4519, LDAP Subentry Internet Draft
01core389.ldif - 389 specific schema (required to start server)
02common.ldif - 389 specific schema (highly recommended,
Changelog Internet Draft, plug-in schema)
05rfc2927.ldif - MIME Directory Profile for LDAP Schema
05rfc4523.ldif - Schema Definitions for X.509 Certificates
05rfc4524.ldif - Cosine LDAP/X.500 Schema
06inetorgperson.ldif - RFC 2798 (pulls in RFC 2079 and part of
the obsolete RFC 1274 due to required attributes)
There are still a handful of syntaxes that we don't support, so
I've substituted syntaxes for about 15 attributes. The schema and
DIT related description syntaxes are not supported, so I've used
the "Directory String" syntax instead in 00core.ldif. The
certificate syntaxes defined in 4523 are not supported, so I've
used the "Octet String" syntax instead. All of these deviations
are commented with a "TODO" listing the syntax that we need to
I have also updated the Mozilla address book schema to the latest
from upstream for a minor bug fix. I changed the nsSymmetricKey
attribute to use the "Octet String" syntax since the "Binary"
syntax is deprecated.
Ok. What impact will this have on migration and upgrades?
(In reply to comment #3)
> Ok. What impact will this have on migration and upgrades?
I'm still trying to decide on the best course of action for upgrades and migrations. The least intrusive thing to do is to leave the old schema used by instances alone, which is what we do now. Newly instances will use the new schema.
We need some procedure/tool to bridge the gap here, where an instance can be updated to use the new core schema after ensuring that the existing data works with the new schema (perhaps by creating a new test instance and trying an import of the old data to see if any schema violations pop up). We need to also deal with the addition of new plug-in configuration, updating the instance specific scripts from the new templates, and perhaps other things with this procedure/tool.
Pushed to master. Thanks to Rich for his review!
Current Failures in Acceptance :
SetupDS run Tests FAIL : 3% (1/26) line 797:
Sleep: command not found
I18n run Tests FAIL : 2% (1/34)
TestCase [tp4] result-> [FAIL]
modifying entry cn=Celine,cn=ldbm database,cn=plugins,cn=config
EntryUSN run Tests FAIL : 10% (3/30)
add_replication_agreement: ldapmodify failed (error code 32)
namedPipelog run Tests FAIL : 6% (1/16)
Test result for NamedPipe_15, Running ds-logpipe.py script with --serverpid PID option, Actual_Result=1, Expected_Result=0
TestCase [namedPipe_15] result-> [FAIL]
mmrepl mmraccept cleanup Tests FAIL : 100% (1/1)
This is cleanup failure
It does not seen to me related to the schema, hence marking this bug as VERIFIED.