[Date Prev][Date Next]
Re: autofs and OpenLDAP integration
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
automountInformation: jim -fstype=nfs,soft,intr,rsize=8192,wsize=8192
> 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 ( 188.8.131.52.184.108.40.206 NAME 'automountInformation'
DESC 'Information used by the autofs automounter'
SYNTAX 220.127.116.11.4.1.1418.104.22.168.26 SINGLE-VALUE )
objectclass ( 22.214.171.124.126.96.36.199 NAME 'automount' SUP top STRUCTURAL
DESC 'An entry in an automounter map'
MUST ( cn $ automountInformation )
MAY ( description ) )
objectclass ( 188.8.131.52.4.1.23184.108.40.206 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
* 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
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).