The automounter reads each of the entries to learn how to behave. Each entry defines the relationship between a directory and a corresponding NFS filesystem, in a direct or an indirect way.
The entry − defines direct mappings; it points to the etcauto_direct file for the actual direct mappings. Often, the NIS map is used instead of presented entries. The +auto_master refers to the
NIS map auto_master, which spreads a unique configuration all over the network. However, for this host this is not the case; obviously this host is the NIS master server.
The main candidates for the automount are the home and share filesystems — the first one to provide the same users access to any machine in the network, the second one because of its
purpose to be shared among all machines. They are fully determined indirectly through the etcauto_home and etcauto_share files. Please note that any exported filesystem can be
controlled by an automounter; this is simply an administrative decision. Also, the naming of the corresponding indirect automount map is not mandatory; the map itself is specified within the
auto_master configuration file. It is logical for the maps name to match the name of the exported remote filesystem, but it is not necessary, and an arbitrary name for the map could be used instead.
18.3.1.1 An Example
An example of the auto_home and auto_share maps follows. The contents of two configuration files are:
cat etcauto_home
Home directory map for automounter for nis clients
The map reflects site configuration +auto_home
As we can see, the etcauto_home file includes a single line: the NIS map auto_home replaces all individual users entries, and this could be a very long list hundreds, even thousands of users,
which should be defined only at a single host — the NIS master server. A home directory must be defined in the usual NFS way hostname:pathname for each user.
ypcat −k auto_home
rmargoli aegean:files1exporthomermargoli nrosenbl aegean:files1exporthomenrosenbl
lchristi aegean:files1exporthomelchristi fhomolka aegean:files1exporthomefhomolka
dandjeli aegean:files1exporthomedandjeli
... ...
ktung aegean:files1export homektung cteti aegean:files1exporthomecteti
ssze aegean:files1exporthomessze mlee aegean:files1exporthomemlee
bbae aegean:files1exporthomebbae kwu aegean:files1exporthomekwu
cko aegean:files1exporthomecko
Similarly, for the etcauto_share file:
436
Shared directory map for automounter for nis clients
The map reflects a site configuration +auto_share
And the NIS auto_share map:
ypcat −k auto_share
suitespot aegean:files1exportsharesuitespot totalnet hunter:filesexportsharetotalnet
catalog aegean:files1exportsharecatalog sybase peri:filesexportsharesybase
public aegean:files1exportsharepublic
..... .....
openv mekong:filesexportshareopenv batch aegean:files1exportsharebatch
mail admin:varmail http peri:filesexportsharehttp
man aegean:usrman doc aegean:files1exportsharedoc
When any subdirectory in the directory share is referenced, or any of subdirectories or files beneath the corresponding NFS filesystem specified in the automount auto_share map i.e., the
etcauto_share file or the subsequent NIS map is temporarily mounted. This is done automatically and is transparent to users and processes; they do not know anything about the huge job that is
accomplished before getting the required data. The same happens if the directory home is referenced, except that the file etcauto_home and the subsequent NIS map auto_home are used
instead.
The hierarchical structure of the automount configuration data provides a flexible way to join data from different systems into a unified network−based collection of data. In that way, each user can
log in to any system, and access the same data in the same home directory that actually resides on some other system. Simply, users are always at home, regardless of where they started their login
process.
A simple mapping entry takes the form:
key [ −mount−options ] location …
where
key
The full pathname of the directory to mount when used in a direct map, or the simple name of a directory in an indirect map
mount−options A comma−separated list of mount options location
Specifies a filesystem from which the directorysubdirectory may be mounted. In the case of a simple NFS mount, location takes the form:
host:pathname, where: host
The name of the host from which to mount the filesystem if omitted, the pathname refers to the local device
pathname The pathname of the directory to mount We have talked about indirect automount maps. Let us see how the etcauto_direct file looks:
cat etcauto_direct
437
Let us see the NIS auto_direct map:
ypcat −k auto_direct
In this case the auto_direct map is empty. Otherwise, the very same rules are implemented as with the auto_home and auto_share maps, except that the NIS auto_direct map is empty. Please note
that the map exists, but it is empty — there is simply no need for direct mappings at this site.
The entry:
net −host
has a special meaning; −host is a special map used to mount all exported filesystems from any host that the automounter can mount the assumed key is the host name of an NFS server. In other
words, the directory net includes subdirectories named by the host names of NFS servers that have exported their filesystems to this machine. Obviously, subdirectories below are exported directories.
Here is an example:
cd net ls −l
total 10 lrwxrwxrwx 1 root root 26 Jun 8 15:01 admin − tmp_mntnetadmin
lrwxrwxrwx 1 root root 29 Jun 8 15:02 aegean − tmp_mntnetaegean lrwxrwxrwx 1 root root 38 Jun 8 15:02 baltic − tmp_mntnetbaltic
lrwxrwxrwx 1 root root 33 Jun 8 15:02 delft − tmp_mntnetdelft lrwxrwxrwx 1 root root 33 Jun 8 15:01 hunter − tmp_mntnethunter
cd admin ls −l
total 4 drwxrwxr−x 11 root sys 512 Jun 5 13:30 export
dr−xr−xr−x 3 root root 96 Jun 8 15:01 files2 dr−xr−xr−x 3 root root 96 Nov 12 1997 usr
dr−xr−xr−x 2 root root 96 Jun 8 15:01 var
Since we have mentioned most of the advantages of the automounter, it is fair to also mention some of its disadvantages. When the host where the home directories reside is down, users will
still be able to login to other hosts, but they will not be able to reach their home directories and data; this situation takes some time to correct. Also, dont be surprised when you list a directory that is a
mount point for automounter, and you dont see the expected subdirectory; dont forget that the automounter mounts only referenced directories — once you reference a previously unseen
directory for example, cd to the subdirectory and back, it will appear in the directory list, until it is dismounted again.
Today, the automount is widely in use — it improves network performance, makes maintenance easier, and makes the network behave as an equivalent large system. It integrates all of the
advantages of NFS and NIS, bringing them together for users benefits.
438
NFS and NIS are two independent services in the network environment. Their missions are quite different: NFS is the user−oriented service, enabling the use of remote filesystem resources locally,
and NIS helps UNIX administrators accomplish the system administration through the network in a uniform and well−organized way. Obviously, the two services can exist separately.
However, NFS requires, in some ways, that NIS also be implemented. This is not a must, but is highly recommended to keep the user administrative database uniform and consistent on all NFS
clients. What is the reason for this statement?
NFS identifies users by their UID; this is not unusual on UNIX systems, but in this specific case NFS users are coming from different client−hosts. If it happens that two different users at two different
NFS client hosts have equal UIDs this is a very probable situation, NFS recognizes them as the same, single user. It also means that all NFS resources directories, files, etc. would be accessible,
in an unrestricted way, to both users. And this is a problem, a main drawback of NFS, and a security hole that simply eliminates the possible use of NFS in some highly secure network environments.
This situation can easily be prevented by using NIS to administer NFS clients, and by providing conditions for safe NFS implementation, i.e., each user has a single UID networkwide.
439
Chapter 19: UNIX Remote Commands
19.1 UNIX r Commands
This is a topic that illustrates in greater detail why UNIX is so suitable for network implementations. UNIX designers realized long ago the significance of tightening multiple hosts into a unique working
environment, where a whole network of connected hosts appears as an equivalent host. Such an equivalency, based on mutual trusting relationships among all participating hosts, eliminates the
need for individual user authentication and enables easy and powerful local and remote processing.
If you ever had the task of handling a dozen hosts in a network, you would understand this very well. How do you execute the same or a similar program efficiently on a dozen hosts? And just
imagine if you should run them every day, or every hour, or even more frequently. What do you do if it is not a dozen hosts, but a hundred, or maybe five hundred, or a thousand?
It is hard to imagine the efficient maintenance of hosts in a network environment without UNIX remote commands. UNIX remote commands are the vehicles that make each host in the network
accessible in an extremely comfortable and efficient way. We will call them UNIX r commands, according to the implemented prefix r in their names.
What are the UNIX r−commands? Among all available commands, UNIX also provides a set of remote commands:
rlogin
Remote login provides interactive access to remote hosts. A user can reach a remote host through the network, log in, and perform all activities regularly provided by the host.
rcp
Remote copy allows files to be copied from or to remote systems. Its syntax is similar to the regular copy cp command, except that the file path includes the name of a remote
host. It moves the files between hosts on the network using a simple command−line interface.
rsh remsh
Remote shell passes a command to a remote host for execution. Standard output and standard error from the remote execution are returned to the local host.
The third command listed is not a single command at all; here we talk about a UNIX shell that includes all UNIX commands. This is an extremely powerful and versatile way to execute any UNIX
command or set of commands on a remote host, with full control over their execution, just as if everything is happening locally.
Some UNIX flavors, like HP−UX, use remsh for remote shell−ing even the verb remshing is widely implemented, because rsh also in use could be misinterpreted for a restricted shell.
Although both terms are correct, the command name remsh will be used in the text that follows.
The main advantages of using UNIX r−commands is the fact that they are used in very familiar ways, just like any other, local UNIX command is used. However, an efficient remshing is supposed
to bypass the authentication on a remote host, and it could affect some security issues. Bypassing the authentication is always a challenge for potential intruders; this means everything must be set
up very carefully to avoid possible security problems. This is accomplished by establishing a so−called trusted relationship between hosts involved in remote command execution.
Trusted hosts another term used is equivalent hosts establish a special mutual relationship where a certain number of users, known as trusted users receive special treatment. Once
authenticated, trusted users at one host are assumed to be allowed without any additional authentication into another trusted host. Trusted users have direct access to remote hosts and play
440
