Integrating Leopard Autofs with LDAP

In the two-part series titled “Autofs goodness in Apple’s Leopard (10.5)“, we took a detailed look at Leopard’s automount, autofs. In this article, we will look at the integration of leopard’s autofs with LDAP. There is not a lot of documentation from Apple on it, and when I got down to do the work, it took a bit of trial-and-error on my part.

First off, Leopard’s autofs DOES work with LDAP.  Second, we are also looking at a little bit of hardcoded application from Apple, ergo not very flexible. Third, the integration of Mac OS X into LDAP is not covered in this particular post, as it was quite heavily covered in this comprehensive article titled “Integrating Mac OS X into Unix LDAP Environment with NFS Home Directories“.

Autofs and Directory Utility

Directory Utility is used to manage LDAP connections, services setup and lookup order using Directory Utility. For those who used Directory Utility in TIGER to setup mount objects, user objects etc in an remote LDAP servers, all that is still there and it will still work. However, the new autofs that is introduced in Leopard will not use Directory Utility to manage any of its maps in LDAP. The autofs ldap maps are managed separately.

Autofs LDAP schema

This one is easy. Leopard comes with openldap installed. The openldap schema directory contains all the schema files, including the autofs schema. The automount specific schema is re-produced below:

attributetype ( 1.3.6.1.1.1.1.31 NAME 'automountMapName'
            DESC 'automount Map Name'
            EQUALITY caseExactMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
            SINGLE-VALUE )

attributetype (
                        1.3.6.1.1.1.1.32
                        NAME 'automountKey'
            DESC 'Automount Key value'
            EQUALITY caseExactMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
            SINGLE-VALUE )

attributetype (
                        1.3.6.1.1.1.1.33
                        NAME 'automountInformation'
            DESC 'Automount information'
            EQUALITY caseExactMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
            SINGLE-VALUE )

objectclass (
                        1.3.6.1.1.1.2.16
                        NAME 'automountMap'
                        SUP top STRUCTURAL
            MUST ( automountMapName )
            MAY description )

objectclass (
                        1.3.6.1.1.1.2.17
                        NAME 'automount'
                        SUP top STRUCTURAL
            DESC 'Automount'
            MUST ( automountKey $ automountInformation )
            MAY description )

The big difference between linux autofs and leopard’s autofs is that linux autofs supports both nisMap and automount schemas, whereas Leopard’s autofs only supports the automount schema definition. Considering that all vendors are (slowly) moving towards the automount schema, it is not bad after all. The hassle is for those who already have legacy autofs implementations in Linux, Solaris and elsewhere that depend on the nisMap schema definitions. Leopard sort of forces you to make that breakway.

Leopard’s autofs only supports the automount schema definition

For example, in Derek‘s case (and in my own case), our maps are laid out using the legacy nisMap schema. To allow for the newer clients to look up ldap maps, Solaris ldap clients are adjusted and the newer schema is mapped to the old schema.

auto_master

Here’s the first hard coded part. The master file for autofs is hardcoded to auto_master. This is also different from the linux autofs where you can specify the master file in the sysconfig files.  When automount starts up in Leopard, it issues this ldap search.

SRCH base="automountMapName=auto_master,<BASEDN>" scope=1 deref=0 filter="(&(|(objectClass=automount)))"


The auto_master entries are extracted out of this search and subsequent LDAP calls are issued as the mount requests are made. These subsequent LDAP autofs calls are all quite simple and easy to understand.

The master file for autofs is hardcoded to auto_master

THe following ldif file is a working example of how one could lay out the autofs maps in a LDAP suffix:

dn: automountMapName=auto_master,dc=example,dc=com
objectClass: top
objectClass: automountMap
automountMapName: auto_master

dn: automountKey=/home,automountMapName=auto_master,dc=example,dc=com
objectClass: top
objectClass: automount
automountKey: /home
automountInformation: auto.home

dn: automountKey=/local,automountMapName=auto_master,dc=example,dc=com
objectClass: top
objectClass: automount
automountKey: /local
automountInformation: auto.local

dn: automountKey=/,automountMapName=auto.home,dc=example,dc=com
objectClass: top
objectClass: automount
automountKey: /
automountInformation: filer:/vol/home/&

dn: automountKey=tier1,automountMapName=auto.local,dc=example,dc=com
objectClass: top
objectClass: automount
automountKey: tier1
automountInformation: filer:/vol/tier1

These maps also do not collide with the LDAP Directory Services mapping you may have setup during the TIGER days and should put you in a decent shape to begin peeling off the NetInfo stuff from LDAP and moving towards the Directory Utility world. Good Luck!