Date: Thu, 3 Apr 2014 23:19:11 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44432 - head/en_US.ISO8859-1/books/handbook/network-servers Message-ID: <201404032319.s33NJBVt047059@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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 ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201404032319.s33NJBVt047059>