Bug 479753 - Update core schema to latest defined in LDAP RFCs
Summary: Update core schema to latest defined in LDAP RFCs
Alias: None
Product: 389
Classification: Retired
Component: Schema
Version: 1.1.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Viktor Ashirov
Depends On:
Blocks: 389_1.3.0 639035
TreeView+ depends on / blocked
Reported: 2009-01-12 21:19 UTC by Nathan Kinder
Modified: 2015-12-07 16:43 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-12-07 16:43:47 UTC

Attachments (Terms of Use)
Patch (761.47 KB, patch)
2009-07-15 21:08 UTC, Nathan Kinder
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1195599 1 None None None 2021-01-20 06:05:38 UTC

Internal Links: 1195599

Description Nathan Kinder 2009-01-12 21:19:44 UTC
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.

Comment 1 Rich Megginson 2009-04-09 17:36:15 UTC
Be sure to look at RFC 4519, 4523

Comment 2 Nathan Kinder 2009-07-15 21:08:54 UTC
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.

Comment 3 Rich Megginson 2009-07-15 21:30:46 UTC
Ok.  What impact will this have on migration and upgrades?

Comment 4 Nathan Kinder 2009-07-15 21:43:51 UTC
(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.

Comment 5 Nathan Kinder 2009-07-16 15:03:06 UTC
Pushed to master.  Thanks to Rich for his review!

Comment 8 Amita Sharma 2011-06-21 08:14:46 UTC
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.

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