Bug 150340

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>
Severity:	low	Docs Contact:
Priority:	medium
Version:	4.0	CC:	jfeeney, srevivo, tao
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	RHBA-2006-0417	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-08-10 21:37:44 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	181409

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 1.3.6.1.1.1.1.13 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 1.3.6.1.1.1.1.13 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 1.3.6.1.1.1.2.13.  
Luke Howard <lukeh> 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:
1.3.6.1.1.1.1.33 is the attributetype OID for automountInformation (RFC 2307bis)
1.3.6.1.1.1.1.25 is the attributetype OID for automountInformation (autofs.schema)

Conflict:
1.3.6.1.1.1.1.13 is the attributetype OID for memberNisNetgroup (RFC 2307)
1.3.6.1.1.1.1.13 is the objectclass OID for automount (autofs.schema)

Registered and unique, but undocumented:
1.3.6.1.4.1.2312.4.2.2 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