svn commit: r42967 - head/en_US.ISO8859-1/books/handbook/network-servers

Dru Lavigne dru at FreeBSD.org
Tue Oct 15 16:57:04 UTC 2013


Author: dru
Date: Tue Oct 15 16:57:03 2013
New Revision: 42967
URL: http://svnweb.freebsd.org/changeset/doc/42967

Log:
  White space fix only. Translators can ignore.

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 16:52:15 2013	(r42966)
+++ head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml	Tue Oct 15 16:57:03 2013	(r42967)
@@ -600,19 +600,19 @@ server-program-arguments</programlisting
       </listitem>
     </itemizedlist>
 
-      <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
-	order for this to function properly a few processes have to be
-	configured and running.</para>
+    <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 order for this to function properly a few
+      processes have to be configured and running.</para>
 
-      <para>These daemons must be running on the server:</para>
-      <indexterm>
-	<primary>NFS</primary>
+    <para>These daemons must be running on the server:</para>
+    <indexterm>
+      <primary>NFS</primary>
 	<secondary>server</secondary>
-      </indexterm>
-      <indexterm>
-	<primary>file server</primary>
+     </indexterm>
+     <indexterm>
+       <primary>file server</primary>
 	<secondary>UNIX clients</secondary>
       </indexterm>
 
@@ -666,21 +666,21 @@ server-program-arguments</programlisting
       <para>Running &man.nfsiod.8; can improve performance on the
 	client, but is not required.</para>
 
-    <sect2 id="network-configuring-nfs">
-      <title>Configuring <acronym>NFS</acronym></title>
+      <sect2 id="network-configuring-nfs">
+	<title>Configuring <acronym>NFS</acronym></title>
 
-      <indexterm>
-	<primary>NFS</primary>
-	<secondary>configuration</secondary>
-      </indexterm>
+	<indexterm>
+	  <primary>NFS</primary>
+	  <secondary>configuration</secondary>
+	</indexterm>
 
-      <para>Enabling the <acronym>NFS</acronym> server
-	is straightforward.  The required processes
-	can be set to start at boot time by adding
-	these options to
-	<filename>/etc/rc.conf</filename>:</para>
+	<para>Enabling the <acronym>NFS</acronym> server
+	  is straightforward.  The required processes
+	  can be set to start at boot time by adding
+	  these options to
+	  <filename>/etc/rc.conf</filename>:</para>
 
-      <programlisting>rpcbind_enable="YES"
+	<programlisting>rpcbind_enable="YES"
 nfs_server_enable="YES"
 mountd_flags="-r"</programlisting>
 
@@ -1037,7 +1037,8 @@ Exports list on foobar:
       </authorgroup>
     </sect1info>
     -->
-    <title>Network Information System (NIS/YP)</title>
+      <title>Network Information System (NIS/YP)</title>
+
       <indexterm><primary>NIS</primary></indexterm>
       <indexterm><primary>Solaris</primary></indexterm>
       <indexterm><primary>HP-UX</primary></indexterm>
@@ -1051,14 +1052,13 @@ Exports list on foobar:
       </indexterm>
 
       <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>
+	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>
@@ -1066,18 +1066,19 @@ Exports list on foobar:
       </indexterm>
 
       <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 <acronym>NIS</acronym> client systems with only minimal configuration data
-	and add, remove or modify configuration data from a single
-	location.</para>
+	(<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
+	<acronym>NIS</acronym> client systems with only minimal
+	configuration data and add, remove or modify configuration
+	data from a single location.</para>
 
     <sect2>
       <title><acronym>NIS</acronym> Terms and Processes</title>
 
-      <para>Table 28.1 summarizes the terms and important processes used
-	by <acronym>NIS</acronym>:</para>
+      <para>Table 28.1 summarizes the terms and important processes
+	used by <acronym>NIS</acronym>:</para>
 
       <indexterm>
 	<primary><application>rpcbind</application></primary>
@@ -1088,6 +1089,7 @@ Exports list on foobar:
 
       <table frame="none" pgwide="1">
 	<title><acronym>NIS</acronym> Terminology</title>
+
 	<tgroup cols="2">
 	  <colspec colwidth="1*"/>
 	  <colspec colwidth="3*"/>
@@ -1103,42 +1105,41 @@ Exports list on foobar:
 	    <row>
 	      <entry><acronym>NIS</acronym> domain name</entry>
 
-	      <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>
+	      <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>&man.rpcbind.8;</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>
+		must be running in order to run an
+		<acronym>NIS</acronym> server or act as an
+		<acronym>NIS</acronym> client.</entry>
 	    </row>
 
 	    <row>
 	      <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
-		<acronym>NIS</acronym> server.</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 <acronym>NIS</acronym>
+		server.</entry>
 	    </row>
 
 	    <row>
 	      <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
+	      <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
@@ -1148,11 +1149,12 @@ Exports list on foobar:
 	    <row>
 	      <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
-		<acronym>NIS</acronym> master server and change their passwords
-		there.</entry>
+		<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
+		<acronym>NIS</acronym> master server and change their
+		passwords there.</entry>
 	    </row>
 	  </tbody>
 	</tgroup>
@@ -1163,64 +1165,68 @@ Exports list on foobar:
 
     <sect2>
       <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>master server</secondary>
-	      </indexterm>
-	      <indexterm>
-		<primary>NIS</primary>
-		<secondary>slave server</secondary>
-	      </indexterm>
-	      <indexterm>
-		<primary>NIS</primary>
-		<secondary>client</secondary>
-	      </indexterm>
+	<secondary>client</secondary>
+      </indexterm>
 
-      <para>There are three types of hosts in an <acronym>NIS</acronym> environment:</para>
+      <para>There are three types of hosts in an
+	<acronym>NIS</acronym> environment:</para>
 
-	<itemizedlist>
-	  <listitem>
-	    <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 <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>
+      <itemizedlist>
+	<listitem>
+	  <para><acronym>NIS</acronym> master server</para>
 
-	  <listitem>
-	    <para><acronym>NIS</acronym> slave servers</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 <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>
 
-	    <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><acronym>NIS</acronym> slave servers</para>
 
-	  <listitem>
-	    <para><acronym>NIS</acronym> clients</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>
 
-	      <para><acronym>NIS</acronym> clients
-	      authenticate against the <acronym>NIS</acronym> server
-	      during log on.</para>
-	  </listitem>
-	</itemizedlist>
+	<listitem>
+	  <para><acronym>NIS</acronym> clients</para>
+
+	  <para><acronym>NIS</acronym> clients authenticate
+	    against the <acronym>NIS</acronym> server during log
+	    on.</para>
+	</listitem>
+      </itemizedlist>
 
-      <para>Information in many files can be shared using <acronym>NIS</acronym>.
-	The <filename>master.passwd</filename>,
+      <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>
+	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>
@@ -1232,8 +1238,8 @@ Exports list on foobar:
 	  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, when a user is added to the lab, the
-	  process must be repeated on all 15 machines..</para>
+	  intervention.  Currently, when a user is added to the lab,
+	  the process must be repeated on all 15 machines..</para>
 
 	<para>The configuration of the lab will be as follows:</para>
 
@@ -1295,28 +1301,29 @@ Exports list on foobar:
 	    <primary>NIS</primary>
 	    <secondary>domain name</secondary>
 	  </indexterm>
-	  <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 <acronym>NIS</acronym> domain name as the name for a
-	    group of hosts.</para>
-
-	  <para>Some organizations choose to use their Internet
-	    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 <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> <acronym>NIS</acronym> domain.  This example
-	    will use the domain name
-	    <literal>test-domain</literal>.</para>
-
-	  <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, the Internet domain name <emphasis>must</emphasis> be used as the
+	  <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 <acronym>NIS</acronym> domain name as the
+	    name for a group of hosts.</para>
+
+	  <para>Some organizations choose to use their Internet 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 <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>
+	    <acronym>NIS</acronym> domain.  This example will use the
+	    domain name <literal>test-domain</literal>.</para>
+
+	  <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, the Internet domain name
+	    <emphasis>must</emphasis> be used as the
 	    <acronym>NIS</acronym> domain name.</para>
 	</sect3>
 
@@ -1324,69 +1331,71 @@ Exports list on foobar:
 	  <title>Physical Server Requirements</title>
 
 	  <para>There are several things to keep in mind when choosing
-	    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
-	    all <acronym>NIS</acronym> clients.</para>
-      </sect3>
-    </sect2>
+	    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 all
+	    <acronym>NIS</acronym> clients.</para>
+	</sect3>
+      </sect2>
 
       <sect2>
 	<title>Configuring the <acronym>NIS</acronym> Servers</title>
 
-	<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
+	<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><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
+	  <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><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
 	  to the client.</para>
 
 	<sect3>
-	  <title>Setting Up a <acronym>NIS</acronym> Master Server</title>
+	  <title>Setting Up a <acronym>NIS</acronym> Master
+	    Server</title>
 
 	  <indexterm>
 	    <primary>NIS</primary>
 	    <secondary>server configuration</secondary>
 	  </indexterm>
-	  <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
+	  <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>
 
 	  <procedure>
 	    <step>
 	      <programlisting>nisdomainname="test-domain"</programlisting>
 
-	      <para>This line sets the <acronym>NIS</acronym> domain name to
-		<literal>test-domain</literal>.</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 automates the start up of the <acronym>NIS</acronym> server
-		processes when the system
-		boots.</para>
+	      <para>This automates the start up of the
+		<acronym>NIS</acronym> server processes when the
+		system boots.</para>
 	    </step>
 
 	    <step>
@@ -1399,56 +1408,61 @@ Exports list on foobar:
 	    </step>
 	  </procedure>
 
-	    <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>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
+	    <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>
 	</sect3>
 
 	<sect3>
-	  <title>Initializing the <acronym>NIS</acronym> Maps</title>
+	  <title>Initializing the <acronym>NIS</acronym>
+	    Maps</title>
 
 	  <indexterm>
 	    <primary>NIS</primary>
 	    <secondary>maps</secondary>
 	  </indexterm>
-	  <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 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>
+	  <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 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 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>
+	    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 that the
 	    <filename>/var/yp/master.passwd</filename> is neither
-	      group or world readable by setting its permissions to <literal>600</literal>.</para></note>
+	      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 <acronym>NIS</acronym> maps.  &os; includes the
-	    &man.ypinit.8; script to do this.  When generating
+	    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>
+	    <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
@@ -1478,9 +1492,10 @@ 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 <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>
+	    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>
 
 	  <screen>ellington&prompt.root; <userinput>vi /var/yp/Makefile</userinput></screen>
 
@@ -1492,20 +1507,23 @@ ellington has been setup as an YP master
 	</sect3>
 
 	<sect3>
-	  <title>Setting up a <acronym>NIS</acronym> Slave Server</title>
+	  <title>Setting up a <acronym>NIS</acronym> Slave
+	    Server</title>
 
 	  <indexterm>
 	    <primary>NIS</primary>
 	    <secondary>slave server</secondary>
 	  </indexterm>
-	  <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
+	  <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 <acronym>NIS</acronym> master be passed to it as
-	    well, so our command line looks like:</para>
+	    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>
 
@@ -1564,38 +1582,39 @@ 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>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>
 
-	  <programlisting>20      *       *       *       *       root   /usr/libexec/ypxfr passwd.byname
+	<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
-	    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.
-	    This is especially important on busy networks where map
-	    updates might not always complete.</para>
+	<para>These two lines force the slave to sync its maps with
+	  the maps on the master server.  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.
+	  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>Now, run the command <command>/etc/netstart</command>
+	  on the slave server as well, which again starts the NIS
+	  server.</para>
       </sect3>
 
       <sect3>
 	<title>Setting Up a <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
+	<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
@@ -1607,8 +1626,8 @@ 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 <acronym>NIS</acronym> requests to that server.
-	  <command>ypbind</command> will occasionally
+	  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,
@@ -1616,18 +1635,20 @@ Remember to update map ypservers on elli
 	  and begin broadcasting again in the hopes of locating
 	  another server.</para>
 
-	  <indexterm>
-	    <primary>NIS</primary>
-	    <secondary>client configuration</secondary>
-	  </indexterm>
-	  <para>Setting up a FreeBSD machine to be a <acronym>NIS</acronym> client is
-	    fairly straightforward.</para>
+	<indexterm><primary>NIS</primary>
+	  <secondary>client configuration</secondary>
+	</indexterm>
+
+	<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 <acronym>NIS</acronym> domain name and
-		start <command>ypbind</command> during network
+		following lines in order to set the
+		<acronym>NIS</acronym> domain name and start
+		<command>ypbind</command> during network
 		startup:</para>
 
 	      <programlisting>nisdomainname="test-domain"
@@ -1636,7 +1657,8 @@ 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
+		<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>
@@ -1645,8 +1667,9 @@ nis_client_enable="YES"</programlisting>
 
 	      <note>
 		<para>This line will afford anyone with a valid
-		  account in the <acronym>NIS</acronym> server's password maps an
-		  account.  There are many ways to configure the NIS
+		  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
@@ -1675,15 +1698,16 @@ nis_client_enable="YES"</programlisting>
 	    </step>
 	  </procedure>
 
-	  <para>To start the <acronym>NIS</acronym> client immediately, execute the
-	    following commands as the superuser:</para>
+	  <para>To start the <acronym>NIS</acronym> client
+	    immediately, execute the following commands as the
+	    superuser:</para>
 
 	  <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, the command,
+	  <command>ypcat passwd</command>, should show the
+	  server's passwd map.</para>
       </sect3>
     </sect2>
 
@@ -1691,13 +1715,13 @@ nis_client_enable="YES"</programlisting>
       <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, &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
+	&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, &man.ypserv.8; will
+	attempt to load the securenets information from a file called
 	<filename>/var/yp/securenets</filename>.</para>
 
       <note>
@@ -1742,30 +1766,31 @@ nis_client_enable="YES"</programlisting>
 	  firewall.</para>
 
 	<para>Servers using <filename>/var/yp/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 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
+	  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.  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>
+	  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 <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
-	  <acronym>NIS</acronym> slave servers and force them to bind to
-	  themselves.</para>
+	  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 <acronym>NIS</acronym> slave servers and force them to
+	  bind to themselves.</para>
       </note>
     </sect2>
 
@@ -1774,21 +1799,23 @@ 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 <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
+	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 <acronym>NIS</acronym> database.  To do
-	this, add
+	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
 	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 blocked user must be before the <literal>+</literal> line
-	for allowing <acronym>NIS</acronym> 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
@@ -1849,12 +1876,12 @@ basie&prompt.root;</screen>
 	each machine separately, thus losing the main benefit of NIS:
 	<emphasis>centralized</emphasis> administration.</para>
 
-      <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
-	and the ability to define a netgroup by including both user
-	accounts and other netgroups.</para>
+      <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 and the ability to define a netgroup by
+	including both user accounts and other netgroups.</para>
 
       <para>Netgroups were developed to handle large, complex networks
 	with hundreds of users and machines.  On one hand, this is a
@@ -1863,11 +1890,13 @@ 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 <acronym>NIS</acronym> in
-	the laboratory caught a superiors' interest.  The next task is
-	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>
+      <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
+	<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>
 
       <informaltable frame="none" pgwide="1">
 	<tgroup cols="2">
@@ -1973,15 +2002,15 @@ basie&prompt.root;</screen>
 	adding a new machine, login restrictions must be defined for
 	all netgroups.  If a new user is added, they must be added to
 	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 <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 <acronym>NIS</acronym> map
-	netgroup.  &os;'s &man.ypinit.8; does not create this map by
-	default, but its <acronym>NIS</acronym> implementation will support it after
+	other: no more <quote>for each combination of user and machine
+	  do...</quote>  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
+	<acronym>NIS</acronym> map netgroup.  &os;'s &man.ypinit.8;
+	does not create this map by 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>
@@ -2015,8 +2044,9 @@ INTERNS (,able,test-domain)     (,baker,
 	</listitem>
 
 	<listitem>
-	  <para>The <acronym>NIS</acronym> domain for the account.  Accounts may be
-	    imported from other <acronym>NIS</acronym> 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>
 
@@ -2027,18 +2057,19 @@ INTERNS (,able,test-domain)     (,baker,
 	<indexterm><primary>netgroups</primary></indexterm>
 	<para>Netgroup names longer than 8 characters should not be
 	  used, especially with machines running other operating
-	  systems within the <acronym>NIS</acronym> domain.  The names are case
-	  sensitive; using capital letters for netgroup names is an
-	  easy way to distinguish between user, machine and netgroup
-	  names.</para>
-
-	<para>Some <acronym>NIS</acronym> clients (other than &os;) cannot handle
-	  netgroups with a large number of entries.  For example, some
-	  older versions of &sunos; start to cause trouble if a
-	  netgroup contains more than 15 <emphasis>entries</emphasis>.
-	  This limit may be circumvented by creating several
-	  sub-netgroups with 15 users or fewer and a real netgroup
-	  consisting of the sub-netgroups:</para>
+	  systems within the <acronym>NIS</acronym> domain.  The names
+	  are case sensitive; using capital letters for netgroup names
+	  is an easy way to distinguish between user, machine and
+	  netgroup names.</para>
+
+	<para>Some <acronym>NIS</acronym> clients (other than &os;)
+	  cannot handle netgroups with a large number of entries.  For
+	  example, some older versions of &sunos; start to cause
+	  trouble if a netgroup contains more than 15
+	  <emphasis>entries</emphasis>.  This limit may be
+	  circumvented by creating several sub-netgroups with 15 users
+	  or fewer and a real netgroup consisting of the
+	  sub-netgroups:</para>
 
 	<programlisting>BIGGRP1  (,joe1,domain)  (,joe2,domain)  (,joe3,domain) [...]
 BIGGRP2  (,joe16,domain)  (,joe17,domain) [...]
@@ -2049,8 +2080,8 @@ BIGGROUP  BIGGRP1 BIGGRP2 BIGGRP3</progr
 	  within a single netgroup.</para>
       </note>
 
-      <para>Activating and distributing the new <acronym>NIS</acronym> map is
-	easy:</para>

*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***


More information about the svn-doc-all mailing list