Re: autofs and OpenLDAP integration

[Brian Wert <bwert@mediaone.net>]

On Thu, May 17, 2001 at 01:45:02PM -0400, Brian Wert wrote:
> I am trying to integrate OpenLDAP and AutoFS.  It looks as if there is
> support in AutoFS 3.1.7 for LDAP compiled in my Redhat 7.1, but I can not
> find any docs to specify how the maps should be setup in LDAP.
>
> My questions:
> 1.  Should I have an /etc/auto.master with a line like this:?
>        /home  ldap:ou=auto.home,ou=Services,dc=myorg,dc=org    --timeout 60


Yes, this is correct.  The lookup module will perform a subtree search
under "ou=auto.home,ou=Services,dc=myorg,dc=org" for objects in the
"automount" object class, using the name of the directory you're trying
to mount as the "cn" to match against.  For example, an entry like this
should match:

dn: cn=jim,ou=auto.home,ou=Services,dc=myorg,dc=org
objectclass: automount
cn: jim
automountInformation: jim -fstype=nfs,soft,intr,rsize=8192,wsize=8192
 bigdisk.example.com:/home/j/jim

> 2.  Why cant I use a nsswitch.conf entry like:
>        automounter: files ldap
>      This returns "/usr/lib/autofs/autofs-ldap-auto-master: auto.master not
> found" when I start AutoFS.  If this method does work, how do I set things
> up? I can not find any docs to do this.


Docs are slim because, well, they didn't seem necessary at the time the
lookup module was written.

We had to patch up the init script to do some primitive parsing of the
nsswitch.conf file because between files, NIS, and LDAP, there was no
parsing order and precedence which didn't generate bug reports from
people who wanted it changed.  If your auto.master isn't in LDAP, you
don't need to muck with nsswitch.conf at all.

> 3.  What is the proper schema and sample entries to use for Automounter
> maps in OpenLDAP?


These are the schema definitions we're using.  IIRC the first two
are from the folks at padl.com (via the ldap-nis mailing list).  The
third we allocated from our arc because I couldn't find an OID for
it anywhere else.

attributetype ( 1.3.6.1.1.1.1.25 NAME 'automountInformation'
        DESC 'Information used by the autofs automounter'
        EQUALITY caseExactIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

objectclass ( 1.3.6.1.1.1.1.13 NAME 'automount' SUP top STRUCTURAL
        DESC 'An entry in an automounter map'
        MUST ( cn $ automountInformation )
        MAY ( description ) )

objectclass ( 1.3.6.1.4.1.2312.4.2.2 NAME 'automountMap' SUP top STRUCTURAL
        DESC 'A group of related automount objects'
        MUST ( ou ) )

The method for migrating maps is like this:
* Automounter maps are of class 'automountMap', and contain 'automount'
  objects.  In the above example,
  "ou=auto.home,ou=Services,dc=myorg,dc=org" is an 'automountMap'
  object.  Its DN is used as the base for a subtree search by the LDAP
  module.
* Entries in a map have two attributes: "cn", and "automountInformation",
  (taken from the docs at the iPlanet web site).  The "cn" attribute is
  what the lookup module uses to search with.  Specifically, it uses
  the filter "(&(cn=KEY)(objectclass=automount))" to look up information
  for a request named "KEY".
* Using automountMap objects lets you nest maps, so things can get
  more interesting.

However, Luke's recently posted that this is probably the wrong way to
do it.  We should probably be using nisObject and nisMap objects instead,
but this would require code changes to the module (which would break any
installations using the current method, unless we decided to support
both ways of doing things).

Cheers,

Nalin

----------------------------------------------