Now our attention turns to configuring network servers. As with name service, these servers are not strictly required for the network to operate, but they provide services that are central to the network's purpose.
We begin with NFS, which is the server that provides file sharing on UNIX networks.
The Network File System (NFS) allows directories and files to be shared across a network. It was originally developed by Sun Microsystems, but is now supported by virtually all UNIX implementations and many non-UNIX operating systems. Through NFS, users and programs can access files located on remote systems as if they were local files. In a perfect NFS environment, the user neither knows nor cares where files are actually stored.
There are two sides to NFS - a client side and a server side. The client is the system that uses the remote directories as if they were part of its local filesystem. The server is the system that makes the directories available for use. Attaching a remote directory to the local filesystem (a client function) is called mounting a directory. Offering a directory for remote access (a server function) is called sharing a directory.  Frequently, a system runs both the client and the server NFS software. In this section we'll look at how to configure a system to share and mount directories using NFS.
If you're responsible for an NFS server for a large site, you should take care in planning and implementing the NFS environment. The discussion in this chapter tells how NFS is configured to run on a client and a server, but you may want more details to design an optimal NFS environment. For a comprehensive treatment, see Managing NFS and NIS , by Hal Stern (O'Reilly & Associates).
The Network File System is run by several daemons, some performing client functions and some performing server functions. Before we discuss the NFS configuration, let's look at the function of the daemons that run NFS:
The daemons necessary to run NFS are started from boot scripts. On a Solaris system, two scripts located in the /etc/init.d directory, nfs.client and nfs.server , handle this job. The nfs.client script starts the statd and lockd programs.  NFS server systems run those two daemons, plus the NFS server daemon, nfsd , and the mount server daemon, mountd . On Solaris systems, the nfs.server script starts mountd and 16 copies of nfsd .
Each system has its own technique for starting these daemons. If some of the daemons aren't starting, make sure your startup scripts are correct.
The first step in configuring a server is deciding which filesystems will be shared, and what restrictions will be placed on them. Only filesystems that provide a benefit to the client should be shared. Before you share a filesystem, think about what purpose it will serve. Some common reasons for sharing filesystems are:
Once you've selected the filesystems you'll share, you must configuring them for sharing using the appropriate commands for your system. In the following sections we emphasize the way this is done on Solaris systems. It is very different on Linux systems. Check your system's documentation to find out exactly how it implements NFS file sharing.
A simplified syntax for the share command is:
share -F nfs -o rw=almond:pecan ro /usr/man share -F nfs -o rw=peanut:almond:pecan:walnut /export/home/research
The first share command grants read and write access to almond and peanut and read-only access to all other clients. On the other hand, the second share command grants read/write access to peanut , almond , pecan , and walnut , and no access of any kind to any other client.
The share command does not survive a boot. Put the share commands in the /etc/dfs/dfstab file to make sure that the filesystems continue to be offered to your clients even if the system reboots. Here is a sample dfstab file containing our two share commands:
% cat /etc/dfs/dfstab # place share(1M) commands here for automatic execution # on entering init state 3. # # share [-F fstype] [ -o options] [-d "<text>"] <pathname> [resource] # .e.g, # share -F nfs -o rw=engineering -d "home dirs" /export/home2 share -F nfs -o rw=almond:pecan ro /usr/man share -F nfs -o rw=peanut:almond:pecan:walnut /export/home/research
The share command, the dfstab file, and even the terminology "share" are Solaris-specific. Most UNIX systems say that they are exporting files, instead of sharing files, when they are offering files to NFS clients. Furthermore, they do not use the share command or the dfstab file; instead, they offer filesystems through the /etc/exports file. Linux is an example of such a system.
The /etc/exports file is the NFS server configuration file for Linux systems. It controls which files and directories are shared (exported), which hosts can access them, and what kinds of access are allowed. A sample /etc/exports file might contain these entries:
/usr/man almond(rw) pecan(rw) (ro) /usr/local (ro) /home/research peanut(rw) almond(rw) pecan(rw) walnut(rw)
This sample file says that:
The options used in each of the entries in the /etc/exports file determine what kinds of access are allowed. The information derived from the sample file is based on the options specified on each line in the file. The general format of the entries is as follows:
You need some basic information before you can decide which NFS directories to mount on your system. You need to know which servers are connected to your network, and which directories are available from those servers. A directory cannot be mounted unless it is first exported by a server.
Your network administrator is a good source for this information. The administrator can tell you what systems are providing NFS service, what directories they are exporting, and what these directories contain. If you are the administrator of an NFS server, you should develop this type of information for your users. See Chapter 4, Getting Started .
On Solaris systems you can also obtain information about the shared directories directly from the servers by using the showmount command. The NFS servers are usually the same centrally supported systems that provide other services such as mail and domain name service. Select a likely server and query it with the command showmount -e hostname . In response to this command, the server lists the directories that it exports and the conditions applied to their export.
For example, a showmount -e query to filbert produces the following output:
The export list shows the NFS directories exported by filbert , as well as who is allowed to access those directories. From this list, peanut 's administrator may decide to mount any of the directories offered by filbert . Our imaginary administrator decides to:
The amount to which you use NFS is a personal choice. Some people prefer the greater personal control you get from keeping files locally, while others prefer the convenience offered by NFS. Your site may have guidelines for how NFS should be used, which directories should be mounted, and which files should be centrally maintained. Check with your network administrator if you're unsure about how NFS is used at your site.
A client must mount a shared directory before using it. "Mounting" the directory attaches it to the client's filesystem hierarchy. Only directories offered by the servers can be mounted, but any part of the offered directory, such as a subdirectory or a file, can be mounted.
NFS directories are mounted using the mount command. The general structure of the mount command is:
For example, assume that filbert.nuts.com is an NFS server and that it shares the files shown in the section above. Further assume that the administrator of peanut wants to access the /home/research directory. The administrator simply creates a local /home/research directory, and mounts the remote /home/research directory offered by filbert on this newly created mount point.
Once a remote directory is mounted, it stays attached to the local file system until it is explicitly dismounted or the local system reboots. To dismount a directory, use the umount command. On the umount command line, specify either the local or remote name of the directory that is to be dismounted. For example, the administrator of peanut can dismount the remote filbert:/home/research filesystem from the local /home/research mount point, with either:
UNIX systems use the information provided in a special table to remount all types of filesystems, including NFS directories, after a system reboot. The table is a critical part of providing users consistent access to software and files, so care should be taken whenever it is modified. Two different files with two different formats are used for this purpose by the different flavors of UNIX. Linux and BSD systems use the /etc/fstab file and Solaris, our System V example, uses the /etc/vfstab file.
The format of the NFS entries in the Solaris vfstab file is:
The various fields in the entry must appear in the order shown above
and they must be separated by whitespace. The items in bold (both
dashes and the words
filbert:/home/research - /home/research nfs - yes rw,soft
This entry mounts the NFS filesystem filbert:/home/research on the local mount point /home/research . The filesystem is mounted with the rw and soft options set. The mount options available on Solaris systems are:
On the Solaris system, the NFS filesystems defined in the vfstab file are mounted by a mountall command located in a startup file. On the Linux system, the startup file contains a mount command with the -a flag set, which causes Linux to mount all filesystems listed in fstab . The format of NFS entries in the /etc/fstab file is:
The fields must appear in the order shown and must be separated by
whitespace. The keyword
is required for NFS filesystems.
A grep of fstab shows sample NFS entries. 
The grep shows that there are three NFS filesystems contained in the /etc/fstab file. The mount -a command in the boot script remounts these three directories every time the system boots.
The vfstab and fstab files are the most common methods used for mounting filesystems at boot time. There is another technique that automatically mounts NFS filesystems, but only when they are actually needed. It is called automounter .
On Solaris systems the automounter daemon ( automountd ) and the automount command are started by the /etc/init.d/autofs script. The script is run with the start option to start automounter, i.e., autofs start . It is run with the stop option to shut down automounter. automount and automountd are two distinct, separate programs. automountd runs as a daemon and dynamically mounts filesystems when they are needed. automount processes the auto_master file to determine the filesystems that can be dynamically mounted.
mount-point map-name options
The Solaris system comes with a default
preconfigured. Customize the file for your configuration. Comment out
# Master map for automounter # #+auto_master #/xfn -xfn /net -hosts -nosuid /home auto_home /- auto_direct
All lines that begin with a sharp sign (#) are comments, including the
The second entry automatically mounts the home directories listed in the
map under the
directory. A default
file is provided with the Solaris system. Comment
# Home directory map for automounter # #+auto_home craig almond:/export/home/craig * pecan:/export/home/&
The first entry mounts the
on the local mount point
map is an indirect map, so the mount point specified in the
That's it for the auto_home map. Refer back to the auto_master map. The third and final entry in the /etc/auto_master file is:
We added this entry for our direct map. The special mount point
# Direct map for automounter # /home/research -rw filbert:/home/research /usr/man -ro,soft pecan,almond,filbert:/usr/share/man
The format of entries in a direct map file is:
mount-point options remote filesystem
Our sample file contains two typical entries. The first entry mounts the remote filesystem /home/research offered by the server filbert on the local mount point /home/research . It is mounted read-write. The second entry mounts the man pages read-only with a "soft" timeout.  Note that three servers are specified for the man pages in a comma-separated list. If a server is unavailable or fails to respond within the soft timeout period, the client asks the next server in the list. This is one of the nice features of automounter.
Automounter has four key features: the -hosts map, wildcarding, automounting, and multiple servers. The -hosts map makes every exported filesystem from every server listed in the /etc/hosts file available to the local user. The wildcard characters make it very easy to mount every directory from a remote server to a like-named directory on the local system. Automounting goes hand-in-glove with these two features because only the filesystems that are actually used are mounted. While -hosts and wildcards make a very large number of filesystems available to the local host, automounting limits the filesystems that are actually mounted to those that are needed. The last feature, multiple servers, improves the reliability of NFS by removing the dependence on a single server.
The PC NFS Authentication and Print Server ( pcnfsd ) is needed to support non-UNIX clients on an NFS network. The print services of this daemon are covered in the next section. The authentication services are the services needed by NFS.
The reason NFS needs an authentication server for some clients springs from the difference between trusted host security and password authenticated security. Trusted host security is discussed in Chapter 12, Network Security . Essentially, it works this way: we trust that a remote host has already authenticated its users, and we grant those users equivalent access to our local host. This is more or less how NFS treats its clients. The Solaris share command grants NFS access to hosts. A user is allowed to access files through NFS using standard UNIX user , group , and world file permissions based on the userid (UID) and groupid (GID) provided by the trusted host. Remember, unless a share command option is used to restrict access, all hosts are trusted to access the shared filesystem.
The trusted host model does not work for non-UNIX clients for a couple of reasons. First, some systems do not perform local user authentication; for example, anyone who sits at the keyboard of a DOS PC has complete access to the system. Second, some systems do not employ user or group IDs and do not have any values that can be mapped to the UNIX user or group file permissions. At best, an unauthenticated user can be granted world permissions.  We need a server that authenticates usernames and passwords and assigns UIDs and GIDs to the authenticated users. That's what the PC NFS authentication server does.
The authentication server can run on any system on the network. It is not necessary to run it on the NFS server, but that is the most common configuration. The PC NFS authentication server is not included in the software of all UNIX systems. It is included with our Linux system but not with our Solaris system. If it doesn't come with your UNIX system, don't worry; the source code for pcnfsd is available from many anonymous FTP servers on the Internet. Download the source code. Compile the software with make .  If pcnfsd compiles without errors, copy the daemon into a system directory such as /usr/etc . Then add code to start pcnfsd from a boot script. On a Slackware Linux system, simply uncomment the lines in the /etc/rc.d/rc.inet2 file that start rpc.nfsd .
Normally starting a daemon from inetd is an alternative to starting it from a boot script. However, Sun cautions against starting pcnfsd from inetd because the slow startup of this daemon can cause time-out errors.
Once the pcnfsd daemon is installed and running, the server authenticates usernames and passwords for its clients. Here's how. When the user asks to mount a remote filesystem, the client software prompts him for a username and password. It sends them to the authentication server. The server validates them against its /etc/passwd file. A user that can successfully login to the server is consider to be a valid NFS user. The server sends the client the UID and GID that are assigned to the user in the passwd file. The client uses them for NFS access.
The authentication server must have an entry in the /etc/passwd file for every user who needs NFS access. It is common for a large UNIX server, such as the mail server that has an account for every mail user, to be used as the authentication server.
NFS-based print services are easy to understand and simple to configure. The NFS server exports a printer spool directory to its clients, and the clients copy print files into that directory. pcnfsd sends files deposited in the directory to printers accessible to the server. Any printer defined by the server can be used.
To add NFS print service to an NFS server, first install pcnfsd . Next, make a print spool directory on the server for the print clients. Add the spool directory to the shared filesystems in the /etc/dfs/dfstab file or /etc/exports file, as appropriate for your system.
Finally tell pcnfsd what directory to use for spooling print jobs. Use the spool command in the /etc/pcnfsd.conf configuration file to define the directory name on most systems. On others, for example our Linux system, define the directory on the pcnfsd command line. See the pcnfsd manpage for details.
Finished! Running pcnfsd and exporting the printer spool directory are all that is required to configure an NFS print server, assuming that the printers are already properly configured. Check the printers by logging directly into the print server and issuing an lpr command for each printer you wish to test. See the following section on lpr and lpd if a printer is not properly configured.