tyt12fi.htm

tcpip 协议学习电子书籍 第一次上传东西

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>EXPORT

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Provides a list of exported file systems

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>DUMP

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Provides a list of the file systems on the server that are currently mounted on the client</FONT>

</TABLE></CENTER><BR>

<P>Some versions of NFS enable an automount capability, in which the remote file systems are mounted only when required. This prevents them from being attached for extended periods of time and simplifies administration. The process of automounting is completely transparent to the user.

<BR>

<P>The automount capability is built upon NFS's procedures, but it performs a few clever tricks. The automounter is not part of NFS but is an application that sits on top of it. Symbolic links are the key to the automounter's operation.

<BR>

<BR>

<A ID="E69E156" NAME="E69E156"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>File Locking</B></FONT></CENTER></H4>

<BR>

<P>Occasionally a system administrator wants to prevent access to an NFS-available file system. Such instances occur regularly during maintenance, software updates, or to protect data during a particular process. UNIX has the capability to lock a particular file by changing permissions, and the same can be done for file systems to some extent, but it would seem intuitive that locking a file system is more involved than simply locking a file or two. The capability to lock file systems from access was not developed with the original NFS product but was implemented as a parallel service after NFS became more widely available.

<BR>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE>

<IMG SRC="note.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/note.gif" WIDTH = 75 HEIGHT = 46>Separating functionality (such as file locking) into separate protocols or procedures is consistent with both the OSI and NFS philosophies. This also enables better portability and compatibility across platforms.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P>File system locking is handled by several protocols and procedures, involving a few daemon processes. In the original file locking system developed by Sun Microsystems, a lock daemon called lockd was used. This requires that every RPC activity that involves a lock communicates with the process, even when it is on another machine. The communications between RPC and lockd use a protocol called Kernel Lock Manager (KLM), which rides on UDP.

<BR>

<P>Whenever a lock procedure is called, lockd decides whether it can handle the task on the local machine or whether messages have to be sent to remote lockd processes (on other machines). Communications between different lockd processes are through another protocol called the Network Lock Manager (NLM). There are several versions of both KLM and NLM in use, with implementations available for most hardware platforms.

<BR>

<P>A process called statd (status monitor) monitors the state of locks and handles queries against a locked file system. This is necessary so that a new query against a locked file system can be queued (if it is locked for a short time) or rejected (if the file system is locked for a while).

<BR>

<P>There are several built-in protection systems for file locking, such as automatic timers to prevent infinite locking after a machine crash, conflicting requests for locks, and a short period for completion of existing procedures before a lock is completed. These are all defined and explained in the RFC.

<BR>

<BR>

<A ID="E69E157" NAME="E69E157"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Remote Execution Service (REX)</B></FONT></CENTER></H4>

<BR>

<P>The Remote Execution Service (REX) is designed to enable a user to run commands on another machine with full environment variables, without incurring the overhead of processes such as Telnet, rlogin, or rsh. REX uses a daemon called rexd that runs on the server and employs NFS's services. (Remember that each machine can be both client and server, so most multitasking machines on a network can run rexd.) REX is commonly used when some applications are installed on only a few machines but should be available to all users.

<BR>

<P>REX has an important advantage over the other UNIX utilities for this type of service. It enables access to the local machine's data while executing the command on the remote. This enables a user to run an application on another machine while accessing data files on the local machine. It also enables another machine's resources to be used without starting a user shell process or logging into the remote machine.

<BR>

<P>To run an application or execute a command on a remote machine, the REX on command is used. The syntax adds the name of the machine on which the command is to be executed and the command to run. The following code gives an example of this:

<BR>

<PRE>

<FONT COLOR="#000080">$ hostname

tpci_hpws4

$ cat file1

This is the file &quot;file1&quot; on &quot;tpci_hpws4&quot;.

This is the client machine.

$ on merlin hostname

merlin

$ rsh merlin cat file1

cat: cannot open file1

$ on merlin cat file1

This is the file &quot;file1&quot; on &quot;tpci_hpws4&quot;.

This is the client machine.</FONT></PRE>

<P>This example shows the remote machine executing a cat command on a local file. When the remote machine runs commands using on, an identical environment to the client is established on the remote, including user and group IDs and environment variables. So, if the remote machine in the previous example had a file called file1, but it was not in the search path of the process running the command, the system would still refer back to the client for the file.

<BR>

<BR>

<A ID="E69E158" NAME="E69E158"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>rusers</B><B> and </B><B>spray</B></FONT></CENTER></H4>

<BR>

<P>Two utilities available to NFS users are simple examples of RPC programs. They are also useful to the user who wants to check the status of connections and the load on a remote machine.

<BR>

<P>The spray program is similar to ping in that it sends a batch of messages across the network and waits for replies. Several supported options can configure the use of spray. When the spray command is issued with the -c option, it sends a supplied number of datagrams to the remote machine and times the results. A typical use is shown here:

<BR>

<PRE>

<FONT COLOR="#000080">$ spray -c 200 beast

sending 200 packets of length 86 to beast...

   in 18.3 seconds elapsed time,

   4 packets (2.00%) dropped by beast

Sent:  10 packets/sec, 912 bytes/sec

Recd:   9 packets/sec, 862 bytes/sec</FONT></PRE>

<P>The rusers program gives you an idea of who is logged into remote machines. A typical output is the following:

<BR>

<PRE>

<FONT COLOR="#000080">$ rusers

beast.tpci.com       tparker  bsmallwood  rmaclean

merlin.tpci.com      ychow  etreijs  tgrace

tpci_hpws3.tpci.com  tparker  sysadm

tpci_hpws4.tpci.com  pepper</FONT></PRE>

<P>As shown, the output from the rusers program includes the machine name and the list of users on that machine. Some implementations support options for rusers, whereas some have slightly differing output.

<BR>

<BR>

<A ID="E68E110" NAME="E68E110"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Configuring NFS</B></FONT></CENTER></H3>

<BR>

<P>Many people love using the NFS service when they are faced with it as a user but are scared to configure it when acting as a system administrator. The general assumption is that the process must be convoluted, complex, and require a lot of knowledge about the operating systems. For this reason, many people don't bother with NFS, which is a shame because it is one of the most useful services TCP/IP has to offer. As you see in this section, it is not difficult to implement an NFS network.

<BR>

<P>I configure NFS on two different operating systems to show the general process. I use an SCO UNIX machine as an example of a UNIX installation, and a Windows for Workgroups system to show setting up a client and server NFS PC system. I start with the UNIX machine, because UNIX is most often associated with NFS servers.

<BR>

<BR>

<A ID="E69E159" NAME="E69E159"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Configuring UNIX as an NFS Server</B></FONT></CENTER></H4>

<BR>

<P>The NFS service makes extensive use of the RPC service. For this reason, the RPC server daemon must be running for NFS to be implemented. On some UNIX systems you can check whether RPC is active by issuing this command at the shell prompt:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">rpcinfo -p </FONT></PRE>

<P>You should see a list of all the RPC servers currently running on your machine. If RPC is running properly, you see four rpcbind listings (two for UDP and two for TCP) and an entry for pcnfsd, the NFS daemon. This command doesn't show all this output for some versions of UNIX, including SCO UNIX.

<BR>

<P>For SCO UNIX, NFS is started and stopped by a script called /etc/nfs. This can be linked into the startup routines to load NFS automatically when the system boots by linking the /etc/nfs file to the file /etc/rc2.d/Sname. To shut down NFS properly, you also need to link /etc/nfs to the file /etc/rc0.d/Kname. (On other UNIX implementations the filenames change, but the general approach is the same.) If you want to start and stop the NFS daemon manually, you can do this with these commands:

<BR>

<PRE>

<FONT COLOR="#000080">/etc/nfs start

/etc/nfs stop</FONT></PRE>

<P>The /etc/nfs command starts up and shuts down the NFS server daemon when the appropriate command is issued. When you issue the start command, the daemons that are activated are echoed to the screen:

<BR>

<PRE>

<FONT COLOR="#000080">$ /etc/nfs start

Starting NFS services: exportfs mountd nfsd pcnfsd biod(x4)

Starting NLM services: statd lockd</FONT></PRE>

<P>With a stop command, you see a message that the daemons and server are shut down:

<BR>

<PRE>

<FONT COLOR="#000080">$ /etc/nfs stop

NFS shutdown: [NFS Shutdown Complete]</FONT></PRE>

<P>For a filesystem on a SCO UNIX machine to be available to NFS clients on other machines, the filesystem must be listed in the UNIX file /etc/exports. With some versions of UNIX, the NFS daemons are started automatically if the /etc/exports file exists during boot time. This invokes a program called exportfs that sets the filesystem as available for NFS use. If any changes are made to the /etc/exports file while the system is running, you can issue another exportfs command, or simply reboot the machine, to make the changes effective.

<BR>

<P>The format of the /etc/exports file is as follows: 

<BR>

<BR>

<PRE>

<FONT COLOR="#000080"><I>directory</I> [ -<I>option</I>, <I>option</I> ... ]</FONT></PRE>

<P>The directory is the pathname of the directory or file to be shared (exported, in NFS terminology) by NFS, and the options are one of the following:

<BR>

<UL>

<UL>

<P>ro: Export the directory as read-only. (The default value is to export as read-write.) 

<BR>

</UL></UL>

<UL>

<UL>

<P>rw=hostnames: Export the directory as read-mostly, which means read-only to most machines but read-write to machines specifically identified.

<BR>

</UL></UL>

<UL>

<UL>

<P>anon=uid: If an NFS request comes from an unknown user, use uid as the effective user ID for ownership and permissions.

<BR>

</UL></UL>

<UL>

<UL>

<P>root=hostnames: Gives root access to the root users from a specified machine.

<BR>

</UL></UL>

<BLOCKQUOTE>

<BLOCKQUOTE>

<P>access=client: Gives mount access to each client listed. A client can be a host name or a net group.

<BR>

</BLOCKQUOTE></BLOCKQUOTE>

<P>An example of an /etc/exports file helps show the use of these options. A pound sign (#) on a line means a comment. Here's a sample /etc/exports file:

<BR>

<PRE>

<FONT COLOR="#000080">/usr/stuff -ro            # export as read-only to anyone

/usr   -access=clients    # export to the group called clients

/usr/public               # export as read-write to anyone</FONT></PRE>

<P>NFS is now ready for use on the SCO UNIX server. You might notice that SCO UNIX creates a new file called /etc/xtab that contains the filesystem information from the exports file. You should not modify the contents of the /etc/xtab file or the NFS server cannot function properly. The /etc/xtab file is generated by the exportfs command.