Node:Using the automounter, Next:Editing files, Previous:NFS resources, Up:Global configurations
The automounter is a daemon based service which replaces static mounting of NFS filesystems with a dynamical model. When the automounter is running, filesystems are mounted only when a user tries to access a file which resides on one of those filesystem. After a given period (usually five minutes) any filesystem which has not been accessed is unmounted. The advantage of this scenario is that hanging servers do not affect the behaviour of hosts which mount their filesystems, unless a specific file is being accessed. In both cases, filesystems must be exported in order to be mountable.
It is not the purpose of this section to explain the use of the automounter in detail, only to offer hints as to how cfengine can be used to simplify and rationalize automount configuration for the already initiated. Let us begin by comparing the behaviour of the automounter with the cfengine model for mounted filesystems.
The automounter is designed to be used together with a global
configuration file, distributed by NIS (the network information
service). As such, all hosts read the same configuration
file. This makes it appear as though all hosts end up mounting every
filesystem in the automount configuration database, but this is not so
in practice because filesystems are only mounted if required. Thus a
system which does not require a filesystem will not attempt to mount it.
Moreover, the existence of a global configuration file does not affect
which hosts have the right to mount certain filesystems (which is specified
by exports or share on the relevant server), thus a request to mount
a non-exported filesystem will result in an access denial. The automounter
is configured locally on each host in files named /etc/auto_master
,
auto_direct
etc.
In the cfengine static mounting scheme, you define a list of binary
and home servers. The filesystem table is modified on the basis of
these decisions, and filesystems are only added if cfengine deems it
appropriate to mount them on a given host. The idea here is to minimize
the number of filesystems mounted to those which are known to be required.
Again the issue of access permissions must be arranged separately. These
filesystems are placed directly in /etc/fstab
, or the equivalent for
your system.
From cfengine, you can use the automounter instead of the static mount model by
addmounts
, mountinfo
, mountall
from the actionsequence, in the control part
of your cfengine program,
editfiles
to edit the relevant configuration files
such as /etc/auto_master
, or auto_direct
etc,
AutomountDirectResources
command in editfiles
to dump the list of cfengine class-based list of mountables
into a file of your choice in the correct format for
autmount's direct maps,
processes
to restart the automounter
(send the hangup signal hup
), or perhaps stop and restart
the daemon by sending the term
signal (you should never
send the kill
signal).
files
or tidy
to
clean up stale links afterwards,
copy
to distribute basic automount configuration
files to multiple systems.
The automounter was created to solve certain problems which cfengine now
solves (in the author's opinion) better. For example, the use of the
`hosts' map in the automounter mounts filesystems like
/usr/local
on different (uniquely named) mountpoints for each host
in order to avoid name space collisions. Using cfengine and a unique
naming scheme, you can achieve the same thing more cleanly, without all
of the gratuitous linking and unlinking which the automounter performs
by itself. Moreover, the idea of a unique name-space is better practice
and more in keeping with new global filesystem ideas such as AFS and DFS.
The only advantage of the automounter is that one avoids the annoying
error messages from hung servers about "NFS server not responding".
In that respect, it seems sensible to use only direct mounts and a
unique name space.
Some systems advocate grouping all users' login (home) directories
under a common directory called /home
or users
.
The automounter goes through all manner of contortions to achieve
this task. If you use a unique naming scheme like the one
advocated here, this is a trivial task. You simply arrange to mount
or automount all user directories, such as
/site/host/home1 /site/host/home2 ...
and then link them as follows:
/home +> /site/host/home1 /home +> /site/host/home2 ...
Finally, you should be aware that the automounter does not like to be mixed with static mount and unmount operations. Automounted filesystems take priority over statically mounted filesystems, but the automounter can be confused by manually mounting or unmounting filesystems while it is running.