Network File System (NFS) has a reputation for being difficult to set up and install. The truth is that NFS is quite easy to implement on Linux systems, and if your machine is one of a few Linux systems on a local area network (LAN), NFS can give you enormous flexibility.
This chapter explains the benefits of NFS, and how you can set up your system to act as both a client and server for other machines on your LAN. If you are running as a stand-alone Linux machine, NFS will be of no value (other than academic) to you, but if you are part of a LAN (whether composed of PC, Mac, UNIX, or Linux machines doesn't matter), you should at least find out what NFS has to offer.
The second part of this chapter looks at the Network Information Service (NIS), an early version of which was previously called Yellow Pages, and how it works over a network. Although you probably will not need NIS unless you are part of a very large network, you can see how the system works. The chapter also looks at some system administration tools for managing NFS (Network File System), NIS (Network Information Service), and RPC (Remote Procedure Call).
NFS was developed to help solve a common problem on UNIX-based networks. With the trend to distributed processing and client-server networks, many users end up with small, powerful machines that communicate with a server. The applications users need are often located in places other than on their desktop, so some method of accessing remote files is needed. Although utilities such as Telnet enable users to use remote machines, they don't take advantage of the desktop machine's CPU, transferring the load to the remote. Another important aspect of the shift to distributed computing was peripheral sharing and the need to provide access for many users to some devices. To help integrate workstations into local area networks, as well as to simplify remote file access and peripheral sharing, Sun Microsystems introduced the Network File System (NFS). NFS uses a system called RPC (Remote Procedure Calls).
Sun designed NFS to enable machines from different manufacturers to work together independent of their operating systems. By publishing the NFS specifications, Sun allowed other vendors to modify their systems to work with NFS, resulting in a completely homogeneous network. NFS is now a de facto standard among UNIX environments, with strong support in other operating systems.
NFS actually refers to two different things: a product and a protocol. The NFS product is a set of protocols for different tasks. The NFS protocol is the single protocol of the NFS product that deals with file access. NFS is now intimately tied with UNIX and TCP/IP. For other operating systems (such as Novell NetWare), NFS is an extension that is added by the system administrator. Linux (and most UNIX versions) uses the process nfsd to manage NFS access.
NFS allows an application to read and write files that reside on NFS servers. Access to the NFS server is transparent to the application and the user. Transparent access to another machine's file structure is achieved by logically mounting the NFS server to the client. You can mount the NFS server's filesystem in whole or in part. The mount is handled in the same way as any other filesystem mount (see Chapter 18, "Filesystems and Disks," for information on the mount command), although a special keyword is added to the command to show that NFS is being used. For example, to mount the directory /usr/database/data on the remote machine wizard onto your directory /usr/data, you would issue the following command:
mount -t nfs wizard:/usr/database/data /usr/data
When the command is issued, the local machine checks with the remote machine for permission to access the directory. If all is well, the remote machine sends a file handle that is used to redirect all requests for that directory from the local machine. Whenever the user of an NFS-mounted directory issues a request, a daemon called nfsd handles the transfers.
NFS uses the term client to represent any machine that requests a file from another machine, which is the server. Multitasking operating systems can act as both client and server simultaneously. Usually, restrictions are imposed on the files or portions of a filesystem that can be shared, both for security and speed considerations.
A typical NFS installation uses personal computers or diskless workstations as clients accessing a powerful server system. (Since personal computer operating systems such as MS-DOS are single-tasking, PCs usually act as clients only, unless they run a multitasking operating system such as Windows NT, Windows 95, or OS/2.) For Linux-based networks, you can have several Linux systems sharing their drives with other machines on the network. It is possible to have an entire network of multitasking computers sharing their drives with each other, although in practice this works well only with small networks.
Due to the requirement transferring files quickly with NFS, network speed becomes important. When it was designed, the original goal for an NFS-mounted filesystem was to provide performance equivalent to 80 percent of the performance expected from a locally mounted hard disk. This goal puts the performance emphasis on both the NFS disk drive and the network. Typically, NFS disk drives on a dedicated server are amongst the fastest available in order to reduce bottlenecks at the drive end. In practice for most networks, the NFS systems use standard equipment, which isn't a problem for sharing a few directories among a small network.
Typically, for a small Linux network, NFS offers a few useful benefits. Primarily, it allows data and large applications to be kept on a single drive on the network that all other machines have access to (hence saving the disk space independent copies would require). For a system administrator, NFS offers the option of keeping applications in one location (or even placing all user directories on one machine) for ease of updating, backups, and management.
The Linux version of FTP differs slightly from the standard UNIX versions, in that many of the features of the NFS system are embedded in the code for the Virtual File System (VFS) kernel layer. Early versions of Linux have a problem with Linux FTP because of the maximum size of TCP datagrams, which must be reduced in size to function properly. This had the effect of slowing performance dramatically.
Because NFS is UNIX-based, the security offered is rudimentary. For this reason, Sun has introduced Secure NFS, which implements an encrypted messaging protocol for added protection against unauthorized access to NFS-mounted file systems. This version is not available in a Linux implementation yet.
The first step to installing NFS on your Linux system is to ensure that the NFS support is compiled into the kernel. Most later Linux versions have this by default, but if you are running an early version you should verify the NFS code. Versions of Linux after 1.1 can confirm support for NFS by examining the /proc/filesystems file. An entry in this file should show nfs with the command nodev. An extract from the /proc/filesystems file looks like this:
minix ext2 umsdos msods nodev proc nodev nfs iso9660
The second line from the bottom shows that the NFS code is included in the kernel. If the NFS code is not included, you will have to rebuild the kernel including the NFS drivers.
Versions of Linux before 1.1 are more difficult to easily check for NFS code. The best way to perform the check is to try to mount an NFS directory. If it fails, it is likely the NFS code is missing (assuming the mount commands are correct, of course). As a fast check, you can mount a local directory onto your own machine (which is perfectly legal with all versions of NFS, although it can be confusing at times). To perform this check, create a new subdirectory and issue the mount command with an existing directory. For example, these commands try to mount /usr on the empty directory /tmp/nfstest:
mkdir /tmp/nfstest mount localhost:/usr /tmp/nfstest
If the mount command is successful (you can go into the /tmp/nfstest directory and examine the same file listing as in /usr), your kernel has the NFS code embedded in it. If you get an error message similar to this:
fs type nfs not supported
then the NFS code is missing and you should rebuild a new kernel with the NFS drivers added.
When you perform this NFS code check you may see many error messages. The only message that matters is nfs not supported. The rest of the messages have to do with the lack of NFS configuration.
The NFS daemons need to be set up on your system. If you are going to act as an NFS server (allow your directories to be mounted by others), you must install both the nfsd and mountd daemons. These daemons start when your machine boots, reading the rc files. Both daemons need the program rpc.portmap to function because they both register themselves with the portmapper utility.
The startup commands for the daemons usually are placed in the /etc/rc.d/rc.inet2 file (or wherever you have installed the rc files). Most newer versions of Linux will have the proper section already in the /etc/rc.d/rc.inet2 file. For example, the section dealing with NFS will look much like this:
# # Start the various SUN RPC servers.
if [ -f ${NET}/rpc.portmap ]; then
# Start the NFS server daemons.
if [ -f ${NET}/rpc.mountd ]; then
echo -n " mountd"
${NET}/rpc.mountd
fi
if [ -f ${NET}/rpc.nfsd ]; then
echo -n " nfsd"
${NET}/rpc.nfsd
fi
# # Fire up the PC-NFS daemon(s).
# if [ -f ${NET}/rpc.pcnfsd ]; then
# echo -n " pcnfsd"
# ${NET}/rpc.pcnfsd ${LPSPOOL}
# fi
# if [ -f ${NET}/rpc.bwnfsd ]; then
# echo -n " bwnfsd"
# ${NET}/rpc.bwnfsd ${LPSPOOL}
# fi
fi # Done starting various SUN RPC servers.
If your inet2 file doesn't have any lines similar to these, find a location below the rpc.portmapper startup command. The portmapper startup section will look similar to this:
# Start the SUN RPC Portmapper.
if [ -f ${NET}/rpc.portmap ]; then
echo -n " portmap"
${NET}/rpc.portmap
fi
Below these lines, enter the following commands to start the rpcd and mountd daemons:
if [ -x /usr/sbin/rpc.mountd ]; then echo -n " mountd" /usr/sbin/rpc.mountd fi if [ -x /usr/sbin/rpc.nfsd ]; then echo -n " nfsd" /usr/sbin/rpc.nfsd fi
If the rpc.nfsd and rpc.mountd daemons are not in /usr/sbin, enter the proper pathnames. These lines don't make use of a prior defined path. The paths to the deamons should be explicitly specified.
The next step in configuring your system for NFS server duty is to set up a file listing all the clients who can attach to your system and mount directories. This is done through the /etc/exports file. The /etc/exports file is read every time the mountd daemon receives a request to mount a directory. The file contains a list of directories that you want to allow to be mounted, and the remote systems that can mount them followed by a permission indication.
The best way to explain the /etc/exports file is to examine a sample. The following file shows several systems allowed to mount directories on the local machine:
# /etc/exports for merlin /usr/database/data chatton(rw) big_roy (rw) wizard (rw) /usr/book chatton(rw) wizard (ro) /usr/bin/bigapp big_roy(rw) wizard (ro) /usr/ftp (ro)
This file shows that the three machines chatton, big_roy, and wizard can all mount the local directory /usr/database/data in read-write mode (meaning they can modify the contents). The directory /usr/book can be mounted read-write by remote machine chatton, and read-only (no writing allowed) by wizard. The /usr/ftp directory can be mounted read-only by any machine that wants to.
When you are specifying machine names in the /etc/exports file, you can use explicit names, or a combination of asterisk and question mark wildcards to match multiple machines. For example, the entry
/usr/tim/book big_*(rw)
allows any machine starting with big_ to mount the directory as read-write. When no hostname is provided (as with the /usr/ftp directory in the previous example), any machine can mount the directory.
The /etc/exports file allows a long list of possible permissions for a remote machine to mount a local directory. Although most systems use only rw and ro (for read-write and read-only respectively), you may need more permissions occasionally. The following are valid permissions:
insecure Allows non-authenticated access for the specified machine (overrides authentication requirements)
kerberos Forces Kerberos authentication from the remote (not implemented for Linux NFS)
link_absolute Leaves symbolic links as they are
link_relative Converts absolute symbolic links to relative links by prepending ../ as necessary
root_squash Denies root users on remote machines root access on local machine
secure-rpc Forces RPC authentication from the remote (on by default, although not implemented in most Linux NFS versions)
How does NFS handle file and user permissions across mountings? When the NFS daemon transfers files or requests, it passes the user and group ID numbers. If the client and the server have the same user and group ID numbers (called sharing the same uid/gid space), there is no problem with permissions. When the UID and GID numbers do not match, the daemon can handle translations between them.
Once NFS is configured, you can use it to mount remote directories on your local filesystem. This is done with the mount command. The general format of the mount command when dealing with NFS is
mount -t nfs remote_dir local_dir [-o options]
where remote_dir is the name of the remote machine and directory to be NFS mounted, local_dir is where you want to mount the remote directory, and options can be any of the permissible flags used by NFS. The remote_dir is always specified by the format
remote_name:remote_dir
such as wizard:/usr/lib. Many administrators leave off the -t nfs component of the mount command since this format is unique to NFS. Others feel it is good practice to leave the -t option in as it is a constant reminder that the remote is NFS mounted.
Although many options are possible for the mount command in NFS mode, only a few are ever used in real situations. You can select valid options from the following list:
| hard | This option explicitly tags the directory as hard-mounted. This is a default action. |
| intr | This option allows interrupts to the NFS call. |
| rsize | This option specifies the datagram size used for read requests (default is 1024 bytes). |
| soft | This option soft-mounts the directory (instead of hard mounting). |
| timeo | This option specifies the timeout in tenths of a second for completion of an NFS request (default is 7/10ths). |
| wsize | This option specifies the datagram size used for write requests (default is 1024 bytes). |
The rsize, timeo, and wsize options are followed by an equal sign and the value they are to be assigned. The rsize and wsize options are used primarily to switch the remote machine to another datagram size (in case it uses a larger size than Linux can handle). All NFS options must follow the -o switch on the command line, if the options are set there. For example, to set the timeout to 2 seconds on the remote mount of a directory and allow interrupts, you could issue the command:
mount -t nfs wizard:/usr/data /usr/data -o timeo=20,intr
Alternatively, if you don't want to specify the options on the command line for frequently mounted volumes, you can use the /etc/fstab file to provide them. The same command line as above can be placed in the /etc/fstab file like this:
wizard:/usr/data /usr/data nfs timeo=20,intr
When you use the /etc/fstab file to specify options and mount points, you can mount the remote volume much more easily by issuing the command:
mount wizard:/usr/data
The mount command examines the /etc/fstab file for the mount point and options to use, as well as recognizes the command as an NFS mount. For remote directories you will need often, this command is much easier than typing the entire command line every time.
Two of the NFS mount options deal with hard and soft mounting. The default with NFS is to hard mount a directory. What this means is that if NFS is unable to mount a requested volume, it times out, generates an error message, and tries again with double the timeout value. This goes on forever until the remote directory is mounted (generating error messages each time a timeout occurs). Any remote directory that is repeatedly tried until successfully mounted is called a hard mount. A soft mount is one that acts the same way but generates error messages only after a major timeout, which is every 60 seconds. The error messages are not displayed, since they are in the I/O queue, but you can usually gain control of the system more easily with a soft mount after a major timeout.
NFS (and RPC, which NFS depends on) has two primary administration tools available for providing status updates and indications of trouble within the system. Running any single tool is usually not sufficient to isolate a problem. It often happens that one tool reports a problem with a port, but, upon closer examination, you find out that the port is functioning and the process at the other end has died. Therefore, these tools are designed to be used as a complement to each other until an accurate diagnosis can be produced.
The rpcinfo program monitors the port mapper of the machine on which it is running and, through the network, the port mappers of servers. Because the port mapper is the program that controls access to RPCs, this type of information is important in tracking problems. The rpcinfo program can display the contents of the mapping tables, showing the port and program numbers for each connection, and is able to activate remote servers for testing a connection.
Typically, rpcinfo is called with the -p option to show the list of RPC programs that are currently tracked by the port mapper. An optional machine name can be added to display only connections with one machine. A typical output from the rpcinfo program is shown below:
$ rpcinfo -p program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100008 1 udp 1026 walld 150001 1 udp 1027 pcnfsd 150001 2 udp 1027 pcnfsd 100002 1 udp 1028 rusersd 100002 2 udp 1028 rusersd 100024 1 udp 1029 status 100024 1 tcp 1024 status 100020 1 udp 1034 llockmgr 100020 1 tcp 1025 llockmgr 100021 2 tcp 1026 nlockmgr 100021 1 tcp 1027 nlockmgr 100021 1 udp 1038 nlockmgr 100021 3 tcp 1028 nlockmgr 100021 3 udp 1039 nlockmgr
In case of a problem contacting the port mapper, rpcinfo returns an error message. In such a case, the port mapper is not functioning correctly and there may be no contact with other machines. A check using ping will verify this. An example of this kind of fatal error message is:
$ rpcinfo -p rpcinfo: can't contact port mapper: RFC: Remote system errer -125
Specific connections can be tested with rpcinfo by using the machine and process name, as the following example shows:
$ rpcinfo -u merlin walld program 100008 version 1 is ready and waiting
Note that the -u option is used for UDP connections, while -t must be used with TCP connections. In this example, the client rpcinfo sent a request to the program specified and waited for a reply. A successful reply results in the message shown above. If a reply is not received before a timer expires, an error message is displayed.
In the sample output above, there is a process called pcnfsd, which is an RPC server developed for use with DOS-based machines. It handles access rights and spooling services for the DOS side, while simplifying the DOS machine's access to NFS services.
The nfsstat program, as its name suggests, provides statistics about the number and type of RPC requests that are made. Although this command is usually called without an option, several options exist (depending on the implementation and version) to show specific statistics or sample only certain parts of the connection. The nfsstat program is not part of most Linux distributions, but you can find it on some Linux FTP and BBS sites and as part of some system administration utility packages. The output from nfsstat is shown below for a typical small network:
Server rpc: calls badcalls nullrecv badlen xdrcall 10465 0 0 0 0 Server nfs: calls badcalls 10432 0 null getattr setattr root lookup readlink read 1 0% 24 0% 1 0% 0 0% 10123 0% 0 0% 5 0% wrcache write create remove rename link symlink 0 0% 2 0% 0 0% 1 0% 0 0% 1 0% 0 0% Client rpc: calls badcalls retrans badxid timeout wait newcred 8273 2 0 0 0 0 0 Client nfs: calls badcalls 8263 0 null getattr setattr root lookup readlink read 1 0% 24 0% 1 0% 0 0% 10123 0% 0 0% 5 0% wrcache write create remove rename link symlink 0 0% 2 0% 0 0% 1 0% 0 0% 1 0% 0 0%
The output from nfsstat is useful for diagnosing connection problems. The number shown as badcalls shows the number of defective RPC messages processed by the system. The numbers for nullrecv and badlen show the number of empty or incomplete messages. The number for xdrcall shows the number of errors in understanding messages.
For the client side, badxid shows the number of received messages that did not match with a sent request (based on the identification numbers). The timeout and retrans numbers show the number of times a message had to be resent. If these numbers are high it usually means the connection is too slow or there is a fault with UDP. The wait number shows the number of times a process had to be delayed due to a lack of available ports.
These types of statistics are useful for configuring RPC properly. System administrators can adjust (tweak) values for the NFS system and monitor their effect on performance over time.
The Yellow Pages (YP) protocol is an RPC application service (like NFS) that provides a directory service. Due to copyright requirements, Yellow Pages was renamed to Network Information Service (NIS), although both terms are in common use and mean much the same thing. YP was developed for several reasons, but the one that affects users the most is access permissions.
If you are a user on a large network and you connect to other machines (through Telnet or FTP, for example), you must maintain accounts on each machine you connect to. You therefore would need user accounts on every machine you could conceivably want to access. Maintaining the passwords on a large number of machines is awkward, because you must log in to each one to perform password changes. Yellow Pages was developed to allow one central password file to be shared over the network.
NIS is a distributed access system in that each machine on the network that uses NIS accesses a central server, called the NIS master or ypmaster, for access permission. On larger networks, a number of other machines can be designated as slaves or ypslaves, maintaining up-to-date access information. In case of a failure of the master server, a slave takes up the validation functions.
Two versions of YP or NIS are in general use. The first release (Version 1) had serious problems under certain circumstances, so Version 2 was quickly released. However, some systems use the older version.
The YP or NIS protocol (both names are valid, although NIS should be used if you have a choice) has a set of procedures that allow a search for master servers, access to the user files, and system management functions. Another procedure is used to transfer copies of master access files. With NIS, a number of machines are grouped together into one NIS subnetwork called a "domain" (not to be confused with the Internet domain). Each domain has master and slave machines of their own.
NIS keeps access information in a set of "maps," each map corresponding to a particular area or domain of a network. This allows several groups to use the same NIS master but have different access permissions. The NIS maps do not have to correspond to DNS domains, which allows more versatility in configuration. Maps consist of a set of records in ASCII format, each with an index for fast lookup (the index is usually the user name). The records have the same structure as a normal /etc/passwd file), for compatibility and simplicity.
The use of NIS does not negate the need for a complete set of access files on each machine, since NIS or YP is loaded after the machine has been booted. The stand-alone files should have access for a system administrator at least, although it is good practice to also include the most frequent users in case of a network crash preventing access to the NIS directories.
NIS is not restricted to just users. Any file can be set up to use NIS, such as the list of machines on a network (/etc/hosts file). Thus, only one change needs to be made to these files on any network. A set of aliases can also be managed by NIS or YP.
Several YP/NIS-specific commands are involved with the protocol, although most system administrators set up aliases to minimize the impact on users. For most users, only one command is necessary on a regular basis: yppasswd to change a password. This is usually aliased to passwd, the normal password change command.
Some implementations of NIS for Linux are better than others. A new release is appearing, called NYS, that offers the most flexibility. NYS (or an earlier version of one of the Linux NIS versions) is included with most CD-ROM distributions of Linux.
NIS has two components: the server and the client. If an NIS server is already on your network, you need only to install the client portions. However, to set up a Linux server system, you need both.
You can choose between two NIS server products currently in general distribution for Linux: ypserv and yps. The choice of which server to use is not important, since both provide complete services. If anything, though, the ypserv system has a slightly better security system than yps. You can obtain the NIS software from Linux FTP and BBS sites.
To install either server program, copy it to /usr/sbin (or some other commonly accessed binary file location). Next, create a directory specifically to hold the map files for your domain (remember, that's an NIS domain, not an Internet domain). Usually, the map files go in a directory such as /var/yp/tpci (the last component of the pathname is the name of your domain).
Your NIS server can support several map files. In general, the files are mirrors of standard Linux files, but named to reflect whether they are accessed by name or by some other criteria (such as IP address or user name). For example, there are two copies of the /etc/passwd file maintained by NIS: passwd.byname and passwd.byuid. The following files are handled by NIS and their corresponding maps:
| /etc/group | group.byname, group.bygid |
| /etc/hosts | hosts.byname, hosts.byaddr |
| /etc/networks | networks.byname, networks.byaddr |
| /etc/passwd | passwd.byname, passwd.byuid |
| /etc/protocols | protocols.byname, protocols.bynumber |
| /etc/rpc | rpc.byname, rpc.bynumber |
| /etc/services | service.byname, services.bynumber |
All these map files are stored in a format called DBM (a simple database program). Linux systems often include a GNU version of DBM called gdbm.
If you are using ypserv, use the ypMakefile utility to build the database files for NIS. Copy the file to the directory containing the map files, rename it to Makefile, and edit it to show the maps you want on your domain. This is handled by one of the first few lines, which looks like this:
all: hosts networks protocols rpc services passwd group
Remove the entries you don't want map files for. If you choose to use the yps server, you have to use the makedbm program to build the indexes from the map files.
To set up the client software on your Linux system (allowing it to connect through a ypmaster on another server), you have to instruct your kernel to use the NIS system. Begin by setting up the name of the ypmaster in the /etc/yp.conf file. This file will have a line that looks like this:
ypserver wizard.tpci.com
This line tells the local machine where to reach the ypserver. (Some versions of Linux use the word server interchangeably with ypserver in the yp.conf file.) Some older Linux systems use a two-line /etc/yp.conf file that lists the domain name and the server on separate lines, like this:
domainname tpci.com server wizard
Set the yp.conf file to readable by user, group, and other. Then test the NIS installation by using the ypcat command:
ypcat passwd.byname
This command should list the master server's passwd.byname map. If you get error messages, it is probably because the local machine has not contacted the remote server properly. If you see the message:
Can't bind to server which serves domain
you either have a faulty server or the wrong name in the /etc/yp.conf file. To check the server, use the ping command to verify that the network connection is intact.
Once you are sure the NIS connection is functioning properly, you can decide which files you want to retrieve from the ypmaster and which are to be kept local. In most cases, you want to get the passwd and group files from the server, but the rest of the files can be kept locally. The order in which the local and NIS server machines are checked for each type of map file is controlled by the file /etc/nsswitch.conf. This file looks like this:
hosts: nis files networks: nis files services: files rpc: files protocols: files
Each line starts with the name of a file, followed by keywords that control where the Linux system looks for the file. The following are valid values in the list (which are read and processed in order):
| dbm | Use a file in the DBM files under /var/dbm |
| dns | Use the domain name server |
| files | Use local files |
| nis | Use NIS server |
Many more options are available with some feature-laden versions of NIS, but these are the primary choices (and should be sufficient for most Linux systems).
As you have seen, NFS is quite easy to implement on a local area network. It is especially handy for sharing files between machines if you have two or more networked together. In most cases, there is no reason not to use NFS with a LAN, especially since the code is linked into the server anyway. NFS does provide a flexible way of transferring files across operating systems, too, if you can find a TCP/IP NFS implementation for the other operating systems (such as DOS or Windows).
NIS is often useful on large networks, but is seldom necessary for small Linux-based systems, except when you move around your LAN a lot. However, NIS is quite easy to install and use, so it remains an option for those with larger networks.
