svn commit: r42965 - head/en_US.ISO8859-1/books/handbook/network-servers
Dru Lavigne
dru at FreeBSD.org
Tue Oct 15 14:44:56 UTC 2013
Author: dru
Date: Tue Oct 15 14:44:55 2013
New Revision: 42965
URL: http://svnweb.freebsd.org/changeset/doc/42965
Log:
This is a very large chapter that needs a lot of work, many more patches to come.
This patch does the following to mostly the NIS section:
- comments out authors
- fixes some (not all) acronym tags and &os; entities
- tightens up some headings
- some word-smithing to make things clearer
- adds title to Table
This will be followed by a white-space fix, then more content patches to be followed by a more thorough technical review.
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 13:08:26 2013 (r42964)
+++ head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Tue Oct 15 14:44:55 2013 (r42965)
@@ -6,16 +6,17 @@
-->
<chapter id="network-servers">
+ <!--
<chapterinfo>
<authorgroup>
<author>
<firstname>Murray</firstname>
<surname>Stokely</surname>
- <contrib>Reorganized by </contrib>
+ <contrib>Reorganized by in July 2004</contrib>
</author>
</authorgroup>
- <!-- 23 July 2004 -->
</chapterinfo>
+ -->
<title>Network Servers</title>
@@ -113,6 +114,7 @@
</sect1>
<sect1 id="network-inetd">
+ <!--
<sect1info>
<authorgroup>
<author>
@@ -128,6 +130,7 @@
</author>
</authorgroup>
</sect1info>
+ -->
<title>The <application>inetd</application>
<quote>Super-Server</quote></title>
@@ -539,6 +542,7 @@ server-program-arguments</programlisting
</sect1>
<sect1 id="network-nfs">
+ <!--
<sect1info>
<authorgroup>
<author>
@@ -555,6 +559,7 @@ server-program-arguments</programlisting
</author>
</authorgroup>
</sect1info>
+ -->
<title>Network File System (NFS)</title>
<indexterm><primary>NFS</primary></indexterm>
@@ -595,9 +600,6 @@ server-program-arguments</programlisting
</listitem>
</itemizedlist>
- <sect2>
- <title>How <acronym>NFS</acronym> Works</title>
-
<para><acronym>NFS</acronym> consists of at least two main
parts: a server and one or more clients. The client remotely
accesses the data that is stored on the server machine. In
@@ -663,7 +665,6 @@ server-program-arguments</programlisting
<para>Running &man.nfsiod.8; can improve performance on the
client, but is not required.</para>
- </sect2>
<sect2 id="network-configuring-nfs">
<title>Configuring <acronym>NFS</acronym></title>
@@ -910,6 +911,7 @@ rpc_statd_enable="YES"</programlisting>
</sect2>
<sect2 id="network-amd">
+ <!--
<sect2info>
<authorgroup>
<author>
@@ -926,6 +928,7 @@ rpc_statd_enable="YES"</programlisting>
</author>
</authorgroup>
</sect2info>
+ -->
<title>Automatic Mounts with
<application>amd</application></title>
@@ -1012,6 +1015,7 @@ Exports list on foobar:
</sect1>
<sect1 id="network-nis">
+ <!--
<sect1info>
<authorgroup>
<author>
@@ -1032,11 +1036,8 @@ Exports list on foobar:
</author>
</authorgroup>
</sect1info>
+ -->
<title>Network Information System (NIS/YP)</title>
-
- <sect2>
- <title>What Is It?</title>
-
<indexterm><primary>NIS</primary></indexterm>
<indexterm><primary>Solaris</primary></indexterm>
<indexterm><primary>HP-UX</primary></indexterm>
@@ -1044,52 +1045,39 @@ Exports list on foobar:
<indexterm><primary>Linux</primary></indexterm>
<indexterm><primary>NetBSD</primary></indexterm>
<indexterm><primary>OpenBSD</primary></indexterm>
-
- <para><acronym role="Network Information System">NIS</acronym>,
- which stands for Network Information Services, was developed
- by Sun Microsystems to centralize administration of &unix;
- (originally &sunos;) systems. It has now essentially become
- an industry standard; all major &unix; like systems
- (&solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD, FreeBSD,
- etc) support <acronym
- role="Network Information System">NIS</acronym>.</para>
-
<indexterm>
<primary>yellow pages</primary>
<see>NIS</see>
</indexterm>
- <para><acronym role="Network Information System">NIS</acronym>
- was formerly known as Yellow Pages, but because of trademark
- issues, Sun changed the name. The old term (and yp) is still
- often seen and used.</para>
+ <para>Network Information System (<acronym>NIS</acronym>)
+ is designed
+ to centralize administration of &unix;-like
+ systems such as
+ &solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD, and &os;.
+ <acronym>NIS</acronym>
+ was originally known as Yellow Pages but the name was changed due to trademark
+ issues. This is the reason why <acronym>NIS</acronym>
+ commands begin with <literal>yp</literal>.</para>
<indexterm>
<primary>NIS</primary>
<secondary>domains</secondary>
</indexterm>
- <para>It is a RPC-based client/server system that allows a group
- of machines within an NIS domain to share a common set of
+ <para><acronym>NIS</acronym> is a Remote Procedure Call
+ (<acronym>RPC</acronym>)-based client/server system that allows a group
+ of machines within an <acronym>NIS</acronym> domain to share a common set of
configuration files. This permits a system administrator to
- set up NIS client systems with only minimal configuration data
+ set up <acronym>NIS</acronym> client systems with only minimal configuration data
and add, remove or modify configuration data from a single
location.</para>
- <indexterm><primary>Windows NT</primary></indexterm>
-
- <para>It is similar to the &windowsnt; domain system; although
- the internal implementation of the two are not at all similar,
- the basic functionality can be compared.</para>
- </sect2>
-
<sect2>
- <title><acronym>NIS</acronym>Terms and Processes</title>
+ <title><acronym>NIS</acronym> Terms and Processes</title>
- <para>There are several terms and important user processes that
- will be explained while attempting to implement NIS on
- FreeBSD, regardless if the system is a NIS server or a NIS
- client:</para>
+ <para>Table 28.1 summarizes the terms and important processes used
+ by <acronym>NIS</acronym>:</para>
<indexterm>
<primary><application>rpcbind</application></primary>
@@ -1098,7 +1086,8 @@ Exports list on foobar:
<primary><application>portmap</application></primary>
</indexterm>
- <informaltable frame="none" pgwide="1">
+ <table frame="none" pgwide="1">
+ <title><acronym>NIS</acronym> Terminology</title>
<tgroup cols="2">
<colspec colwidth="1*"/>
<colspec colwidth="3*"/>
@@ -1112,163 +1101,141 @@ Exports list on foobar:
<tbody>
<row>
- <entry>NIS domainname</entry>
+ <entry><acronym>NIS</acronym> domain name</entry>
- <entry>An NIS master server and all of its clients
- (including its slave servers) have a NIS domainname.
- Similar to an &windowsnt; domain name, the NIS
- domainname does not have anything to do with
+ <entry>An <acronym>NIS</acronym> master server and all of its clients,
+ including its slave servers, share a <acronym>NIS</acronym> domain name
+ which
+ does not have anything to do with
<acronym>DNS</acronym>.</entry>
</row>
<row>
- <entry><application>rpcbind</application></entry>
+ <entry>&man.rpcbind.8;</entry>
- <entry>Must be running in order to enable
- <acronym>RPC</acronym> (Remote Procedure Call, a
- network protocol used by NIS). If
- <application>rpcbind</application> is not running, it
- will be impossible to run an NIS server, or to act as
- an NIS client.</entry>
+ <entry>This service enables <acronym>RPC</acronym> and
+ must be running
+ in order to run an <acronym>NIS</acronym> server or act as
+ an <acronym>NIS</acronym> client.</entry>
</row>
<row>
- <entry><application>ypbind</application></entry>
- <entry><quote>Binds</quote> an NIS client to its NIS
- server. It will take the NIS domainname from the
- system, and using <acronym>RPC</acronym>, connect to
- the server. <application>ypbind</application> is the
- core of client-server communication in an NIS
- environment; if <application>ypbind</application> dies
+ <entry>&man.ypbind.8;</entry>
+ <entry>This service binds an <acronym>NIS</acronym> client to its <acronym>NIS</acronym>
+ server. It will take the <acronym>NIS</acronym> domain name
+ and use <acronym>RPC</acronym> to connect to
+ the server. It is the
+ core of client/server communication in an <acronym>NIS</acronym>
+ environment. If this service is not running
on a client machine, it will not be able to access the
- NIS server.</entry>
+ <acronym>NIS</acronym> server.</entry>
</row>
<row>
- <entry><application>ypserv</application></entry>
- <entry>Should only be running on NIS servers; this is
- the NIS server process itself. If &man.ypserv.8;
- dies, then the server will no longer be able to
- respond to NIS requests (hopefully, there is a slave
- server to take over for it). There are some
- implementations of NIS (but not the FreeBSD one), that
- do not try to reconnect to another server if the
- server it used before dies. Often, the only thing
- that helps in this case is to restart the server
- process (or even the whole server) or the
- <application>ypbind</application> process on the
- client.</entry>
+ <entry>&man.ypserv.8;</entry>
+ <entry>This is the process for
+ the <acronym>NIS</acronym> server. If this service stops running,
+ the server will no longer be able to
+ respond to <acronym>NIS</acronym> requests so hopefully, there is a slave
+ server to take over. Some
+ non-&os; clients
+ will not try to reconnect using a slave server and the
+ <application>ypbind</application> process may need to
+ be restarted on these
+ clients.</entry>
</row>
<row>
- <entry><application>rpc.yppasswdd</application></entry>
- <entry>Another process that should only be running on
- NIS master servers; this is a daemon that will allow
- NIS clients to change their NIS passwords. If this
+ <entry>&man.rpc.yppasswdd.8;</entry>
+ <entry>This process only runs on
+ <acronym>NIS</acronym> master servers. This daemon allows
+ <acronym>NIS</acronym> clients to change their <acronym>NIS</acronym> passwords. If this
daemon is not running, users will have to login to the
- NIS master server and change their passwords
+ <acronym>NIS</acronym> master server and change their passwords
there.</entry>
</row>
</tbody>
</tgroup>
- </informaltable>
+ </table>
<!-- XXX Missing: rpc.ypxfrd (not important, though) May only run
on the master -->
</sect2>
<sect2>
- <title>How Does It Work?</title>
-
- <para>There are three types of hosts in an NIS environment:
- master servers, slave servers, and clients. Servers act as a
- central repository for host configuration information. Master
- servers hold the authoritative copy of this information, while
- slave servers mirror this information for redundancy. Clients
- rely on the servers to provide this information to
- them.</para>
-
- <para>Information in many files can be shared in this manner.
- The <filename>master.passwd</filename>,
- <filename>group</filename>, and <filename>hosts</filename>
- files are commonly shared via NIS. Whenever a process on a
- client needs information that would normally be found in these
- files locally, it makes a query to the NIS server that it is
- bound to instead.</para>
+ <title>Machine Types</title>
+ <indexterm><primary>NIS</primary>
+ <secondary>master server</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>NIS</primary>
+ <secondary>slave server</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>NIS</primary>
+ <secondary>client</secondary>
+ </indexterm>
- <sect3>
- <title>Machine Types</title>
+ <para>There are three types of hosts in an <acronym>NIS</acronym> environment:</para>
<itemizedlist>
<listitem>
- <para>A <emphasis>NIS master server</emphasis><indexterm>
- <primary>NIS</primary>
- <secondary>master server</secondary>
- </indexterm>.
- This server, analogous to a &windowsnt; primary domain
- controller, maintains the files used by all of the NIS
+ <para><acronym>NIS</acronym> master server</para>
+
+ <para>This server acts as a
+ central repository for host configuration information and
+ maintains the authoritative copy of the files used by all of the <acronym>NIS</acronym>
clients. The <filename>passwd</filename>,
<filename>group</filename>, and other various files used
- by the NIS clients live on the master server.</para>
-
- <note>
- <para>It is possible for one machine to be an NIS master
- server for more than one NIS domain. However, this
- will not be covered in this introduction, which
- assumes a relatively small-scale NIS
- environment.</para>
- </note>
+ by <acronym>NIS</acronym> clients are stored on the master server. While
+ it is possible for one machine to be an <acronym>NIS</acronym> master
+ server for more than one <acronym>NIS</acronym> domain, this
+ will not be covered in chapter as it
+ assumes a relatively small-scale <acronym>NIS</acronym>
+ environment.</para>
</listitem>
<listitem>
- <para><emphasis>NIS slave servers</emphasis><indexterm>
- <primary>NIS</primary>
- <secondary>slave server</secondary>
- </indexterm>. Similar to the &windowsnt; backup domain
- controllers, NIS slave servers maintain copies of the
- NIS master's data files. NIS slave servers provide the
- redundancy, which is needed in important environments.
- They also help to balance the load of the master server:
- NIS Clients always attach to the NIS server whose
- response they get first, and this includes
- slave-server-replies.</para>
+ <para><acronym>NIS</acronym> slave servers</para>
+
+ <para><acronym>NIS</acronym> slave servers maintain copies of the
+ <acronym>NIS</acronym> master's data files in order to provide
+ redundancy.
+ Slave servers also help to balance the load of the master server as
+ <acronym>NIS</acronym> clients always attach to the <acronym>NIS</acronym> server which
+ responds first.</para>
</listitem>
<listitem>
- <para><emphasis>NIS clients</emphasis><indexterm>
- <primary>NIS</primary>
- <secondary>client</secondary>
- </indexterm>.
- NIS clients, like most &windowsnt; workstations,
- authenticate against the NIS server (or the &windowsnt;
- domain controller in the &windowsnt; workstations case)
- to log on.</para>
+ <para><acronym>NIS</acronym> clients</para>
+
+ <para><acronym>NIS</acronym> clients
+ authenticate against the <acronym>NIS</acronym> server
+ during log on.</para>
</listitem>
</itemizedlist>
- </sect3>
+
+ <para>Information in many files can be shared using <acronym>NIS</acronym>.
+ The <filename>master.passwd</filename>,
+ <filename>group</filename>, and <filename>hosts</filename>
+ files are commonly shared via <acronym>NIS</acronym>. Whenever a process on a
+ client needs information that would normally be found in these
+ files locally, it makes a query to the <acronym>NIS</acronym> server that it is
+ bound to instead.</para>
</sect2>
<sect2>
- <title>Using NIS/YP</title>
-
- <para>This section will deal with setting up a sample NIS
- environment.</para>
-
- <sect3>
- <title>Planning</title>
+ <title>Planning Considerations</title>
- <para>Let us assume that an administrator of a small
- university lab, which consists of 15 FreeBSD machines,
+ <para>This section describes a sample <acronym>NIS</acronym>
+ environment which consists of 15 &os; machines and which
currently has no centralized point of administration. Each
machine has its own <filename>/etc/passwd</filename> and
<filename>/etc/master.passwd</filename>. These files are
kept in sync with each other only through manual
- intervention; currently, a user is added to the lab, the
- process must be ran on all 15 machines. The lab would
- clearly benefit from the addition of two
- <acronym>NIS</acronym> servers.</para>
+ intervention. Currently, when a user is added to the lab, the
+ process must be repeated on all 15 machines..</para>
- <para>Therefore, the configuration of the lab now looks
- something like:</para>
+ <para>The configuration of the lab will be as follows:</para>
<informaltable frame="none" pgwide="1">
<tgroup cols="3">
@@ -1284,13 +1251,13 @@ Exports list on foobar:
<row>
<entry><hostid>ellington</hostid></entry>
<entry><hostid role="ipaddr">10.0.0.2</hostid></entry>
- <entry>NIS master</entry>
+ <entry><acronym>NIS</acronym> master</entry>
</row>
<row>
<entry><hostid>coltrane</hostid></entry>
<entry><hostid role="ipaddr">10.0.0.3</hostid></entry>
- <entry>NIS slave</entry>
+ <entry><acronym>NIS</acronym> slave</entry>
</row>
<row>
@@ -1321,96 +1288,88 @@ Exports list on foobar:
decisions need to be made as part of the planning
process.</para>
- <sect4>
- <title>Choosing a NIS Domain Name</title>
+ <sect3>
+ <title>Choosing a <acronym>NIS</acronym> Domain Name</title>
<indexterm>
<primary>NIS</primary>
- <secondary>domainname</secondary>
+ <secondary>domain name</secondary>
</indexterm>
- <para>This might not be the normal <quote>domainname</quote>
- for the network. It is more accurately called the
- <quote>NIS domainname</quote>. When a client broadcasts
- its requests for info, it includes the name of the NIS
+ <para>When a client broadcasts
+ its requests for info, it includes the name of the <acronym>NIS</acronym>
domain that it is part of. This is how multiple servers
on one network can tell which server should answer which
- request. Think of the NIS domainname as the name for a
- group of hosts that are related in some way.</para>
+ request. Think of the <acronym>NIS</acronym> domain name as the name for a
+ group of hosts.</para>
<para>Some organizations choose to use their Internet
- domainname for their NIS domainname. This is not
+ domain name for their <acronym>NIS</acronym> domain name. This is not
recommended as it can cause confusion when trying to debug
- network problems. The NIS domainname should be unique
+ network problems. The <acronym>NIS</acronym> domain name should be unique
within the network and it is helpful if it describes the
group of machines it represents. For example, the Art
department at Acme Inc. might be in the
- <quote>acme-art</quote> NIS domain. For this example,
- assume the chosen name will be
+ <quote>acme-art</quote> <acronym>NIS</acronym> domain. This example
+ will use the domain name
<literal>test-domain</literal>.</para>
- <indexterm><primary>SunOS</primary></indexterm>
- <para>However, some operating systems (notably &sunos;) use
- their NIS domain name as their Internet domain name. If
+ <para>However, some non-&os; operating systems require
+ the <acronym>NIS</acronym> domain name to be the same as the Internet domain name. If
one or more machines on the network have this
- restriction, it <emphasis>must</emphasis> be used as the
- Internet domain name for the NIS domain name.</para>
- </sect4>
+ restriction, the Internet domain name <emphasis>must</emphasis> be used as the
+ <acronym>NIS</acronym> domain name.</para>
+ </sect3>
- <sect4>
+ <sect3>
<title>Physical Server Requirements</title>
<para>There are several things to keep in mind when choosing
- a machine to use as a NIS server. One of the unfortunate
- things about NIS is the level of dependency the clients
- have on the server. If a client cannot contact the server
- for its NIS domain, very often the machine becomes
- unusable. The lack of user and group information causes
- most systems to temporarily freeze up. With this in mind
- be sure to choose a machine that will not be prone to
- being rebooted frequently, or one that might be used for
- development. The NIS server should ideally be a stand
- alone machine whose sole purpose in life is to be an NIS
- server. If the network is not very heavily used, it is
- acceptable to put the NIS server on a machine running
- other services, however; if the NIS server becomes
+ a machine to use as a <acronym>NIS</acronym> server. Since
+ <acronym>NIS</acronym> clients depend upon the availability
+ of the server, choose a machine that is
+ not rebooted frequently. The <acronym>NIS</acronym> server should ideally be a stand
+ alone machine whose sole purpose is to be an <acronym>NIS</acronym>
+ server. If the network is not heavily used, it is
+ acceptable to put the <acronym>NIS</acronym> server on a machine running
+ other services. However, if the <acronym>NIS</acronym> server becomes
unavailable, it will adversely affect
- <emphasis>all</emphasis> NIS clients.</para>
- </sect4>
+ all <acronym>NIS</acronym> clients.</para>
</sect3>
+ </sect2>
- <sect3>
- <title>NIS Servers</title>
+ <sect2>
+ <title>Configuring the <acronym>NIS</acronym> Servers</title>
- <para> The canonical copies of all NIS information are stored
- on a single machine called the NIS master server. The
- databases used to store the information are called NIS maps.
- In FreeBSD, these maps are stored in
- <filename>/var/yp/[domainname]</filename> where
- <filename>[domainname]</filename> is the name of the NIS
- domain being served. A single NIS server can support
- several domains at once, therefore it is possible to have
- several such directories, one for each supported domain.
+ <para> The canonical copies of all <acronym>NIS</acronym> files are stored
+ on the master server. The
+ databases used to store the information are called <acronym>NIS</acronym> maps.
+ In &os;, these maps are stored in
+ <filename>/var/yp/[domain name]</filename> where
+ <filename>[domain name]</filename> is the name of the <acronym>NIS</acronym>
+ domain. Since multiple
+ domains are supported, it is possible to have
+ several directories, one for each domain.
Each domain will have its own independent set of
maps.</para>
- <para>NIS master and slave servers handle all NIS requests
- with the <command>ypserv</command> daemon.
- <command>ypserv</command> is responsible for receiving
- incoming requests from NIS clients, translating the
+ <para><acronym>NIS</acronym> master and slave servers handle all <acronym>NIS</acronym> requests
+ through &man.ypserv.8;. This daemon
+ is responsible for receiving
+ incoming requests from <acronym>NIS</acronym> clients, translating the
requested domain and map name to a path to the corresponding
- database file and transmitting data from the database back
+ database file, and transmitting data from the database back
to the client.</para>
- <sect4>
- <title>Setting Up a NIS Master Server</title>
+ <sect3>
+ <title>Setting Up a <acronym>NIS</acronym> Master Server</title>
<indexterm>
<primary>NIS</primary>
<secondary>server configuration</secondary>
</indexterm>
- <para>Setting up a master NIS server can be relatively
- straight forward, depending on environmental needs. &os;
- comes with support for NIS out-of-the-box. It only needs
+ <para>Setting up a master <acronym>NIS</acronym> server can be relatively
+ straight forward, depending on environmental needs. Since &os;
+ provides built-in <acronym>NIS</acronym> support, it only needs
to be enabled by adding the following lines to
<filename>/etc/rc.conf</filename>:</para>
@@ -1418,96 +1377,78 @@ Exports list on foobar:
<step>
<programlisting>nisdomainname="test-domain"</programlisting>
- <para>This line will set the NIS domainname to
- <literal>test-domain</literal>
- upon network setup (e.g., after reboot).</para>
+ <para>This line sets the <acronym>NIS</acronym> domain name to
+ <literal>test-domain</literal>.</para>
</step>
<step>
<programlisting>nis_server_enable="YES"</programlisting>
- <para>This will tell FreeBSD to start up the NIS server
- processes when the networking is next brought
- up.</para>
+ <para>This automates the start up of the <acronym>NIS</acronym> server
+ processes when the system
+ boots.</para>
</step>
<step>
<programlisting>nis_yppasswdd_enable="YES"</programlisting>
- <para>This will enable the
- <command>rpc.yppasswdd</command> daemon which, as
- mentioned above, will allow users to change their NIS
+ <para>This enables the
+ &man.rpc.yppasswdd.8; daemon so that
+ users can change their <acronym>NIS</acronym>
password from a client machine.</para>
</step>
</procedure>
- <note>
- <para>Depending on the NIS setup, additional entries may
- be required. See the
- <link linkend="network-nis-server-is-client">section
- about NIS servers that are also NIS clients</link>,
- below, for details.</para>
- </note>
-
- <para>After setting up the above entries, run the command
- <command>/etc/netstart</command> as superuser. It will
- set up everything, using the values defined in
- <filename>/etc/rc.conf</filename>. As a last step, before
- initializing the NIS maps, start the
- <application>ypserv</application> daemon manually:</para>
+ <para>Depending on the <acronym>NIS</acronym> setup, additional entries may
+ be required. Refer to
+ <xref linkend="network-nis-server-is-client"/> if
+ the <acronym>NIS</acronym> server is also an <acronym>NIS</acronym> clients.</para>
+
+ <para>After saving the edits, type
+ <command>/etc/netstart</command> to restart the network and
+ apply the values defined in
+ <filename>/etc/rc.conf</filename>. Before
+ initializing the <acronym>NIS</acronym> maps, start
+ &man.ypserv.8;:</para>
<screen>&prompt.root; <userinput>service ypserv start</userinput></screen>
- </sect4>
+ </sect3>
- <sect4>
- <title>Initializing the NIS Maps</title>
+ <sect3>
+ <title>Initializing the <acronym>NIS</acronym> Maps</title>
<indexterm>
<primary>NIS</primary>
<secondary>maps</secondary>
</indexterm>
- <para>The <emphasis>NIS maps</emphasis> are database files,
- that are kept in the <filename>/var/yp</filename>
- directory. They are generated from configuration files in
- the <filename>/etc</filename> directory of the NIS master,
+ <para><acronym>NIS</acronym> maps are database files
+ stored in <filename class="directory">/var/yp</filename>.
+ They are generated from configuration files in
+ <filename class="directory">/etc</filename> on the <acronym>NIS</acronym> master,
with one exception:
- <filename>/etc/master.passwd</filename>. This is for a
- good reason, never propagate passwords for
- <username>root</username> and other administrative
- accounts to all the servers in the NIS domain. Therefore,
- before the NIS maps are initialized, configure the primary
+ <filename>/etc/master.passwd</filename>. This is to prevent the
+ propagation passwords to all the servers in the <acronym>NIS</acronym> domain. Therefore,
+ before the <acronym>NIS</acronym> maps are initialized, configure the primary
password files:</para>
<screen>&prompt.root; <userinput>cp /etc/master.passwd /var/yp/master.passwd</userinput>
&prompt.root; <userinput>cd /var/yp</userinput>
&prompt.root; <userinput>vi master.passwd</userinput></screen>
- <para>It is advisable to remove all entries regarding system
- accounts (<username>bin</username>,
- <username>tty</username>, <username>kmem</username>,
- <username>games</username>, etc), as well as any accounts
- that do not need to be propagated to the NIS clients
- (for example <username>root</username> and any other UID 0
- (superuser) accounts).</para>
+ <para>It is advisable to remove all entries for system
+ accounts as well as any user accounts
+ that do not need to be propagated to the <acronym>NIS</acronym> clients, such as
+ the <username>root</username> accounts.</para>
- <note><para>Ensure the
+ <note><para>Ensure that the
<filename>/var/yp/master.passwd</filename> is neither
- group or world readable (mode 600)! Use the
- <command>chmod</command> command, as
- appropriate.</para></note>
-
- <indexterm><primary>Tru64 UNIX</primary></indexterm>
+ group or world readable by setting its permissions to <literal>600</literal>.</para></note>
<para>When this task has been completed, it is time to
- initialize the NIS maps. FreeBSD includes a script named
- <command>ypinit</command> to do this (see its
- manual page for more information). Note that this script
- is available on most &unix; Operating Systems, but not on
- all. On Digital UNIX/Compaq Tru64 UNIX it is called
- <command>ypsetup</command>. Because we are generating
- maps for an NIS master, we are going to pass the
- <option>-m</option> option to <command>ypinit</command>.
- To generate the NIS maps run:</para>
+ initialize the <acronym>NIS</acronym> maps. &os; includes the
+ &man.ypinit.8; script to do this. When generating
+ maps for the master server, include
+ <option>-m</option> and specify the <acronym>NIS</acronym> domain name:</para>
<screen>ellington&prompt.root; <userinput>ypinit -m test-domain</userinput>
Server Type: MASTER Domain: test-domain
@@ -1537,7 +1478,7 @@ ellington has been setup as an YP master
created <filename>/var/yp/Makefile</filename> from
<filename>/var/yp/Makefile.dist</filename>. When created,
this file assumes that the operating environment is a
- single server NIS system with only &os; machines. Since
+ single server <acronym>NIS</acronym> system with only &os; machines. Since
<literal>test-domain</literal> has a slave server as well,
edit <filename>/var/yp/Makefile</filename> as well:</para>
@@ -1548,22 +1489,22 @@ ellington has been setup as an YP master
<programlisting>NOPUSH = "True"</programlisting>
<para>(if it is not commented out already).</para>
- </sect4>
+ </sect3>
- <sect4>
- <title>Setting up a NIS Slave Server</title>
+ <sect3>
+ <title>Setting up a <acronym>NIS</acronym> Slave Server</title>
<indexterm>
<primary>NIS</primary>
<secondary>slave server</secondary>
</indexterm>
- <para>Setting up an NIS slave server is even more simple
+ <para>Setting up an <acronym>NIS</acronym> slave server is even more simple
than setting up the master. Log on to the slave server
and edit the file <filename>/etc/rc.conf</filename> as you
did before. The only difference is that we now must use
the <option>-s</option> option when running
<command>ypinit</command>. The <option>-s</option> option
- requires the name of the NIS master be passed to it as
+ requires the name of the <acronym>NIS</acronym> master be passed to it as
well, so our command line looks like:</para>
<screen>coltrane&prompt.root; <userinput>ypinit -s ellington test-domain</userinput>
@@ -1625,7 +1566,7 @@ Remember to update map ypservers on elli
<para>There should be a directory called
<filename>/var/yp/test-domain</filename>. Copies of the
- NIS master server's maps should be in this directory.
+ <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>
@@ -1646,14 +1587,13 @@ Remember to update map ypservers on elli
<para>Now, run the command <command>/etc/netstart</command>
on the slave server as well, which again starts the NIS
server.</para>
- </sect4>
</sect3>
<sect3>
- <title>NIS Clients</title>
+ <title>Setting Up a <acronym>NIS</acronym> Client</title>
- <para>An NIS client establishes what is called a binding to a
- particular NIS server using the <command>ypbind</command>
+ <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
@@ -1667,7 +1607,7 @@ Remember to update map ypservers on elli
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
- direct all of its NIS requests to that server.
+ 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
@@ -1676,20 +1616,17 @@ Remember to update map ypservers on elli
and begin broadcasting again in the hopes of locating
another server.</para>
- <sect4>
- <title>Setting Up a NIS Client</title>
-
<indexterm>
<primary>NIS</primary>
<secondary>client configuration</secondary>
</indexterm>
- <para>Setting up a FreeBSD machine to be a NIS client is
+ <para>Setting up a FreeBSD machine to be a <acronym>NIS</acronym> client is
fairly straightforward.</para>
<procedure>
<step>
<para>Edit <filename>/etc/rc.conf</filename> and add the
- following lines in order to set the NIS domainname and
+ following lines in order to set the <acronym>NIS</acronym> domain name and
start <command>ypbind</command> during network
startup:</para>
@@ -1699,7 +1636,7 @@ nis_client_enable="YES"</programlisting>
<step>
<para>To import all possible password entries from the
- NIS server, remove all user accounts 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
the end of the file:</para>
@@ -1708,7 +1645,7 @@ nis_client_enable="YES"</programlisting>
<note>
<para>This line will afford anyone with a valid
- account in the NIS server's password maps an
+ 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
@@ -1738,7 +1675,7 @@ nis_client_enable="YES"</programlisting>
</step>
</procedure>
- <para>To start the NIS client immediately, execute the
+ <para>To start the <acronym>NIS</acronym> client immediately, execute the
following commands as the superuser:</para>
<screen>&prompt.root; <userinput>/etc/netstart</userinput>
@@ -1747,16 +1684,15 @@ nis_client_enable="YES"</programlisting>
<para>After completing these steps, the command,
<command>ypcat passwd</command>, should show the
server's passwd map.</para>
- </sect4>
</sect3>
</sect2>
<sect2>
- <title>NIS Security</title>
+ <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 NIS maps,
- provided the remote user knows the domainname. To prevent
+ &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, &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,
@@ -1806,7 +1742,7 @@ nis_client_enable="YES"</programlisting>
firewall.</para>
<para>Servers using <filename>/var/yp/securenets</filename>
- may fail to serve legitimate NIS clients with archaic TCP/IP
+ 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 calculating the broadcast address.
@@ -1818,17 +1754,17 @@ nis_client_enable="YES"</programlisting>
<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 NIS functionality
+ really bad idea and will lead to loss of <acronym>NIS</acronym> functionality
for large parts of the network.</para>
<indexterm><primary>TCP Wrappers</primary></indexterm>
<para>The use of <application>TCP Wrapper</application>
- increases the latency of the NIS server. The additional
+ 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 into
- NIS slave servers and force them to bind to
+ <acronym>NIS</acronym> slave servers and force them to bind to
themselves.</para>
</note>
</sect2>
@@ -1838,13 +1774,13 @@ nis_client_enable="YES"</programlisting>
<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 NIS domain, yet the
- <filename>passwd</filename> file on the master NIS server
+ to take this machine out of the <acronym>NIS</acronym> domain, yet the
+ <filename>passwd</filename> file on the master <acronym>NIS</acronym> server
contains accounts for both faculty and students. What can we
do?</para>
<para>There is a way to bar specific users from logging on to a
- machine, even if they are present in the NIS database. To do
+ machine, even if they are present in the <acronym>NIS</acronym> database. To do
this, add
<literal>-<replaceable>username</replaceable></literal> with
the correct number of colons like other entries to the end of
@@ -1852,7 +1788,7 @@ nis_client_enable="YES"</programlisting>
machine, where <replaceable>username</replaceable> is the
username of the user to bar from logging in. The line with
the blocked user must be before the <literal>+</literal> line
- for allowing NIS users. This should preferably be done using
+ 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
@@ -1889,6 +1825,7 @@ basie&prompt.root;</screen>
</sect2>
<sect2 id="network-netgroups">
+ <!--
<sect2info>
<authorgroup>
<author>
@@ -1898,6 +1835,7 @@ basie&prompt.root;</screen>
</author>
</authorgroup>
</sect2info>
+ -->
<title>Using Netgroups</title>
@@ -1911,7 +1849,7 @@ basie&prompt.root;</screen>
each machine separately, thus losing the main benefit of NIS:
<emphasis>centralized</emphasis> administration.</para>
- <para>The NIS developers' solution for this problem is called
+ <para>The <acronym>NIS</acronym> developers' solution for this problem is called
<emphasis>netgroups</emphasis>. Their purpose and semantics
can be compared to the normal groups used by &unix; file
systems. The main differences are the lack of a numeric ID
@@ -1925,9 +1863,9 @@ basie&prompt.root;</screen>
with really simple examples. The example used in the
remainder of this section demonstrates this problem.</para>
- <para>Let us assume that the successful introduction of NIS in
+ <para>Let us assume that the successful introduction of <acronym>NIS</acronym> in
the laboratory caught a superiors' interest. The next task is
- to extend the NIS domain to cover some of the other machines
+ to extend the <acronym>NIS</acronym> domain to cover some of the other machines
on campus. The two tables contain the names of the new users
and new machines as well as brief descriptions of them.</para>
@@ -2037,13 +1975,13 @@ basie&prompt.root;</screen>
one or more netgroups. Those changes are independent of each
other: no more
<quote>for each combination of user and machine do...</quote>
- If the NIS setup is planned carefully, only one central
+ If the <acronym>NIS</acronym> setup is planned carefully, only one central
configuration file needs modification to grant or deny access
to machines.</para>
- <para>The first step is the initialization of the NIS map
+ <para>The first step is the initialization of the <acronym>NIS</acronym> map
netgroup. &os;'s &man.ypinit.8; does not create this map by
- default, but its NIS implementation will support it after
+ default, but its <acronym>NIS</acronym> implementation will support it after
creation. To create an empty map, simply type</para>
<screen>ellington&prompt.root; <userinput>vi /var/yp/netgroup</userinput></screen>
@@ -2077,8 +2015,8 @@ INTERNS (,able,test-domain) (,baker,
</listitem>
<listitem>
- <para>The NIS domain for the account. Accounts may be
- imported from other NIS domains into a netgroup.</para>
+ <para>The <acronym>NIS</acronym> domain for the account. Accounts may be
+ imported from other <acronym>NIS</acronym> domains into a netgroup.</para>
</listitem>
</orderedlist>
@@ -2089,12 +2027,12 @@ INTERNS (,able,test-domain) (,baker,
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
More information about the svn-doc-all
mailing list