Configuring an NFS Server
 |
If you installed the NFS server during installation, a startup script will have been created in /etc/init.d , called nfs.server . Thus, the NFS server can be started manually by typing the following command:
# /etc/init.d/nfs.server start
This command will start at least two daemons: the NFS server ( /usr/lib/nfs/nfsd ) and the mount daemon ( /usr/lib/nfs/ mountd ). nfsd is responsible for answering access requests from clients for shared volumes on the server, while mountd is responsible for providing information about mounted file systems.
To check whether or not the NFS server has started correctly, it is possible to examine the process list for nfsd and mountd by using the following commands:
# ps -eaf grep nfsd root 19961 1 0 Aug 31 ? 0:09 /usr/lib/nfs/nfsd -a 16 # ps -eaf grep mountd root 370 1 0 May 16 ? 2:49 /usr/lib/nfs/mountd
Or, to save space:
# ps -aef egrep 'mountdnfsd'
In this case, both nfsd and mountd are operating correctly. In order to stop the NFS server, the following command may be used:
# /etc/init.d/nfs.server stop
There are some optional services started by the NFS server startup script, including daemons that support diskless booting (the Reverse Address Resolution Protocol daemon, /usr/sbin/in.rarpd , and the boot parameter server, /usr/sbin/rpc.bootparamd ). In addition, a separate daemon for x86 boot support ( /usr/sbin/rpld ), using the Network Booting RPL (Remote Program Load) protocol, may also be started.
| Tip | You only need to configure these services if you wish to provide diskless booting for local clients; otherwise , they can be safely commented from the /etc/init.d/nfs.server script. |
Sharing File Systems
To actually share file systems and directories, you can use the share command. For example, if you want to share the /var/mail directory from carolina to georgia , you could use the following command:
# share -F nfs -o rw=georgia /var/mail
In this example, '-F nfs' stands for 'a file system of type NFS.' Of course, we really want to share to virginia and fairfax as well, so we would probably use this command:
# share -F nfs -o rw=georgia,virginia,fairfax /var/mail
The /var/mail volume is shared to these clients because users on these systems need to read and write their e-mail. However, if we need to share a CD-ROM volume, we obviously need to share it read-only:
# share -F nfs -o ro /cdrom
Normally, the volumes to be shared are identified in the /etc/dfs/dfstab file. One of the really innovative features of NFS is that a system that shares volumes to other systems can actually remotely mount shared volumes from its own clients. For example, while carolina might share the volume /cdrom to georgia, fairfax, and virginia, virginia might share the /staff directory, which contains home directories, to carolina, georgia, and fairfax using the following command:
# share -F nfs -o rw=georgia,carolina,fairfax /staff
File systems can be unshared using the unshare command. For example, if we are going to change a CD-ROM on carolina that is shared to clients using NFS, it might be wise to unmount it first:
# unshare -F nfs /cdrom
To unshare all volumes that are currently being shared from a NFS server, the following command can be used:
# unshareall
The command dfmounts shows the local resources shared through the networked file system that are currently mounted by specific clients:
# dfmounts RESOURCE SERVER PATHNAME CLIENTS - carolina /cdrom virginia,Georgia - carolina /var/mail fairfax,virginia,Georgia - carolina /opt/answerbook fairfax
However, dfmounts does not provide information about the permissions by which directories and file systems are shared, nor does it show those shared resources that have no clients currently using them. To display this information, we need to use the share command with no arguments. On virginia, this looks like this:
# share /staff rw=georgia,fairfax,carolina "staff"
while on carolina, the volumes are different:
# share - /cdrom ro=georgia,fairfax,carolina "cdrom" - /var/mail rw=georgia,fairfax,carolina "mail"
Conversely, as a client, you want to determine which volumes are available for you to mount from NFS servers. This can be achieved by using the dfshares command. For example, to view the mounts available from the server virginia, executed on carolina, the dfshares would be entered as shown, and the following output would be displayed:
# dfshares -F nfs virginia RESOURCE SERVER ACCESS TRANSPORT virginia:/staff virginia - -
Table 23-1 shows the most common options for the share command.
| Parameter | Description |
|---|---|
| anon=username | Sets the username of unknown users to username. |
| log | Starts NFS logging. |
| nosuid | Prevents applications from executing as setuid. |
| nosub | Prevents client access to subdirectories of exported server volumes. |
| ro | Prevents writing to an exported file system. |
| root | Allows remote access by remote root users as the local root user . |
| rw | Permits reading and writing to an exported file system. |
| sec | Specifies the authentication level (sys, dh, or krb4). |
Installing an NFS Client
In order to access file systems being shared from an NFS server, a separate NFS client must be operating on the client system. There are two main daemon processes that must be running in order to use the mount command to access shared volumes: the NFS lock daemon ( /usr/lib/nfs/lockd ), and the NFS stat daemon ( /usr/lib/nfs/statd ). lockd manages file sharing and locking at the user level, while the statd is used for file recovery after connection outage .
If NFS was installed during the initial system setup, a file called nfs.client should have been created in /etc/init.d . In order to run the NFS client, the following command needs to be executed:
# /etc/init.d/nfs.client start
Just like the NFS server, you can verify that the NFS daemons have started correctly by using the following commands:
# ps -eaf grep statd daemon 211 1 0 May 16 ? 0:04 /usr/lib/nfs/statd # ps -eaf grep lockd root 213 1 0 May 16 ? 0:03 /usr/lib/nfs/lockd
These commands can be combined as follows :
# ps -aef egrep 'statdlockd'
If these two daemons are not active, the NFS client will not run. The next step is for the client to consult the /etc/vfstab file, which lists both the UFS and NFS file systems that need to be mounted, and attempts to mount the latter if they are available by using the mountall command.
To stop the NFS client once it is operating, the following command may be used:
# /etc/init.d/nfs.client stop
The NFS server is usually started automatically during run level 3.
Checking portmapper Status
If you're having trouble starting the NFS daemon, it's often an rpc problem. In order to determine whether an rpc portmapper is running, you may use the rpcinfo command:
# rpcinfo -p program vers proto port service 100000 4 tcp 111 rpcbind 100000 3 tcp 111 rpcbind 100000 2 tcp 111 rpcbind 100000 4 udp 111 rpcbind 100000 3 udp 111 rpcbind 100000 2 udp 111 rpcbind 100007 3 udp 32774 ypbind 100007 2 udp 32774 ypbind 100007 1 udp 32774 ypbind 100007 3 tcp 32771 ypbind 100007 2 tcp 32771 ypbind 100007 1 tcp 32771 ypbind 100011 1 udp 32785 rquotad 100024 1 udp 32789 status 100024 1 tcp 32775 status 100021 1 udp 4045 nlockmgr 100021 2 udp 4045 nlockmgr 100021 3 udp 4045 nlockmgr 100021 4 udp 4045 nlockmgr 100068 2 udp 32809 100068 3 udp 32809 100068 4 udp 32809 100068 5 udp 32809 100083 1 tcp 32795 100021 1 tcp 4045 nlockmgr 100021 2 tcp 4045 nlockmgr 100021 3 tcp 4045 nlockmgr 100021 4 tcp 4045 nlockmgr 100005 1 udp 32859 mountd 100005 2 udp 32859 mountd 100005 3 udp 32859 mountd 100005 1 tcp 32813 mountd 100005 2 tcp 32813 mountd 100005 3 tcp 32813 mountd 100026 1 udp 32866 bootparam 100026 1 tcp 32815 bootparam
In this example, both mountd and nfsd are running, along with several other services, so the NFS daemon should have no problems executing. However, the RPL service is not active, so x86 clients would not be able to use the local server as a boot server.
Mounting Remote File Systems
On the client side, if we want to mount a volume that has been shared from an NFS server, we use the mount command. For example, if we want to mount the exported CD-ROM from carolina on the NFS client virginia, we would use this command:
# mount -F nfs -o ro carolina:/cdrom /cdrom
Like the /etc/dfs/dfstab files, which record a list of volumes to be exported, the /etc/vfstab file can contain entries for NFS volumes to be mounted from remote servers. For example, on the machine fairfax, if we wanted the /var/mail volume on carolina to be mounted locally as /var/mail , we would enter the following line in /etc/vfstab :
carolina:/var/mail - /var/mail nfs - yes rw
This line can be interpreted as a request to mount /var/mail from carolina read/write on the local mount point /var/mail as an NFS volume that should be mounted at boot time. If you made the appropriate changes to the /etc/vfstab file on virginia, and you want to mount the /var/mail partition, you can use the following command:
# mount /var/mail
This will attempt to mount the remote /var/mail directory from the server carolina. Alternatively, you can use the command,
# mountall
which will mount all partitions that are listed in /etc/vfstab , but which have not yet been mounted.
File systems can be unmounted by using the umount command. For example, if the /cdrom file system on carolina is mounted on virginia as /cdrom , then the command,
# umount /cdrom
will unmount the mounted NFS volume. Alternatively, the unmountall command can be used, which unmounts all currently mounted NFS volumes. For example, the command,
# umountall -F nfs
unmounts all volumes that are currently mounted through NFS. The umount -f command forcibly unmounts a file system:
# umount -f /cdrom
When a remote volume is mounted on a local client, it should be visible to the system just like a normal disk, and so commands like df , which displays disk slice information, can be readily used:
# df -k carolina:/cdrom 412456 341700 70756 83% /cdrom carolina:/var/mail 4194304 343234 3851070 8% /var/mail carolina:/opt/answerbook 2097152 1345634 750618 64% /opt/answerbook
The main options available for mounting NFS file systems are shown in Table 23-2.
| Option | Description |
|---|---|
| ro | Mounts a file system's read-only permissions. |
| rw | Mounts a file system's read/write permissions. |
| hard | No timeouts permitted-the client will repeatedly attempt to make a connection. |
| soft | Timeouts permitted-the client will attempt a connection, and give an error message if connection fails. |
| bg | Attempts to mount a remote file system in the background if connection fails. |
Enhancing Security
So far, we've examined NFS without considering the security implications of sharing a file system to clients. In a local intranet environment, with protection from a firewall, some administrators implement open NFS sharing, where client lists are not supplied to share commands to limit access to server volumes. The problem with this approach is spoofing: an external system may be able to ' pretend ' to be part of your local network, thereby gaining access to globally shared NFS volumes. Given that NFS authentication is usually based on mappings of usernames on the client to the server, if a spoofed system contains equivalent user accounts to those found on the server, unauthorized clients will be able to read and write data at will. This is why it's critical to only share volumes to specific client systems, using the appropriate 'read-write' or 'read-only' designation.
The other key parameter for the share command, sec , specifies the type of authentication required to access server volumes. By default, the sys level is used, whereby usernames and groups are mapped between client and server. Thus, the user lynda on the client will have the same access permissions as lynda on the server. However, other alternatives are available, depending on the relative risks involved in data loss. If sensitive data is being shared by a NFS server, it may be wise to implement a more sophisticated authentication method, including one based on DES public-key cryptography (the dh level, standing for Diffie-Hellman), or the Kerberos 4 authentication method (the krb4 level). If a volume is exported with the dh or krb4 authentication levels, then all clients must use the method specified to access data on the volume specified. To support the dh or krb4 authentication levels, secure RPC must be running.
| Tip | User keys can be updated by using the chkey command. |
Performance
NFS performance is determined by a number of factors, including:
-
Server CPU speed, and number of server CPUs
-
Server physical RAM and virtual RAM
-
Server disk speed
-
Server system load
-
Server CacheFS capacity
-
Server network interfaces
-
Number of clients
-
Speed of local network
-
Domain Name Lookup Cache (DNLC) speed
Many sites develop NFS services incrementally-as the number of users grows, so does the number of CPUs, memory, and network interfaces, along with faster disks allocated to improving NFS performance.
| Tip | A number of software methods , including the CacheFS and DNLC settings, can be modified to improve data throughput. |
One of the best methods for determining how NFS is performing, from both a client and server perspective, is to use the nfsstat command to gather performance statistics over a period of weeks or months. In particular, counting the number of calls and bad calls can show the proportion of successful to unsuccessful requests, respectively, to the server. To run nfsstat on the server, the following command is used:
# nfsstat -s ... Server nfs: calls badcalls 575637455 3433 ...
Here, we can see that the proportion of bad calls to the total number of calls is 3433 575637455, which is much less than 1 percent. After gathering statistics for each interval, the counters can be reset to zero by using the following command:
# nfsstat -z
EAN: 2147483647
Pages: 265