Page 281
| WARNING |
NFS's design by nature is, unfortunately, insecure. While there are some steps that provide a moderate level of security to protect you from the common user pretending to be an evil hacker, there is not much more you can do. Any time you share a disk via NFS with another machine, you need to give the users of that machine (especially the root user) a certain amount of trust. If you believe that the person you are sharing the disk with is untrustworthy, you need to explore alternatives to NFS for sharing data and disk space. |
Although the NFS software that comes with Red Hat Linux does come preinstalled, you do need to be aware of what the software is and what each specific program does. This is important when trying to troubleshoot problems and configure NFS-related tools such as the automounter.
There are three programs used to provide NFS server services:
| rpc.portmapper | This program does not directly provide NFS services itself; however, it maps calls made from other machines to the correct NFS daemons. |
| rpc.nfsd | This daemon is what translates the NFS requests into actual requests on the local filesystem. |
| rpc.mountd | This daemon's services requests to mount and unmount filesystems. |
| NOTE |
The rpc.nfsd and rpc.mountd programs need only run on your NFS servers. In fact, you might find it prudent to not have them run at all on your client machines for security concerns and to free up resources that might otherwise be consumed by them. NFS clients do not need any special NFS software to run. They should, however, run the rpc.portmapper program because it provides RPC functionality to programs other than NFS as well. |
By default, these programs are installed and loaded at boot time for you. To check for this, use the rpcinfo command as follows:
rpcinfo -p
Page 282
This will display all the registered RPC programs running on your system. To check which RPC programs are registered on a remote host, use rpcinfo such as
rpcinfo -p hostname
where hostname is the name of the remote host you want to check. The output for a Linux host running NFS appears something like the following:
[root@vestax /root]# rpcinfo -p program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100005 1 udp 821 mountd 100005 1 tcp 823 mountd 100003 2 udp 2049 nfs 100003 2 tcp 2049 nfs
Note the number specified after rpc.nfsd and rpc.mountd. Those numbers tell each program how many instances it should start up at once. Having several instances of each daemon improves network performance up to a point. Having too many started will degrade performance. Unfortunately, there is no magic formula for determining the ideal number to use for your system as it varies depending on your own usage. Typically, most sites start with four and adjust later.
| NOTE |
Currently, multiple NFS servers running in parallel is still experimental. The key limitation is that when running more than one instance of rpc.nfsd, the filesystem can only be shared read-only. This is useful for disks that hold large quantities of read-only information such as Usenet news spools, but not much else. |
You might run across instances when you need to stop NFS and restart it later. You can do this by using the startup scripts that are executed at boot time and shutdown. NFS's scripts are /etc/rc.d/init.d/nfs.
To start the NFS services, run the following as root:
[root@vestax /root]# /etc/rc.d/init.d/nfs start
To stop NFS services, run the following as root:
[root@vestax /root]# /etc/rc.d/init.d/nfs stop
The two key files to NFS are the /etc/exports and /etc/fstab files. The exports file is configured on the server side. This file specifies which directories are to be shared with which clients
Page 283
and each client's access rights. The fstab file is configured on the client side and specifies
which servers to contact for certain directories as well as where to place them in the directory tree.
The /etc/exports file specifies which directories to share with which hosts on the network. This file needs only to be set up on your NFS servers.
The /etc/exports file follows the following format:
/directory/to/export host1(permissions) host2(permissions)
Âhost3(permissions) host4(permissions)
#
# Comments begin with the pound sign and must be at the start of
# the line
#
/another/dir/to/export host2(permissions) host5(permissions)
In this example, /directory/to/export is the directory you want to make available to other machines on the network. You must supply the absolute pathname for this entry. On the same line, the hosts that can access this directory are listed. If the list is longer than the line size permits, you can use the standard continuation character (the backslash, \) to continue onto the next line. Each host is given a set of access permissions. They are as follows:
| rw | Read and write access. |
| ro | Read-only access. |
| no_root_squash | Acknowledge and trust the client's root account. |
If you are familiar with the export file configurations of other flavors of UNIX, you know that this is not similar. Whether one is better than the other is a holy war discussion best left to Usenet newsgroups.
After you have set up your /etc/exports file, run the exportfs command with the -a option—for example,
exportfs -a
This sends the appropriate signals to the rpc.nfsd and rpc.mountd daemons to reread the /etc/exports file and update their internal tables.
| TIP |
It is considered good convention to place all the directories you want to export in the /export hierarchy. This makes their intent clear and self-documenting. If you need the directory to also exist elsewhere in the directory tree, use symbolic links. For example, if your server is exporting its /usr/local hierarchy, you should place the directory in |