Automount
If you are used to later versions of Windows, you certainly know how nice it is to be able to
access files on remote systems without having to explicitely mount
them each time.
Occassionally, I get comments from Windows fans that the lack of this feature in Linux is
one of it’s major shortcoming. Well, that would be true, if Linux was missing this functionality.
In fact, this feature has been available for UNIX
longer than Windows NT has been around and
has been with Linux from the beginning. This is called “automount” or “automounter“.
In order to be able to mount a remote filesystem
using automount, you would first need to be able to mount
it using normal NFS. That is to say that there are no flags that you
can set on the remote side (where the filesystem
is being exported) that says either to explicitly allow or deny
access via automount. The remote filesystem
simply makes a resource available and you access it with whatever tool you see fit.
Therefore, for the purpose of this discussion, we are going to simply
assume that in each case, the remote host
has given us permission to access that filesystem.
For more details, see the previous section on NFS configuration.
The amd program provides you with the ability to mount
NFS filesystems only when you need them, automatically. They are
automatically mounted by automount, hence the name. Actually, conventional NFS mounted filesystems
can also be mounted automatically in the sense that you can configure them in /etc/fstab and they
are automatically mounted as the system boots. Automount filesystems, on the other hand, are first mounted
when a user tries to access files or directories under the mount
point. Also, if the files or
directories are not accessed within a specific time, (five minutes by default) they are unmounted,
thereby saving network
resources. When booting you could also save time since the system might be waiting to
connect to a remote machine that possibly could be down.
Keep in mind that the server side is oblivious to the fact that the request is coming from
automount. As far as it knows it is just your normal every day NFS
mount, therefore automounter
can be used with systems that don’t know about it.
The basic configuration unit with the automounter
is one or more files called “maps.” These map the filesystems you want to access to the
directory where you want to mount them (the mount points). These map
files are fairly easy to configure and can be edited with any text
editor. All automount connections are based on references in a map file.
The amd program is command-line based, so you can specify the name of the map file directly.
An example map file would look like this:
/defaults opts:=rw;type=nfs jmohr_home rhost:=jmohr;rfs:=/home
The first line specifies default parameters that are used during the mount.
In this case, we say that the filesystem
should be read-write (opts:=rw) and of type nfs (type=nfs). The next line specifies the directories to be
mounted. The syntax for these lines is:
directory rhost:=<remote_host>;rfs:=<remote_filesystem>
where directory is the name of the
directory on the local machine where the filesystem
should be mounted, <remote_host> is the
name of the machine from which you are mounting the filesystem
and <remote_filesystem> is the name of the remote filesystem.
To start amd the general syntax is:
/usr/sbin/amd -a <temp_dir> — /<real_dir> <map_file>
Here, <temp_dir> is the name of a
temporary directory where the remote filesystems are actually mounted. This directory is created by
amd and should be removed if you start amd automatically through the rc scripts. A common convention
is to define this directory as /amd. The two dashes (–) is a common construct and tell amd that there
are no more option to process. The /<real_dir> indicates the directory where the users will
see the filesystems mounted. Finally, <map_file> is the name of the map file where amd should
get its configuration information.
To run amd using the example configuration file, we might start it like this:
/usr/sbin/amd -a /amd — /usr/jmohr/homes /etc/amd.junior
Here we
mount the remote filesystems under /amd and the users see them under /usr/jmohr/homes. So, if my
home directory on junior was /usr/jmohr/homes/jimmo every time I log into junior, amd kicks
in and mounts the /home directory from jmohr.
Don’t think of automount as your only means of mounting NFS
filesystem just because of it’s advantages. If you are constantly accessing
certain filesystems, then you gain nothing by making them automounted. In fact, you might lose
something since each time the connection is made, you need to wait. If mounted in the conventional
manner, then you only need to wait once. If you have filesystems that are accessed regularly, but
others that are accessed only on occasion, you simply mount
some at boot and the rest via automount.
A common use of automount is with NIS. NIS is used to distribute configuration
files from the NIS server across the net to the NIS
clients. Why not include the automount maps in the set of files
that is being distributed? This could be useful if you wanted to have all the documentation on a
single machine to save space and access to the doc is made through automount. Since doc is not being
constantly access, this saves the problem of having the filesystem
containing the doc be continually
mounted.
Another use is when you want each user to have the same home directory
no matter
where they are. Something similar to what we had in the example above. If mounted by automount and
distributed via NIS,
every time they logged in, no matter on what machine, they would have the same
home directory. Granted, there is the problem of not being able to access their
home directory if
the server is down. However, the problem of not being able to access the home directory still applies
when login into a single machine. For example, if the home directory was on
a filesystem that wasn’t mounted.
In reality, automount behaves very similarly to traditional NFS
mounts. The system knows that the
specified directory is an NFS
mount
point. When something is accesses on the other side of the mount
point, the automount daemon
reacts to the request basically the same way nfsd does with a normal NFS
filesystem. The automount daemon then checks the mount
table (/etc/mnttab) to see if the filesystem is already mounted
and mounts it if it isn’t. Once the file system is mounted, requests are handled
normally.
Like other filesystems, an entry is maintained in the system mount table
(/etc/mnttab) for all filesystem
that have been mounted with automounter.
When the timeout has
expired (five minutes by default), automounter
removes the entry from /etc/mnttab, but still
maintains a copy in its memory. This copy is updated whenever mounting or unmounting a filesystem.
The version of amd that I installed with Caldera OpenLinux has some really nifty
features. (These feature may be available in other releases, I just didn’t test them). The most
exciting feature for me required me to reconsider what amd was there for.
I had always used amd (as well as the automounter
of other UNIXes) to automatically mount
files systems from other machines. That is, mounting them via NFS.
On the surface, one thinks of UNIX system administrators
as being lazy. They spend all day trying to get out of work. That is, they develop programs that save
them work. Never mind that the work that is saved is much less than the work that they invested in
trying to save that work.
This is not a bad thing, for two reasons. First, the mentality of
most UNIX
administrators is that this really isn’t an attempt to get out work. There should be a
better way of doing something, so they set out to find it. Just like the great inventors and
explorers of the past, they try it because “it’s there.”
The reason that this is not a bad
thing is because like other kinds of inventions, the results are there for others. Once the program
exists, then other administrators can use it. In keeping with the Linux mentality, you create a
program that _you_ want to write, share it with others and they share theirs with you. You now have
an entire tool chest of utilities that didn’t exist a year ago.
So, what does this have to do
with amd? Well, how often have you wanted to access a floppy, CD-ROM
or DOS partition
on your machine? First, you need to find the device that it’s on, then find a place to mount
it and then finally you get around to mounting it. Wouldn’t it be nice if you could access these filesystem
without having to go through all of this? You can!
That’s the nice thing about amd. You can use it to mount
all sorts of filesystems, including those on floppy, CD-ROMs and DOS
partitions. In fact, that’s what I did. I have a handful of applications that do not run under VMWare, so
I am forced to switch to Windows 95
when I want to run them. Therefore, I cannot make my entire system Linux. Often, I need to transfer
data from one system to other. That means finding the device that it’s on, then finding a place
to mount it and then finally getting around to mounting it.
What a waste of time!
I noticed that amd was running on my system, using the configuration file
/etc/amd.localdev. Seeing that I thought, “localdev? local devices? Hmmm….” Checking in this file,
I discovered that you can, in fact, mount
local filesystem via amd. So, let’s take a look at the
file that had on my system:
# /etc/amd.localdev : automounter map for local devices
# Don’t forget to unmount floppies with “amq -u /auto/floppy” before
# ejecting them, especially when they are mounted read-write !!!
/defaults opts:=nodev,nosuid,ro;dev:=/dev/${key};type:=msdos;
# floppy -dev:=/dev/fd0;type:=msdos opts:=rw opts:=ro
floppy dev:=/dev/fd0;type:=msdos;
# floppy95 -dev:=/dev/fd0;type:=vfat; opts:=rw opts:=ro
floppy95 dev:=/dev/fd0;type:=vfat;
cdrom type:=iso9660
c_drive dev:=/dev/sda1;type:=vfat; opts=rw
d_drive dev:=/dev/sda5;type:=vfat; opts=rw
e_drive dev:=/dev/sdb1;type:=vfat; opts=rw
f_drive dev:=/dev/sdb5;type:=vfat; opts=rw
g_drive dev:=/dev/sdb6;type:=vfat; opts=rw
h_drive dev:=/dev/sdb7;type:=vfat; opts=rw
* dev:=/dev/${key}
In principle the options are the similar to those for the fstab and exports files.
I leave it to you to check amd(8) man-page for the details.
The thing I want to first point out is the last line:
* dev:=/dev/${key}
As one might guess from the asterisk, this is a wild
card and represents every filesystem
that we have not specified previously. Since we did not specify any options,
the options used are those in the /default line. The nifty part of this
is the ${key} part of the device name. This is translated to
mean the name of the sub-directory under /auto. For example,
my C: drive is /dev/sda1. If I did cd
/auto/sda1, amd would see the name of the sub-directory as sda1, then it
would look for a matching device. Since it finds one, it can mount
that device. Therefore, if you
have mountable filesystem,
you do *not* need to explicitely define them.
In this file are two
lines for floppies (floppy and floppy95). The type of filesystem
in the first line is msdos and this
second is vfat, which allows you to mount
a floppy and still have access to the long filenames. The
next line is one for a cdrom. These were the lines that were originally in my amd.localdev file.
When you start amd, you tell it the name of where it should mount
these filesystems. By
default, on my system, this is the directory, /auto. So,
when I do a cd /auto/cdrom, the cdrom is automatically
mounted and I find myself in the root directory of the cdrom without going through the hassle of
mounting it first.
Once I discovered this, I add the lines that look like this:
c_drive dev:=/dev/sda1;type:=vfat; opts=rw
As you might guess, this automatically mounts my DOS
filesystems. I originally had them
all in /etc/fstab, so they would automatically mount
at boot
up. Since I only use them occasionally,
this didn’t make sense. I changed the entries so that they weren’t mounted automatically, all I had
to do was run “mount /dev/sda1! (or whatever) and they were mounted.
Note in this case that
the filesystem
type is actually VFAT, and not the standard DOS
FAT filesystem. Now, when I do
cd /auto/c_drive, I find myself on the C: drive of my
Windows 95 system. (/dev/sda1) When I do
cd /auto/g_drive, I am then on the G: drive.
Being a normal Linux system administrator,
this was too much for me. Not that the work was too much, I had too many
entries in there that were basically all the same. In essence, the default behavior that I wanted was
that I would cd into a directory under /auto and I would be
on one of my Windows 95
drives. Therefore, I could change the
/default like to look like this:
/defaults opts:=nodev,nosuid;dev:=/dev/${key};type:=vfat;
Note that I not only changed the filesystem
type to vfat, but I also removed the options to say that this was a read-only
filesystem (ro). Now when I do a cd /auto/sda1 I am on the
C: drive or /auto/sdb6 I am on the G: drive.
Hmmmm.
How do I know that /dev/sdb6 is the G: drive? Trying to
figure that out each time is as much work as mounting it by hand. (Well, not quite.) To save me some
work, I simply created a handful on links in /dev that look
like this:
lrwxrwxrwx 1 root root 4 Jan 26 10:46 /dev/c_drive -> sda1
lrwxrwxrwx 1 root root 4 Jan 26 10:46 /dev/d_drive -> sda5
lrwxrwxrwx 1 root root 4 Jan 26 10:46 /dev/e_drive -> sdb1
lrwxrwxrwx 1 root root 4 Jan 26 10:46 /dev/f_drive -> sdb5
lrwxrwxrwx 1 root root 4 Jan 26 10:46 /dev/g_drive -> sdb6
lrwxrwxrwx 1 root root 4 Jan 26 10:46 /dev/h_drive -> sdb7
Now, I all need to do is cd /auto/g_drive and I end up on the right drive.
One might ask what advantage this has over traditional mounts via /etc/fstab. When dealing
with NFS mounts across the
network, there is the issue of bandwidth
and the problems that occur when the server side goes down.
Since you are accessing a local drive, there are no issues of bandwidth
and if the server goes down, the client
goes with it.
Well, that last part is the point. If I only need to access the
filesystem for a short time, it is safer to umount when I am done. By using amd, I don’t need to
worry about forgetting it. After specific period of time (default: 5 minutes), the system will
unmount any unused filesystems.
| File | Function |
| /etc/amd.local | Automount configuration file for local devices |
| /etc/exports | NFS files systems being exported |
| /usr/sbin/rpc.portmap | Portmapper. Converts DARPA ports to RPC program number. |
| /usr/sbin/rpc.mountd | NFS mount request server. |
| /usr/sbin/rpc.nfsd | NFS daemon to handle client requests. |
| /usr/sbin/amd | The automount program. |
| /usr/sbin/rpc.rusersd | Network user name server. |
| /usr/sbin/rpc.rwalld | Network wall server. |
| /usr/bin/rpcinfo | Reports RPC information. |
| /usr/bin/rusers | Reports information on network users. |
| /usr/bin/rwall | Write to all users on the network. |
| /usr/bin/showmount | Shows information on remotely mounted filesystems. |
