|Summary:||OID conflict in LDAP schemas shipped|
|Product:||Red Hat Enterprise Linux 4||Reporter:||Steve Bonneville <sbonnevi>|
|Component:||openldap||Assignee:||Jay Fenlason <fenlason>|
|Status:||CLOSED ERRATA||QA Contact:||Jay Turner <jturner>|
|Version:||4.0||CC:||jfeeney, srevivo, tao|
|Fixed In Version:||RHBA-2006-0417||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-08-10 21:37:44 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Steve Bonneville 2005-03-04 18:37:54 UTC
Affected packages: openldap-servers-2.2.13-2 autofs-4.1.3-67 Two OIDs used by objects in the schema files shipped in openldap-servers conflict with each other. The incorrect schema file is identical to the one shipped with autofs (in /usr/share/doc/autofs-4.1.3/autofs.schema), so I'm not sure which package to file this against.... :) /etc/openldap/schema/nis.schema assigns the OID 184.108.40.206.220.127.116.11 to the memberNisNetgroup attribute It is also assigned to this attribute by RFC 2307, so this one is set correctly. /etc/openldap/schema/redhat/autofs.schema assigns the OID 18.104.22.168.22.214.171.124 to the automount object class inappropriately. This object class is not in the RFC. I believe the (old) automount object class' OID, using the old-style attributes we use in the schema file, should be 126.96.36.199.188.8.131.52. Luke Howard <email@example.com> defined the OID and should know for sure, but this is what I see in e-mail archives discussing this dating from 2001. The current I-D revising RFC 2307 (draft-howard-rfc2307bis-01.txt, 2005 Feb 20) has *other* different OIDs because it redefines the object classes automount and automountMap, and the automountInformation attribute, and deprecates the old definitions. Those OIDs and that schema shouldn't apply until autofs changes to match. (The changes are still in draft, but apparently Solaris uses the draft schema for the automounter, leading to interop problems with us.) :(
Comment 1 Jeff Layton 2006-03-01 18:54:15 UTC
This does indeed seem to be a problem, but I'm not clear on the solution. There are 3 different automount schema "standards" nisObject/nisMap (RFC 2307 -- not a factor here) automountKey/automountInformation (RFC2307bis) and the unoffical: automount/cn/automountInformation It's this 3rd one that is in the contents of autofs.schema, and appears to be the problem. Perhaps we should just make any entries in here that match the names in RFC2307bis, match OID's as well? Changing this, however, may have implications for people that have directories loaded already. I'm not certain if reloading the data would be required if you change the OID's. As an aside, recent versions of autofs also support the RFC draft schema as well, so interoperability problems with sun should not be an issue.
Comment 3 Murray Schwalbaum 2006-03-02 14:45:10 UTC
I opened a ticket with RH about this recently. It isn't clear what RH wants it's customers to use as an information services schema. I hope that you can provide more information as to why things were setup this way, and what the future direction is going to be. Here's my summary of the problems. Discrepancy: 184.108.40.206.220.127.116.11 is the attributetype OID for automountInformation (RFC 2307bis) 18.104.22.168.22.214.171.124 is the attributetype OID for automountInformation (autofs.schema) Conflict: 126.96.36.199.188.8.131.52 is the attributetype OID for memberNisNetgroup (RFC 2307) 184.108.40.206.220.127.116.11 is the objectclass OID for automount (autofs.schema) Registered and unique, but undocumented: 18.104.22.168.4.1.2322.214.171.124 is the object class OID for automountMap (autofs.schema)
Comment 4 Steve Bonneville 2006-03-02 19:36:39 UTC
It's not clear what the LDAP powers-that-be want to use as an automount schema. The most common approach used with Linux autofs is probably the generic nisMap/nisObject method from RFC 2307, which I think Solaris 8 also supported. Now, RFC 2307 has been up for revision as an Internet-Draft for some time, and one of the things that's been in development is a specific set of object classes for automount information. There have been several iterations using slightly different OIDs over the years as the definitions of the proposed object classes have been altered. On top of that, there's a typo in the obsolete autofs.schema file shipped with openldap-servers, as this bug notes in the initial report. Despite the fact that it's still an Internet-Draft, Sun used the newer proposed schema from one of the more recent draft versions of RFC 2307bis for the automounter in the latest versions of Solaris. Therefore, supposedly the most recent versions of autofs have also been modified to understand that draft schema as well for interoperability purposes, as mentioned in comment #1. In my personal experience as a system administrator, I've only worked with the nisMap/nisObject approach in Linux, which currently works fine.
Comment 6 Bob Johnson 2006-04-11 16:34:03 UTC
This issue is on Red Hat Engineering's list of planned work items for the upcoming Red Hat Enterprise Linux 4.4 release. Engineering resources have been assigned and barring unforeseen circumstances, Red Hat intends to include this item in the 4.4 release.
Comment 10 Red Hat Bugzilla 2006-08-10 21:37:45 UTC
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0417.html