 Advanced Automounter Revealed
Victor Burns
You may think the automounter is just a simple and
straightforward utility for mounting shared resources on demand. Although
this is true, probably most or all of the automounter maps you have
maintained are of the garden variety direct and indirect syntax. In this
article, I will start with an overview of these basic formats and then
focus on the advanced indirect multi-map and
the powerful dynamic features of the autofs file
system. I will describe how to use the autofs file system dynamically
within indirect maps to solve virtually any mounting problem.
I encountered a situation with an IBM Rational
ClearCase mounting requirement that was difficult to solve using the
automounter in a traditional configuration. While investigating this
problem, I found that the use of the autofs file system within an indirect
map was compatible with my mounting requirements and could be used to solve
many such difficult situations. Best of all, it works on Solaris, Linux,
and HP-UX.
Linux is a wonderful environment; one of its strengths
is its fluid and dynamic ability to change over time. This ability to
change, however, also means that things I say now may be false in the near
future. This is especially true when I make statements about the Linux
autofs automounter. It is very difficult to keep up with features and
specific Linux versions. This condition should not make the information in
this text useless; however, changes in future releases of Linux autofs may
require adjustments to the syntax used in the examples. The technique
described here has worked with the versions of autofs packaged with Red Hat
7.2 through Red Hat Enterprise Linux 3.0.
Terminology
I use the term "autofs" many times in this
article, and I have made every attempt to make it clear which
"autofs" I am speaking of. There is the Linux automounter
package that supports a Sun like indirect map syntax. There is also a
file-system type called "autofs". The autofs file system is
what the automounter is based on. When I am speaking of the file system, I
will address it as such. Most of the time, I will use auto_master when
referring to the automounter configuration file. In such cases, it is safe
to assume I am speaking of the auto.master file as well.
Overview
I'll start by briefly reviewing the most common
and standard automounter features and syntax. The list of features
presented is incomplete because of limited space but covers those details
that act as a reference for the advanced features that follow. During this
review of basics, I will primarily use the Solaris syntax. All of the
indirect examples can be adjusted to work with the Linux autofs automounter
as well. The primary difference is the extra syntax required for the Linux
autofs automounter configuration file auto.master to identify the per-map
source type (e.g., file, program, yp, nisplus, etc.). The Linux man pages
and other documentation cover this topic and syntax, so I will not cover it
here in great detail.
Direct Map
The direct map syntax is not supported by Linux using
the autofs automounter. I cover it here, because it is supported on other
platforms and can be useful for solving specific mounting problems. The
typical problem solved using a direct map is the mounting of individual
unique resources at mount points of specific non-uniform paths.
The direct map syntax is straightforward. Its typical
use is to mount one shared resource atop one defined mount directory. A
simple Solaris auto_master direct map example would resemble this:
# auto_master
/- auto_direct
There should only be one such entry in the auto_master.
The name given the direct map is useful for this
discussion because it describes the contents but is not important
otherwise. The content of this direct map is unique and includes full paths
to each mount point. The syntax of this direct map has the form of
"key [options] resource". The key must be unique and is used as
the full path name of the mount point where a single file-system resource
will be mounted when requested. The following is an example of two distinct
direct mount points, whereas Figure 1 provides a picture representation:
# auto_direct
/usr/share/man serv1:/shared/man
/usr/remote serv2:/shared/remote
There is no relationship between two or more of the
mount points. They are managed independently. Note that one direct map
entry cannot exist as a subordinate of another.
Indirect Map
The direct map syntax is useful; however, it is not as
commonly used as the indirect map. The indirect map has advantages over the
direct map. For example, it is widely supported with nearly the same syntax
on many platforms, it is simple to use, and changes are automatically
loaded into the automounter without a restart. The indirect map uses the
basic syntax of "key [options] resource".
The primary difference between the two map types is
that the direct map has full pathname keys, and the auto_master plays no
role in the full path of a direct map entry. The indirect map defines keys
that have no branches and are not full paths. The root path of the indirect
map is configured in the auto_master. This shows examples of indirect map
definitions in the auto_master:
#Solaris / HP-UX etc
/home auto_home
#Linux (/home examples - only use one!)
/home auto_home
/home yp:auto_home
/home file:/etc/auto_home
The syntax of the common indirect map is also well
known. You will likely recognize the syntax and usage here:
#auto_home
fred filer1:/finance/home/&
sam filer1:/engineering/home/&
* filer2:/export/home/&
When the indirect map is of source type file, it may
also be configured as a program or script. In this case, the map is not
opened and read by the automounter, rather the map is executed and passed a
"key" as the first argument. The execution map is expected to
use the key to dynamically return a single line on its standard output in
the form of "[options] resource". The key is not returned in
the response. The execution map may also return no output and exit with a
failure code to tell the automounter that this key is invalid and matches
no resource. On Solaris, an execution map is detected by the file having
its execution rights set. Linux should have the same rights set but also requires the "program:" map-type designator. On Linux, such an entry in the auto.master would
resemble this:
#auto.master
/exec program:/etc/auto_exec
I could write an entire article on the subject of
execution maps; this is, however, outside the scope of this article. I have
introduced the topic here because I use a simple executable map later in
this text. This completes the overview of the basic direct and indirect
map. I did not dwell on mount options because they are not important for
this review. In many cases the options are site-specific and tuned to local
network, client, and server requirements. Often the options reflect local
security policies as well.
Seldom-Used Automounter Features
The first advanced indirect-map syntax I will cover is
the Solaris-supported "multi-map" or "Multiple
Mount" syntax. This syntax is supported on some other operating
systems but not Linux. I have applied this method to solve a few mounting
requirements very nicely. The simplest way to explain this method is in
terms of what it produces. This syntax is really one indirect map entry
that describes a list of resources that mount on top of each other in an
orderly and systematic fashion.
The indirect map below includes both a simple and
multi-mount entry. Remember that the multi-mount entry is only one entry,
and it can coexist with other standard indirect map entries in the same
map. The leading key in the multi-mount entry serves as the first key and
mount-point name under the indirect mount-point defined in the auto_master.
In this example, when the map mount point is defined
as "/top auto_top" in the auto_master, "Libra"
becomes "/top/Libra". Do not confuse the first simple map entry
shown in this example as being part of the second entry. I have shown them
together to illustrate how they would look together. The important detail
to note is that each mounted resource must provide the paths and
directories that each successive mount will require. For instance, the
resource mounted on "zip" must have a subdirectory named
"man" so that the "man" resource has a place to
mount. Compare the "/zip" and "/zip/man" keys:
# auto_top
standard srv1,srv2:/vol/vol6/&
Libra -ro\
/ svrX,svrY:/export/libra \
/zip svrA,svrB:/export/zip \
/zip/man svrP,svrQ:/export/man \
/yellow svr1,svr2:/vol/vol2/yellow
The illustration in Figure 2 should make the end result picture perfect.
The multi-mount indirect map entry is powerful but can
be somewhat inflexible. It should be used with only one resource type at a
time and perhaps should only be used with NFS + lofs. The primary weakness is that it is supported on Solaris and HP-UX,
but not Linux Autofs. The multi-mount syntax cannot be fully
appreciated until you've tried it.
autofs
The next indirect map feature is really quite simple
but can be daunting to follow because of its powerful implications. The
best part is that it works on Solaris and Linux. It should also work on any
OS that has licensed Sun's automounter.
Would it be useful to dynamically build a mount
hierarchy and have all the benefits of the indirect-map? You bet! Would it
be useful to break out of the single-level mounts obtained by generic
indirect mount entries? Would you like more flexibility than the
multi-mount syntax? Yes, of course. These features are obtained by using
the "autofs" file system in conjunction with the -fstype option. Each
indirect-map entry within the auto_master defines and creates an autofs
file system. It is used to manage an indirect map. All that is needed is a
method for creating these on demand. This is
possible by including indirect map entries that call upon the autofs file
system dynamically by using the -fstype option to create a
new autofs file system on demand.
Let's review the syntax and usage of a few file
system types within an indirect automounter map. The auto_example below
includes common and at least one not so common file system type that may be
used in indirect automounter maps. This example is a perfectly valid set of
compatible indirect map entries to illustrate a mixing of types and
introduce a file system you may have seen before but not in this context:
# auto_example
simple -fstype=nfs svr:/export/&
tools -fstype=nfs,ro svr1,svr2:/vol/vol3/&
local -fstype=lofs :/var/tmp
subdir -fstype=autofs auto_subdir
cc_vob -fstype=mvfs :/storage/for/mvfs/cc_vob.vbs
The first three map entries here are fairly standard.
The first two show typical NFS mounts, and the third uses the Solaris
"lofs" type to improve performance by explicitly bypassing NFS
because the resource is local. The last two examples are interesting, and
when the autofs file system is used in conjunction with any other file
system types the possibilities are limitless.
Let's look closer at the entry keyed as
"subdir". This entry is marked as file system type
"autofs". That's right, placing one indirect map under
another is really that simple. The defined map can be sourced from a file,
NIS, NIS+ or LDAP. It can be any supported map resource. The map can even
be an execution/program-map, making it very dynamic.
This would be a good time to illustrate what the
autofs file system does in support of an indirect map. Basically, the
autofs file system produces a distinct memory-based file system instance
for each indirect map directory and associated map defined in the
auto_master. An autofs file system may also be created by using the -fstype=autofs option from
within an indirect map.
The content of the autofs directory includes the
standard items you would find in any file system that supports directory
trees in a parent and child relationship. This directory includes the
standard "." (self) and ".." (parent)
entries/references. It also includes one mount point directory for each key
in the associated indirect map. When the automounter is successfully started, an autofs file system is created and
mounted upon each of the defined auto_master mount points. For example, the
entry "/home auto_home" defines an autofs file system that will
mount upon the "/home" directory. In this case, the process of
mounting causes the autofs ".." entry to reference
"/".
Figure 3 illustrates this symbiotic relationship. I
have also included a sub-map of auto_home to show how this would look. One
may think of the autofs file system as "file system glue".
Notice how two levels of directories have been defined and created if one
changes directory into them but has not mounted any resources until those
resources are required.
Now consider the auto_master and script in the next
example; it illustrates how simple it is to use the autofs file system to
dynamically build a mounting tree:
# auto_master (use only one of the following lines)
/its_magic program:/etc/auto.fsmagic # Linux
/its_magic /etc/auto_fsmagic # others
#!/bin/ksh
# /etc/auto_fsmagic or auto.fsmagic
# do not forget to make this file executable
#Linux (include next line on Linux only)
print - '-fstype=autofs program:/etc/auto.fsmagic'
#Others (use the next line on everything but Linux)
print - '-fstype=autofs,nobrowse :/etc/auto_fsmagic'
exit 0
Once the automounter is operational, you should be
able to change directory to any arbitrary path you want under /its_magic,
and the path will magically appear. With a little more work and some kind
of data interrogation, you could produce script output to create a
desirable and useful mounting tree. Other methods could include
pre-dynamically creating maps in the backend and storing them in your
service of choice, including LDAP and NIS.
Special Uses: MVFS (IBM/Rational ClearCase)
If you support IBM/Rational ClearCase, you will know
that ClearCase adds a new file system type known as "mvfs". I
work in an environment that supports a large number of VOBs (Versioned
Object Base) that are replicated using IBM/Rational Multisite. One of the
biggest issues with VOB management is the mounting and un-mounting of these
resources. The normal VOB mounting behavior is to mount all VOBS. This is
not possible or practical in situations where it would exhaust or exceed OS
limits and fail in the process, or at the very least become a performance issue for systems, environment, and
applications. The automounter is one possible solution.
Note that IBM/Rational does not support the
automounter. However, we have been using this solution for about two years.
It has not solved every issue but has helped to overcome the resource,
performance, and limit problems of mounting all VOBS. If you are not an
administrator of ClearCase, you may consider skipping this section. I use
terms that are specific to ClearCase, and I provide no definitions as they
would not be useful in this limited context.
I will use a simple site example with only a few VOBs.
Each VOB's location or path is defined by a "tag". I have
used tags in this example with varying depths to show how to use the autofs
file system, indirect-maps, and "mvfs" together. In this
example, I will use syntax specific to Linux, but the Solaris format should
be easy to extract from this information.
Note that the output of "cleartool lsvob"
provides all the information needed to create these files.
A set of VOB tags:
/vtop/vob1
/vtop/vob2
/vtop/sub1/vob3
/vtop/sub1/vob4
/vtop/sub1/sub2/vob5
/vtop/sub1/sub2/vob6
The following example includes the required indirect
map files (other sources will work as well) needed to make
"mvfs" and the autofs file system work together:
# auto.master
/vtop file:/etc/auto_vtop
# /etc/auto_vtop
vob1 -fstype=mvfs :/vob_storage/vob1.vbs
vob2 -fstype=mvfs :/vob_storage/vob2.vbs
sub1 -fstype=autofs file:/etc/auto_vtop_sub1
#/etc/auto_vtop_sub1
vob3 -fstype=mvfs :/vob_storage/vob3.vbs
vob4 -fstype=mvfs :/vob_storage/vob4.vbs
sub2 =fstype=mvfs file:/etc/auto_vtop_sub1_sub2
#/etc/auto_vtop_sub1_sub2
vob5 -fstype=mvfs :/vob_storage/vob5.vbs
vob6 -fstype=mvfs :/vob_storage/vob6.vbs
Once the set of indirect maps has been configured, it
will resemble Figure 4 while in operation. The VOBS will mount at the
respective mount points when needed.
The next step is to edit the ClearCase startup script
and disable the mounting of all VOBs at boot time (see /opt/rational/clearcase/etc/clearcase). Once a user has entered into a Clearcase view, it is only a matter
of changing into the directory of one of the defined VOBS to automatically
trigger its mounting. This example is rather simple, and if you have only
six VOBs there is no reason for using the automounter. However, I know from
experience that it is not hard to have many hundreds of VOBs in a large
enterprise development environment, and the automounter (or some tool to
address the situation) quickly becomes necessary.
Quick analysis of this solution should render the
conclusion that the number of required automounter maps can become
unmanageable. This is because of the number of indirect maps needed when
you have many hundreds of VOBs. VOB tags should have local naming standards
placed on them to minimize the number of maps; however, some flexibility in
the name and number of sub-directories in each tag should be allowed and
supported. This flexibility adds to the total number of indirect maps
required. You will quickly determine that one map is needed for each unique
directory of all VOB tags. The most manageable solution is to write a
simple program (a good task for Perl) to convert a list of VOB tags (output
of "cleartool lsvob") into all of the required indirect maps
needed for your site. These maps can easily be scripted for automatic and
dynamic creation and updating into your service of choice.
Summary
I hope this review was helpful. I have seen many
references to the use of autofs in indirect maps on the Internet. However,
I think its usefulness is often overlooked and that some administrators do
not even know that this technique exists. I hope I have created more
awareness of the use of autofs. Good luck!
Victor Burns served 4+ years in the USAF servicing
electronic equipment for the Airborne Command Post (missile launching and
satellite communications systems). During his 21+ years of employment at
Texas Instruments, he has been an ASIC Designer, Programmer, and Unix
Network Administrator. He thanks his wonderful
wife and five children for their support in all
he does. Victor can be reached at: v-burns@ti.com.
|