Task Overview for Autofs Administration
This section describes some of the most common tasks you might encounter in
your own environment. Recommended procedures are included for each scenario to help you
configure autofs to best meet your clients' needs. To perform the tasks that
are discussed in this section, use the Solaris Management Console tools or see
the System Administration Guide: Naming and Directory Services (NIS+).
Note - Starting in the Solaris 10 release, you can also use the /etc/default/autofs
file to configure your autofs environment. For task information, refer to Using the /etc/default/autofs File to Configure Your autofs Environment.
Task Map for Autofs Administration
The following table provides a description and a pointer to many of the
tasks that are related to autofs.
Table 5-5 Task Map for Autofs Administration
Using the /etc/default/autofs File to Configure Your autofs Environment
Starting in the Solaris 10 release, you can use the /etc/default/autofs file
to configure your autofs environment. Specifically, this file provides an additional way to
configure your autofs commands and autofs daemons. The same specifications you would make
on the command line can be made in this configuration file. You can
make your specifications by providing values to keywords. For more information, refer to
/etc/default/autofs File.
The following procedure shows you how to use the /etc/default/autofs file.
How to Use the /etc/default/autofs File
- Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- Add or modify an entry in the /etc/default/autofs file.
For example, if you want to turn off browsing for all autofs mount
points, you could add the following line.
AUTOMOUNTD_NOBROWSE=ON
This keyword is the equivalent of the -n argument for automountd. For
a list of keywords, refer to /etc/default/autofs File.
- Restart the autofs daemon.
Type the following command:
# svcadm restart system/filesystem/autofs
Administrative Tasks Involving Maps
The following tables describe several of the factors you need to be aware
of when administering autofs maps. Your choice of map and name service affect
the mechanism that you need to use to make changes to the
autofs maps.
The following table describes the types of maps and their uses.
Table 5-6 Types of autofs Maps and Their Uses
Type of
Map |
Use |
|---|
Master |
Associates a directory with a map |
Direct |
Directs autofs to specific file
systems |
Indirect |
Directs autofs to reference-oriented file systems |
The following table describes how to make changes to your autofs environment that
are based on your name service.
Table 5-7 Map Maintenance
Name Service |
Method |
|---|
Local files |
Text editor |
NIS |
make
files |
NIS+ |
nistbladm |
The next table tells you when to run the automount command, depending on
the modification you have made to the type of map. For example, if
you have made an addition or a deletion to a direct map,
you need to run the automount command on the local system. By running
the command, you make the change effective. However, if you have modified an
existing entry, you do not need to run the automount command for the change
to become effective.
Table 5-8 When to Run the automount Command
Type of Map |
Restart automount? |
|
|---|
|
Addition or Deletion |
Modification |
|---|
auto_master |
Y |
Y |
direct |
Y |
N |
indirect |
N |
N |
Modifying the Maps
The following procedures require that you use NIS+ as your name service.
How to Modify the Master Map
- Log in as a user who has permissions to change the maps.
- Using the nistbladm command, make your changes to the master map.
See the System Administration Guide: Naming and Directory Services (NIS+).
- For each client, become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- For each client, run the automount command to ensure that your changes become
effective.
- Notify your users of the changes.
Notification is required so that the users can also run the automount
command as superuser on their own computers. Note that the automount command
gathers information from the master map whenever it is run.
How to Modify Indirect Maps
- Log in as a user who has permissions to change the maps.
- Using the nistbladm command, make your changes to the indirect map.
See the System Administration Guide: Naming and Directory Services (NIS+). Note that the change becomes effective the next time that
the map is used, which is the next time a mount is performed.
How to Modify Direct Maps
- Log in as a user who has permissions to change the maps.
- Using the nistbladm command, add or delete your changes to the direct map.
See the System Administration Guide: Naming and Directory Services (NIS+).
- If you added or deleted a mount-point entry in the previous step, run
the automount command.
- Notify your users of the changes.
Notification is required so that the users can also run the automount
command as superuser on their own computers.
Note - If you only modify or change the contents of an existing direct map
entry, you do not need to run the automount command.
For example, suppose you modify the auto_direct map so that the /usr/src directory
is now mounted from a different server. If /usr/src is not mounted at
this time, the new entry becomes effective immediately when you try to access
/usr/src. If /usr/src is mounted now, you can wait until the auto-unmounting occurs,
then access the file.
Note - Use indirect maps whenever possible. Indirect maps are easier to construct and less
demanding on the computers' file systems. Also, indirect maps do not occupy as
much space in the mount table as direct maps.
Avoiding Mount-Point Conflicts
If you have a local disk partition that is mounted on /src
and you plan to use the autofs service to mount other source directories,
you might encounter a problem. If you specify the mount point /src, the NFS
service hides the local partition whenever you try to reach it.
You need to mount the partition in some other location, for example, on
/export/src. You then need an entry in /etc/vfstab such as the following:
/dev/dsk/d0t3d0s5 /dev/rdsk/c0t3d0s5 /export/src ufs 3 yes -
You also need this entry in auto_src:
terra terra:/export/src
terra is the name of the computer.
Accessing Non-NFS File Systems
Autofs can also mount files other than NFS files. Autofs mounts files on
removable media, such as diskettes or CD-ROM. Normally, you would mount files on
removable media by using the Volume Manager. The following examples show how this
mounting could be accomplished through autofs. The Volume Manager and autofs do not
work together, so these entries would not be used without first deactivating the
Volume Manager.
Instead of mounting a file system from a server, you put the
media in the drive and reference the file system from the map. If
you plan to access non-NFS file systems and you are using autofs, see
the following procedures.
How to Access CD-ROM Applications With Autofs
Note - Use this procedure if you are not using Volume Manager.
- Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- Update the autofs map.
Add an entry for the CD-ROM file system, which should resemble the following:
hsfs -fstype=hsfs,ro :/dev/sr0
The CD-ROM device that you intend to mount must appear as a
name that follows the colon.
How to Access PC-DOS Data Diskettes With Autofs
Note - Use this procedure if you are not using Volume Manager.
- Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- Update the autofs map.
Add an entry for the diskette file system such as the following:
pcfs -fstype=pcfs :/dev/diskette
Accessing NFS File Systems Using CacheFS
The cache file system (CacheFS) is a generic nonvolatile caching mechanism. CacheFS improves
the performance of certain file systems by utilizing a small, fast local disk.
For example, you can improve the performance of the NFS environment by using
CacheFS.
CacheFS works differently with different versions of NFS. For example, if both the
client and the back file system are running NFS version 2 or
version 3, the files are cached in the front file system for access
by the client. However, if both the client and the server are running
NFS version 4, the functionality is as follows. When the client makes the
initial request to access a file from a CacheFS file system, the request
bypasses the front (or cached) file system and goes directly to the back
file system. With NFS version 4, files are no longer cached in a
front file system. All file access is provided by the back file
system. Also, since no files are being cached in the front file
system, CacheFS-specific mount options, which are meant to affect the front file system,
are ignored. CacheFS-specific mount options do not apply to the back file
system.
Note - The first time you configure your system for NFS version 4, a warning
appears on the console to indicate that caching is no longer performed.
How to Access NFS File Systems by Using CacheFS
- Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- Run the cfsadmin command to create a cache directory on the local disk.
# cfsadmin -c /var/cache
- Add the cachefs entry to the appropriate automounter map.
For example, adding this entry to the master map caches all home directories:
/home auto_home -fstype=cachefs,cachedir=/var/cache,backfstype=nfs
Adding this entry to the auto_home map only caches the home directory for
the user who is named rich:
rich -fstype=cachefs,cachedir=/var/cache,backfstype=nfs dragon:/export/home1/rich
Note - Options that are included in maps that are searched later override options which
are set in maps that are searched earlier. The last options that are
found are the ones that are used. In the previous example, an
additional entry to the auto_home map only needs to include the options in the
master maps if some options required changes.
Customizing the Automounter
You can set up the automounter maps in several ways. The following
tasks give details about how to customize the automounter maps to provide an
easy-to-use directory structure.
Setting Up a Common View of /home
The ideal is for all network users to be able to locate
their own or anyone's home directory under /home. This view should be common across
all computers, whether client or server.
Every Solaris installation comes with a master map: /etc/auto_master.
# Master map for autofs
#
+auto_master
/net -hosts -nosuid,nobrowse
/home auto_home -nobrowse
A map for auto_home is also installed under /etc.
# Home directory map for autofs
#
+auto_home
Except for a reference to an external auto_home map, this map is empty.
If the directories under /home are to be common to all computers, do
not modify this /etc/auto_home map. All home directory entries should appear in the
name service files, either NIS or NIS+.
Note - Users should not be permitted to run setuid executables from their home directories.
Without this restriction, any user could have superuser privileges on any computer.
How to Set Up /home With Multiple Home Directory File Systems
- Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- Install home directory partitions under /export/home.
If the system has several partitions, install the partitions under separate directories, for
example, /export/home1 and /export/home2.
- Use the Solaris Management Console tools to create and maintain the auto_home map.
Whenever you create a new user account, type the location of the user's
home directory in the auto_home map. Map entries can be simple, for example:
rusty dragon:/export/home1/&
gwenda dragon:/export/home1/&
charles sundog:/export/home2/&
rich dragon:/export/home3/&
Notice the use of the & (ampersand) to substitute the map key. The
ampersand is an abbreviation for the second occurrence of rusty in the
following example.
rusty dragon:/export/home1/rusty
With the auto_home map in place, users can refer to any home directory
(including their own) with the path /home/user. user is their login name
and the key in the map. This common view of all home directories
is valuable when logging in to another user's computer. Autofs mounts your home
directory for you. Similarly, if you run a remote windowing system client on
another computer, the client program has the same view of the /home directory.
This common view also extends to the server. Using the previous example, if
rusty logs in to the server dragon, autofs there provides direct access to
the local disk by loopback-mounting /export/home1/rusty onto /home/rusty.
Users do not need to be aware of the real location of
their home directories. If rusty needs more disk space and needs to have
his home directory relocated to another server, a simple change is sufficient. You need
only change rusty's entry in the auto_home map to reflect the new location.
Other users can continue to use the /home/rusty path.
How to Consolidate Project-Related Files Under /ws
Assume that you are the administrator of a large software development project. You
plan to make all project-related files available under a directory that is called
/ws. This directory is to be common across all workstations at the site.
- Add an entry for the /ws directory to the site auto_master map, either
NIS or NIS+.
/ws auto_ws -nosuid
The auto_ws map determines the contents of the /ws directory.
- Add the -nosuid option as a precaution.
This option prevents users from running setuid programs that might exist in any
workspaces.
- Add entries to the auto_ws map.
The auto_ws map is organized so that each entry describes a subproject. Your
first attempt yields a map that resembles the following:
compiler alpha:/export/ws/&
windows alpha:/export/ws/&
files bravo:/export/ws/&
drivers alpha:/export/ws/&
man bravo:/export/ws/&
tools delta:/export/ws/&
The ampersand (&) at the end of each entry is an abbreviation for
the entry key. For instance, the first entry is equivalent to the following:
compiler alpha:/export/ws/compiler
This first attempt provides a map that appears simple, but the map
is inadequate. The project organizer decides that the documentation in the man entry
should be provided as a subdirectory under each subproject. Also, each subproject requires
subdirectories to describe several versions of the software. You must assign each of
these subdirectories to an entire disk partition on the server.
Modify the entries in the map as follows:
compiler \
/vers1.0 alpha:/export/ws/&/vers1.0 \
/vers2.0 bravo:/export/ws/&/vers2.0 \
/man bravo:/export/ws/&/man
windows \
/vers1.0 alpha:/export/ws/&/vers1.0 \
/man bravo:/export/ws/&/man
files \
/vers1.0 alpha:/export/ws/&/vers1.0 \
/vers2.0 bravo:/export/ws/&/vers2.0 \
/vers3.0 bravo:/export/ws/&/vers3.0 \
/man bravo:/export/ws/&/man
drivers \
/vers1.0 alpha:/export/ws/&/vers1.0 \
/man bravo:/export/ws/&/man
tools \
/ delta:/export/ws/&Although the map now appears to be much larger, the map still
contains only the five entries. Each entry is larger because each entry contains
multiple mounts. For instance, a reference to /ws/compiler requires three mounts for the vers1.0,
vers2.0, and man directories. The backslash at the end of each line informs autofs
that the entry is continued onto the next line. Effectively, the entry is
one long line, though line breaks and some indenting have been used to
make the entry more readable. The tools directory contains software development tools for
all subprojects, so this directory is not subject to the same subdirectory structure.
The tools directory continues to be a single mount.
This arrangement provides the administrator with much flexibility. Software projects typically consume substantial amounts
of disk space. Through the life of the project, you might be
required to relocate and expand various disk partitions. If these changes are reflected in
the auto_ws map, the users do not need to be notified, as the
directory hierarchy under /ws is not changed.
Because the servers alpha and bravo view the same autofs map, any users
who log in to these computers can find the /ws namespace as
expected. These users are provided with direct access to local files through loopback
mounts instead of NFS mounts.
How to Set Up Different Architectures to Access a Shared Namespace
You need to assemble a shared namespace for local executables, and applications, such
as spreadsheet applications and word-processing packages. The clients of this namespace use several
different workstation architectures that require different executable formats. Also, some workstations are running different
releases of the operating system.
- Create the auto_local map with the nistbladm command.
See the System Administration Guide: Naming and Directory Services (NIS+).
- Choose a single, site-specific name for the shared namespace. This name makes
the files and directories that belong to this space easily identifiable.
For example, if you choose /usr/local as the name, the path /usr/local/bin
is obviously a part of this namespace.
- For ease of user community recognition, create an autofs indirect map. Mount this
map at /usr/local. Set up the following entry in the NIS+ (or NIS)
auto_master map:
/usr/local auto_local -ro
Notice that the -ro mount option implies that clients cannot write to any
files or directories.
- Export the appropriate directory on the server.
- Include a bin entry in the auto_local map.
Your directory structure resembles the following:
bin aa:/export/local/bin
- (Optional) To serve clients of different architectures, change the entry by adding the autofs
CPU variable.
bin aa:/export/local/bin/$CPU
How to Support Incompatible Client Operating System Versions
- Combine the architecture type with a variable that determines the operating system type
of the client.
You can combine the autofs OSREL variable with the CPU variable to form a
name that determines both CPU type and OS release.
- Create the following map entry.
bin aa:/export/local/bin/$CPU$OSREL
For clients that are running version 5.6 of the operating system, export the
following file systems:
How to Replicate Shared Files Across Several Servers
The best way to share replicated file systems that are read-only is to
use failover. See Client-Side Failover for a discussion of failover.
- Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- Modify the entry in the autofs maps.
Create the list of all replica servers as a comma-separated list, such as
the following:
bin aa,bb,cc,dd:/export/local/bin/$CPU
Autofs chooses the nearest server. If a server has several network interfaces, list
each interface. Autofs chooses the nearest interface to the client, avoiding unnecessary routing
of NFS traffic.
How to Apply Autofs Security Restrictions
- Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- Create the following entry in the name service auto_master file, either NIS or
NIS+:
/home auto_home -nosuid
The nosuid option prevents users from creating files with the setuid or setgid
bit set.
This entry overrides the entry for /home in a generic local /etc/auto_master file.
See the previous example. The override happens because the +auto_master reference to the external
name service map occurs before the /home entry in the file. If the
entries in the auto_home map include mount options, the nosuid option is overwritten. Therefore,
either no options should be used in the auto_home map or the nosuid
option must be included with each entry.
Note - Do not mount the home directory disk partitions on or under /home
on the server.
How to Use a Public File Handle With Autofs
- Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- Create an entry in the autofs map such as the following:
/usr/local -ro,public bee:/export/share/local
The public option forces the public handle to be used. If the NFS
server does not support a public file handle, the mount fails.
How to Use NFS URLs With Autofs
- Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- Create an autofs entry such as the following:
/usr/local -ro nfs://bee/export/share/local
The service tries to use the public file handle on the NFS
server. However, if the server does not support a public file handle,
the MOUNT protocol is used.
Disabling Autofs Browsability
Starting with the Solaris 2.6 release, the default version of /etc/auto_master that
is installed has the -nobrowse option added to the entries for /home and
/net. In addition, the upgrade procedure adds the -nobrowse option to the /home
and /net entries in /etc/auto_master if these entries have not been modified.
However, you might have to make these changes manually or to turn off
browsability for site-specific autofs mount points after the installation.
You can turn off the browsability feature in several ways. Disable the feature
by using a command-line option to the automountd daemon, which completely disables autofs
browsability for the client. Or disable browsability for each map entry on all
clients by using the autofs maps in either an NIS or NIS+ namespace.
You can also disable the feature for each map entry on each client,
using local autofs maps if no network-wide namespace is being used.
How to Completely Disable Autofs Browsability on a Single NFS Client
- Become superuser or assume an equivalent role on the NFS client.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- Edit the /etc/default/autofs file to include the following keyword and value.
AUTOMOUNTD_NOBROWSE=TRUE
- Restart the autofs service.
# svcadm restart system/filesystem/autofs
How to Disable Autofs Browsability for All Clients
To disable browsability for all clients, you must employ a name service such
as NIS or NIS+. Otherwise, you need to manually edit the automounter maps
on each client. In this example, the browsability of the /home directory is
disabled. You must follow this procedure for each indirect autofs node that needs
to be disabled.
- Add the -nobrowse option to the /home entry in the name service auto_master
file.
/home auto_home -nobrowse
- Run the automount command on all clients.
The new behavior becomes effective after you run the automount command on the
client systems or after a reboot.
# /usr/sbin/automount
How to Disable Autofs Browsability on a Selected File System
In this example, browsability of the /net directory is disabled. You can use
the same procedure for /home or any other autofs mount points.
- Check the automount entry in /etc/nsswitch.conf.
For local file entries to have precedence, the entry in the name service
switch file should list files before the name service. For example:
automount: files nisplus
This entry shows the default configuration in a standard Solaris installation.
- Check the position of the +auto_master entry in /etc/auto_master.
For additions to the local files to have precedence over the entries in
the namespace, the +auto_master entry must be moved to follow /net:
# Master map for automounter
#
/net -hosts -nosuid
/home auto_home
/xfn -xfn
+auto_master
A standard configuration places the +auto_master entry at the top of the file.
This placement prevents any local changes from being used.
- Add the nobrowse option to the /net entry in the /etc/auto_master file.
/net -hosts -nosuid,nobrowse
- On all clients, run the automount command.
The new behavior becomes effective after running the automount command on the
client systems or after a reboot.
# /usr/sbin/automount
