Bug 479753

Be sure to look at RFC 4519, 4523

Created attachment 353910 [details]
Patch

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
implement.

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.