0278-0280.html
来自「linux-unix130.linux.and.unix.ebooks130 l」· HTML 代码 · 共 356 行
HTML
356 行
<HTML>
<HEAD>
<TITLE>Developer.com - Online Reference Library - 0672311739:RED HAT LINUX 2ND EDITION:TCP/IP Network Management</TITLE>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<SCRIPT>
<!--
function displayWindow(url, width, height) {
var Win = window.open(url,"displayWindow",'width=' + width +
',height=' + height + ',resizable=1,scrollbars=yes');
}
//-->
</SCRIPT>
</HEAD>
-->
<!-- ISBN=0672311739 //-->
<!-- TITLE=RED HAT LINUX 2ND EDITION //-->
<!-- AUTHOR=DAVID PITTS ET AL //-->
<!-- PUBLISHER=MACMILLAN //-->
<!-- IMPRINT=SAMS PUBLISHING //-->
<!-- PUBLICATION DATE=1998 //-->
<!-- CHAPTER=13 //-->
<!-- PAGES=0243-0298 //-->
<!-- UNASSIGNED1 //-->
<!-- UNASSIGNED2 //-->
<P><CENTER>
<a href="0275-0277.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0281-0283.html">Next</A>
</CENTER></P>
<A NAME="PAGENUM-278"><P>Page 278</P></A>
<!-- CODE //-->
<PRE>
denon.domain.com's NIS database has been set up.
If there were warnings, please figure out what went wrong, and fix it.
At this point, make sure that /etc/passwd and /etc/group have
been edited so that when the NIS is activated, the databases you
have just created will be used, instead of the /etc ASCII files.
</PRE>
<!-- END CODE //-->
<P>Don't worry about the Trying ypxfrd...not
running message. This happens because you haven't set the NIS master server to run the YP map transfer daemon
rpc.ypxfrd. In fact, you never set it up to do so—instead use a server push method where the NIS master server
pushes the maps to all the NIS slaves whenever there is an update.
</P>
<P>In order to set the NIS master to do the actual push, you need to change its
Makefile a little. On the master server, edit the
Makefile so that the line NOPUSH="True" is changed to
read #NOPUSH="True" and the line that reads
DOMAIN = `basename \'pwd\'' is changed to DOMAIN=
'/bin/domainname'.
</P>
<P>Now for the big test. On the NIS master server, run
cd /var/yp;make all to force all the maps to be rebuilt and pushed. The output should look something like the following:
</P>
<!-- CODE //-->
<PRE>
Updating passwd.byname....
Pushed passwd.byname map.
Updating passwd.byuid...
Pushed passwd.byuid map.
Updating hosts.byname...
Pushed hosts.byname.
Updating hosts.byaddr...
Pushed hosts.byaddr.
[etc...]
</PRE>
<!-- END CODE //-->
<P>On the NIS slave server, change the
/etc/yp.conf file so that the ypserver is set to point to
the slave server. Try running the command ypcat
passwd and see if your NIS password file is displayed. If so, you're set! The NIS slave server is configured.
</P>
<P>If you're having problems, go back and trace through your steps. Also, be sure to reboot
the machine and see if your NIS slave server still works correctly. If it doesn't come back up,
be sure that the changes you made to the boot sequence when installing
ypserv were correct.
</P>
<CENTER>
<TABLE BGCOLOR="#FFFF99">
<TR><TD><B>
TIP
</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
If your NIS client or slave server seems to have a hard time finding other hosts on
the network, be sure that the /etc/nsswitch.conf file is set to resolve hosts by file before
NIS. Then be sure that all the important hosts needed for the NIS servers to set themselves up
are in their own local /etc/hosts file.
</BLOCKQUOTE></TD></TR>
</TABLE></CENTER>
<BR>
<H4>
Using NIS-isms in Your /etc/passwd File
</H4>
<P>The most popular use of NIS is to keep a global user database so that it is possible to
grant access to any machine at your site to any user. Under Red Hat Linux, this behavior is
implicit for all NIS clients.
</P>
<A NAME="PAGENUM-279"><P>Page 279</P></A>
<P>There are times, however, when you do not want everyone accessing certain systems, such
as those used by personnel. This can be fixed by using the special token
+ in your /etc/passwd file. By default, NIS clients have the line
+:::::: at the end of their /etc/passwd file,
thereby allowing everyone in NIS to log in to the system. In order to change this so that the host
remains an NIS client but does not grant everyone permission, the line
+::::::/bin/false should be explicitly added to the end of your
/etc/passwd file. This will allow only people with
actual entries in the /etc/passwd file for that host (for example, root) to log in.
</P>
<P>In order to allow a specific person to log in to a host, you can add a line
to the /etc/passwd file granting this access. The format of the line is
+username:::::: where username is the login of the user you want to grant access to. NIS will automatically grab the user's
passwd entry from the NIS server and use the correct information for determining the user information (for
example, UID, GID, GECOS, and so on). You can override particular fields by inserting
the new value in the +username:::::: entry. For example, if the user
sshah uses /usr/local/bin/tcsh as his shell, but the host he needs to log in to keeps it in
/bin/tcsh, his /etc/passwd entry can be set to
+sshah::::::/bin/tcsh.
</P>
<H4><A NAME="ch13_ 37">
Using Netgroups
</A></H4>
<P>Netgroups are a great way to group people and machines into nice neat names for access
control. A good example of this is for a site where users are not allowed to log in to server
machines. A netgroup for the system administrators can be created and those in the group let
in through a special entry in the /etc/passwd file.
</P>
<P>Netgroup information is kept in the
/etc/netgroup file and shared via NIS.
</P>
<P>The format of a netgroups file is
</P>
<!-- CODE SNIP //-->
<PRE>
groupname member-list
</PRE>
<!-- END CODE SNIP //-->
<P>where groupname is the name of the group being defined and the
member-list is comprised of other group names or tuples of specific data. Each entry in the
member-list is separated by a whitespace.
</P>
<P>A tuple containing specific data comes in the form</P>
<!-- CODE SNIP //-->
<PRE>
(hostname, username, domain name)
</PRE>
<!-- END CODE SNIP //-->
<P>where hostname is the name of the machine for which that entry is valid,
username is the login of the person being referenced, and
domain name is the NIS domain name. Any entry left
blank is considered a wildcard; for example,
(technics,,,) implies everybody on the host
technics. An entry with a dash in it (-) means that there are no valid values for that entry. For
example, (-,sshah,) implies the user sshah and nothing else. This is useful for generating
a list of users or machine names for use in other netgroups.
</P>
<P>In files where netgroups are supported (such as
/etc/passwd), they are referenced by placing an @ sign in front of them.
So if you wanted to allow the netgroup sysadmins consisting of
(-,sshah,) (-,heidis,) permission to log in to a server, you would add the line
</P>
<A NAME="PAGENUM-280"><P>Page 280</P></A>
<!-- CODE SNIP //-->
<PRE>
+@sysadmins
</PRE>
<!-- END CODE SNIP //-->
<P>to your /etc/passwd file.</P>
<P>An example of a full netgroups file is as follows:</P>
<!-- CODE //-->
<PRE>
sysadmins (-,sshah,) (-,heidis)
servers (numark,-,) (vestax,-,)
clients (denon,-,) (technics,-,) (mtx,-,)
research-1 (-,boson,) (-,jyom,) (-,weals,) (-,dave,)
research-2 (-,scora,) (-,dan,) (-,david,) (-,barth,)
consultants (-,arturo,)
allusers sysadmins research-1 research-2 consultants
allhosts servers clients
</PRE>
<!-- END CODE //-->
<H3><A NAME="ch13_ 38">
The Network File System
</A></H3>
<P>The Network File System, or NFS, is the means by which UNIX systems share their disk
resources with one another. By abstracting the details of the filesystem to this level, it is
possible for other systems (both UNIX and non-UNIX alike) to follow the NFS protocol and
share disks across one another.
</P>
<P>The success of NFS is due to a number of its key features, the first and foremost being that
its specifications have been made publicly available from Sun Microsystems from its initial
development onward. At the same time, Sun began shipping all of its workstations with this
capability. During the '80s and early '90s, the Sun UNIX (SunOS and later Solaris) made
heavy use of the protocol and many other UNIX vendors followed suit. Linux supported NFS
before even version 1.0 was released.
</P>
<P>Another key feature is NFS's robust nature. It is a
stateless protocol meaning that each request made between the client and server is complete in itself and does not require knowledge
of prior transactions. Because of this, NFS cannot tell the difference between a very slow host
and a host that has failed altogether. This allows for servers to go down and come back up
without having to reboot the clients.
</P>
<CENTER>
<TABLE BGCOLOR="#FFFF99">
<TR><TD><B>
NOTE
</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
NFS works by using a protocol called remote procedure
calls, or RPC for short. RPCs are a well-defined protocol for allowing two hosts to communicate with each other. In order
for RPC to work, however, a central registry for all the RPC programs running on a
system needs to be established. This registry then listens for RPC calls over the network and
relays them to the appropriate program. Under Linux, this registry is called
rpc.portmapper and is discussed in the next section, "Installing NFS."<BR>
</BLOCKQUOTE></TD></TR>
</TABLE></CENTER>
<BR>
<P><CENTER>
<a href="0275-0277.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0281-0283.html">Next</A>
</CENTER></P>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?