svn commit: r44432 - head/en_US.ISO8859-1/books/handbook/network-servers
Dru Lavigne
dru at FreeBSD.org
Thu Apr 3 23:19:12 UTC 2014
Author: dru
Date: Thu Apr 3 23:19:11 2014
New Revision: 44432
URL: http://svnweb.freebsd.org/changeset/doc/44432
Log:
White space fix only. Translators can ignore.
Sponsored by: iXsystems
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 Thu Apr 3 23:00:29 2014 (r44431)
+++ head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Thu Apr 3 23:19:11 2014 (r44432)
@@ -503,7 +503,7 @@ server-program-arguments</programlisting
remote systems as if they were stored locally.</para>
<para><acronym>NFS</acronym> has many practical uses. Some of
- the more common uses include:</para>
+ the more common uses include:</para>
<itemizedlist>
<listitem>
@@ -530,9 +530,8 @@ server-program-arguments</programlisting
<listitem>
<para>Administration of <acronym>NFS</acronym> exports is
- simplified. For example, there is only one file
- system where security or backup policies must be
- set.</para>
+ simplified. For example, there is only one file system
+ where security or backup policies must be set.</para>
</listitem>
<listitem>
@@ -545,11 +544,10 @@ server-program-arguments</programlisting
</listitem>
</itemizedlist>
- <para><acronym>NFS</acronym> consists of
- 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 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>
@@ -587,28 +585,28 @@ server-program-arguments</programlisting
<row>
<entry><application>nfsd</application></entry>
<entry>The <acronym>NFS</acronym> daemon which services
- requests from <acronym>NFS</acronym>
- clients.</entry>
+ requests from <acronym>NFS</acronym> clients.</entry>
</row>
<row>
<entry><application>mountd</application></entry>
<entry>The <acronym>NFS</acronym> mount daemon which
- carries out requests received from <application>nfsd</application>.</entry>
+ carries out requests received from
+ <application>nfsd</application>.</entry>
</row>
<row>
<entry><application>rpcbind</application></entry>
- <entry> This daemon allows
- <acronym>NFS</acronym> clients to discover which port
- the <acronym>NFS</acronym> server is using.</entry>
+ <entry> This daemon allows <acronym>NFS</acronym>
+ clients to discover which port the
+ <acronym>NFS</acronym> server is using.</entry>
</row>
</tbody>
</tgroup>
</informaltable>
- <para>Running &man.nfsiod.8; on the
- client can improve performance, but is not required.</para>
+ <para>Running &man.nfsiod.8; on the client can improve
+ performance, but is not required.</para>
<sect2 xml:id="network-configuring-nfs">
<title>Configuring the Server</title>
@@ -618,15 +616,14 @@ server-program-arguments</programlisting
<secondary>configuration</secondary>
</indexterm>
- <para>The file systems which the <acronym>NFS</acronym> server will
- share are specified in <filename>/etc/exports</filename>. Each
- line in this file specifies a file
- system to be exported, which clients have access to that
- file system, and any access options. When adding entries to this file,
- each exported file system, its properties, and allowed
- hosts must occur on a single line. If no clients are listed in the entry,
- then any client on the network can mount that file
- system.</para>
+ <para>The file systems which the <acronym>NFS</acronym> server
+ will share are specified in <filename>/etc/exports</filename>.
+ Each line in this file specifies a file system to be exported,
+ which clients have access to that file system, and any access
+ options. When adding entries to this file, each exported file
+ system, its properties, and allowed hosts must occur on a
+ single line. If no clients are listed in the entry, then any
+ client on the network can mount that file system.</para>
<indexterm>
<primary>NFS</primary>
@@ -634,24 +631,23 @@ server-program-arguments</programlisting
</indexterm>
<para>The following <filename>/etc/exports</filename> entries
- demonstrate how to export file systems.
- The examples can be modified to match the file systems
- and client names on the reader's network. There are many
- options that can be used in this file, but only a few
- will be mentioned here. See &man.exports.5; for the full list
- of options.</para>
+ demonstrate how to export file systems. The examples can be
+ modified to match the file systems and client names on the
+ reader's network. There are many options that can be used in
+ this file, but only a few will be mentioned here. See
+ &man.exports.5; for the full list of options.</para>
<para>This example shows how to export
- <filename>/cdrom</filename> to
- three hosts named <replaceable>alpha</replaceable>,
+ <filename>/cdrom</filename> to three hosts named
+ <replaceable>alpha</replaceable>,
<replaceable>bravo</replaceable>, and
<replaceable>charlie</replaceable>:</para>
<programlisting>/cdrom -ro <replaceable>alpha</replaceable> <replaceable>bravo</replaceable> <replaceable>charlie</replaceable></programlisting>
<para>The <literal>-ro</literal> flag makes the file system
- read-only, preventing clients from making any changes to
- the exported file system. This example assumes that the host
+ read-only, preventing clients from making any changes to the
+ exported file system. This example assumes that the host
names are either in <acronym>DNS</acronym> or in
<filename>/etc/hosts</filename>. Refer to &man.hosts.5; if
the network does not have a <acronym>DNS</acronym>
@@ -660,42 +656,40 @@ server-program-arguments</programlisting
<para>The next example exports <filename>/home</filename> to
three clients by <acronym>IP</acronym> address. This can be
useful for networks without <acronym>DNS</acronym> or
- <filename>/etc/hosts</filename> entries.
- The <literal>-alldirs</literal> flag
- allows subdirectories to be mount points. In other words, it
- will not automaticaly mount the subdirectories, but will permit the client to
- mount the directories that are required as needed.</para>
+ <filename>/etc/hosts</filename> entries. The
+ <literal>-alldirs</literal> flag allows subdirectories to be
+ mount points. In other words, it will not automaticaly mount
+ the subdirectories, but will permit the client to mount the
+ directories that are required as needed.</para>
<programlisting>/home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4</programlisting>
- <para>This next example exports <filename>/a</filename> so that two
- clients from different domains may access that file system.
- The <option>-maproot=root</option> allows
- <systemitem class="username">root</systemitem> on the
- remote system to write data on the exported file system as
- <systemitem class="username">root</systemitem>. If
+ <para>This next example exports <filename>/a</filename> so that
+ two clients from different domains may access that file
+ system. The <option>-maproot=root</option> allows <systemitem
+ class="username">root</systemitem> on the remote system to
+ write data on the exported file system as <systemitem
+ class="username">root</systemitem>. If
<literal>-maproot=root</literal> is not specified, the
client's <systemitem class="username">root</systemitem> user
will be mapped to the server's <systemitem
class="username">nobody</systemitem> account and will be
- subject to the access limitations defined for
- <systemitem class="username">nobody</systemitem>.</para>
+ subject to the access limitations defined for <systemitem
+ class="username">nobody</systemitem>.</para>
<programlisting>/a -maproot=root host.example.com box.example.org</programlisting>
- <para>A client can only be specified once per file
- system. For example, if
- <filename>/usr</filename> is a single file system, these
- entries would be
- invalid as both entries
- specify the same host:</para>
+ <para>A client can only be specified once per file system. For
+ example, if <filename>/usr</filename> is a single file system,
+ these entries would be invalid as both entries specify the
+ same host:</para>
<programlisting># Invalid when /usr is one file system
/usr/src client
/usr/ports client</programlisting>
- <para>The correct format for this
- situation is to use one entry:</para>
+ <para>The correct format for this situation is to use one
+ entry:</para>
<programlisting>/usr/src /usr/ports client</programlisting>
@@ -712,35 +706,35 @@ server-program-arguments</programlisting
/exports -alldirs -maproot=root client01 client02
/exports/obj -ro</programlisting>
- <para>To enable the processes required by the <acronym>NFS</acronym> server
- at boot time, add
- these options to
- <filename>/etc/rc.conf</filename>:</para>
+ <para>To enable the processes required by the
+ <acronym>NFS</acronym> server at boot time, add 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>
- <para>The server can be started now by
- running this command:</para>
+ <para>The server can be started now by running this
+ command:</para>
<screen>&prompt.root; <userinput>service nfsd start</userinput></screen>
<para>Whenever the <acronym>NFS</acronym> server is started,
<application>mountd</application> also starts automatically.
However, <application>mountd</application> only reads
- <filename>/etc/exports</filename> when it is started. To make subsequent
- <filename>/etc/exports</filename> edits take effect immediately,
- force <application>mountd</application> to reread it:</para>
+ <filename>/etc/exports</filename> when it is started. To make
+ subsequent <filename>/etc/exports</filename> edits take effect
+ immediately, force <application>mountd</application> to reread
+ it:</para>
<screen>&prompt.root; <userinput>service mountd reload</userinput></screen>
</sect2>
- <sect2>
+ <sect2>
<title>Configuring the Client</title>
- <para>To enable <acronym>NFS</acronym> clients, set this option in each client's
- <filename>/etc/rc.conf</filename>:</para>
+ <para>To enable <acronym>NFS</acronym> clients, set this option
+ in each client's <filename>/etc/rc.conf</filename>:</para>
<programlisting>nfs_client_enable="YES"</programlisting>
@@ -752,8 +746,8 @@ mountd_flags="-r"</programlisting>
<para>The client now has everything it needs to mount a remote
file system. In these examples, the server's name is
<systemitem>server</systemitem> and the client's name is
- <systemitem>client</systemitem>. To
- mount the <filename>/home</filename> file system on
+ <systemitem>client</systemitem>. To mount the
+ <filename>/home</filename> file system on
<systemitem>server</systemitem> to the
<filename>/mnt</filename> mount point on
<systemitem>client</systemitem>:</para>
@@ -764,10 +758,9 @@ mountd_flags="-r"</programlisting>
</indexterm>
<screen>&prompt.root; <userinput>mount server:/home /mnt</userinput></screen>
- <para>The files and
- directories in
- <filename>/home</filename> will now be available
- on <systemitem>client</systemitem>, in the
+ <para>The files and directories in
+ <filename>/home</filename> will now be available on
+ <systemitem>client</systemitem>, in the
<filename>/mnt</filename> directory.</para>
<para>To mount a remote file system each time the client boots,
@@ -782,8 +775,8 @@ mountd_flags="-r"</programlisting>
<sect2>
<title>Locking</title>
- <para>Some applications
- require file locking to operate correctly. To enable locking, add these lines to
+ <para>Some applications require file locking to operate
+ correctly. To enable locking, add these lines to
<filename>/etc/rc.conf</filename> on both the client and
server:</para>
@@ -797,8 +790,9 @@ rpc_statd_enable="YES"</programlisting>
<para>If locking is not required on the server, the
<acronym>NFS</acronym> client can be configured to lock
- locally by including <option>-L</option> when running <application>mount</application>.
- Refer to &man.mount.nfs.8; for further details.</para>
+ locally by including <option>-L</option> when running
+ <application>mount</application>. Refer to &man.mount.nfs.8;
+ for further details.</para>
</sect2>
<sect2 xml:id="network-amd">
@@ -831,27 +825,25 @@ rpc_statd_enable="YES"</programlisting>
</indexterm>
<para>The automatic mounter daemon,
- <application>amd</application>, automatically
- mounts a remote file system whenever a file or directory
- within that file system is accessed. File systems that are
- inactive for a period of time will be automatically
- unmounted by <application>amd</application>.</para>
-
-
- <para>This daemon provides an alternative to
- modifying <filename>/etc/fstab</filename> to list every
- client. It operates by attaching
- itself as an <acronym>NFS</acronym> server to the
- <filename>/host</filename> and
- <filename>/net</filename> directories. When
- a file is accessed within one of these directories,
+ <application>amd</application>, automatically mounts a remote
+ file system whenever a file or directory within that file
+ system is accessed. File systems that are inactive for a
+ period of time will be automatically unmounted by
+ <application>amd</application>.</para>
+
+ <para>This daemon provides an alternative to modifying
+ <filename>/etc/fstab</filename> to list every client. It
+ operates by attaching itself as an <acronym>NFS</acronym>
+ server to the <filename>/host</filename> and
+ <filename>/net</filename> directories. When a file is
+ accessed within one of these directories,
<application>amd</application> looks up the corresponding
remote mount and automatically mounts it.
<filename>/net</filename> is used to mount an exported file
system from an <acronym>IP</acronym> address while
<filename>/host</filename> is used to mount an export from a
- remote hostname. For instance, an attempt to access a file within
- <filename>/host/foobar/usr</filename> would tell
+ remote hostname. For instance, an attempt to access a file
+ within <filename>/host/foobar/usr</filename> would tell
<application>amd</application> to mount the
<filename>/usr</filename> export on the host
<systemitem>foobar</systemitem>.</para>
@@ -860,9 +852,10 @@ rpc_statd_enable="YES"</programlisting>
<title>Mounting an Export with
<application>amd</application></title>
- <para>In this example, <command>showmount -e</command> shows the exported file
- systems that can be mounted from the <acronym>NFS</acronym>
- server, <systemitem>foobar</systemitem>:</para>
+ <para>In this example, <command>showmount -e</command> shows
+ the exported file systems that can be mounted from the
+ <acronym>NFS</acronym> server,
+ <systemitem>foobar</systemitem>:</para>
<screen>&prompt.user; <userinput>showmount -e foobar</userinput>
Exports list on foobar:
@@ -888,7 +881,7 @@ Exports list on foobar:
<para>To start <application>amd</application> now:</para>
<screen>&prompt.root; <userinput>service amd start</userinput></screen>
-
+
<para>Custom flags can be passed to
<application>amd</application> from the
<varname>amd_flags</varname> environment variable. By
@@ -897,9 +890,8 @@ Exports list on foobar:
<programlisting>amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map"</programlisting>
<para>The default options with which exports are mounted are
- defined in <filename>/etc/amd.map</filename>.
- Some of the more
- advanced features of <application>amd</application> are
+ defined in <filename>/etc/amd.map</filename>. Some of the
+ more advanced features of <application>amd</application> are
defined in <filename>/etc/amd.conf</filename>.</para>
<para>Consult &man.amd.8; and &man.amd.conf.5; for more
@@ -930,46 +922,44 @@ Exports list on foobar:
</authorgroup>
</sect1info>
-->
- <title>Network Information System
- (<acronym>NIS</acronym>)</title>
+ <title>Network Information System
+ (<acronym>NIS</acronym>)</title>
- <indexterm><primary>NIS</primary></indexterm>
- <indexterm><primary>Solaris</primary></indexterm>
- <indexterm><primary>HP-UX</primary></indexterm>
- <indexterm><primary>AIX</primary></indexterm>
- <indexterm><primary>Linux</primary></indexterm>
- <indexterm><primary>NetBSD</primary></indexterm>
- <indexterm><primary>OpenBSD</primary></indexterm>
- <indexterm>
- <primary>yellow pages</primary>
- <see>NIS</see>
- </indexterm>
+ <indexterm><primary>NIS</primary></indexterm>
+ <indexterm><primary>Solaris</primary></indexterm>
+ <indexterm><primary>HP-UX</primary></indexterm>
+ <indexterm><primary>AIX</primary></indexterm>
+ <indexterm><primary>Linux</primary></indexterm>
+ <indexterm><primary>NetBSD</primary></indexterm>
+ <indexterm><primary>OpenBSD</primary></indexterm>
+ <indexterm>
+ <primary>yellow pages</primary>
+ <see>NIS</see>
+ </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>
+ <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>
+ <primary>NIS</primary>
+ <secondary>domains</secondary>
</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 to add, remove, or modify configuration
- data from a single location.</para>
+ <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 to add, remove,
+ or modify configuration data from a single location.</para>
- <para>&os; uses version 2 of the <acronym>NIS</acronym>
- protocol.</para>
+ <para>&os; uses version 2 of the <acronym>NIS</acronym>
+ protocol.</para>
<sect2>
<title><acronym>NIS</acronym> Terms and Processes</title>
@@ -1130,250 +1120,245 @@ Exports list on foobar:
<title>Planning Considerations</title>
<para>This section describes a sample <acronym>NIS</acronym>
- environment which consists of 15 &os; machines with
- 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, 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>
-
- <informaltable frame="none" pgwide="1">
- <tgroup cols="3">
- <thead>
- <row>
- <entry>Machine name</entry>
- <entry><acronym>IP</acronym> address</entry>
- <entry>Machine role</entry>
- </row>
- </thead>
-
- <tbody>
- <row>
- <entry><systemitem>ellington</systemitem></entry>
- <entry><systemitem
- class="ipaddress">10.0.0.2</systemitem></entry>
- <entry><acronym>NIS</acronym> master</entry>
- </row>
-
- <row>
- <entry><systemitem>coltrane</systemitem></entry>
- <entry><systemitem
- class="ipaddress">10.0.0.3</systemitem></entry>
- <entry><acronym>NIS</acronym> slave</entry>
- </row>
-
- <row>
- <entry><systemitem>basie</systemitem></entry>
- <entry><systemitem
- class="ipaddress">10.0.0.4</systemitem></entry>
- <entry>Faculty workstation</entry>
- </row>
-
- <row>
- <entry><systemitem>bird</systemitem></entry>
- <entry><systemitem
- class="ipaddress">10.0.0.5</systemitem></entry>
- <entry>Client machine</entry>
- </row>
-
- <row>
- <entry><systemitem>cli[1-11]</systemitem></entry>
- <entry>
- <systemitem
- class="ipaddress">10.0.0.[6-17]</systemitem></entry>
- <entry>Other client machines</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>If this is the first time an <acronym>NIS</acronym>
- scheme is being developed, it should be thoroughly planned
- ahead of time. Regardless of network size, several
- decisions need to be made as part of the planning
- process.</para>
-
- <sect3>
- <title>Choosing a <acronym>NIS</acronym> Domain Name</title>
-
- <indexterm>
- <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
- <acronym>NIS</acronym> domain name.</para>
- </sect3>
-
- <sect3>
- <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>
-
- <sect2>
- <title>Configuring the <acronym>NIS</acronym> Master
- Server</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
- <filename>/var/yp/[domainname]</filename> where
- <filename>[domainname]</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>
+ environment which consists of 15 &os; machines with 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, 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>
+
+ <informaltable frame="none" pgwide="1">
+ <tgroup cols="3">
+ <thead>
+ <row>
+ <entry>Machine name</entry>
+ <entry><acronym>IP</acronym> address</entry>
+ <entry>Machine role</entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry><systemitem>ellington</systemitem></entry>
+ <entry><systemitem
+ class="ipaddress">10.0.0.2</systemitem></entry>
+ <entry><acronym>NIS</acronym> master</entry>
+ </row>
+
+ <row>
+ <entry><systemitem>coltrane</systemitem></entry>
+ <entry><systemitem
+ class="ipaddress">10.0.0.3</systemitem></entry>
+ <entry><acronym>NIS</acronym> slave</entry>
+ </row>
+
+ <row>
+ <entry><systemitem>basie</systemitem></entry>
+ <entry><systemitem
+ class="ipaddress">10.0.0.4</systemitem></entry>
+ <entry>Faculty workstation</entry>
+ </row>
+
+ <row>
+ <entry><systemitem>bird</systemitem></entry>
+ <entry><systemitem
+ class="ipaddress">10.0.0.5</systemitem></entry>
+ <entry>Client machine</entry>
+ </row>
+
+ <row>
+ <entry><systemitem>cli[1-11]</systemitem></entry>
+ <entry>
+ <systemitem
+ class="ipaddress">10.0.0.[6-17]</systemitem></entry>
+ <entry>Other client machines</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+
+ <para>If this is the first time an <acronym>NIS</acronym>
+ scheme is being developed, it should be thoroughly planned
+ ahead of time. Regardless of network size, several decisions
+ need to be made as part of the planning process.</para>
- <indexterm><primary>NIS</primary>
- <secondary>server configuration</secondary>
+ <sect3>
+ <title>Choosing a <acronym>NIS</acronym> Domain Name</title>
+
+ <indexterm>
+ <primary>NIS</primary>
+ <secondary>domain name</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
- <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>
- </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>
- </step>
-
- <step>
- <programlisting>nis_yppasswdd_enable="YES"</programlisting>
-
- <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>
-
- <para>Care must be taken in a multi-server domain where the
- server machines are also <acronym>NIS</acronym> clients. It
- is generally a good idea to force the servers to bind to
- themselves rather than allowing them to broadcast bind
- requests and possibly become bound to each other. Strange
- failure modes can result if one server goes down and others
- are dependent upon it. Eventually, all the clients will
- time out and attempt to bind to other servers, but the delay
- involved can be considerable and the failure mode is still
- present since the servers might bind to each other all over
- again.</para>
-
- <para>A server that is also a client can be forced to bind to
- a particular server by adding these additional lines to
- <filename>/etc/rc.conf</filename>:</para>
+ <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>
- <programlisting>nis_client_enable="YES" # run client stuff as well
+ <sect3>
+ <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>
+
+ <sect2>
+ <title>Configuring the <acronym>NIS</acronym> Master
+ Server</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
+ <filename>/var/yp/[domainname]</filename> where
+ <filename>[domainname]</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>
+
+ <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
+ <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>
+ </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>
+ </step>
+
+ <step>
+ <programlisting>nis_yppasswdd_enable="YES"</programlisting>
+
+ <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>
+
+ <para>Care must be taken in a multi-server domain where the
+ server machines are also <acronym>NIS</acronym> clients. It
+ is generally a good idea to force the servers to bind to
+ themselves rather than allowing them to broadcast bind
+ requests and possibly become bound to each other. Strange
+ failure modes can result if one server goes down and others
+ are dependent upon it. Eventually, all the clients will time
+ out and attempt to bind to other servers, but the delay
+ involved can be considerable and the failure mode is still
+ present since the servers might bind to each other all over
+ again.</para>
+
+ <para>A server that is also a client can be forced to bind to a
+ particular server by adding these additional lines to
+ <filename>/etc/rc.conf</filename>:</para>
+
+ <programlisting>nis_client_enable="YES" # run client stuff as well
nis_client_flags="-S <replaceable>NIS domain</replaceable>,<replaceable>server</replaceable>"</programlisting>
- <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>
-
- <sect3>
- <title>Initializing the <acronym>NIS</acronym>
- Maps</title>
-
- <indexterm>
- <primary>NIS</primary>
- <secondary>maps</secondary>
- </indexterm>
- <para><acronym>NIS</acronym> maps are generated from the
- configuration files in <filename>/etc</filename> on the
- <acronym>NIS</acronym> master, with one exception:
- <filename>/etc/master.passwd</filename>. This is to
- prevent the propagation of 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>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>
+
+ <sect3>
+ <title>Initializing the <acronym>NIS</acronym> Maps</title>
+
+ <indexterm>
+ <primary>NIS</primary>
+ <secondary>maps</secondary>
+ </indexterm>
+ <para><acronym>NIS</acronym> maps are generated from the
+ configuration files in <filename>/etc</filename> on the
+ <acronym>NIS</acronym> master, with one exception:
+ <filename>/etc/master.passwd</filename>. This is to prevent
+ the propagation of 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>
+ <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 <systemitem class="username">root</systemitem> and
- any other administrative 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>
-
- <para>After completing this task, 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>
+ <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 <systemitem class="username">root</systemitem> and any
+ other administrative 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>
+
+ <para>After completing this task, 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>
+ <screen>ellington&prompt.root; <userinput>ypinit -m test-domain</userinput>
Server Type: MASTER Domain: test-domain
Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.
@@ -1397,63 +1382,58 @@ Is this correct? [y/n: y] <userinput>y<
NIS Map update completed.
ellington has been setup as an YP master server without any errors.</screen>
- <para>This will create
- <filename>/var/yp/Makefile</filename> from
- <filename>/var/yp/Makefile.dist</filename>. By
- default, this file assumes that the environment has a
- single <acronym>NIS</acronym> server with only &os;
- clients. Since <literal>test-domain</literal> has a
- slave server, edit this line in
- <filename>/var/yp/Makefile</filename> so that it begins
- with a comment (<literal>#</literal>):</para>
-
- <programlisting>NOPUSH = "True"</programlisting>
- </sect3>
-
- <sect3>
- <title>Adding New Users</title>
-
- <para>Every time a new user is created, the user account
- must be added to the master <acronym>NIS</acronym>
- server and the <acronym>NIS</acronym> maps rebuilt.
- Until this occurs, the new user will not be able to
- login anywhere except on the <acronym>NIS</acronym>
- master. For example, to add the new user
- <systemitem class="username">jsmith</systemitem> to the
- <literal>test-domain</literal> domain, run these
- commands on the master server:</para>
+ <para>This will create <filename>/var/yp/Makefile</filename>
+ from <filename>/var/yp/Makefile.dist</filename>. By
+ default, this file assumes that the environment has a
+ single <acronym>NIS</acronym> server with only &os; clients.
+ Since <literal>test-domain</literal> has a slave server,
+ edit this line in <filename>/var/yp/Makefile</filename> so
+ that it begins with a comment
+ (<literal>#</literal>):</para>
+
+ <programlisting>NOPUSH = "True"</programlisting>
+ </sect3>
+
+ <sect3>
+ <title>Adding New Users</title>
+
+ <para>Every time a new user is created, the user account must
+ be added to the master <acronym>NIS</acronym> server and the
+ <acronym>NIS</acronym> maps rebuilt. Until this occurs, the
+ new user will not be able to login anywhere except on the
+ <acronym>NIS</acronym> master. For example, to add the new
+ user <systemitem class="username">jsmith</systemitem> to the
+ <literal>test-domain</literal> domain, run these commands on
+ the master server:</para>
- <screen>&prompt.root; <userinput>pw useradd jsmith</userinput>
+ <screen>&prompt.root; <userinput>pw useradd jsmith</userinput>
&prompt.root; <userinput>cd /var/yp</userinput>
&prompt.root; <userinput>make test-domain</userinput></screen>
- <para>The user could also be added using <command>adduser
- jsmith</command> instead of <command>pw useradd
- jsmith</command>.</para>
- </sect3>
- </sect2>
-
- <sect2>
- <title>Setting up a <acronym>NIS</acronym> Slave
- Server</title>
-
- <indexterm>
- <primary>NIS</primary>
- <secondary>slave server</secondary>
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
More information about the svn-doc-all
mailing list