|
|
NFSObjectives: Explain NFS fundamentals, and configure and manage the NFS server and client including daemons, files, and commands.
The NFS service lets computers of different architectures, running different operating systems, share file systems across a network. Just as the mount command lets you mount a file system on a local disk, NFS lets you mount a file system that is located on another system anywhere on the network. Furthermore, NFS support has been implemented on many platforms, ranging from MS-DOS on personal computers to mainframe operating systems, such as Multiprogramming using Virtual Storage (MVS). Each operating system applies the NFS model to its file system semantics. For example, a Sun system can mount the file system from a Windows NT or Linux system. File system operations, such as reading and writing, function as though they are occurring on local files. Response time might be slower when a file system is physically located on a remote system, but the connection is transparent to the user regardless of the hardware or operating systems. The NFS service provides the following benefits:
The NFS service makes the physical location of the file system irrelevant to the user. You can use NFS to allow users to see all the data, regardless of location. With NFS, instead of placing copies of commonly used files on every system, you can place one copy on one computer's disk and have all other systems across the network access it. Under NFS operation, remote file systems are almost indistinguishable from local ones. NFS Version 4Solaris 10 introduced a new version of the NFS protocol, which has the following features:
Servers and ClientsWith NFS, systems have a client/server relationship. The NFS server is where the file system resides. Any system with a local file system can be an NFS server. As described later in this chapter, in the section "Setting Up NFS," you can configure the NFS server to make file systems available to other systems and users. The system administrator has complete control over which file systems can be mounted and who can mount them. An NFS client is a system that mounts a remote file system from an NFS server. You'll learn later in this chapter, in the section "Mounting a Remote File System," how you can create a local directory and mount the file system. As you will see, a system can be both an NFS server and an NFS client. NFS DaemonsNFS uses a number of daemons to handle its services. These services are initialized at startup from the svc:/network/nfs/server:default and svc:/network/nfs/client:default startup service management functions. The most important NFS daemons are described in Table 9.8.
Setting Up NFSServers let other systems access their file systems by sharing them over the NFS environment. A shared file system is referred to as a shared resource. You specify which file systems are to be shared by entering the information in the file /etc/dfs/dfstab. Entries in this file are shared automatically whenever you start the NFS server operation. You should set up automatic sharing if you need to share the same set of file systems on a regular basis. Most file system sharing should be done automatically; the only time manual sharing should occur is during testing or troubleshooting. The /etc/dfs/dfstab file lists all the file systems your NFS server shares with its NFS clients. It also controls which clients can mount a file system. If you want to modify /etc/dfs/dfstab to add or delete a file system or to modify the way sharing is done, you edit the file with a text editor, such as vi. The next time the computer enters the multi-user-server milestone, the system reads the updated /etc/dfs/dfstab to determine which file systems should be shared automatically. Each line in the dfstab file consists of a share command, as shown in the following example: more /etc/dfs/dfstab The system responds by displaying the contents of /etc/dfs/dfstab: # Place share(1M) commands here for automatic execution # on entering init state 3. # # Issue the command 'svcadm enable network/nfs/server' to # run the NFS daemon processes and the share commands, after adding # the very first entry to this file. # # 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 /export/install/sparc_10 share -F nfs /jumpstart The /usr/sbin/share command exports a resource or makes a resource available for mounting. If it is invoked with no arguments, share displays all shared file systems. The share command can be run at the command line to achieve the same results as the /etc/dfs/dfstab file, but you should use this method only when testing. This is the syntax for the share command: share -F <FSType> -o <options> -d <description> <pathname> where <pathname> is the name of the file system to be shared. Table 9.9 describes the options of the share command.
To share a file system as read-only every time the system is started up, you add this line to the /etc/dfs/dfstab file: share -F nfs -o ro /data1 After you edit the /etc/dfs/dfstab file, restart the NFS server by either rebooting the system or by typing this: svcadm restart nfs/server You need to run the svcadm enable nfs/server command only after you make the first entry in the /etc/dfs/dfstab file. This is because at startup, when the system enters the multi-user-server milestone, mountd and nfsd are not started if the /etc/dfs/dfstab file is empty. After you have made an initial entry and have executed the svcadm enable nfs/server command, you can modify /etc/dfs/dfstab without restarting the daemons. You simply execute the shareall command, and any new entries in the /etc/dfs/dfstab file are shared. Note Sharing Even if you share a file system from the command line by typing the share command, mountd and nfsd still won't run until you make an entry into /etc/dfs/dfstab and run the svcadm enable nfs/server command. When you have at least one entry in the /etc/dfs/dfstab file and when both mountd and nfsd are running, you can share additional file systems by typing the share command directly from the command line. Be aware, however, that if you don't add the entry to the /etc/dfs/dfstab file, the file system is not automatically shared the next time the system is restarted. Exam Alert File System Sharing There is often at least one question on the exam related to the sharing of file systems. Remember that the NFS server must be running in order for the share to take effect. The dfshares command displays information about the shared resources that are available to the host from an NFS server. Here is the syntax for dfshares: dfshares <servername>You can view the shared file systems on a remote NFS server by using the dfshares command, like this: dfshares apollo If no servername is specified, all resources currently being shared on the local host are displayed. Another place to find information on shared resources is in the server's /etc/dfs/sharetab file. This file contains a list of the resources currently being shared. Mounting a Remote File SystemChapter 1 describes how to mount a local file system by using the mount command. You can use the same mount command to mount a shared file system on a remote host using NFS. Here is the syntax for mounting NFS file systems: mount -F NFS <options> <-o specific-options > <-O> \ <server>:<file-system> <mount-point> In this syntax, server is the name of the NFS server in which the file system is located, file-system is the name of the shared file system on the NFS server, and mount-point is the name of the local directory that serves as the mount point. As you can see, this is similar to mounting a local file system. The options for the mount command are described in Table 9.10.
File systems mounted with the bg option indicate that mount is to retry in the background if the server's mount daemon (mountd) does not respond when, for example, the NFS server is restarted. From the NFS client, mount retries the request up to the count specified in the retry=<n> option. After the file system is mounted, each NFS request made in the kernel waits a specified number of seconds for a response (specified with the timeo=<n> option). If no response arrives, the timeout is multiplied by 2, and the request is retransmitted. If the number of retransmissions has reached the number specified in the retrans=<n> option, a file system mounted with the soft option returns an error, and the file system mounted with the hard option prints a warning message and continues to retry the request. Sun recommends that file systems mounted as read-write or containing executable files should always be mounted with the hard option. If you use soft-mounted file systems, unexpected I/O errors can occur. For example, consider a write request: If the NFS server goes down, the pending write request simply gives up, resulting in a corrupted file on the remote file system. A read-write file system should always be mounted with the specified hard and intr options. This lets users make their own decisions about killing hung processes. You use the following to mount a file system named /data located on a host named thor with the hard and intr options: mount -F nfs -o hard,intr thor:/data /data If a file system is mounted hard and the intr option is not specified, the process hangs when the NFS server goes down or the network connection is lost. The process continues to hang until the NFS server or network connection becomes operational. For a terminal process, this can be annoying. If intr is specified, sending an interrupt signal to the process kills it. For a terminal process, you can do this by pressing Ctrl+C. For a background process, sending an INT or QUIT signal, as follows, usually works: kill -QUIT 3421 Note Overkill Won't Work Sending a KILL signal (-9) does not terminate a hung NFS process. To mount a file system called /data that is located on an NFS server called thor, you issue the following command, as root, from the NFS client: mount -F nfs -o ro thor:/data /thor_data In this case, the /data file system from the server thor is mounted read-only on /thor_data on the local system. Mounting from the command line enables temporary viewing of the file system. If the umount command is issued or the client is restarted, the mount is lost. If you would like this file system to be mounted automatically at every startup, you can add the following line to the /etc/vfstab file: thor:/data - /thor_data nfs - yes ro Note Mount Permissions The mount and umount commands require root access. The umount command and /etc/vfstab file are described in Chapter 1. To view resources that can be mounted on the local or remote system, you use the dfmounts command, as follows: dfmounts sparcserver The system responds with a list of file systems currently mounted on sparcserver: RESOURCE SERVER PATHNAME CLIENTS
- ultra5 /usr 192.168.1.201
ultra5 /usr/dt 192.168.1.201Sometimes you rely on NFS mount points for critical information. If the NFS server were to go down unexpectedly, you would lose the information contained at that mount point. You can address this issue by using client-side failover. With client-side failover, you specify an alternative file system to use in case the primary file system fails. The primary and alternative file systems should contain equivalent directory structures and identical files. This option is available only on read-only file systems. To set up client-side failover, on the NFS client, mount the file system by using the -ro option. You can do this from the command line or by adding an entry to the /etc/vfstab file that looks like the following: zeus,thor:/data - /remote_data nfs - no -o ro If multiple file systems are named and the first server in the list is down, failover uses the next alternative server to access files. To mount a replicated set of NFS file systems, which might have different paths to the file system, you use the following mount command: mount -F nfs -o ro zeus:/usr/local/data,thor:/home/data /usr/local/data Replication is discussed further in the "AutoFS" section, later in this chapter. NFS Server LoggingA feature that first appeared in Solaris 8 is NFS server logging (refer to Chapter 1). NFS server logging provides event and audit logging functionality to networked file systems. The daemon nfslogd provides NFS logging, and you enable it by using the log=<tag> option in the share command, as described earlier in this chapter, in the section "Setting Up NFS." When NFS logging is enabled, the kernel records all NFS operations on the file system in a buffer. The data recorded includes a timestamp, the client Internet Protocol (IP) address, the UID of the requestor, the file handle of the resource that is being accessed, and the type of operation that occurred. The nfslogd daemon converts this information into ASCII records that are stored in ASCII log files. Note No Logging in NFS Version 4 Remember that NFS logging is not supported in NFS version 4. To enable NFS server logging, follow the procedure described in Step by Step 9.5. Exam Alert NSF Server Logging Configuration You should be familiar with the concept of NFS server logging, especially the location of the configuration file (/etc/nfs/nfslog.conf). The nfs directory in the path can be easily forgotten, and you lose an exam point unnecessarily if you leave it out. You can change the file configuration settings in the NFS server logging configuration file /etc/nfs/nfslog.conf. This file defines pathnames, filenames, and types of logging to be used by nfslogd. Each definition is associated with a tag. The global tag defines the default values, but you can create new tags and specify them for each file system you share. The NFS operations to be logged by nfslogd are defined in the /etc/default/nfslogd configuration file. Note Logging Pros and Cons NFS server logging is particularly useful for being able to audit operations carried out on a shared file system. The logging can also be extended to audit directory creations and deletions. With logging enabled, however, the logs can become large and consume huge amounts of disk space. It is necessary to configure NFS logging appropriately so that the logs are pruned at regular intervals. |
|
|