Bug 617629 - Missing aliases in new schema files
Summary: Missing aliases in new schema files
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Schema
Version: 1.2.6
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 389_1.2.6 639035
TreeView+ depends on / blocked
 
Reported: 2010-07-23 15:18 UTC by Roberto Polli
Modified: 2015-12-07 16:48 UTC (History)
3 users (show)

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


Attachments (Terms of Use)
0001-Bug-617629-Missing-aliases-in-new-schema-files.patch (10.17 KB, patch)
2010-07-23 22:33 UTC, Rich Megginson
nkinder: review+
Details | Diff

Description Roberto Polli 2010-07-23 15:18:29 UTC
Description of problem:
the new schema files 00core.ldif & co miss the aliases definition

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

How reproducible:
# grep -i 'commonname' 00core.ldif

Steps to Reproduce:
1. # grep -i 'commonname' schema/00core.ldif

  
Actual results:
nothing

Expected results:
attributeTypes: ( 2.5.4.3 NAME ( 'cn' 'commonName' ) DESC 'Standard LDAP attribute type' SUP name X-ORIGIN 'RFC 2256' )

Additional info:

see http://lists.fedoraproject.org/pipermail/389-users/2010-July/011829.html

Comment 1 Rich Megginson 2010-07-23 15:55:17 UTC
Are there any other attributes with missing aliases?  Please let us know asap.

Comment 2 Roberto Polli 2010-07-23 16:08:54 UTC
afaisee *all* attribute alias of 00core.ldif are missing...

if you create the 00core.ldif via sed/awk then the issue is there...

anyway as a result none of my ns*.ldif schema works on 1.2.6

Peace,
R.

Comment 3 Rich Megginson 2010-07-23 16:44:32 UTC
Are there any missing aliases, other than commonName, that are preventing you from using your ns*.ldif schema?

Comment 4 Rich Megginson 2010-07-23 18:37:10 UTC
I wrote a quick python script to analyze the old schema vs. the new schema.  This is what I found:

new attribute ('uid',) has different aliases than old definition ('uid', 'userid')
new attribute ('st',) has different aliases than old definition ('st', 'stateOrProvinceName')
new attribute ('c',) has different aliases than old definition ('c', 'countryName')
new attribute ('l',) has different aliases than old definition ('l', 'locality', 'localityname')
new attribute ('cn',) has different aliases than old definition ('cn', 'commonName')
new attribute ('sn',) has different aliases than old definition ('sn', 'surName')
new attribute ('o',) has different aliases than old definition ('o', 'organizationname')
new attribute ('ou',) has different aliases than old definition ('ou', 'organizationalUnitName')
new attribute ('dc',) has different aliases than old definition ('dc', 'domaincomponent')
new attribute ('facsimileTelephoneNumber',) has different aliases than old definition ('facsimileTelephoneNumber', 'fax')
new attribute ('street',) has different aliases than old definition ('street', 'streetaddress')
new attribute ('distinguishedName',) has different aliases than old definition ('dn', 'distinguishedName')
new attribute ('drink',) has different aliases than old definition ('drink', 'favouriteDrink')
new attribute ('mail',) has different aliases than old definition ('mail', 'rfc822mailbox')
new attribute ('co',) has different aliases than old definition ('co', 'friendlycountryname')
new attribute ('pager',) has different aliases than old definition ('pager', 'pagerTelephoneNumber')
new attribute ('mobile',) has different aliases than old definition ('mobile', 'mobileTelephoneNumber')
new attribute ('homePhone',) has different aliases than old definition ('homePhone', 'homeTelephoneNumber')
new attribute ('labeledURI',) has different aliases than old definition ('labeledUri', 'labeledurl')

I guess, in order to be absolutely safe with respect to old data, we must add back all of these aliases.

Comment 5 Rich Megginson 2010-07-23 19:36:44 UTC
Hmm - ever since the first draft of LDAPv3 (see http://www.ietf.org/rfc/rfc2256.txt) we should never have supported aliases for most if not all of these listed above.  It would be painful to just turn these off.  Users need a way to identify deprecated schema usage, and a way to transition to the standards.

Put back these aliases in our schema definition.  Add an X-DEPRECATED notation that lists the aliases e.g.
attributeTypes: ( 2.5.4.3 NAME ( 'cn' 'commonName' )
  SUP name
  X-ORIGIN 'RFC 4519' X-DEPRECATED 'commonName' )

Have a list of these deprecated aliases.  Have a cn=config switch e.g. nsslapd-deprecated-aliases: on/off.  If the switch is on, attempts to use a deprecated alias are rejected with the appropriate LDAP error e.g. NO_SUCH_ATTRIBUTE.  This way, users can turn on the switch, find out which data/apps use the deprecated attribute alias, and fix them.

Comment 6 Rich Megginson 2010-07-23 22:33:30 UTC
Created attachment 434078 [details]
0001-Bug-617629-Missing-aliases-in-new-schema-files.patch

I have not completed testing this patch yet.

Comment 7 Rich Megginson 2010-07-24 17:24:17 UTC
There is a potential problem with this patch:
-attributeTypes: ( 2.5.4.49 NAME 'distinguishedName'
+attributeTypes: ( 2.5.4.49 NAME ( 'distinguishedName' 'dn' )

The old definition of dn was this:
( 'dn' 'distinguishedName' )

The first one is the key - this is the one returned to clients.  I've already seen failures in the ger tests because they expect the GER results to be returned with 'dn' but instead they are returned with 'distinguishedName'.  It should be simple to fix those tests, but perhaps not so simple to fix user applications.  There are a couple of different approaches:

1) Use distinguishedName as the primary name - if they absolutely have to, users can edit 00core.ldif and flip the order of the names so that 'dn' comes first - assumes there are very few apps that expect 'dn'

2) Use dn as the primary name - will make deprecating it that much harder in the future, but if there are a lot of apps that expect 'dn' there is really no other choice

Comment 8 Nathan Kinder 2010-07-27 21:50:52 UTC
(In reply to comment #5)
> Hmm - ever since the first draft of LDAPv3 (see
> http://www.ietf.org/rfc/rfc2256.txt) we should never have supported aliases for
> most if not all of these listed above.

I haven't really seen anything that says that a server "SHOULD NOT" have these aliases in any of the recent specs.  The aliases are listed in RFC 4519, so perhaps we should indeed be supporting them.  The aliases are listed individually along with the attribute they alias in RFC 4519, section 2.  They are also in the "IANA Considerations" section of RFC 4519 (section 4).  It appears that these aliases are from different sources (some from X.500, some from older RFCs).

Comment 9 Rich Megginson 2010-08-02 17:56:35 UTC
To ssh://git.fedorahosted.org/git/389/ds.git
   d67bb39..34c4ab7  389-ds-base-1.2.6 -> 389-ds-base-1.2.6
commit 34c4ab700d99e455ba3523e7d7a02e4eae401d3d
Author: Rich Megginson <rmeggins@redhat.com>
Date:   Fri Jul 23 16:03:51 2010 -0600
   666873d..f87b2ba  master -> master
commit f87b2ba449659fc2dfb934a90c73a5279db5a4b1
Author: Rich Megginson <rmeggins@redhat.com>
Date:   Fri Jul 23 16:03:51 2010 -0600
    Reviewed by: nkinder (Thanks!)
    Branch: master
    Fix Description: add back the aliases we removed - added a new schema flag
    X-DEPRECATED - this is a quoted string containing a space separated list
    of the deprecated aliases for this attribute
    Platforms tested: RHEL5 x86_64
    Flag Day: no
    Doc impact: no
    (cherry picked from commit 34c4ab700d99e455ba3523e7d7a02e4eae401d3d)

Comment 10 Amita Sharma 2011-05-31 06:44:42 UTC
[root@testvm schema]# grep -i 'commonname' 00core.ldif
attributeTypes: ( 2.5.4.3 NAME ( 'cn' 'commonName' )
  X-DEPRECATED 'commonName' )

[root@testvm schema]# grep -i 'X-DEPRECATED' 00core.ldif
  X-DEPRECATED 'countryName' )
  X-DEPRECATED 'commonName' )
  X-DEPRECATED 'domaincomponent' )
  X-DEPRECATED 'dn' )
  X-DEPRECATED 'fax' )
  X-DEPRECATED 'locality localityname' )
  X-DEPRECATED 'organizationname' )
  X-DEPRECATED 'organizationalUnitName' )
  X-DEPRECATED 'surName' )
  X-DEPRECATED 'stateOrProvinceName' )
  X-DEPRECATED 'streetaddress' )
  X-DEPRECATED 'userid' )


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