Date: Tue, 15 Oct 2013 16:57:03 +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: r42967 - head/en_US.ISO8859-1/books/handbook/network-servers Message-ID: <201310151657.r9FGv3UV054772@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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 ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201310151657.r9FGv3UV054772>