svn commit: r42970 - head/en_US.ISO8859-1/books/handbook/network-servers
Dru Lavigne
dru at FreeBSD.org
Tue Oct 15 22:03:05 UTC 2013
Author: dru
Date: Tue Oct 15 22:03:04 2013
New Revision: 42970
URL: http://svnweb.freebsd.org/changeset/doc/42970
Log:
This patch provides general tightening and clarification of the sections NIS Slave Servers through NIS Security.
Modified:
head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Tue Oct 15 21:03:04 2013 (r42969)
+++ head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Tue Oct 15 22:03:04 2013 (r42970)
@@ -1517,14 +1517,16 @@ ellington has been setup as an YP master
<primary>NIS</primary>
<secondary>slave server</secondary>
</indexterm>
- <para>Setting up an <acronym>NIS</acronym> slave server is
- simpler than setting up the master. Log on to
+ <para>To set up an <acronym>NIS</acronym> slave server, log on to
the slave server and edit
- <filename>/etc/rc.conf</filename> as before. This
- time, include
- <option>-s</option> when running
- <command>ypinit</command>. This option
- requires the name of the <acronym>NIS</acronym> master, as
+ <filename>/etc/rc.conf</filename> as for the master server.
+ Do not generate any <acronym>NIS</acronym> maps, as these
+ already exist on the master server. When running
+ <command>ypinit</command> on the slave server, use
+ <option>-s</option> (for slave) instead of
+ <option>-m</option> (for master). This option
+ requires the name of the <acronym>NIS</acronym> master in
+ addition to the domain name, as
seen in this example:</para>
<screen>coltrane&prompt.root; <userinput>ypinit -s ellington test-domain</userinput>
@@ -1584,56 +1586,51 @@ ypxfr: Exiting: Map successfully transfe
coltrane has been setup as an YP slave server without any errors.
Remember to update map ypservers on ellington.</screen>
- <para>There should be a directory called
- <filename>/var/yp/test-domain</filename>. Copies of the
- <acronym>NIS</acronym> master server's maps should be in
- this directory. These files must always be up to date.
- The following <filename>/etc/crontab</filename> entries on
- the slave servers should do the job:</para>
+ <para>This will generate a directory on the slave server called
+ <filename class="directory">/var/yp/test-domain</filename> which contains copies of the
+ <acronym>NIS</acronym> master server's maps.
+ Adding these <filename>/etc/crontab</filename> entries on each
+ slave server will force the slaves to sync their maps with
+ the maps on the master server:</para>
<programlisting>20 * * * * root /usr/libexec/ypxfr passwd.byname
21 * * * * root /usr/libexec/ypxfr passwd.byuid</programlisting>
- <para>These two lines force the slave to sync its maps with
- the maps on the master server. These entries are not
+ <para>These entries are not
mandatory because the master server automatically attempts
- to push any map changes to its slaves; however, due to
- the importance of correct password information on other
- clients depending on the slave server, it is recommended
- to specifically force the password map updates frequently.
+ to push any map changes to its slaves. However, since clients may
+ depend upon the slave server to provide correct password information,
+ it is recommended
+ to force frequent password map updates.
This is especially important on busy networks where map
updates might not always complete.</para>
- <para>Now, run the command <command>/etc/netstart</command>
- on the slave server as well, which again starts the NIS
- server.</para>
+ <para>To finish the configuration, run <command>/etc/netstart</command>
+ on the slave server in order to start the <acronym>NIS</acronym>
+ services.</para>
</sect2>
<sect2>
- <title>Setting Up a <acronym>NIS</acronym> Client</title>
+ <title>Setting Up an <acronym>NIS</acronym> Client</title>
- <para>An <acronym>NIS</acronym> client establishes what is
- called a binding to a particular <acronym>NIS</acronym>
- server using the <command>ypbind</command> daemon. The
- <command>ypbind</command> command checks the system's
- default domain (as set by the
- <command>domainname</command> command), and begins
- broadcasting RPC requests on the local network. These
- requests specify the name of the domain for which
- <command>ypbind</command> is attempting to establish a
- binding. If a server that has been configured to serve the
- requested domain receives one of the broadcasts, it will
- respond to <command>ypbind</command>, which will record the
- server's address. If there are several servers available (a
- master and several slaves, for example),
- <command>ypbind</command> will use the address of the first
- one to respond. From that point on, the client system will
+ <para>An <acronym>NIS</acronym> client binds
+ to an <acronym>NIS</acronym>
+ server using &man.ypbind.8;. This
+ daemon
+ broadcasts RPC requests on the local network. These
+ requests specify the domain name configured on the client.
+ If an <acronym>NIS</acronym> server in the same domain
+ receives one of the broadcasts, it will
+ respond to <application>ypbind</application>, which will record the
+ server's address. If there are several servers available,
+ the client will use the address of the first
+ server to respond and will
direct all of its <acronym>NIS</acronym> requests to that
- server. <command>ypbind</command> will occasionally
- <quote>ping</quote> the server to make sure it is still up
- and running. If it fails to receive a reply to one of its
- pings within a reasonable amount of time,
- <command>ypbind</command> will mark the domain as unbound
+ server. The client will automatically
+ <application>ping</application> the server on a regular basis to make sure it is still
+ available. If it fails to receive a reply
+ within a reasonable amount of time,
+ <application>ypbind</application> will mark the domain as unbound
and begin broadcasting again in the hopes of locating
another server.</para>
@@ -1641,16 +1638,15 @@ Remember to update map ypservers on elli
<secondary>client configuration</secondary>
</indexterm>
- <para>Setting up a &os; machine to be a
- <acronym>NIS</acronym> client is fairly
- straightforward.</para>
+ <para>To configure a &os; machine to be an
+ <acronym>NIS</acronym> client:</para>
<procedure>
<step>
<para>Edit <filename>/etc/rc.conf</filename> and add the
following lines in order to set the
<acronym>NIS</acronym> domain name and start
- <command>ypbind</command> during network
+ &man.ypbind.8; during network
startup:</para>
<programlisting>nisdomainname="test-domain"
@@ -1659,40 +1655,34 @@ nis_client_enable="YES"</programlisting>
<step>
<para>To import all possible password entries from the
- <acronym>NIS</acronym> server, remove all user
- accounts from the
- <filename>/etc/master.passwd</filename> file and use
- <command>vipw</command> to add the following line to
+ <acronym>NIS</acronym> server, use
+ <command>vipw</command> to remove all user
+ accounts except one from
+ <filename>/etc/master.passwd</filename>. When removing
+ the accounts, keep in mind that at least one local account
+ should remain and this
+ account should be a member of
+ <groupname>wheel</groupname>. If there is a problem
+ with <acronym>NIS</acronym>, this local account can be used to log in
+ remotely, become the superuser, and fix
+ the problem. Before saving the edits, add the following line to
the end of the file:</para>
<programlisting>+:::::::::</programlisting>
- <note>
- <para>This line will afford anyone with a valid
+ <para>This line configures the client to provide anyone with a valid
account in the <acronym>NIS</acronym> server's
- password maps an account. There are many ways to
- configure the NIS
- client by changing this line. See the
- <link linkend="network-netgroups">netgroups
- section</link> below for more information. For
- more detailed reading see O'Reilly's book on
- <literal>Managing NFS and NIS</literal>.</para>
- </note>
-
- <note>
- <para>Keep in mind that at least one local account
- (i.e. not imported via NIS) must exist in
- <filename>/etc/master.passwd</filename> and this
- account should also be a member of the group
- <groupname>wheel</groupname>. If there is something
- wrong with NIS, this account can be used to log in
- remotely, become <username>root</username>, and fix
- things.</para>
- </note>
+ password maps an account on the client. There are many ways to
+ configure the <acronym>NIS</acronym>
+ client by modifying this line. One method is described in
+ <xref linkend="network-netgroups"/>. For
+ more detailed reading, refer to the book
+ <literal>Managing NFS and NIS</literal>, published by
+ O'Reilly Media.</para>
</step>
<step>
- <para>To import all possible group entries from the NIS
+ <para>To import all possible group entries from the <acronym>NIS</acronym>
server, add this line to
<filename>/etc/group</filename>:</para>
@@ -1707,32 +1697,27 @@ nis_client_enable="YES"</programlisting>
<screen>&prompt.root; <userinput>/etc/netstart</userinput>
&prompt.root; <userinput>service ypbind start</userinput></screen>
- <para>After completing these steps, the command,
- <command>ypcat passwd</command>, should show the
- server's passwd map.</para>
+ <para>After completing these steps, running
+ <command>ypcat passwd</command> on the client should show the
+ server's <filename>passwd</filename> map.</para>
</sect2>
<sect2>
<title><acronym>NIS</acronym> Security</title>
- <para>In general, any remote user may issue an RPC to
- &man.ypserv.8; and retrieve the contents of the
- <acronym>NIS</acronym> maps, provided the remote user knows
- the domain name. To prevent such unauthorized transactions,
+ <para>Since <acronym>RPC</acronym> is a broadcast-based service,
+ any system running <application>ypbind</application> within the same domain
+ can retrieve the contents of the
+ <acronym>NIS</acronym> maps. To prevent unauthorized transactions,
&man.ypserv.8; supports a feature called
<quote>securenets</quote> which can be used to restrict access
- to a given set of hosts. At startup, &man.ypserv.8; will
- attempt to load the securenets information from a file called
- <filename>/var/yp/securenets</filename>.</para>
-
- <note>
- <para>This path varies depending on the path specified with
- the <option>-p</option> option. This file contains entries
- that consist of a network specification and a network mask
- separated by white space. Lines starting with
- <quote>#</quote> are considered to be comments. A sample
- securenets file might look like this:</para>
- </note>
+ to a given set of hosts. By default, this information is stored in
+ <filename>/var/yp/securenets</filename>, unless &man.ypserv.8; is started with
+ <option>-p</option> and an alternate path. This file contains entries
+ that consist of a network specification and a network mask
+ separated by white space. Lines starting with
+ <literal>#</literal> are considered to be comments. A sample
+ <filename>securenets</filename> might look like this:</para>
<programlisting># allow connections from local host -- mandatory
127.0.0.1 255.255.255.255
@@ -1748,89 +1733,64 @@ nis_client_enable="YES"</programlisting>
matches one of these rules, it will process the request
normally. If the address fails to match a rule, the request
will be ignored and a warning message will be logged. If the
- <filename>/var/yp/securenets</filename> file does not exist,
+ <filename>securenets</filename> does not exist,
<command>ypserv</command> will allow connections from any
host.</para>
- <para>The <command>ypserv</command> program also has support for
- Wietse Venema's <application>TCP Wrapper</application>
- package. This allows the administrator to use the
- <application>TCP Wrapper</application> configuration files for
+ <para><xref linkend="tcpwrappers"/> is
+ an alternate mechanism for providing
access control instead of
- <filename>/var/yp/securenets</filename>.</para>
-
- <note>
- <para>While both of these access control mechanisms provide
- some security, they, like the privileged port test, are
+ <filename>securenets</filename>. While either access control mechanism adds
+ some security, they are both
vulnerable to <quote>IP spoofing</quote> attacks. All
- NIS-related traffic should be blocked at the
+ <acronym>NIS</acronym>-related traffic should be blocked at the
firewall.</para>
- <para>Servers using <filename>/var/yp/securenets</filename>
+ <para>Servers using <filename>securenets</filename>
may fail to serve legitimate <acronym>NIS</acronym> clients
with archaic TCP/IP implementations. Some of these
implementations set all host bits to zero when doing
- broadcasts and/or fail to observe the subnet mask when
+ broadcasts or fail to observe the subnet mask when
calculating the broadcast address. While some of these
problems can be fixed by changing the client configuration,
- other problems may force the retirement of the client
- systems in question or the abandonment of
- <filename>/var/yp/securenets</filename>.</para>
-
- <para>Using <filename>/var/yp/securenets</filename> on a
- server with such an archaic implementation of TCP/IP is a
- really bad idea and will lead to loss of
- <acronym>NIS</acronym> functionality for large parts of the
- network.</para>
+ other problems may force the retirement of these client
+ systems or the abandonment of
+ <filename>securenets</filename>.</para>
- <indexterm><primary>TCP Wrappers</primary></indexterm>
+ <indexterm><primary>TCP Wrapper</primary></indexterm>
<para>The use of <application>TCP Wrapper</application>
increases the latency of the <acronym>NIS</acronym> server.
The additional delay may be long enough to cause timeouts in
- client programs, especially in busy networks or with slow
- NIS servers. If one or more of the client systems suffers
- from these symptoms, convert the client systems in question
+ client programs, especially in busy networks with slow
+ <acronym>NIS</acronym> servers. If one or more clients suffer
+ from latency, convert those clients
into <acronym>NIS</acronym> slave servers and force them to
bind to themselves.</para>
- </note>
- </sect2>
- <sect2>
- <title>Barring Some Users from Logging On</title>
+ <sect3>
+ <title>Barring Some Users</title>
- <para>In our lab, there is a machine <hostid>basie</hostid> that
- is supposed to be a faculty only workstation. We do not want
- to take this machine out of the <acronym>NIS</acronym> domain,
- yet the <filename>passwd</filename> file on the master
+ <para>In this example, the <hostid>basie</hostid> system
+ is a faculty workstation within the <acronym>NIS</acronym> domain.
+ The <filename>passwd</filename> map on the master
<acronym>NIS</acronym> server contains accounts for both
- faculty and students. What can we
- do?</para>
+ faculty and students. This section demonstrates how to allow
+ faculty logins on this system while refusing student logins.</para>
- <para>There is a way to bar specific users from logging on to a
- machine, even if they are present in the
- <acronym>NIS</acronym> database. To do this, add
+ <para>To prevent specified users from logging on to a
+ system, even if they are present in the
+ <acronym>NIS</acronym> database, use <command>vipw</command> to add
<literal>-<replaceable>username</replaceable></literal> with
- the correct number of colons like other entries to the end of
- the <filename>/etc/master.passwd</filename> file on the client
- machine, where <replaceable>username</replaceable> is the
- username of the user to bar from logging in. The line with
+ the correct number of colons towards the end of
+ <filename>/etc/master.passwd</filename> on the client,
+ where <replaceable>username</replaceable> is the
+ username of a user to bar from logging in. The line with
the blocked user must be before the <literal>+</literal> line
- for allowing <acronym>NIS</acronym> users. This should
- preferably be done using
- <command>vipw</command>, since <command>vipw</command> will
- sanity check the changes to
- <filename>/etc/master.passwd</filename>, as well as
- automatically rebuild the password database after editing.
- For example, to bar user <username>bill</username> from
+ that allows <acronym>NIS</acronym> users.
+ In this example, <username>bill</username> is barred from
logging on to <hostid>basie</hostid>:</para>
- <screen>basie&prompt.root; <userinput>vipw</userinput>
-<userinput>[add -bill::::::::: to the end, exit]</userinput>
-vipw: rebuilding the database...
-vipw: done
-
-basie&prompt.root; <userinput>cat /etc/master.passwd</userinput>
-
+ <screen>basie&prompt.root; <userinput>cat /etc/master.passwd</userinput>
root:[password]:0:0::0:0:The super-user:/root:/bin/csh
toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh
daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin
@@ -1850,6 +1810,7 @@ nobody:*:65534:65534::0:0:Unprivileged u
+:::::::::
basie&prompt.root;</screen>
+ </sect3>
</sect2>
<sect2 id="network-netgroups">
More information about the svn-doc-all
mailing list