tyt12fi.htm

一个学习tcp/ip协议的教程

<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.<BR><P>Some versions of UNIX use the share command to set up a directory for export. (SCO UNIX does not support the share command because the functions are duplicated in the /etc/exports file.) The syntax of the share command is as follows:<BR><BR><PRE>

<FONT COLOR=#000080>share -F nfs -o <I>options</I> -d <I>description</I> <I>path</I></FONT></PRE><P>The -F option indicates that the directory or files given in the path are to be set as NFS filesystems. The options following -o set the type of access in the same way as the SCO UNIX options for the /etc/exports file shown earlier. The -d option can be followed by a descriptive statement used by clients to describe the export filesystem. For example, to share the directory /usr/public as read-write (the default), you could issue this command:<BR><BR><PRE>

<FONT COLOR=#000080>share -F nfs -d &quot;Server public directory&quot; /usr/public</FONT></PRE><P>Options can be combined, as shown in this example:<BR><BR><PRE>

<FONT COLOR=#000080>share -F nfs -o ro=artemis,anon=200 -d &quot;Book material&quot; /usr/tparker/book</FONT></PRE><P>This command shares the directory /usr/tparker/book, which is tagged with the description &quot;Book material&quot;, with everyone as read-write except for a machine called artemis, for which it is read-only. Any anonymous users accessing the system use UID 200.<BR><P>The share command by itself usually shows a list of all filesystems that are exported.<BR><BR><A ID=E69E160 NAME=E69E160></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Setting Up a UNIX NFS Client</B></FONT></CENTER></H4><BR><P>UNIX can mount an NFS exported filesystem from another machine with the mount command. The syntax for mounting an NFS filesystem is as follows:<BR><BR><PRE>

<FONT COLOR=#000080>mount -F nfs -o <I>options</I> <I>machine:filesystem</I> <I>mount-point</I></FONT></PRE><P>The -F option tells the mount command the filesystem is an NFS filesystem; <I>machine:filesystem</I> is the name of the remote machine and the filesystem to be mounted; and <I>mount-point</I> is the location in the current filesystem where the remote filesystem is to be mounted. Some versions of UNIX change the syntax a little. For example, SCO UNIX uses a lower case f and uppercase NFS to indicate the type. Check the man pages for the exact syntax on your version.<BR><P>In use, mount is easy to work with. For example, the command<BR><BR><PRE>

<FONT COLOR=#000080>mount -F nfs artemis:usr/public /usr/artemis</FONT></PRE><P>mounts the filesystem /usr/public on the remote machine called artemis onto the local machine in the directory called /usr/artemis. The mount-point (in this case /usr/artemis) must exist for the mount to succeed.<BR><P>The -o optional component of the mount command can be used to set options from the following list:<BR><UL><UL><P>rw: Sets the mount to read-write (the default value)<BR></UL></UL><UL><UL><P>ro: Sets the mount to read-only<BR></UL></UL><UL><UL><P>timeo=x: Gives a timeout value in tenths of a second to attempt the mount before giving up<BR></UL></UL><UL><UL><P>retry=x: Retries x times before giving up<BR></UL></UL><UL><UL><P>soft: Forces the client to give up the mount attempt if an acknowledgment is not received from the remote machine<BR></UL></UL><UL><UL><P>hard: The client continues trying to mount the filesystem until successful<BR></UL></UL><BLOCKQUOTE><BLOCKQUOTE><P>intr: Enables the keyboard to interrupt the mount request; otherwise, the attempts go on forever<BR></BLOCKQUOTE></BLOCKQUOTE><P>Any of these options can be combined in one mount command, as they could be for the share command. For example, the command line<BR><BR><PRE>

<FONT COLOR=#000080>mount -F nfs -o soft,ro artemis:usr/public /usr/artemis</FONT></PRE><P>tries to mount the /usr/public directory on artemis as read-only, but it gives up if the mount attempt is not acknowledged by artemis. The mount command by itself usually shows all mounted filesystems.<BR><BR><A ID=E69E161 NAME=E69E161></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Setting Up Windows-Based NFS</B></FONT></CENTER></H4><BR><P>Several TCP/IP suites and application packages for Windows 3.<I>x</I>, Windows 95, and Windows NT provide NFS support. One of the widest used is NetManage's ChameleonNFS, which can be used under any of the Windows operating system versions. ChameleonNFS enables a Windows machine to act as both client and server for NFS file access. In other words, another machine can access files on the ChameleonNFS machine, and the ChameleonNFS machine can access files on other NFS-equipped machines.<BR><P>Implementing NFS access on a Windows machine can vary from very complex to very easy, depending on the software package that provides the NFS capabilities. Some available NFS products don't offer server capabilities, enabling only NFS client behavior on the installation machine. Carefully check the software before you purchase or install it to ensure you are getting a product that meets your NFS requirements. In this section I continue with ChameleonNFS as the example NFS software, because it is relatively easy to install, configure, and use. I use Windows 3.11 as the operating system example.<BR><P>ChameleonNFS relies on a software daemon called Portmapper, which maintains a list of all currently registered network services (including NFS). Portmapper is loaded automatically when the Windows machine boots in most installations. ChameleonNFS is set to record mounted drives to the WIN.INI file (for Windows 3.<I>x</I> at least) whenever a Windows session is saved. This enables currently mounted drives to be remounted automatically when the next Windows session is started.<BR><P>ChameleonNFS server activities such as administration and configuration are conducted through the NFS icon in the NetManage program group. The sole exception is printer handling for network devices, which is handled through the Printer icon on the Control Panel. NFS client activities are done through normal Windows applications, such as the File Manager and Control Panel. Drives are mounted and unmounted through the File Manager, whereas all other options are handled through the Network panel in the Control Panel.<BR><P>Once installed, ChameleonNFS lets you mount a remote directory on an NFS server from the File Manager. Select the Network Connections option from the Disk pull-down menu. This displays the Network Connections dialog shown in Figure 12.4. The remote machine name and the directory to be mounted are specified in this dialog. The mounted filesystem is usually mounted as another drive, not as part of an existing drive's filesystem.<BR><P><B><A HREF=12tyt04.gif>Figure 12.4. The Network Connections dialog lets </B><B>you mount a remote filesystem using NFS.</A></B><BR><P>If you want to see all the filesystems that are available for mounting on a remote machine, use the Browse button. The remote machine name and all the filesystems available are listed, as shown in Figure 12.5. In Figure 12.5 the only filesystem that is showing as available on the machine called tpci is the root filesystem, which means the entire filesystem on the remote. You can't tell from this window whether it is set for special access rights such as read-only.<BR><P><B><A HREF=12tyt05.gif>Figure 12.5. When you specify the host name in the </B><B>Browse dialog, all that remote's NFS filesystems are listed.</A></B><BR><P>Clicking the OK button after the remote machine name and directory name are filled in mounts the remote filesystem at the location you indicate in the window, as shown in Figure 12.6. This mounts the remote machine's root directory as drive H on the local machine. When you click OK to close the NFS dialog, the remote machine's filesystem is available from the File Manager. The drive icon shows that it is a network drive.<BR><P><B><A HREF=12tyt06.gif>Figure 12.6. This window shows that tpci's root </B><B>directory is to be mounted as drive H on the local machine.</A></B><BR><P>To disconnect an NFS-mounted drive, use the Disconnect button on the Network Connections dialog. The drive icon should be removed from the File Manager to show that the mount is no longer in effect.<BR><BR><A ID=E69E162 NAME=E69E162></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Sharing a Windows Directory</B></FONT></CENTER></H4><BR><P>ChameleonNFS can be used to share PC drives or directories with other users on the network. To share a drive, create a list of users who have access to the drive, unless everyone can mount the drives. The user access list is maintained under the NFS icon with ChameleonNFS. Start the NFS server process by clicking the NFS icon in the Chameleon program group. This displays the NFS main window. Clicking the Users menu item on the NFS window opens the Server Users window, shown in Figure 12.7. From here you can add and manage all access to your NFS available drives. To enter a user, type the name, any password you want them to use (if you want a password), and a group and user ID number. Click the Add button, and the entry appears as part of the user list.<BR><P><B><A HREF=12tyt07.gif>Figure 12.7. The Server Users window lets you set </B><B>access rights to your NFS drives.</A></B><BR><P>When you have entered all the users, click the Save button to write the entries to the disk. If you don't save the table, any changes are lost. Figure 12.8 shows two users on the access table.<BR><P><B><A HREF=12tyt08.gif>Figure 12.8. Two users are allowed to access the </B><B>local machine's NFS drives.</A></B><BR><P>Next, you need to set the drives and directories that can be exported by other clients. Use the Exports menu item in the NFS window to display the Server Exports window. Use the directory browser to move between the drives and directories, selecting the ones you want to export. Click the Add button to enter the drive and directory combination to the export list.<BR><P>Figure 12.9 shows the Server Exports window with two specific directories and one entire drive set to be exported. For each drive or directory you can set access rights by clicking the Access button. This displays the Access dialog, which you can use to select the proper permissions and access rights.<BR><P><B><A HREF=12tyt09.gif>Figure 12.9. The Server Exports window with </B><B>directories and drives defined for NFS access.</A></B><BR><P>Once the access permissions are set, a remote client can access your NFS drives. The remote user is prompted for a password if you have set your system to require one.<BR><BR><A ID=E68E111 NAME=E68E111></A><H3 ALIGN=CENTER><CENTER><FONT SIZE=5 COLOR=#FF0000><B>Network Information Service (NIS)</B></FONT></CENTER></H3><BR><P>The Yellow Pages (YP) protocol is an RPC application layer service (like NFS) that provides a versatile directory service. Because of copyright restrictions, Yellow Pages was renamed to Network Information Service (NIS), although both terms are in common use. NIS was developed for several reasons, but the one that affects users the most is access permissions. The effect these permissions have on users is generally transparent except for one major advantage.<BR><P>If you are a user on a large network and you tend to connect to other machines frequently (through Telnet or FTP, for example), you must maintain accounts on each machine you connect to. Thus, you would need user accounts on every machine you could conceivably want to access. Maintaining the passwords on a large number of machines is awkward, because you must log into each one and perform password changes. NIS was developed to enable one single, central user file to be shared over the network, requiring only a single entry to enable access to all machines (unless specific restrictions are imposed), and simplifying a password change on all machines to one step.<BR><P>In RPC terms, this combination of user ID and password works on the RPC authentication procedures. RPC uses the user and group IDs to grant access to files, so it is necessary for the client and server's user and group IDs to match. Without NIS this could be very difficult to implement because each machine's user file might have the same names, but their user IDs might not coincide. Worse, another user with a matching user ID on another machine could access files on your machine as though he or she were logged in as you.<BR><P>NIS is a distributed access system in that each machine on the network that uses NIS accesses a central server, called the <I>NIS master </I>or <I>ypmaster</I> (depending on the version), for access information. On larger networks, to spread the load, and for all networks as a backup contingency, several other machines are designated as <I>slaves</I> or <I>ypslaves </I>that maintain up-to-date access information. In case of a failure of the master server, a slave takes up the functions. NIS uses both TCP and UDP for communications.<BR><BLOCKQUOTE><BLOCKQUOTE><HR ALIGN=CENTER><BR><NOTE><IMG SRC=note.gif WIDTH = 75 HEIGHT = 46>There are two versions of NIS in general use. The first release (Version 1) had serious problems under certain circumstances, so Version 2 was quickly released. However, some systems still use the older version.</NOTE><BR><HR ALIGN=CENTER></BLOCKQUOTE></BLOCKQUOTE><P>The NIS protocol has a set of procedures defined within the RFC. These enable a search for master servers, access to the user files, and system management functions. Another procedure is used to transfer copies of the master files. Several machines are grouped together into one NFS subnetwork, called a <I>domain</I> (not to be confused with the Internet domain). Each domain has master and slave machines.<BR><P>NIS keeps the access information in a set of <I>maps,</I> each map corresponding to a particular area or domain of a network. This allows for several groups to use the same NIS master but have different access permissions. The NIS maps do not have to correspond to DNS domains, enabling more versatility in configuration. Maps consist of a set of records in ASCII format, each with an <I>index key </I>for fast lookup. The index key is usually the user name. The records have the same structure as normal user files (such as UNIX's /etc/passwd), both for compatibility and for simplicity.<BR><BLOCKQUOTE><BLOCKQUOTE><HR ALIGN=CENTER><BR><NOTE><IMG SRC=note.gif WIDTH = 75 HEIGHT = 46>The use of NIS does not negate the need for a complete set of access files on each machine, because NIS is loaded after the machine has been booted (and these files are read). The stand-alone files should have access for a system administrator at least, although it is good practice to also include the most frequent users in case of a network crash preventing access to the NIS directories.</NOTE><BR><HR ALIGN=CENTER></BLOCKQUOTE></BLOCKQUOTE><P>NIS is not restricted to the users of a system. Any file can be set up to use NIS, such as the list of machines on a network (UNIX's /etc/hosts file). Thus, only one change needs to be made to these files on any network. A set of aliases also can be managed by NIS.<BR><P>Several NIS-specific commands are involved with the protocol, although most system administrators set up aliases to minimize the impact on users. For most users, only one command is necessary on a regular basis. For UNIX systems, this is the command yppasswd to change a user's password. This is usually aliased to passwd, the normal password change command. Application developers might have to examine the NIS protocol in more detail when writing client/server code that runs on an NIS-based system, but the effects of the distributed system are usually transparent.<BR><BR><A ID=E68E112 NAME=E68E112></A><H3 ALIGN=CENTER><CENTER><FONT SIZE=5 COLOR=#FF0000><B>Configuring NIS</B></FONT></CENTER></H3><BR><P>Earlier today you saw how NIS can be used to provide network-wide access to files that would normally be local, offering greatly improved access for users and administrators. With NIS active, you don't need to maintain a separate current /etc/passwd file on each UNIX system; instead, you can use the NIS master password files to enable global access to any machine on the network.<BR><P>In this section I look at how to set up NIS on a simple UNIX network. There are many variations of network architecture and configurations, some of which get awfully complex for a network administrator. Although the principles of setting up NIS and NIS domains are the same for all networks, some extra steps are required on very complex setups. For the most part, I look at the basics only. The files that are normally handled by NIS are as follows:<BR><BR><CENTER><TABLE BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 CELLPADDING=3><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>/etc/ethers<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Ethernet MAC to IP address mappings<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>/etc/group<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Group access information<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>/etc/hosts<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>IP address to hostname mappings<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>/etc/netmasks<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>IP network masks<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>/etc/passwd<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>User access information<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>/etc/protocols<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Network protocol and number mappings<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>/etc/rpc<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>RPC numbers<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>/etc/services<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Port number to TCP/IP protocol mappings</FONT></TABLE></CENTER><BR><P>I look at the most commonly used files as I set up the NIS master and NIS slave, as well as looking at what has to be changed on any client machines that want to use NIS.<BR><BR><A ID=E69E163 NAME=E69E163></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Setting Up the NIS Domain</B></FONT></CENTER></H4><BR><P>NIS domains are usually assigned to group machines together with an NIS master and one or more NIS slaves as backup. An NIS domain doesn't have to be the same as an Internet domain, although for most networks they are identical (in other words, the entire network is the NIS domain). The NIS domain has to have a name, which can also correspond with your Internet domain name. Alternatively, you can set up subsidiary domains for small logical groups in a large corporation, such as domains for accounting, research and development, and marketing.<BR><P>To set up an NIS domain, you need to decide on the domain name and know the IP address of the NIS master and any NIS slaves. If you have more than one NIS domain established, you need to know which machines are handled by which NIS master. Each machine on the domain (whether one or many domains are established) must be entered into a configuration file to enable the client machine to use NIS.<BR><P>To set up the NIS domain, you need to log into each client machine on the network and set up the domain name with the following command:<BR><BR><PRE>

<FONT COLOR=#000080><I>domainname</I> <I>domain</I></FONT></PRE><P><I>domain</I> is the domain name the machine uses. You need to be logged in as root or an administrative account with access to the root utilities to set these values. Because this type of command is effective only until the machine is rebooted, it is better to enter the domain name in one of the startup rc scripts. These differ for each version of UNIX, so you should check your rc commands to find out where to embed the domain name. Usually it is in a file under the /etc/rc.d directory.<BR><BR><A ID=E69E164 NAME=E69E164></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>NIS Daemons</B></FONT></CENTER></H4><BR><P>NIS uses several daemons on the server and on all clients to enable the NIS system. On the NIS master and any NIS slaves, the daemon is usually called ypserv. The ypserv daemon waits for incoming client requests for service, then handles them.<BR><P>On the clients, the process ypbind is used. This is responsible for connecting with the NIS master when the machine boots and determining any resolution steps necessary to handle logins and other network configuration information handled by NIS. The process of having ypbind connect to the NIS master and establish procedures is called a binding, because the client is bound to the master for requests.<BR><P>The binding process begins with ypbind sending out a broadcast message for any NIS masters on the network to respond with their IP address and the port number to send requests on. If more than one NIS master responds to the request, only the first received reply is used. If for some reason ypbind finds it isn't getting replies from the NIS master, it assumes that the master has crashed and retransmits a request for a master.<BR><P>You can find out which NIS master any client machine is bound to with the command ypwhich. It usually responds with the name of the NIS master, as shown here:<BR><PRE>

<FONT COLOR=#000080>$ ypwhich

merlin</FONT></PRE><BR><A ID=E69E165 NAME=E69E165></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Setting Up an NIS Master</B></FONT></CENTER></H4><BR><P>Setting up an NIS master is usually straightforward. Begin by verifying the existing files on the master machine, such as /etc/passwd and /etc/group, to ensure that the information is accurate and current. You should remove any expired or unwanted accounts, for example, and verify that all the login directories and commands are correct. While you are examining the /etc/passwd file, check to make sure that all accounts have passwords. I