Introduction

Figure 22-1 shows the flow of data from a client to a server in a typical NFS client/server setup. An NFS directory hierarchy appears to users and application programs as just another directory hierarchy. By looking at it, you cannot tell that a given directory holds a remotely mounted NFS directory hierarchy and not a local ext3 filesystem. The NFS server translates commands from the client into operations on the server's filesystem.

Figure 22-1. Flow of data in a typical NFS client/server setup

Diskless systems

In many computer facilities, user files are stored on a central fileserver equipped with many large-capacity disk drives and devices that quickly and easily make backup copies of the data. A diskless system boots from a fileserver (netboots, discussed next), a CD, or a floppy diskette and loads system software from a fileserver. The Linux Terminal Server Project (LTSP.org) Web site says it all: "Linux makes a great platform for deploying diskless workstations that boot from a network server. The LTSP is all about running thin client computers in a Linux environment." Because a diskless workstation does not require a lot of computing power, you can give older, retired computers a second life by using them as diskless systems.

Netboot/PXE

You can netboot (page 1044) systems that are appropriately set up. Red Hat Linux includes the PXE (Preboot Execution Environment) server package for netbooting Intel systems. Older systems sometimes use tftp (Trivial File Transfer Protocol) for netbooting. Non-Intel architectures have historically included netboot capabilities, which Red Hat Linux also supports. You can build the Linux kernel so that it mounts root (/) using NFS. Given the many ways to set up a system, the one you choose depends on what you want to do. See the Remote-Boot mini-HOWTO for more information.

Dataless systems

Another type of Linux system is a dataless system, in which the client has a disk but stores no user data (only Linux and the applications are kept on the disk). Setting up this type of system is a matter of choosing which directory hierarchies are mounted remotely.

df: shows where directory hierarchies are mounted

The df utility displays a list of the directory hierarchies available on the system, along with the amount of disk space, free and used, on each. The h (human) option makes the output more intelligible. Directory hierarchy names that are prepended with hostname: are available through NFS.

[bravo]$ cd;pwd /speedy.home/jenny [bravo]$ df -h Filesystem       Size Used Avail Use% Mounted on /dev/hda1        981M 287M  645M  31% / /dev/hda6         20G 2.7G   16G  15% /usr /dev/hda7        9.7G 384M  8.8G   5% /home grape:/gc1       985M  92M  844M  10% /grape.gc1 grape:/gc5       3.9G 3.0G  738M  81% /grape.gc5 speedy:/home     3.9G 2.4G  1.4G  64% /speedy.home

In the preceding example, Jenny's home directory, /home/jenny, is on the remote system speedy. Using NFS, the /home filesystem on speedy is mounted on bravo; to make it easy to recognize, it is mounted as /speedy.home. The /gc1 and /gc5 filesystems on grape are mounted on bravo as /grape.gc1 and /grape.gc5, respectively.

You can use the T option to df to add a Type column to the display. The following command uses t nfs to display NFS filesystems only:

[grape]$ df -ht nfs Filesystem       Size Used Avail Use% Mounted on grape:/gc1       985M  92M  844M  10% /grape.gc1 grape:/gc5       3.9G 3.0G  738M  81% /grape.gc5 speedy:/home     3.9G 2.4G  1.4G  64% /speedy.home

Errors

Sometimes you may lose access to remote files. For example, a network problem or a remote system crash may make these files temporarily unavailable. When you try to access a remote file in these circumstances, you get an error message, such as NFS server speedy not responding. When the local system can contact the remote server again, you see another message, such as NFS server speedy OK. Setting up a stable network and server (or not using NFS) is the best defense against these kinds of problems.

Security

NFS is based on the trusted-host paradigm (page 362) and therefore has all the security shortcomings that plague other services based on this paradigm. In addition, NFS is not encrypted. Because of these issues, you should implement NFS on a single LAN segment only, where you can be (reasonably) sure that systems on a LAN segment are what they claim to be. Make sure a firewall blocks NFS traffic from outside the LAN and never use NFS over the Internet.

To improve security, make sure UIDs and GIDs are the same on the server and clients (page 687).