9.2.1. The master map
The master map is the map of maps. When the automounter is started,
it reads the master map from where the
/etc/nsswitch.conf configuration file says to
read it, as determined by the nsswitch.conf
entry named automount:. Thedefault nsswitch.conf -- whether
files, or NIS is used -- has files listed
first. The master map file, /etc/auto_master,
lists all direct and indirect maps and their associated directories.
It consists of triplets of directory name, map name, and mount
options to be used with that map. Suppose your
/etc/auto_master file contains:
# Directory Map NFS Mount Options
/tools /etc/auto_tools -ro
/- /etc/auto_direct
The first entry is for the indirect map
/etc/auto_tools; entries in this map are mounted
read-only (due to the -ro option) under the
/tools directory. The second line of the master
file is for a direct map; because there is no directory for the
automounter to manage, the place holder /- is
used. Note that the master map format is different from other
automounter maps in the following ways:
-
With the master maps, the mount options are in the third column,
whereas regular automounter maps place the options in the second
column.
-
The first column in a master map is always an absolute pathname that
starts with a leading slash (/) and can have one or more additional
slashes, whereas with indirect maps the first column is a map key
that must not contain a slash.
The earlier example is somewhat limiting in that changes to the
auto_tools or auto_direct
map must be made by editing each /etc/auto_tools
or /etc/auto_direct file on each NFS
client. Instead, if we drop the /etc/ prefix, we
can allow the maps to be maintained in NIS or files:
# Directory Map NFS Mount Options
/tools auto_tools -ro
/- auto_direct
In this example, we observe three things:
-
Two map names -- auto_direct and
auto_tools -- are used in place of the
files pulled from /etc in the previous example.
-
The system decides to use NIS or files for
auto_direct and auto_tools
based on whether files or
nis (or both) are specified in
nsswitch.conf.
-
Even though the corresponding map names in NIS are
auto_direct and auto_tools,
the auto_master file uses a canonical name form,
which uses underscores and not periods to separate the prefix
auto from the unique suffix
(direct or tools). The
reason is that in some directory systems, such as NIS+, a period is a
reserved character.
There is no requirement that the master map be maintained as a local
file. Indeed you might find it easier if you configure your
network's clients' nfsswitch.conf file to read all the
maps, including the master map from NIS by setting automount: line in
nsswitch.conf as:
automount: nis
This way you can exercise control over each client's namespace
without having to reconfigure every client each time you want to add
or delete a map from the master map. We will cover how the
automounter maps are integrated into NIS later, in Section 9.3, "Integration with NIS".
The default master map is not going to appear as in the examples
presented so far. The default Solaris
/etc/auto_master file looks something like this:
+auto_master
/net -hosts -nosuid,nobrowse
/home auto_home -nobrowse
/xfn -xfn
We will discuss the first entry,
+auto_master in
Section 9.3.1, "Mixing NIS and files in the same map". The second entry,
/net, will be covered in
Section 9.5.2.1, "The -hosts map". The
third entry,
/home, will be covered in
Section 9.4.1, "Key substitutions".
The last entry,
/xfn, is for the X/Open
Federated Naming Standard (XFN), which
is a
now-deprecated standard for federating directory systems. Recall from
Section 2.2, "Brief survey of common directory services" that there are lots of directory
services. XFN represented an attempt to allow them all to seamlessly
co-exist in a global namespace. The idea was to allow users in one
DNS domain to browse or access information (such as files, printers,
or calendars) from another domain, even if the naming system that
organized the information did not easily support cross-domain
operations (as is the case with NIS). Because it appears that the
world will be unifying under LDAP, and because
nsswitch.conf meets most of the requirements for
directory service switching, XFN has been deprecated. While the
/xfn entry persists to allow you to browse any
NIS or files data represented in XFN, expect XFN and
/xfn to disappear from future Solaris releases.