Red Hat Bugzilla – Bug 150340
OID conflict in LDAP schemas shipped
Last modified: 2015-01-07 19:09:29 EST
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.... :)
assigns the OID 188.8.131.52.184.108.40.206 to the memberNisNetgroup attribute
It is also assigned to this attribute by RFC 2307, so this one is
assigns the OID 220.127.116.11.18.104.22.168 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 22.214.171.124.126.96.36.199.
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
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
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)
and the unoffical:
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.
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.
188.8.131.52.184.108.40.206 is the attributetype OID for automountInformation (RFC 2307bis)
220.127.116.11.18.104.22.168 is the attributetype OID for automountInformation (autofs.schema)
22.214.171.124.126.96.36.199 is the attributetype OID for memberNisNetgroup (RFC 2307)
188.8.131.52.184.108.40.206 is the objectclass OID for automount (autofs.schema)
Registered and unique, but undocumented:
220.127.116.11.4.1.2318.104.22.168 is the object class OID for automountMap (autofs.schema)
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.
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.
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.