?? tyt12fi.htm
字號:
<HTML>
<HEAD>
<TITLE>tyt12fi.htm</TITLE>
<LINK REL="ToC" HREF="index.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/index.htm">
<LINK REL="Index" HREF="tppmsgs/msgs0.htm#3" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/htindex.htm">
<LINK REL="Next" HREF="tyt13fi.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/tyt13fi.htm">
<LINK REL="Previous" HREF="tyt11fi.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/tyt11fi.htm"></HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080"><A ID="I0" NAME="I0"></A>
<P><P ALIGN=CENTER>
<A HREF="tyt11fi.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/tyt11fi.htm" TARGET="_self"><IMG SRC="blanprev.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/blanprev.gif" WIDTH = 37 HEIGHT = 37 BORDER = 0 ALT="Previous Page"></A>
<A HREF="index.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/index.htm" TARGET="_self"><IMG SRC="blantoc.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/blantoc.gif" WIDTH = 37 HEIGHT = 37 BORDER = 0 ALT="TOC"></A>
<A HREF="tyt13fi.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/tyt13fi.htm" TARGET="_self"><IMG SRC="blannext.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/blannext.gif" WIDTH = 37 HEIGHT = 37 BORDER = 0 ALT="Next Page"></A>
<HR ALIGN=CENTER>
<P>
<UL>
<UL>
<UL>
<LI>
<A HREF="#E68E108" >Network File System (NFS)</A></LI>
<LI>
<A HREF="#E68E109" >NFS Protocols</A></LI>
<UL>
<LI>
<A HREF="#E69E152" >Remote Procedure Call (RPC)</A></LI>
<UL>
<LI>
<A HREF="#E70E47" >Port Mapper</A></LI></UL>
<LI>
<A HREF="#E69E153" >External Data Representation (XDR)</A></LI>
<LI>
<A HREF="#E69E154" >Network File System Protocol</A></LI>
<LI>
<A HREF="#E69E155" >Mount Protocol</A></LI>
<LI>
<A HREF="#E69E156" >File Locking</A></LI>
<LI>
<A HREF="#E69E157" >Remote Execution Service (REX)</A></LI>
<LI>
<A HREF="#E69E158" >rusers and spray</A></LI></UL>
<LI>
<A HREF="#E68E110" >Configuring NFS</A></LI>
<UL>
<LI>
<A HREF="#E69E159" >Configuring UNIX as an NFS Server</A></LI>
<LI>
<A HREF="#E69E160" >Setting Up a UNIX NFS Client</A></LI>
<LI>
<A HREF="#E69E161" >Setting Up Windows-Based NFS </A></LI>
<LI>
<A HREF="#E69E162" >Sharing a Windows Directory</A></LI></UL>
<LI>
<A HREF="#E68E111" >Network Information Service (NIS)</A></LI>
<LI>
<A HREF="#E68E112" >Configuring NIS</A></LI>
<UL>
<LI>
<A HREF="#E69E163" >Setting Up the NIS Domain </A></LI>
<LI>
<A HREF="#E69E164" >NIS Daemons</A></LI>
<LI>
<A HREF="#E69E165" >Setting Up an NIS Master</A></LI>
<LI>
<A HREF="#E69E166" >Setting Up NIS Slaves</A></LI>
<LI>
<A HREF="#E69E167" >Setting Up NIS Clients</A></LI></UL>
<LI>
<A HREF="#E68E113" >RPC and NFS Administration</A></LI>
<UL>
<LI>
<A HREF="#E69E168" >rpcinfo</A></LI>
<LI>
<A HREF="#E69E169" >nfsstat</A></LI></UL>
<LI>
<A HREF="#E68E114" >Summary</A></LI>
<LI>
<A HREF="#E68E115" >Q&A</A></LI>
<LI>
<A HREF="#E68E116" >Quiz</A></LI></UL></UL></UL>
<HR ALIGN=CENTER>
<A ID="E66E12" NAME="E66E12"></A>
<H1 ALIGN=CENTER>
<CENTER>
<FONT SIZE=6 COLOR="#FF0000"><B>— 12 —</B>
<BR><B>Network File System and Network Information Service</B></FONT></CENTER></H1>
<BR>
<P>Today I look at the Network File System (NFS), a set of protocols and products in wide use with TCP/IP-based networks. NFS is especially popular with UNIX networks, but it is now available for many platforms and works well across a local area network. I also look at several protocols that are closely associated with NFS, such as Network Information Service (NIS), and the Remote Execution Service (REX).
<BR>
<P>Today's text concentrates on the UNIX versions of these protocols, simply because they serve as an excellent illustration. For other operating systems, names of files and procedures might change, but the fundamentals are compatible. I show some examples of using PC machines for NFS and NIS as appropriate.
<BR>
<BR>
<A ID="E68E108" NAME="E68E108"></A>
<H3 ALIGN=CENTER>
<CENTER>
<FONT SIZE=5 COLOR="#FF0000"><B>Network File System (NFS)</B></FONT></CENTER></H3>
<BR>
<P>The move to distributed processing and client/server architectures<B><I> </I></B>has meant that many users have small, powerful machines on their desk that communicate with a larger server somewhere on a network. The applications the user needs are often located in places other than on their desktop, so some method of accessing remote files (applications and data) is required. Although both Telnet and rlogin enable a user to use a remote machine, neither system takes advantage of the user's desktop machine. Peripheral sharing has also become important as local area networks grow. To help integrate workstations into local area networks, as well as to simplify remote file access and peripheral sharing, Sun Microsystems introduced the Network File System (NFS).
<BR>
<P>Sun designed NFS so that it would enable machines from different vendors to work together, even if they used different operating systems. Sun published the NFS specifications, enabling other vendors to adopt their own hardware and software to work smoothly with NFS. This results in a completely homogeneous network. Since Sun's introduction, NFS has become a de facto standard among UNIX environments, with strong support in other operating systems, as well.
<BR>
<P>NFS actually refers to both a product and a protocol. There is an NFS product that consists of a set of protocols for different tasks (these are examined in the section titled "NFS Protocols"). The NFS protocol is the one protocol of the NFS product that deals with file access. To avoid confusion, you should think of the NFS protocol specifically (instead of the entire product set) when NFS is mentioned today.
<BR>
<P>NFS is now intimately tied with UNIX, and it is shipped as part of the System V Release 4 software version. It is also tied to TCP/IP, which remains the communications protocol of choice for UNIX networks. For other operating systems, NFS is usually an extension that is added at the system administrator's option. UNIX systems use the process nfsd to manage NFS access, with the process started automatically when the UNIX system boots after NFS has been properly configured.
<BR>
<P>NFS enables an application to read and write files that reside on NFS servers, with the access to the NFS server completely transparent to the application and the user. For developers, NFS requires no extra coding or special handling, which makes it especially attractive. This transparent access to another machine's file structure is achieved by logically attaching the NFS server to the client, a process called <I>mounting. </I>
<BR>
<P>The NFS server's file system can be attached as a whole, or just a portion of it can be mounted. The directory at which the mount occurs is called the <I>mount point. </I>The concept of shared files similar to that encountered with NFS is sometimes called a <I>distributed file system,</I> although this is a misnomer with NFS.
<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>UNIX has had the capability to mount or attach another file system for a long time. This type of mounting can occur across networks and is transparent to the application and user, as long as filenames take into account the full path name of the mounted file system. The NFS mount is similar to the UNIX mount process.</NOTE>
<BR>
<HR ALIGN=CENTER>
</BLOCKQUOTE></BLOCKQUOTE>
<P>NFS uses the term <I>client </I>to represent any machine that requests a file from another machine, which is the <I>server. </I>Multitasking operating systems can act as both client and server simultaneously, with processes on the machine accessing files on another machine while others on the network access its own hard disk. Usually, restrictions are imposed as to the files or portions of a file system that can be shared, both for security and speed considerations. Typical NFS installations use personal computers or diskless workstations as clients accessing a more powerful server system. Because personal computer operating systems such as MS-DOS are single-tasking, PCs usually act only as clients, unless they run a multitasking operating system such as Windows NT or OS/2. It is possible to have an entire network of multitasking computers sharing their drives with each other, although in practice this works well only for small networks because of the high density of network traffic required to support all the mounted filesystems.
<BR>
<P>Because of the need to transfer files quickly, network speed becomes vitally important. When it was designed, the original goal for an NFS-mounted file system was to provide performance equivalent to 80 percent of the performance expected from a locally mounted hard disk. This puts the performance emphasis on both the NFS disk drive and the network system. Typically, NFS disk drives are among the fastest available, specifically to reduce bottlenecks at the drive end. The network hardware and software must be chosen to enable the fastest possible throughput.
<BR>
<P>Because NFS is UNIX-based, the security offered is rudimentary. For this reason, Sun has introduced Secure NFS, which implements an encrypted messaging protocol for added protection against unauthorized access to NFS-mounted file systems.
<BR>
<BR>
<A ID="E68E109" NAME="E68E109"></A>
<H3 ALIGN=CENTER>
<CENTER>
<FONT SIZE=5 COLOR="#FF0000"><B>NFS Protocols</B></FONT></CENTER></H3>
<BR>
<P>The NFS product comprises several protocols, only one of which is called the NFS protocol. The NFS product protocols are designed as a set of layers, similar to the OSI model. The layers of the NFS product are compared to the OSI layers in Figure 12.1. Each protocol in the NFS product has an Internet RFC dedicated to its specification.
<BR>
<P><B><A HREF="12tyt01.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/12tyt01.gif">Figure 12.1. NFS protocol layers.</A></B>
<BR>
<P>The NFS product is based on the OSI layered model, resulting in protocols that are independent (in theory, at least) from each other and protocols in different layers. The design philosophy is that any single-layer protocol could be replaced with any other one, assuming the functionality of the protocol was the same. To date there are no common alternatives for the two lower-layer products, RPC and XDR, although there are several for the top layer.
<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>The source code for both the Remote Procedure Call (RPC) and External Data Representation (XDR) protocols is available free of charge from Sun Microsystems.</NOTE>
<BR>
<HR ALIGN=CENTER>
</BLOCKQUOTE></BLOCKQUOTE>
<P>Figure 12.1 introduces the RPC (Remote Procedure Call) and XDR (External Data Representation) protocols that I look at now in more detail.
<BR>
<BR>
<A ID="E69E152" NAME="E69E152"></A>
<H4 ALIGN=CENTER>
<CENTER>
<FONT SIZE=4 COLOR="#FF0000"><B>Remote Procedure Call (RPC)</B></FONT></CENTER></H4>
<BR>
<P>The Remote Procedure Call (RPC) protocol acts as the session layer and as the message exchanger for all NFS-based applications. RPC is composed of a set of procedures that can be incorporated into high-level applications to handle any required network access. The remote procedures are no more complicated to use than local procedures.
<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>RPC was specially developed for NFS but has since found use in other protocol suites. The principles covered here apply to those RPC products, as well.</NOTE>
<BR>
<HR ALIGN=CENTER>
</BLOCKQUOTE></BLOCKQUOTE>
<P>Application developers can create their own RPC procedures between a client (the one that issues the request) and a server (the one that processes the request). A group of procedures is called a <I>service. </I>Each server can use only one service, so each service is assigned a <I>program </I><I>number </I>to identify itself to both the client and the server.
<BR>
<P>RPC functions over the network between a client and a server. The process followed by an RPC is shown in Figure 12.2. It begins with the activation of the procedure by the client, from which a request message is sent to the server. After receiving the message and extracting the request, the server executes the requested procedure and assembles a response message with the results. Upon receipt of the reply, the client disassembles the message and continues with the application's normal execution. Every step of the procedure is controlled by routines within the RPC library (which is linked into the applications).
<BR>
<P><B><A HREF="12tyt02.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/12tyt02.gif">Figure 12.2. The execution of an RPC.</A></B>
<BR>
<P>RPC messages can be sent using either TCP or UDP (or for that matter, any other protocol that provides the same functionality). Typically, RPC is used with UDP because a connection-based protocol is not necessary and UDP is usually faster. However, UDP does impose a maximum packet size, which can cause some problems with procedures. Also, UDP does not guarantee delivery, so an application that uses UDP must handle reliability issues (usually with a retransmission timer).
<BR>
<P>The use of TCP offers the capability not only to ignore reliability concerns (leaving that to the TCP software), but also to batch requests. With a batch connection, the client and server agree that the client can send several RPC requests one after another without waiting for acknowledgment or a reply to each. This can be a useful feature with some applications.
<BR>
<P>The RPC protocol is used to send requests and replies. The format of the RPC protocol packet header is shown in Figure 12.3, with all fields coded in the External Data Representation (XDR) format (see the section titled "External Data Representation (XDR)" later today). The Transaction ID field is used to match requests and replies and is changed (usually incremented) by the client with each new request. The Direction Indicator field shows whether the message originated with the client (a value of 0) or with the server (a value of 1). The first Version Number is the version of RPC used and the second Version Number identifies the version of the program. The Program Number identifies the service (set of procedures) to use, as mentioned earlier. The Procedure Number identifies the particular procedure in the service.
<BR>
<P><B><A HREF="12tyt03.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/12tyt03.gif">Figure 12.3. The RPC protocol header.</A></B>
<BR>
<P>Some procedures might require a client to authenticate itself to the server, both for identification purposes and for security reasons. The RPC protocol header contains two fields for authentication. The Authorization Information field is for information itself, and the Authorization Verification field is used for the validation. The RPC RFC does not define how authentication is to be performed, leaving it up to the application developer, but it does specify two fields with a maximum size of 400 bytes each. There are currently four types of authentication predefined for use:
<BR>
<UL>
<LI><B>None:</B> No authentication is used. Both authentication fields have zero length.
<BR></LI>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -