Managing NFS and NIS, 2nd Edition - Mike Eisler [57]
There are two aspects to system administration using NFS: choosing a filesystem naming and mounting scheme, and then configuring the servers and clients to adhere to this scheme. The goal of any naming scheme should be to use network transparency wisely. Being able to mount filesystems from any server is useful only if the files are presented in a manner that is consistent with the users' expectations.
If NFS has been set up correctly, it should be transparent to the user. For example, if locally developed applications were found in /usr/local/bin before NFS was installed, they should continue to be found there when NFS is running, whether /usr/local/bin is on a local filesystem or a remote one. To the user, the actual disk holding /usr/local/bin isn't important as long as the executables are accessible and built for the right machine architecture. If users must change their environments to locate files accessed through NFS, they will probably dislike the new network architecture because it changes the way things work.
An environment with many NFS servers and hundreds of clients can quickly become overwhelming in terms of management complexity. Successful system administration of a large NFS network requires adding some intelligence to the standard procedures. The cost of consistency on the network should not be a large administrative overhead. One tool that greatly eases the task of running an NFS network is the automounter, which applies NIS management to NFS configuration. This chapter starts with a quick look at how to get NFS up and running on clients and servers, and then explores NFS naming schemes and common filesystem planning problems. We'll cover the automounter in detail in Chapter 9.
Setting up NFS
Setting up NFS on clients and servers involves starting the daemons that handle the NFS RPC protocol, starting additional daemons for auxiliary services such as file locking, and then simply exporting filesystems from the NFS servers and mounting them on the clients.
On an NFS client, you need to have the lockd and statd daemons running in order to use NFS. These daemons are generally started in a boot script (Solaris uses /etc/init.d/nfs.client):
if [ -x /usr/lib/nfs/statd -a -x /usr/lib/nfs/lockd ]
then
/usr/lib/nfs/statd > /dev/console 2>&1
/usr/lib/nfs/lockd > /dev/console 2>&1
fi
On some non-Solaris systems, there may also be biod daemons that get started. The biod daemons perform block I/O operations for NFS clients, performing some simple read-ahead and write-behind performance optimizations. You run multiple instances of biod so that each client process can have multiple NFS requests outstanding at any time. Check your vendor's documentation for the proper invocation of the biod daemons. Solaris does not have biod daemons because the read-ahead and write-behind function is handled by a tunable number of asynchronous I/O threads that reside in the system kernel.
The lockd and statd daemons handle file locking and lock recovery on the client. These locking daemons also run on an NFS server, and the client-side daemons coordinate file locking on the NFS server through their server-side counterparts. We'll come back to file locking later when we discuss how NFS handles state information.
On an NFS server, NFS services are started with the nfsd and mountd daemons, as well as the file locking daemons used on the client. You should see the NFS server daemons started in a boot script (Solaris uses /etc/init.d/nfs.server):
if grep -s nfs /etc/dfs/sharetab >/dev/null ; then
/usr/lib/nfs/mountd
/usr/lib/nfs/nfsd -a 16
fi
On most NFS servers, there is a file that contains the list of filesystems the server will allow clients to mount via NFS. Many servers store this list in /etc/exports file. Solaris stores the list in / etc/dfs/dfstab. In the previous script file excerpt, the NFS server daemons are not started unless the host shares