The automount daemon, started at boot time on every host, reads its automounter maps and fools the kernel into thinking that those file systems are NFS mounted. The automount daemon then filters every file reference to see if there is a match between the file's directory path and one of the automounter's map entries. If there is, then the automounter will, if necessary, issue the NFS mount command with appropriate access privileges. If no one actually does any work 'in' the automounted NFS file system for a (default) period of 5 minutes, then the automount daemon unmounts the NFS until the next reference.
If the automount daemon has to do an NFS mount it mounts the file system under its own temporary local physical file structure /tmp_mnt and then creates a symbolic link which points to the correct subdirectory of /tmp_mnt to complete the illusion. Example
/data/geophys is referenced and the automounter creates a physical local directory called /tmp_mnt/data/geophys on which it hangs (NFS mounts) the remote machines physical directory /local/data/geophys. Finally, it creates a local symbolic link, /data/geophys, which points to /tmp_mnt/data/geophys.
Solaris 2.4 ( and above) systems use a new and more flexible system, which creates mount points according to the automounter maps, thus eliminating the /tmp_mnt step), and also handles direct maps better. IRIX 6.2 has a version of autofs but unfortunately this does not handle command-line map invocation which is needed for our implementation, so the older version has to be used.
The NERC automounter mount points
In the NERC filesystem there are mount points called
/nerc ( with subdirectories bin,etc, scripts
which are created by the automounter and owned by it. These correspond to the auto.nerc, auto.users, auto.data and auto.packages<arch> maps.On some sites there are also mount points
which correspond to auto.scratch, auto.working maps.
The following lines appear in the NERC auto.master map ( except at SOC which is different!).
# key map [mount options] (lines beginning with # are comments)
/users auto.users -rw,hard,noquota,timeo=10,intr
/data auto.data -rw,hard,noquota,timeo=10,intr
/- auto.nerc -ro,soft,noquota,timeo=10,intr
The three columns are, from the left, the key directory reference which will cause automount to search the map in the second column and make any NFS mounts using the mount options in the third column. These mount options vary from site to site and from architecture to architecture ( to a certain extent).
The first two lines are entries for indirect maps and the third line is for a direct map - see discussion below.
Note: in the present implementations of the automounter only one direct map is allowed. As the NERC system requires two, one for auto.nerc and another for auto.packages<arch>, the second is referenced in the automounter invocation file as an inline command and not included in the auto.master file where it would logically belong. See the discussion of automounter invocation at the end of this chapter.
Indirect maps hold entries for subdirectories of the 'key' directory which caused the particular indirect map to be consulted. auto.data and auto.users are indirect maps.
This relates user ids to their physical login directory location in the NIS domain.
An example of auto.users:
#automounter map for user directories
ncs -rw wlfiles:/local77/users/ncs
ncssys -rw wlcomms:/local22/users/ncs
dr -rw wlcomms:/local22/users/dr
chem -rw wlfiles:/local22/users/chem
In the passwd file all users have home directories /users/<group>/<id> or /users/<id>. When they log on the reference to /users triggers the automounter to look in the auto.users map for the <group> or <id> key. The former method is preferred in the Southern Area, the latter in the Northern Area, but they may both occur in the same auto.users. For example, when a chemistry user 'fred' logs on, with home directory /users/chem/fred, the auto.users table directs the automounter to mount /local22/users/chem from wlfiles on the host where he has just logged in. A user 'dr' on the other hand has his own separate mount /local22/users/dr from wlcomms.
Groups can be split across disks or machines by giving them a different key; some of the ncs users have home directories /users/ncs/<id> and others have home directories /users/ncssys/<id>. When they log on the reference to /users triggers the automounter to look at the auto.users table, and then to pick up either the mount for ncs or the one for ncssys. The 'group' in /users/<group> has no relation to the UNIX GID; it is often named the same for convenience but there is no reason why /users/ncs, /users/ncs1 and /users/dr should not all have user home directories whose GID is 1000 (ncs).
This is the map which allows users to have data directories or common data areas on physical disks other than the one containing their home directory.. This map can also be used for defining spool areas. Its form is the same as for auto.users:
#automounter map for data areas
geophys -rw kwda:/local/data/geophys
The permissions on the local files would determine who could write to them; as far as the automounter is concerned they are mounted read-write.
Direct maps are like wildcard entries; any map whose 'key' is defined as /- should be searched for a match of the absolute directory path being referenced if it doesn't match any indirect map's key.
auto.master,auto.nerc and auto.packages<arch> are direct maps.
These are the maps which are architecture dependent and relate applications packages to their physical location in the NIS domain. They allow one copy of, say, SAS to be used by all the Solaris hosts on the network instead of each having its own. Third- party packages are always installed in a central place. Sometimes it is necessary to have symbolic links back to where the originator intended the package to go - these are handled by scripts called nercinstall. The architecture-dependent maps allow there to be /nerc/packages/oracle pointing to Oracle for Suns or Oracle for Silicon Graphics depending on what architecture machine you happen to be on. The maps are 'direct' so that all packages can be 'seen' at once by 'setup' in order to show what packages are available for a given architecture. Direct maps require a little more thought when updating than Indirect ones.
Example of auto.packages<arch> map
/nerc/packages/sas -ro,hard,intr wlfiles:/local23/packages/solaris/sas
This is the link between the logical and physical /nerc directory structure. It mounts the separate directories etc, <arch>/bin , domain, and <arch>/man from the NERC filesystem master server ( usually the NIS master) onto /nerc/etc, /nerc/bin and so on. A typical auto.nerc looks like this:
# auto.nerc NIS map
/nerc/etc -ro wlcomms:/local/master/etc
/nerc/bin -ro wlcomms:/local/master/$NERCARCH/bin
/nerc/man -ro wlcomms:/local/master/$NERCARCH/man
/nerc/wallingford -ro wlcomms:/local/wallingford/domain
/nerc/scripts -ro wlcomms:/local/master/$NERCARCH/scripts
There is also a mount point called /net which is created by the automounter for direct access to any exported (made to be accessible over NFS) filesystem on any host on the network. There is no map for this. It is used as follows:
To access a directory /local22/users on wlcomms, from anywhere else on the network, type
Assuming local22, or local22/users, is available for export the directory will be mounted on /tmp_mnt/net/wlcomms/local22/users and a link made to /net/wlcomms/local22/users. This is a rather longhand method of accessing filesystems since it requires knowledge of the hostname, but as it does not require root privileges it is useful for temporary mounts.
Some mount options used in automount
ro Read only
rw Read write
soft Once a read/write to a mounted file system has failed after appropriate numbers of attempts then report failure and stop trying.
hard As 'soft' but after reporting a failure keep repeating until an interrupt is received (best used with rw systems).
intr Allows user interrupts to stop a read/write to a file system.
32bitclients Used on 64-bit IRIX systems to allow 32-bit hosts to mount filesystems from it.
Check that the new or changed partition is properly exported from the host, and that mountd is running on the host. If this is the first time a filesystem has been exported the system will need to be rebooted to start mountd.. Note that for Solaris 2.3 and above this applies even when the partition is on the same host where it is to be automounted.
On a Solaris 2.3 ( or above) system the automounter can be made to reread its maps by simply typing
and the new entry should be visible. If it is not, check that the old entry is not still mounted ( i.e. that if it is a package, the package supporter has logged off, or the licence manager daemon referring to it has been stopped).
On other systems, after checking that the affected entry is not being accessed, find the process ID of the automounter daemon and kill it. Restart it with the special NERC command on all architectures (except Solaris 2.3 and above):
If the new entry is in fact a change to an existing one, make sure that
the affected partition is not mounted. If it is a package,
the package owner must log off, and any processes using the package such as licence manager will need to be killed.
Warning: if the system is busy at the time, particularly
with older IRIX systems, it is entirely possible that it will hang. The
only clean way to make a direct map change effective is to reboot the workstation.
With SunOS systems running xdm the Openwindows system will be permanently
mounted, so unless it is locally installed a reboot will certainly be necessary
.... /- auto.packages$NERCARCH.....
which means that the packages map is obtained from the NIS master. Sometimes it is necessary to have the package map local to the host, to override the NIS one.
This happens for example on an ORACLE database server, where the server version of ORACLE is not the same as that seen by clients on the same architecture.
On a SunOS or IRIX system it is necessary to do this explicitly; in this case change /etc/rc.local.automount so that the section above reads
and copy the relevant portion of the NIS map to the local host;
ypcat auto.packagessun4 | grep sas > /etc/auto.packagessun4
This will use only the specific local package and will pick up all other packages from the NIS map.
To do this permanently on an IRIX system the /etc/config/automount.options file must also be changed; SunOS startups have been changed by the NERC installation to invoke /etc/rc.local.automount so there is only one place to change.
On a Solaris system, the changes to /etc/rc.local.automount are not necessary, as the automounter will look for a local map anyway before consulting the NIS one. The form of the local /etc/auto.packages<arch> map will however be the same.
The automounter has to be killed and restarted before the local map comes into effect.
Advanced NIS maps
If the site is large and divides logically into several work groups, it is useful to make several sets of maps, each pertaining to a group. These must all be present in auto.master. In one case we have used a second level of hierarchy in the map key;
normally auto.data looks like
The maps themselves look much like ordinary data
It is sometimes useful to distinguish between data areas which are in constant flux and those which are static, for the purposes of doing backups or archives. New maps similar to auto.data have been created for this purpose, called auto.working and auto.scratch. The philosophy is that auto.data areas are almost static and are backed up infrequently, while auto.working areas are in constant use and should have incremental backups daily. Auto.scratch areas may or may not be backed up and are cleared out at regular intervals.
Any of these maps can be made hierarchical as described for auto.data, since they are indirect maps. This is not a principle that can be applied to package maps since they are direct.
Another use of data areas is to provide world-readable
or world-writable areas under controlled conditions; for example in the
/nerc/packages implementation of LaTeX it is necessary to provide an area
for automatically created fonts generated as the system is used, and this
is done by linking the area where LaTeX wants to put the fonts to a /data/fonts
directory which is world writable and world readable. This protects the
package directory itself which can be mounted read-only.