 | Level: Intermediate Deergha Sahni (deergha.sahni@in.ibm.com), Systems Software Engineer, IBM, Intel, Microsoft,HP
Ujjwal Lanjewar (lujjwal@in.ibm.com), Senior Staff Software Engineer,
IBM
30 Jan 2007 Do you have trouble accessing data exported from multiple file servers? If so, try using open source implementations of autofs and Lightweight Directory Access Protocol (LDAP), with Network File System (NFS) Version 3, to access data under the same global mount point. In this article, study and compare five different methods to create a uniform namespace using autofs. A handy table with a comparative evaluation is available to help you choose the best technique for your scenario.
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.
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.
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.
Figure 1. JavaBeans view
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 ...
...
|
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.
- 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.
- 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.
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.
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.
 |
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.
Table 1. Comparison of techniques
| Method 1
File-based autofs
without LDAP | Method 2
Program-based autofs
without LDAP | Method 3
Program-based autofs
with LDAP | Method 4
Auofs with LDAP
using nis.schema | Method 5
Autofs with LDAP
using
rfc2307bis.schema |
|---|
| Ease of understanding | Very easy | Easy | Understanding of LDAP is required. | Understanding of LDAP is required. | Understanding of LDAP is required. |
|---|
| Ease of implementation | Easiest and fastest -- it requires less knowledge. | Easy implementation -- it requires shell program knowledge. | Fair -- it requires LDAP server configuration to work with LDAP commands. | It's a little difficult to configure autofs and LDAP to work together. | It's a little difficult to configure autofs and LDAP to work together. | | Implementation time | Very little time is required -- it's limited to duplicating files. | Less time is required with the knowledge of shell script. | Fair -- it might require some time for LDAP configuration, but no autofs interfacing needs to be implemented. | Client-side implementation is fast. It might take extra time to interface LDAP server and autofs. | Client-side implementation is fast. It might take extra time to interface LDAP server and autofs. | | Efficiency in performance | It's very efficient, as there is no LDAP server dependency. | It's efficient. | It's least efficient and requires scripts to execute the LDAP search, which contacts the LDAP server. | It's less efficient in accessing namespace for the first time. | It's less efficient in accessing namespace for the first time. | | Flexibility | Least flexible -- each namespace change requires big modification on all clients. | Less flexible -- client-side script must be copied on all clients for any change of the namespace. | Flexible with only server-side changes and it requires new attribute definition in the standard nis.schema schema. | It's more flexible, as changes need to reflect only on the LDAP server. However, uses few older schemas. | It's the most flexible and it requires a change in rfc2307bis.schema, which is easy. | | Overhead on clients | Too much | More | Less | Least | Least | | Implementation | Dependency | Client-side dependency is heavy and no LDAP server dependency. | Client-side dependency is less. | Client-side dependency and LDAP server dependency is less. | No client-side dependency.
No client-side configuration dependency. | | Coupling | No client server coupling -- the namespace is driven by client-side configuration. | No client-server coupling -- the namespace is driven by client-side configuration. | Clients and servers are tightly coupled. | No client server coupling -- the namespace information is entirely on server. | No client-server coupling -- the namespace information is entirely on server. | | Efficiency of maintenance | Least efficient | Less efficient | Efficient | Most efficient | Most efficient |
Resources Learn
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:
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. |
Rate this page
| |
