Author: Brian Jones
Why Use an Automounter Anyway?
Automounters can be a real pain in the neck. Admins don’t like things that are a pain in the neck, so one should be able to gather that if we’re putting up with these things, they must be pretty darn useful – and they are. For one thing, automounters can get their mounting information from centralized ‘maps’, which can be flat files, or even NIS maps or sections of an LDAP directory. This is far easier than editing 300 /etc/fstab files for different static NFS mounts.
In addition, mounting a directory with an automounter means that it is automagically mounted and unmounted as needed. A static NFS mount is usually mounted at boot time, or done manually after boot, and only unmounted during your ‘netfs’ service shutdown, or by hand using the ‘umount’ command. The difference is apparent during a failure: if the remote file server becomes unavailable, an automounter will time out, unmount the directory, and move on, whereas a static NFS mount will hang until the server comes back.
There are other configuration options that automounters can take that make them a more desirable tool for administrators. We’ll talk about some of them once we’ve laid a proper foundation for more advanced topics.
Amd or Autofs? What’s the Difference?
Probably the biggest difference between amd and autofs is where their code lives. Amd is the ‘userland automounter’. It works like a lot of other networked applications using RPC (Remote Procedure Call). The good news is that this should make the application’s inner workings easier to understand for those who use other RPC-enabled applications. The bad news is that the RPC calls go to the kernel, where file system code lives. Every time it makes a file system call to the kernel, it incurs a context switch, where the duties involved in carrying out an operation pass from the user space to the kernel space. This is a somewhat costly proposition for something that could potentially be doing a hundred or more operations per second.
Autofs, by contrast is an ‘in-kernel’ automounter. It also uses maps to figure out what its job is, and the userland interface for this is the automount(8) utility. Generally, in a working environment, my experience has been that it’s rare to have to actually resort to using ‘automount’. Still, it’s a good tool to know about, ‘just in case’.
On top of the performance boost associated with being in kernel space, autofs also enables administrators to perform mounts ‘in place’. This means that directories are mounted under the mount points used directly by the users. This closely mirrors how administrators of static NFS environments would expect things to work. Amd does not perform mounts this way, and by design, it cannot perform in-place mounts. Really. Don’t try it at home. Bad things will happen.
While it’s probably quite easy to look at this comparison and make your mind up right now about which one is ‘better’, remember that this term is completely meaningless outside the context of a production environment. Each one has benefits in certain situations. As a production, enterprise administrator, you really need to have a knowledge of as many mounting methods as possible.
For now, let’s focus on a typical config file from each daemon, which will allow us to discuss some of their respective features in a bit more detail.
Autofs Configuration
The master configuration file for autofs is /etc/auto.master. Here’s a (relatively small) typical sample config:
/.autofs file:/etc/auto.direct --timeout 300
/mnt file:/etc/auto.mnt --timeout 60
/n/fs yp:automap --timeout 300
This file consists of three fields; the first being a mount point on the local filesystem. This means when you do an ‘ls -a /’ on a machine whose autofs used this config file, you should see an /.autofs directory, a /mnt directory and a /n directory (under which is the ‘fs’ directory specified in ‘/n/fs’). The second field is of the format
You’ll notice the /n/fs entry is slightly different in that it specifies ‘yp:automap’ in the map field. We also have the keyword ‘file:’ in front of the other map field entries, even though ‘file’ is the default, just to be safe (actually, in RH 7.3, autofs threw loads of errors until the keywords were put there). The ‘yp’ keyword tells the automounter to look up the map using NIS.
Let’s have a quick look at the ‘auto.direct’ and ‘auto.mnt’ files referenced in the master config file. We’ll look at ‘auto.mnt’ first:
cdrom -fstype=iso9660,ro :/dev/cdrom
floppy -fstype=vfat :/dev/fd0
isoz -ro,hard,intr isoserv:/cd-images
The above ‘auto.mnt’ file specifies mount points managed by autofs. All of these directories will be mounted as subdirectories of the ‘/mnt’ directory, as implied by the ‘/mnt’ entry in the auto.master file referenced earlier. The flags here are probably self explanatory, but just to make sure everyone’s on the same page, the ‘-fstype’ has to be a valid filesystem type on your system, and match that of what you actually try to mount (ie, you can’t put ‘ufs’ in for the cdrom device and expect your audio cd’s to work). The last field is of the form
As you’ve probably noticed, you can string along other mount options in the middle field of these config files. These options come from the standard list of mount options, which you can find in the mount(8) man page, and probably other documents as well. If you understand this, you should be able to apply the same exact logic to the ‘auto.direct’ map. The only difference between these files (and any others listed in auto.master) is the local mount point they are in charge of.
Amd Configuration
Amd gets its main configuration information from a file modeled after the Samba configuration file, and it’s called /etc/amd.conf. This file contains global settings for the daemon, and, like autofs, delegates the configuration of different local mount points to seperate map files. Here’s a rather typical example of an amd.conf file – ripped to shreds to explain the options in a little more detail:
[ global ] # Global settings: these affect how the base daemon runs
normalize_hostnames = no # If set to 'yes', amd will use fully qualified hostnames when contacting remote hosts.
print_pid = yes # print process id number to file indicated by 'pid_file' param. below.
pid_file = /var/run/amd.pid
restart_mounts = yes # causes amd to create a data structure for each file server in /etc/mtab, speeding mount times for new mounts.
auto_dir = /.automount # this is the actual directory under which filesystems
are mounted.
log_file = syslog # Instead of logging to a file, amd sends messages to the
local syslog daemon.
log_options = all # tells amd to log every message. Other options are 'debug',
'warn', etc. This can be a comma-delimited list.
plock = no # this tells the linux kernel to treat amd like a normal, userland
app. Set to 'yes', amd generally runs faster, since the kernel will reserve
memory for amd, and text and data pages will be locked using the 'mlock'
system call. The downside is, of course, you are permanently reserving memory for
amd, making it unavailable for other 'stuff'.
print_version = no # Prints the amd version to the terminal at startup and runs
as normal.
map_type = file
search_path = /etc # this is the directory where amd expects to find
its maps.
browsable_dirs = yes # this means that amd will show *active* directories in
'ls' output. Note that others may be mounted in the background!
show_statfs_entries = no # this passes some useful information to the 'statfs'
call used to produce 'df' output. Note that it is NOT accurate in the context
of 'df' output. It doesn't return percent used or 1k blocks - it returns
instead the number of entries in a map, and the number of those entries that
are active. df then uses those two numbers to calculate the '% used' number,
which in the case of amd is really the '% of map entries that are
active'.
fully_qualified_hosts = no # tells amd whether to use FQHN's during RPC
authentication. Note the difference between this and 'normalize_hostnames'
above, which is used only in the act of mounting remote filesystems and doesn't
address authentication.
cache_duration = 300 # tells amd how long (in seconds) to keep filesystem to
volume mapping details in memory.
# DEFINE AN AMD MOUNT POINT
[ /net ] # the directory users will use for the mount point.
map_name = amd.net # The map that will define what users can get to under the
'/net' directory.
map_type = file # The type of map that amd.net is.
There are a few things that need discussing here. One is the notion of the 'auto_dir', which is unique to amd, and illustrates the earlier point about amd not supporting 'in-place' mounts. What happens is that when amd starts up, it will mount anything it is told, under the directory specified by 'auto_dir' in the amd.conf file. From there, as an administrator, you would make symlinks into this directory from the target points in the filesystem. So if a directory called '/u' is mounted, then '/u' on your local filesystem would actually be a symlink to '/.automount/u'.
Let's have a look at the 'amd.net' file, which, according to amd.conf, contains configuration information for things mounted by amd under the '/net' directory on the local system. It contains only two entries:
/defaults fs:=${autodir}/${rhost}/root/${rfs};opts:=rsize=8192,wsize=8192
* rhost:=${key};type:=host;rfs:=/
The above 'amd.net' is a file that contains the parameters of the '/net' mount point. This is a fairly simple map, with just a '/defaults' entry and one wildcard entry denoted by the '*'. The defaults entry is one that is usually configured by default with most distributions of amd, and simply contains the path to the temp directory for the automounted directories. This can be a bit difficult to parse. The '${autodir}' variable is defined by the 'auto_dir' line in amd.conf. The '${rhost}' variable defaults to the local hostname. This is followed by '/root', which is a placeholder for '/', and the '${rfs}' variable, which defaults to the amd '${path}' variable, the default value of which is ${map}/${key}. You can look at this as the path element being looked up by the user under the directory managed by this map. The default value for ${map} is the directory this map represents, or, in this case '/net'. In case I haven't made that crystal clear, know that if the directory we're trying to reach is '/net/mybox/home/jonesy', then the above 'defaults' entry would translate to a path under the /.automount directory, and amd would return a symlink back to the user under '/net' which would be transparently used to reach whatever the user is looking for.
The '*' wildcard entry says to mount all directories exported by whatever machine the user specifies ( ${rhost} ), which becomes the ${key}. This allows a user to log onto a machine in a local workgroup-style configuration, and get access to any shares available on any host by simply typing 'cd /net/
In Closing
In this whirlwind introduction, I've introduced the basics of automounter configuration under Linux. This is really just the tip of the iceberg where their usage is concerned. These config files have a ton of options available for them, allowing you to employ some logic in them, to allow your automounters to be 'smarter' about how they do their work. While this article lays a very preliminary foundation, future works will explore more advanced and often-times unused functionality been built into the daemons in more recent versions.
