Introduction

A uniform file system namespace enables access to files from different clients under one global mounted directory. When file data is exported from distributed Network File System (NFS) file servers, it eliminates the need to explicitly mount file systems from each file server manually. NFS Version 4 provides a file server referrals feature where a file system namespace is created by mounting a directory exported from one file server and, if the actual data resides on another file server, clients are re-directed accordingly. NFS Version 3 lacks this feature, making it cumbersome to access data exported from multiple file servers under the same global mount point.

This article discusses different ways to use open source implementations of autofs and Lightweight Directory Access Protocol (LDAP), with NFS Version 3, to access data exported from multiple file servers under the same global mount point. Benefits and drawbacks are also provided, so you can select the best approach for your specific scenario.

The examples in this article mainly cover the Linux® platform, but they can also be used with any UNIX® platform, with little or no change, based on the configuration features available in the native operating system. It is assumed that you are familiar with basic LDAP and autofs configurations on UNIX. The security of the files accessed in the namespace is outside the scope of this article. The same can be implemented with additional configuration using Kerberos or other similar approaches.

Back to top

Autofs on UNIX systems

Most UNIX systems come with a utility called autofs, which provides on demand mounting of file systems that are configured into the /etc/auto.master file on Linux and the /etc/auto_master file on AIX® systems. Information about the file system namespace to be mounted is encoded using these autofs configuration entries. Besides using a local file, autofs also provisions the use of other name and directory services. This is helpful in distributed systems that need to share information on exports.

Autofs can also be configured to act as a Network Information Service (NIS) or LDAP client, and it can query the respective servers for information. This article describes different ways of writing an autofs configuration to create a uniform namespace of exported files from different file servers accessible across different NFS clients, augmented by their benefits and drawbacks.

The sample implementations below have been created to work with autofs Version 4.1.4 (or later), with OpenLDAP Version 2.3, and have been verified to work on SuSE Linux Enterprise Server 9 (Service Pack 2). They can also be used with IBM Tivoli® Directory Server without any changes to the information given here.

Back to top

Example namespace scenario

Use the scenario shown in Figure 1 below as an example for the implementations that follow. These will be represented later using autofs and LDAP. The scenario contains a global root directory, which is the mount directory for all the NFS clients. Directories dir1, dir22, dir211, and dir212 are exported from server1, server2, server1, and server3, respectively. There are pseudo mount points within the namespace that do not contain any real data exported from any servers, but they contain either an exported directory or other pseudo mount points. Pseudo mount points help in creating or extending file system global namespace hierarchy.

Preparatory configuration

A map from a mount point to a location on a file server can be resolved by using mappings based on file, NIS, or LDAP. On Linux, this mapping is specified in the /etc/nsswitch.conf file, and it is specified in the /etc/irs.conf file on AIX. In your usage of autofs, you can use the auto.master file as the starting point for maps resolution, so you need to specify file-based mapping. See Listing 1 below.
Listing 1. File-based mapping

...
automount files ...
...
      

Back to top

Methods to create a uniform namespace

Before formulating the namespace using autofs, you need to understand the basic building blocks of the namespace. There are two kinds of directories in the namespace:

NFS-mounted directories

These directories (within the namespace) are exported from NFS servers. dir1 and dir211 of the namespace shown in Figure 1 are examples of this.

Pseudo-mounted directories

These directories are not actually exported from file servers, but the directories exist in the namespace to contain one or more NFS-mounted exported directories. Directories dir2 and dir21 in Figure 1 exhibit pseudo-mounted directories.

The rest of this section outlines the different implementations for creating the namespace using autofs for the directory structure shown in Figure 1.

Method 1. File-based autofs configuration (without LDAP)

This approach uses a heavy NFS client-side autofs configuration. While it offers an easily understood and simple setup, using just the autofs configuration files without the need of an LDAP setup requires too many configuration files to create a namespace. The client-side autofs setup needs to be repeated on each and every NFS client that wants to access the global namespace. Configuration goes like this:

• The /etc/auto.master file contains an entry that refers autofs to another configuration file, such as /etc/auto.net, when /net directory is accessed and mounted.

  /net /etc/auto.net

  
  
• The /etc/auto.net file contains information about directories inside the global mount point /ne’, for example, dir1 and dir2.

  dir1 -fstype=nfs server1.domain.com:/dir1 dir2 -fstype=autofs file:/etc/auto.dir2

  
  
• The /etc/auto.net file refers to the /etc/auto.dir2 file for information about dir2 contents, which in turn refers to the /etc/auto.dir21 file.

  dir21 -fstype=autofs file:/etc/auto.dir21 dir22 -fstype=nfs server2.domain.com:/dir22

  
  
• The /etc/auto.dir21 file looks like this:

  dir211 -fstype=nfs server1.domain.com:/dir211 dir212 -fstype=nfs server3.domain.com:/dir212

  
  

Method 2. Program-based autofs configuration (without LDAP)

This method eliminates having too many configuration files on the NFS clients, and it allows automounting NFS with the help of just one program executed through autofs configuration. However, each time a change is made to the namespace, it mandates changes on each client for it to reflect. This makes configuration as cumbersome as it was in the previous method.

• The main /etc/auto.master configuration file contains an entry for ‘/net’ that refers to /etc/auto.net, as shown in the previous method.

  /net /etc/auto.net

  
  
• The /etc/auto.net file contains a shell program with its execute permission turned ON, as shown in Listing 2:
  
  Listing 2. The /etc/auto.net file
  

  #!/bin/bash [ “$1" = "dir1" -a "$PWD" = "/net" ] && echo "-fstype=nfs server1.domain.com:/dir1" [ “$1" = "dir2" -a "$PWD" = "/net" ] && echo "-fstype=autofs program:/etc/auto.net" [ "$1" = "dir21" -a "$PWD" = "/net/dir2" ] && echo "-fstype=autofs program:/etc/auto.net" [ "$1" = "dir22" -a "$PWD" = "/net/dir2" ] && echo "-fstype=nfs server2.domain.com:/dir22" [ "$1" = "dir211" -a "$PWD" = "/net/dir2/dir21" ] && echo "-fstype=nfs server1.domain.com:/dir211" [ "$1" = "dir212" -a "$PWD" = "/net/dir2/dir21" ] && echo "-fstype=nfs server3.domain.com:/dir212"

  
  

Method 3. Program-based autofs configuration using LDAP

This approach uses an additional server with an LDAP server. It distributes the amount of work to be done for creating a namespace between both the client and LDAP server. However, it enforces tight coupling between client and server configuration. While it reduces a few entries on the LDAP server side, it offers very little flexibility. This approach uses the schema definition specified in nis.schema, which is installed with openldap by default.

• The /etc/auto.master configuration file contains a similar entry, as shown above:

  /net /etc/auto.net

  
  
• The /etc/auto.net file contains a shell program, as shown in Listing 3:
  
  Listing 3. The /etc/auto.net file
  

  #!/bin/bash nisMap=$(ldapsearch -x –LLL –h ldap-server.domain.com -b "cn=$1,nisMapName=nis.map,dc=domain,dc=com" nisMapEntry mountPoint) mountPoint=$(echo $nisMap | grep "^mountPoint:" | tail -1 | awk '/^mountPoint:/ { found = 1 } { gsub(/^ /, "", $0); gsub(/^mountPoint: /, "", $0); if (found > 0) printf("%s", $0) } END { print "" }') nisMapEntry=$(echo $nisMap | grep "^nisMapEntry:" | tail -1 | awk '/^nisMapEntry:/ { found = 1 } { gsub(/^ /, "", $0); gsub(/^nisMapEntry: /, "", $0); if (found > 0) printf("%s", $0) } END { print "" }') if [ "$PWD" = "$mountPoint" ]; then echo $nisMapEntry fi

  
  
• Information about the namespace stored in the LDAP is shown in Listing 4 below. The entries named nisMapName indicate mount points on the client; these might be real or pseudo. In a set of queries sent to the LDAP server, these entries form intermediate hops before the exact location of a real directory is obtained.

  The entries for nisMapEntry contain information about the NFS server hosting the required data. The LDAP Data Interchange Format (LDIF) that stores information about the namespace in LDAP is shown in Listing 4 below.

  
  
  Listing 4. LDAP Data Interchange Format (LDIF)
  

  dn: nisMapName=nis.map,dc=domain,dc=com objectClass: top objectClass: nisMap nisMapName: nis.map dn: cn=dir1,nisMapName=nis.map,dc=domain,dc=com objectClass: nisObject cn: dir1 nisMapEntry: -fstype=nfs server1.domain.com:/dir1 mountPoint: /net nisMapName: nis.map dn: cn=dir2,nisMapName=nis.map,dc=domain,dc=com objectClass: nisObject cn: dir2 nisMapEntry: -fstype=autofs program:/etc/auto.net mountPoint: /net nisMapName: nis.map dn: cn=dir21,nisMapName=nis.map,dc=domain,dc=com objectClass: nisObject cn: dir21 nisMapEntry: -fstype=autofs program:/etc/auto.net mountPoint: /net/dir2 nisMapName: nis.map dn: cn=dir22,nisMapName=nis.map,dc=domain,dc=com objectClass: nisObject cn: dir22 nisMapEntry: -fstype=nfs server2.domain.com:/dir22 mountPoint: /net/dir2 nisMapName: nis.map dn: cn=dir211,nisMapName=nis.map,dc=domain,dc=com objectClass: nisObject cn: dir211 nisMapEntry: -fstype=nfs server1.domain.com:/dir211 mountPoint: /net/dir2/dir21 nisMapName: nis.map dn: cn=dir212,nisMapName=nis.map,dc=domain,dc=com objectClass: nisObject cn: dir212 nisMapEntry: -fstype=nfs server3.domain.com:/dir212 mountPoint: /net/dir2/dir21 nisMapName: nis.map

  
  
• This method also requires you to modify the LDAP default nis.schema file, as shown in bold in Listing 5 below, to store additional information for mount point.
  
  Listing 5. Modifying the LDAP default nis.schema file
  

  # $OpenLDAP: pkg/ldap/servers/slapd/schema/ \ nis.schema,v 1.10.2.6 2006/01/03 22:16:25 kurt Exp $ ... ... attributetype ( 1.3.6.1.1.1.1.27 NAME 'nisMapEntry' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{1024} SINGLE-VALUE ) attributetype ( 1.3.6.1.1.1.1.128 NAME 'mountPoint' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{1024} SINGLE-VALUE ) # Object Class Definitions objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' DESC 'Abstraction of an account with POSIX attributes' SUP top AUXILIARY MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) MAY ( userPassword $ loginShell $ gecos $ description ) ) ... ... objectclass ( 1.3.6.1.1.1.2.9 NAME 'nisMap' DESC 'A generic abstraction of a NIS map' SUP top STRUCTURAL MUST nisMapName MAY description ) objectclass ( 1.3.6.1.1.1.2.10 NAME 'nisObject' DESC 'An entry in a NIS map' SUP top STRUCTURAL MUST ( cn $ nisMapEntry $ nisMapName ) MAY ( mountPoint $ description ) ) objectclass ( 1.3.6.1.1.1.2.11 NAME 'ieee802Device' DESC 'A device with a MAC address' SUP top AUXILIARY MAY macAddress )

  
  

Method 4. LDAP-based autofs with automount nis.schema schema

This method overcomes most of the problems with the previous methods. It uses an LDAP server configured with automount schema based on nis.schema, which NFS clients refer to while mounting file system space using autofs. It offers great flexibility, as it stores namespace information in the LDAP server completely, and it requires no hard coding of namespace directories. With this, the client does not require any configuration except for the main autofs configuration entry.

• The /etc/auto.master file contains an entry, as follows (assuming /net is the main mount directory):

  /net ldap ldap-server.domain.com:nisMapName=net,dc=domain,dc=com

  
  

  This is the only client-side configuration required with this method. Nothing else has to be configured on the client.

• LDAP server configuration includes namespace information; the LDIF for the same is shown in Listing 6 below. Information about the target NFS server is obtained from the nisMapEntry, which is given by the LDAP search.
  
  Listing 6. Modifying the LDAP default nis.schema file
  

  dn: nisMapName=/net,dc=domain,dc=com objectClass: top objectClass: nisMap nisMapName: /net dn: cn=dir1,nisMapName=/net,dc=domain,dc=com objectClass: nisObject cn: dir1 nisMapEntry: -fstype=nfs server1.domain.com:/dir1 nisMapName: /net dn: cn=dir2,nisMapName=/net,dc=domain,dc=com objectClass: nisObject cn: dir2 nisMapEntry: -fstype=autofs ldap://ldap-server.domain.com/ \ nisMapName=/net/dir2,dc=domain,dc=com nisMapName: /net dn: nisMapName=/net/dir2,dc=domain,dc=com objectClass: top objectClass: nisMap nisMapName: /net/dir2 dn: cn=dir21,nisMapName=/net/dir2,dc=domain,dc=com objectClass: nisObject cn: dir21 nisMapEntry: -fstype=autofs ldap://ldap-server.domain.com/nisMapName=/net/dir2/dir21, dc=domain,dc=com nisMapName: /net/dir2 dn: nisMapName=/net/dir2/dir21,dc=domain,dc=com objectClass: top objectClass: nisMap nisMapName: /net/dir2/dir21 dn: cn=dir211,nisMapName=/net/dir2/dir21,dc=domain,dc=com objectClass: nisObject cn: dir211 nisMapEntry: -fstype=nfs server1.domain.com:/dir211 nisMapName: /net/dir2/dir21 dn: cn=dir212,nisMapName=/net/dir2/dir21,dc=domain,dc=com objectClass: nisObject cn: dir212 nisMapEntry: -fstype=nfs server3.domain.com:/dir212 nisMapName: /net/dir2/dir21

  
  

Method 5. LDAP-based autofs with automount rfc2307bis.schema schema

LDAP configuration with the nis.schema has few limitations for the cases where nis.schema is used for access control. Recent autofs development has defined another automount schema based on RFC 2307-bis. The name of the schema is rfc2307bis.schema, and it is recommended for use with autofs. This method offers the same level of flexibility as with nis.schema, and the client does not require any configuration besides the main autofs configuration entry.

• /etc/auto.master contains an entry like this (assuming /net is the main mount directory):

  /net ldap ldap-server.domain.com:automountMapName=net,dc=domain,dc=com

  
  

  This is the only client-side configuration required with this method. Nothing else has to be configured on the client.

• The LDAP server configuration includes namespace information; the LDIF for the same is shown in Listing 7 below. Autofs obtains the information about the target NFS server by searching for the automountInformation attribute for the automount object class, with the given lookup directory as an argument with ‘cn=’.
  
  Listing 7. LDAP server configuration
  

  dn: automountMapName=/net,dc=domain,dc=com objectClass: top objectClass: automountMap automountMapName: /net dn: cn=dir1,automountMapName=/net,dc=domain,dc=com objectClass: automount automountKey: dir1 cn: dir1 automountInformation: -fstype=nfs server1.domain.com:/dir1 dn: cn=dir2,automountMapName=/net,dc=domain,dc=com objectClass: automount automountKey: dir2 cn: dir2 automountInformation: -fstype=autofs ldap://ldap-server.domain.com/ \ automountMapName=/net/dir2, dc=domain,dc=com dn: automountMapName=/net/dir2,dc=domain,dc=com objectClass: top objectClass: automountMap automountMapName: /net/dir2 dn: cn=dir21,automountMapName=/net/dir2,dc=domain,dc=com objectClass: automount automountKey: dir21 cn: dir21 automountInformation: -fstype=autofs ldap://ldap-server.domain.com/ \ automountMapName=/net/dir2/dir21, dc=domain,dc=com dn: cn=dir22,automountMapName=/net/dir2,dc=domain,dc=com objectClass: automount automountKey: dir22 cn: dir22 automountInformation: -fstype=nfs server2.domain.com:/dir22 dn: automountMapName=/net/dir2/dir21,dc=domain,dc=com objectClass: top objectClass: automountMap automountMapName: /net/dir2/dir21 dn: cn=dir211,automountMapName=/net/dir2/dir21,dc=domain,dc=com objectClass: automount automountKey: dir211 cn: dir211 automountInformation: -fstype=nfs server1.domain.com:/dir211 dn: cn=dir212,automountMapName=/net/dir2/dir21,dc=domain,dc=com objectClass: automount automountKey: dir212 cn: dir212 automountInformation: -fstype=nfs server3.domain.com:/dir212

  
  
• For this LDIF to work with the LDAP server, the automount rfc2307bis.schema schema needs to be modified, as shown in bold in Listing 8 below.
  
  Listing 8. Modifying the automount rfc2307bis.schema schema
  

  ... ... 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 information' MUST ( automountKey $ automountInformation ) MAY ( description $ cn ) ) objectclass ( 1.3.6.1.4.1.5322.13.1.1 NAME 'namedObject' SUP top STRUCTURAL MAY cn ) ... ...

  
  

Back to top

Comparative evaluation

This section provides a comparison of the techniques discussed in this article. You can choose a particular technique for the available resources in terms of machine, expertise, and time.

Resources

Learn

• Linux autofs automounter HOW-TO: Learn about the basics of autofs to mount and unmount partitions for access by the system and users.
  
  
• Linux autofs configuration with LDAP: Follow this discussion about autofs configuration with LDAP.
  
  
• Configuring OpenLDAP Configuration: Learn openLDAP configuration steps on Linux in detail.
  
  
• IBM AIX NIS and NIS+ Guide: Read about NIS automount concepts on AIX.
  
  
• OpenLDAP Software 2.3 Administrator's Guide: This guide provides openLDAP administration steps and commands for installation, and working with openLDAP.
  
  
• RFC 2307: Read this approach for using LDAP as a Network Information Service (IETF/rfc2307).
  
  
• NFS v3 Protocol Specification: Check out the Network File System version 3 Protocol Specification.
  
  
• Search the AIX and UNIX library by topic:
  • System administration
  • Application development
  • Performance
  • Porting
  • Security
  • Tips
  • Tools and utilities
  • Java™ technology
  • Linux
  • Open source
  
  
• AIX and UNIX: The AIX and UNIX developerWorks zone provides a wealth of information relating to all aspects of AIX systems administration and expanding your UNIX skills.
  
  
• New to AIX and UNIX: Visit the New to AIX and UNIX page to learn more about AIX and UNIX.
  
  
• AIX 5L™ Wiki: A collaborative environment for technical information related to AIX.
  
  
• Safari bookstore: Visit this e-reference library to find specific technical resources.
  
  
• developerWorks technical events and webcasts: Stay current with developerWorks technical events and webcasts.
  
  
• Podcasts: Tune in and catch up with IBM technical experts.
  
  

Get products and technologies

• OpenLDAP: Download openLDAP server software for Linux.
  
  
• Autofs: Download various autofs implementations for Linux.
  
  
• IBM Tivoli Director Server: Download IBM Tivoli Directory Server for use in place of openLDAP.
  
  
• IBM trial software: Build your next development project with software for download directly from developerWorks.
  
  

Discuss

• Participate in the developerWorks blogs and get involved in the developerWorks community.
  
  
• Participate in the AIX and UNIX forums:
  • AIX 5L -- technical forum
  • AIX for Developers Forum
  • Cluster Systems Management
  • IBM Support Assistant
  • Performance Tools -- technical
  • Virtualization -- technical
  • More AIX and UNIX forums
  
  

About the authors

Deergha Sahni works as a Systems Software Engineer at IBM India Software Labs. She has worked at IBM for one year on support for SAN File System L3. She is currently a developer for the Glamour Version II development project at IBM India Systems and Technology Labs in Pune, India. She holds a B.E. degree in computer science from the University of Pune. You can contact her at deergha.sahni@in.ibm.com.

Ujjwal Lanjewar works as a Senior Staff Software Engineer at the IBM India Software Labs. He has worked for IBM for the past six years, focusing on distributed file systems such as AFS and SAN File System. He is currently a senior developer for the Glamour Version II development project at IBM India Systems and Technology Labs in Pune, India. Prior to joining IBM six years ago, Ujjwal worked in Lucent Technologies Ltd and Motorola India Ltd. He holds an M.E. degree in software systems from BITS Pilani. You can contact him at lujjwal@in.ibm.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Autofs on UNIX systems
• Example namespace scenario
• Methods to create a uniform namespace
• Comparative evaluation
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into AIX and UNIX on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers