Bug 720480 - nisDomain schema is incorrect, causes errors upon upgrade
Summary: nisDomain schema is incorrect, causes errors upon upgrade
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: 389
Classification: Retired
Component: Schema
Version: 1.2.10
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-11 18:57 UTC by Michael Mohr
Modified: 2015-01-04 23:49 UTC (History)
6 users (show)

Fixed In Version: 389-ds-base-1.2.10.rc1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-07 16:10:53 UTC


Attachments (Terms of Use)

Description Michael Mohr 2011-07-11 18:57:01 UTC
Description of problem:

Upgrading from 1.2.6 to 1.2.8 leads to the following errors on service startup:

[08/Jul/2011:15:48:39 -0700] attr_syntax_create - Error: the EQUALITY matching rule [caseIgnoreMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.26] for the attribute [nisDomain]
[08/Jul/2011:15:48:39 -0700] attr_syntax_create - Error: the SUBSTR matching rule [caseIgnoreSubstringsMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.26] for the attribute [nisDomain]

Fix: 60nis.ldif should be updated as follows:

attributeTypes: (
  1.3.6.1.4.1.1.1.1.12
  NAME 'nisDomain'
  DESC 'NIS domain'
  SUP name
  EQUALITY caseIgnoreIA5Match
  SUBSTR caseIgnoreIA5SubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
  )

I was told to report this bug by richm1 from #389 on freenode.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.  Install 1.2.6
2.  Notice that there are no errors on startup
3.  Upgrade to 1.2.8
4.  Notice that there are errors on startup
  
Actual results:

Service does not start up without errors.

Expected results:

Service should start up without errors.

Additional info:

Comment 1 Rich Megginson 2011-07-11 19:02:40 UTC
The problem is that nisDomain inherits from 'name' - but name is defined as DirectoryString.  I'm not sure which rfc or other doc defines nisDomain, but it is likely that the definition has changed in the meantime and we need to update our schema.

Comment 2 Dmitri Pal 2011-07-21 15:59:06 UTC
(In reply to comment #1)
> The problem is that nisDomain inherits from 'name' - but name is defined as
> DirectoryString.  I'm not sure which rfc or other doc defines nisDomain, but it
> is likely that the definition has changed in the meantime and we need to update
> our schema.

http://www.padl.com/~lukeh/rfc2307bis.txt

It has always been a part of the 2307bis schema.

Comment 3 Rich Megginson 2011-07-25 16:26:11 UTC
The problem is that we include an older version of the 2307 schema (60nis.ldif) which has this:
attributeTypes: (
  1.3.6.1.4.1.1.1.1.12
  NAME 'nisDomain'
  DESC 'NIS domain'
  SUP name
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
  )

This worked fine in earlier versions, but breaks in recent versions because we now validate the syntax against the matching rules and vice versa.  The defintion of 'name' is this:
attributeTypes: ( 2.5.4.41 NAME 'name'
  EQUALITY caseIgnoreMatch
  SUBSTR caseIgnoreSubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  X-ORIGIN 'RFC 4519' )

'name' is defined with DirectoryString (i.e. allows any valid utf-8 character) with appropriate equality and substring matching rules (that is, the matching rules apply only to DirectoryString and syntaxes compatible with DirectoryString).

nisDomain is defined with a different syntax IA5String (i.e. allow only 7-bit clean ASCII characters, not utf-8) - it should _not_ have SUP 'name' because it is incompatible - instead, it should define its own matching rules.

The bug here is in 60nis.ldif - we should change the definition to remove the SUP 'name' and add the IA5String compatible matching rules.

Comment 4 Martin Kosek 2012-01-04 13:22:34 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/38

Comment 5 Rich Megginson 2012-02-07 16:10:53 UTC
Fixed in 389-ds-base-1.2.10.rc1 now in Fedora/EPEL Testing


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