Date: Mon, 27 May 2013 20:48:11 +0000 (UTC) From: Tom Rhodes <trhodes@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-projects@freebsd.org Subject: svn commit: r41757 - projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/network-servers Message-ID: <201305272048.r4RKmBFF051879@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: trhodes Date: Mon May 27 20:48:10 2013 New Revision: 41757 URL: http://svnweb.freebsd.org/changeset/doc/41757 Log: Markup, entities, avoid you, grammar, whitespace. Modified: projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Modified: projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml ============================================================================== --- projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Mon May 27 20:33:31 2013 (r41756) +++ projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Mon May 27 20:48:10 2013 (r41757) @@ -126,9 +126,9 @@ <sect2 id="network-inetd-overview"> <title>Overview</title> - <para>&man.inetd.8; is sometimes referred to as the + <para>The &man.inetd.8; daemon is sometimes referred to as the <quote>Internet Super-Server</quote> because it manages - connections for several services. When a connection is + connections for many services. When a connection is received by <application>inetd</application>, it determines which program the connection is destined for, spawns the particular process and delegates the socket to it (the program @@ -175,8 +175,7 @@ <screen>&prompt.root; <userinput>service inetd rcvar</userinput></screen> - <para> - can be run to display the current effective setting.</para> + <para>can be run to display the current effective setting.</para> <para>Additionally, different command-line options can be passed to <application>inetd</application> via the @@ -202,9 +201,9 @@ <para>Although we mention rate-limiting options below, novice users may be pleased to note that these parameters usually do - not need to be modified. These options may be useful should - you find that you are receiving an excessive amount of - connections. A full list of options can be found in the + not need to be modified. These options may be useful if + an excessive amount of connections are being established. + A full list of options can be found in the &man.inetd.8; manual.</para> <variablelist> @@ -509,7 +508,7 @@ server-program-arguments</programlisting place <option>max-connections-per-ip-per-minute</option>, <option>max-child</option> or <option>max-child-per-ip</option> limitations on certain - daemons if you find that you have too many connections.</para> + daemons if there are too many connections.</para> <para>By default, TCP wrapping is turned on. Consult the &man.hosts.access.5; manual page for more information on @@ -529,8 +528,7 @@ server-program-arguments</programlisting services of <application>inetd</application>.</para> <para>The <application>auth</application> service provides - identity - network services, and is + identity network services, and is configurable to a certain degree, whilst the others are simply on or off.</para> @@ -677,8 +675,8 @@ server-program-arguments</programlisting <para><acronym>NFS</acronym> configuration is a relatively straightforward process. The processes that need to be - running can all start at boot time with a few modifications to - your <filename>/etc/rc.conf</filename> file.</para> + running can all start at boot time with a few modifications + to <filename>/etc/rc.conf</filename>.</para> <para>On the <acronym>NFS</acronym> server, make sure that the following options are configured in the @@ -704,8 +702,8 @@ mountd_flags="-r"</programlisting> system. Along with what machines have access to that file system, access options may also be specified. There are many such options that can be used in this file but only a few will - be mentioned here. You can easily discover other options by - reading over the &man.exports.5; manual page.</para> + be mentioned here. Other options are discussed in + the &man.exports.5; manual page.</para> <para>Here are a few example <filename>/etc/exports</filename> entries:</para> @@ -717,11 +715,11 @@ mountd_flags="-r"</programlisting> <para>The following examples give an idea of how to export file systems, although the settings may be different depending - on your environment and network configuration. For instance, + on the environment and network configuration. For instance, to export the <filename>/cdrom</filename> directory to three example machines that have the same domain name as the server (hence the lack of a domain name for each) or have entries in - your <filename>/etc/hosts</filename> file. The + the <filename>/etc/hosts</filename> file. The <option>-ro</option> flag makes the exported file system read-only. With this flag, the remote system will not be able to write any changes to the exported file system.</para> @@ -729,7 +727,7 @@ mountd_flags="-r"</programlisting> <programlisting>/cdrom -ro host1 host2 host3</programlisting> <para>The following line exports <filename>/home</filename> to - three hosts by IP address. This is a useful setup if you have + three hosts by IP address. This is a useful setup on a private network without a <acronym>DNS</acronym> server configured. Optionally the <filename>/etc/hosts</filename> file could be configured for internal hostnames; please review @@ -755,8 +753,7 @@ mountd_flags="-r"</programlisting> <para>In order for a client to access an exported file system, the client must have permission to do so. Make sure the - client is listed in your <filename>/etc/exports</filename> - file.</para> + client is listed in <filename>/etc/exports</filename>.</para> <para>In <filename>/etc/exports</filename>, each line represents the export information for one file system to one host. A @@ -778,8 +775,9 @@ mountd_flags="-r"</programlisting> <para>The properties of one file system exported to a given host must all occur on one line. Lines without a client specified - are treated as a single host. This limits how you can export - file systems, but for most people this is not an issue.</para> + are treated as a single host. This limits how file systems + may be exported; however, for most environments, this is not + an issue.</para> <para>The following is an example of a valid export list, where <filename>/usr</filename> and <filename>/exports</filename> @@ -828,9 +826,8 @@ mountd_flags="-r"</programlisting> <para>Now everything should be ready to actually mount a remote file system. In these examples the server's name will be <hostid>server</hostid> and the client's name will be - <hostid>client</hostid>. If you only want to temporarily - mount a remote file system or would rather test the - configuration, just execute a command like this as + <hostid>client</hostid>. For testing or to temporarily + mount a remote file system execute a command like this as <username>root</username> on the client:</para> <indexterm> @@ -841,11 +838,11 @@ mountd_flags="-r"</programlisting> <para>This will mount the <filename>/home</filename> directory on the server at <filename>/mnt</filename> on the client. If - everything is set up correctly you should be able to enter - <filename>/mnt</filename> on the client and see all the files - that are on the server.</para> + everything is set up correctly, the server's files should be + visible and available in the <filename>/mnt</filename> + directory.</para> - <para>If you want to automatically mount a remote file system + <para>To permanently mount a remote file system each time the computer boots, add the file system to the <filename>/etc/fstab</filename> file. Here is an example:</para> @@ -911,10 +908,9 @@ rpc_statd_enable="YES"</programlisting> <listitem> <para>Several machines could have a common - <filename>/usr/ports/distfiles</filename> directory. That - way, when you need to install a port on several machines, - you can quickly access the source without downloading it - on each machine.</para> + <filename>/usr/ports/distfiles</filename> directory. This + allows for quick access to the source files without + downloading them on each machine.</para> </listitem> </itemizedlist> </sect2> @@ -974,10 +970,10 @@ rpc_statd_enable="YES"</programlisting> <title>Mounting an Export with <application>amd</application></title> - <para>You can view the available mounts of a remote host with - the <command>showmount</command> command. For example, to - view the mounts of a host named <hostid>foobar</hostid>, you - can use:</para> + <para>The <command>showmount</command> command shows the + available mounts on a remote host. For example, to + view the mounts of a host named + <hostid>foobar</hostid>:</para> <screen>&prompt.user; <userinput>showmount -e foobar</userinput> Exports list on foobar: @@ -1062,9 +1058,8 @@ Exports list on foobar: <para>It should be noted that there is a different problem, sometimes mistaken for this one, when the NFS servers and clients are on different networks. If that is the case, make - <emphasis>certain</emphasis> that your routers are routing the - necessary <acronym>UDP</acronym> information, or you will not - get anywhere, no matter what else you are doing.</para> + <emphasis>certain</emphasis> that the routers are routing the + necessary <acronym>UDP</acronym> information.</para> <para>In the following examples, <hostid>fastws</hostid> is the host (interface) name of a high-performance workstation, and @@ -1076,7 +1071,7 @@ Exports list on foobar: client for the exported file system. In all cases, note that additional options, such as <option>hard</option> or <option>soft</option> and <option>bg</option> may be desirable - in your application.</para> + in the application.</para> <para>Examples for the FreeBSD system (<hostid>freebox</hostid>) as the client in <filename>/etc/fstab</filename> on @@ -1211,12 +1206,12 @@ Exports list on foobar: </sect2> <sect2> - <title>Terms/Processes You Should Know</title> + <title><acronym>NIS</acronym>Terms and Processes</title> - <para>There are several terms and several important user - processes that you will come across when attempting to - implement NIS on FreeBSD, whether you are trying to create an - NIS server or act as an NIS client:</para> + <para>There are several terms and important user + processes that will be explained while attempting to + implement NIS on FreeBSD, regardless if the system is a + NIS server or a NIS client:</para> <indexterm> <primary><application>rpcbind</application></primary> @@ -1386,18 +1381,17 @@ Exports list on foobar: <sect3> <title>Planning</title> - <para>Let us assume that you are the administrator of a small - university lab. This lab, which consists of 15 FreeBSD + <para>Let us assume that an administrator of a small + university lab, which consists of 15 FreeBSD machines, currently has no centralized point of - administration; each machine has its own + 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 you add a user to the lab, you - must run <command>adduser</command> on all 15 machines. - Clearly, this has to change, so you have decided to convert - the lab to use NIS, using two of the machines as - servers.</para> + intervention; currently, a user is added to the lab, the + process must be ran on all 15 machines. + The lab would clearly benefit from the addition of two + <acronym>NIS</acronym> servers.</para> <para>Therefore, the configuration of the lab now looks something like:</para> @@ -1446,10 +1440,10 @@ Exports list on foobar: </tgroup> </informaltable> - <para>If you are setting up a NIS scheme for the first time, - it is a good idea to think through how you want to go about - it. No matter what the size of your network, there are a - few decisions that need to be made.</para> + <para>If this is the first time a <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> <sect4> <title>Choosing a NIS Domain Name</title> @@ -1458,8 +1452,8 @@ Exports list on foobar: <primary>NIS</primary> <secondary>domainname</secondary> </indexterm> - <para>This might not be the <quote>domainname</quote> that - you are used to. It is more accurately called the + <para>This might not be the normal <quote>domainname</quote> + for the network. It is more accurately called the <quote>NIS domainname</quote>. When a client broadcasts its requests for info, it includes the name of the NIS domain that it is part of. This is how multiple servers @@ -1471,19 +1465,19 @@ Exports list on foobar: domainname for their NIS domainname. This is not recommended as it can cause confusion when trying to debug network problems. The NIS domainname should be unique - within your network and it is helpful if it describes the + within the network and it is helpful if it describes the group of machines it represents. For example, the Art department at Acme Inc. might be in the <quote>acme-art</quote> NIS domain. For this example, - assume you have chosen the name + assume the chosen name will be <literal>test-domain</literal>.</para> <indexterm><primary>SunOS</primary></indexterm> <para>However, some operating systems (notably &sunos;) use their NIS domain name as their Internet domain name. If - one or more machines on your network have this - restriction, you <emphasis>must</emphasis> use the - Internet domain name as your NIS domain name.</para> + one or more machines on the network have this + restriction, it <emphasis>must</emphasis> be used as the + Internet domain name for the NIS domain name.</para> </sect4> <sect4> @@ -1496,16 +1490,15 @@ Exports list on foobar: for its NIS domain, very often the machine becomes unusable. The lack of user and group information causes most systems to temporarily freeze up. With this in mind - you should make sure to choose a machine that will not be - prone to being rebooted regularly, or one that might be + be sure to choose a machine that will not be + prone to being rebooted frequently, or one that might be used for development. The NIS server should ideally be a stand alone machine whose sole purpose in life is to be an - NIS server. If you have a network that is not very + NIS server. If the network is not very heavily used, it is acceptable to put the NIS server on a - machine running other services, just keep in mind that if - the NIS server becomes unavailable, it will affect - <emphasis>all</emphasis> of your NIS clients - adversely.</para> + machine running other services, however; if + the NIS server becomes unavailable, it will adversely affect + <emphasis>all</emphasis> NIS clients.</para> </sect4> </sect3> @@ -1540,11 +1533,10 @@ Exports list on foobar: <secondary>server configuration</secondary> </indexterm> <para>Setting up a master NIS server can be relatively - straight forward, depending on your needs. FreeBSD comes - with support for NIS out-of-the-box. All you need is to - add the following lines to - <filename>/etc/rc.conf</filename>, and FreeBSD will do the - rest for you.</para> + straight forward, depending on environmental needs. &os; + comes with support for NIS out-of-the-box. It only needs to + be enabled by adding the following lines to + <filename>/etc/rc.conf</filename>:</para> <procedure> <step> @@ -1574,8 +1566,8 @@ Exports list on foobar: </procedure> <note> - <para>Depending on your NIS setup, you may need to add - further entries. See the <link + <para>Depending on the NIS setup, additional entries may + be required. See the <link linkend="network-nis-server-is-client">section about NIS servers that are also NIS clients</link>, below, for details.</para> @@ -1583,7 +1575,7 @@ Exports list on foobar: <para>After setting up the above entries, run the command <command>/etc/netstart</command> as superuser. It will - set up everything for you, using the values you defined in + set up everything, using the values defined in <filename>/etc/rc.conf</filename>. As a last step, before initializing the NIS maps, start the <application>ypserv</application> daemon manually:</para> @@ -1602,44 +1594,44 @@ Exports list on foobar: that are kept in the <filename>/var/yp</filename> directory. They are generated from configuration files in the <filename>/etc</filename> directory of the NIS master, - with one exception: the - <filename>/etc/master.passwd</filename> file. This is for - a good reason, you do not want to propagate passwords to - your <username>root</username> and other administrative + with one exception: <filename>/etc/master.passwd</filename>. + This is for + a good reason, never propagate passwords for + <username>root</username> and other administrative accounts to all the servers in the NIS domain. Therefore, - before we initialize the NIS maps, you should:</para> + before the the NIS 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>You should remove all entries regarding system + <para>It is advisable to remove all entries regarding system accounts (<username>bin</username>, <username>tty</username>, <username>kmem</username>, <username>games</username>, etc), as well as any accounts - that you do not want to be propagated to the NIS clients + that do not need to be propagated to the NIS clients (for example <username>root</username> and any other UID 0 (superuser) accounts).</para> - <note><para>Make sure the + <note><para>Ensure the <filename>/var/yp/master.passwd</filename> is neither - group nor world readable (mode 600)! Use the - <command>chmod</command> command, if + group or world readable (mode 600)! Use the + <command>chmod</command> command, as appropriate.</para></note> <indexterm><primary>Tru64 UNIX</primary></indexterm> - <para>When you have finished, it is time to initialize the - NIS maps! FreeBSD includes a script named - <command>ypinit</command> to do this for you (see its + <para>When this task has been completed, it is time to + initialize the NIS maps. FreeBSD includes a script named + <command>ypinit</command> to do this (see its manual page for more information). Note that this script is available on most &unix; Operating Systems, but not on all. On Digital UNIX/Compaq Tru64 UNIX it is called <command>ypsetup</command>. Because we are generating maps for an NIS master, we are going to pass the <option>-m</option> option to <command>ypinit</command>. - To generate the NIS maps, assuming you already performed - the steps above, run:</para> + To generate the NIS maps run:</para> <screen>ellington&prompt.root; <userinput>ypinit -m test-domain</userinput> Server Type: MASTER Domain: test-domain @@ -1665,14 +1657,14 @@ 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><command>ypinit</command> should have created - <filename>/var/yp/Makefile</filename> from + <para>At this point, <command>ypinit</command> should have + created <filename>/var/yp/Makefile</filename> from <filename>/var/yp/Makefile.dist</filename>. - When created, this file assumes that you are operating - in a single server NIS environment with only FreeBSD + When created, this file assumes that the operating + environment is a single server NIS system with only &os; machines. Since <literal>test-domain</literal> has - a slave server as well, you must edit - <filename>/var/yp/Makefile</filename>:</para> + 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> @@ -1756,12 +1748,12 @@ ypxfr: Exiting: Map successfully transfe coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington.</screen> - <para>You should now have a directory called + <para>There should be a directory called <filename>/var/yp/test-domain</filename>. Copies of the - NIS master server's maps should be in this directory. You - will need to make sure that these stay updated. The + NIS 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 - your slave servers should do the job:</para> + the slave servers should do the job:</para> <programlisting>20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid</programlisting> @@ -1769,7 +1761,7 @@ Don't forget to update map ypservers on <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 + 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. @@ -1785,10 +1777,10 @@ Don't forget to update map ypservers on <sect3> <title>NIS Clients</title> - <para> An NIS client establishes what is called a binding to a + <para>An NIS client establishes what is called a binding to a particular NIS server using the - <command>ypbind</command> daemon. - <command>ypbind</command> checks the system's default + <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 @@ -1820,9 +1812,9 @@ Don't forget to update map ypservers on <procedure> <step> - <para>Edit the file <filename>/etc/rc.conf</filename> + <para>Edit <filename>/etc/rc.conf</filename> and add the following lines in order to set the NIS - domainname and start <command>ypbind</command> upon + domainname and start <command>ypbind</command> during network startup:</para> <programlisting>nisdomainname="test-domain" @@ -1831,7 +1823,7 @@ nis_client_enable="YES"</programlisting> <step> <para>To import all possible password entries from the - NIS server, remove all user accounts from your + NIS 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> @@ -1841,7 +1833,7 @@ nis_client_enable="YES"</programlisting> <note> <para>This line will afford anyone with a valid account in the NIS server's password maps an - account. There are many ways to configure your NIS + account. There are many ways to configure the NIS client by changing this line. See the <link linkend="network-netgroups">netgroups @@ -1851,8 +1843,8 @@ nis_client_enable="YES"</programlisting> </note> <note> - <para>You should keep at least one local account (i.e. - not imported via NIS) in your + <para>Keep in mind that at least one local account (i.e. + not imported via NIS) must exist in <filename>/etc/master.passwd</filename> and this account should also be a member of the group <groupname>wheel</groupname>. If there is something @@ -1864,8 +1856,8 @@ nis_client_enable="YES"</programlisting> <step> <para>To import all possible group entries from the NIS - server, add this line to your - <filename>/etc/group</filename> file:</para> + server, add this line to + <filename>/etc/group</filename>:</para> <programlisting>+:*::</programlisting> </step> @@ -1877,18 +1869,19 @@ nis_client_enable="YES"</programlisting> <screen>&prompt.root; <userinput>/etc/netstart</userinput> &prompt.root; <userinput>service ypbind start</userinput></screen> - <para>After completing these steps, you should be able to - run <command>ypcat passwd</command> and see the NIS + <para>After completing these steps, the command, + <command>ypcat passwd</command>, should show the server's passwd map.</para> - </sect4> </sect3> + </sect4> + </sect3> </sect2> <sect2> <title>NIS Security</title> - <para>In general, any remote user can issue an RPC to - &man.ypserv.8; and retrieve the contents of your NIS maps, - provided the remote user knows your domainname. To prevent + <para>In general, any remote user may issue an RPC to + &man.ypserv.8; and retrieve the contents of the NIS maps, + provided the remote user knows the domainname. To prevent 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, @@ -1934,7 +1927,7 @@ nis_client_enable="YES"</programlisting> <para>While both of these access control mechanisms provide some security, they, like the privileged port test, are vulnerable to <quote>IP spoofing</quote> attacks. All - NIS-related traffic should be blocked at your + NIS-related traffic should be blocked at the firewall.</para> <para>Servers using <filename>/var/yp/securenets</filename> @@ -1951,15 +1944,15 @@ nis_client_enable="YES"</programlisting> <para>Using <filename>/var/yp/securenets</filename> on a server with such an archaic implementation of TCP/IP is a really bad idea and will lead to loss of NIS functionality - for large parts of your network.</para> + for large parts of the network.</para> <indexterm><primary>TCP Wrappers</primary></indexterm> - <para>The use of the <application>TCP Wrapper</application> - package increases the latency of your NIS server. The + <para>The use of <application>TCP Wrapper</application> + increases the latency of the NIS 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 your client systems - suffers from these symptoms, you should convert the client + NIS servers. If one or more of the client systems + suffers from these symptoms, convert the client systems in question into NIS slave servers and force them to bind to themselves.</para> </note> @@ -1977,21 +1970,21 @@ nis_client_enable="YES"</programlisting> <para>There is a way to bar specific users from logging on to a machine, even if they are present in the NIS database. To do - this, all you must do is add + 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 you wish to bar from logging in. + the username of the user to bar from logging in. The line with the blocked user must be before the <literal>+</literal> line for allowing NIS users. This should preferably be done using <command>vipw</command>, - since <command>vipw</command> will sanity check your changes + since <command>vipw</command> will sanity check the changes to <filename>/etc/master.passwd</filename>, as well as - automatically rebuild the password database when you finish - editing. For example, if we wanted to bar user + automatically rebuild the password database after + editing. For example, to bar user <username>bill</username> from logging on to - <hostid>basie</hostid> we would:</para> + <hostid>basie</hostid>:</para> <screen>basie&prompt.root; <userinput>vipw</userinput> <userinput>[add -bill::::::::: to the end, exit]</userinput> @@ -2037,10 +2030,10 @@ basie&prompt.root;</screen> <indexterm><primary>netgroups</primary></indexterm> <para>The method shown in the previous section works reasonably - well if you need special rules for a very small number of - users and/or machines. On larger networks, you - <emphasis>will</emphasis> forget to bar some users from - logging onto sensitive machines, or you may even have to + well for special rules in an environment with small numbers of + users and/or machines. On larger networks, administrators + <emphasis>will</emphasis> likely forget to bar some users from + logging onto sensitive machines, or may even have to modify each machine separately, thus losing the main benefit of NIS: <emphasis>centralized</emphasis> administration.</para> @@ -2054,15 +2047,15 @@ basie&prompt.root;</screen> <para>Netgroups were developed to handle large, complex networks with hundreds of users and machines. On one hand, this is a - Good Thing if you are forced to deal with such a situation. + Good Thing in such a situation. On the other hand, this complexity makes it almost impossible to explain netgroups with really simple examples. The example used in the remainder of this section demonstrates this problem.</para> - <para>Let us assume that your successful introduction of NIS in - your laboratory caught your superiors' interest. Your next - job is to extend your NIS domain to cover some of the other + <para>Let us assume that the successful introduction of NIS in + the laboratory caught a superiors' interest. The next + task is to extend the NIS 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> @@ -2121,7 +2114,7 @@ basie&prompt.root;</screen> <entry><hostid>war</hostid>, <hostid>death</hostid>, <hostid>famine</hostid>, <hostid>pollution</hostid></entry> - <entry>Your most important servers. Only the IT + <entry>The most important servers deployed. Only the IT employees are allowed to log onto these machines.</entry> </row> @@ -2154,37 +2147,36 @@ basie&prompt.root;</screen> </tgroup> </informaltable> - <para>If you tried to implement these restrictions by separately - blocking each user, you would have to add one + <para>Attempting to implement these restrictions by separately + blocking each user, there would have to be an addition of the <literal>-<replaceable>user</replaceable></literal> line to - each system's <filename>passwd</filename> for each user who is - not allowed to login onto that system. If you forget just one - entry, you could be in trouble. It may be feasible to do this - correctly during the initial setup, however you - <emphasis>will</emphasis> eventually forget to add the lines - for new users during day-to-day operations. After all, Murphy - was an optimist.</para> + each system's <filename>passwd</filename>. One for each user + who is not allowed to login onto that system. Forgetting just one + entry, could cause significant trouble. It may be feasible to + do this correctly during the initial setup; however, eventually + someone will forget to add these lines + for new users.</para> <para>Handling this situation with netgroups offers several - advantages. Each user need not be handled separately; you - assign a user to one or more netgroups and allow or forbid - logins for all members of the netgroup. If you add a new - machine, you will only have to define login restrictions for - netgroups. If a new user is added, you will only have to add - the user to one or more netgroups. Those changes are + advantages. Each user need not be handled separately; they + would be assigned to one or more netgroups and allow or forbid + logins for all members of the netgroup. While 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 your NIS setup is planned - carefully, you will only have to modify exactly one central - configuration file to grant or deny access to machines.</para> + of user and machine do...</quote> If the NIS setup is planned + carefully, only one central configuration file + needs modified to grant or deny access to machines.</para> <para>The first step is the initialization of the NIS map - netgroup. FreeBSD's &man.ypinit.8; does not create this map - by default, but its NIS implementation will support it once it - has been created. To create an empty map, simply type</para> + netgroup. &os;'s &man.ypinit.8; does not create this map + by default, but its NIS 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> - <para>and start adding content. For our example, we need at + <para>and begin adding content. For our example, we need at least four netgroups: IT employees, IT apprentices, normal employees and interns.</para> @@ -2202,10 +2194,10 @@ INTERNS (,able,test-domain) (,baker, <orderedlist> <listitem> <para>The name of the host(s) where the following items are - valid. If you do not specify a hostname, the entry is - valid on all hosts. If you do specify a hostname, you - will enter a realm of darkness, horror and utter - confusion.</para> + valid. If a hostname is not specified, the entry is + valid on all hosts. If a hostname is specified, they + will need to be micro-managed within this + configuration.</para> </listitem> <listitem> @@ -2214,43 +2206,41 @@ INTERNS (,able,test-domain) (,baker, </listitem> <listitem> - <para>The NIS domain for the account. You can import - accounts from other NIS domains into your netgroup if you - are one of the unlucky fellows with more than one NIS - domain.</para> + <para>The NIS domain for the account. Accounts may be + imported from other NIS domains into a netgroup.</para> </listitem> </orderedlist> - <para>Each of these fields can contain wildcards. See + <para>Each of these fields may contain wildcards. See &man.netgroup.5; for details.</para> <note> <indexterm><primary>netgroups</primary></indexterm> <para>Netgroup names longer than 8 characters should not be - used, especially if you have machines running other - operating systems within your NIS domain. The names are - case sensitive; using capital letters for your netgroup + used, especially with machines running other + operating systems within the NIS 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 NIS clients (other than FreeBSD) cannot handle + <para>Some NIS 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>. - You can circumvent this limit by creating several - sub-netgroups with 15 users or less and a real netgroup that - consists of the sub-netgroups:</para> + 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) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3</programlisting> - <para>You can repeat this process if you need more than 225 - users within a single netgroup.</para> + <para>Repeat this process if more than 225 + users will exist within a single netgroup.</para> </note> - <para>Activating and distributing your new NIS map is + <para>Activating and distributing the new NIS map is easy:</para> <screen>ellington&prompt.root; <userinput>cd /var/yp</userinput> @@ -2260,7 +2250,7 @@ ellington&prompt.root; <userinput>make</ <filename>netgroup</filename>, <filename>netgroup.byhost</filename> and <filename>netgroup.byuser</filename>. Use &man.ypcat.1; to - check if your new NIS maps are available:</para> + check if the new NIS maps are available:</para> <screen>ellington&prompt.user; <userinput>ypcat -k netgroup</userinput> ellington&prompt.user; <userinput>ypcat -k netgroup.byhost</userinput> @@ -2268,13 +2258,13 @@ ellington&prompt.user; <userinput>ypcat <para>The output of the first command should resemble the contents of <filename>/var/yp/netgroup</filename>. The second - command will not produce output if you have not specified - host-specific netgroups. The third command can be used to + command will not produce output without specified + host-specific netgroups. The third command may be used to get the list of netgroups for a user.</para> <para>The client setup is quite simple. To configure the server - <hostid>war</hostid>, you only have to start - &man.vipw.8; and replace the line</para> + <hostid>war</hostid>, use + &man.vipw.8; to replace the line</para> <programlisting>+:::::::::</programlisting> @@ -2295,8 +2285,8 @@ ellington&prompt.user; <userinput>ypcat <command>ls -l</command> will show the numerical ID instead of the username and <command>find . -user joe -print</command> will fail with <errorname>No such user</errorname>. To fix - this, you will have to import all user entries - <emphasis>without allowing them to login onto your + this, import all user entries + <emphasis>without allowing them to login into the servers</emphasis>.</para> <para>This can be achieved by adding another line to @@ -2306,9 +2296,9 @@ ellington&prompt.user; <userinput>ypcat <para><literal>+:::::::::/sbin/nologin</literal>, meaning <quote>Import all entries but replace the shell with <filename>/sbin/nologin</filename> in the imported - entries</quote>. You can replace any field in the + entries</quote>. It is possible to replace any field in the <literal>passwd</literal> entry by placing a default value in - your <filename>/etc/master.passwd</filename>.</para> + <filename>/etc/master.passwd</filename>.</para> <!-- Been there, done that, got the scars to prove it - ue --> <warning> @@ -2320,9 +2310,9 @@ ellington&prompt.user; <userinput>ypcat shell.</para> </warning> - <para>After this change, you will only have to change one NIS - map if a new employee joins the IT department. You could use - a similar approach for the less important servers by replacing + <para>After this change, the NIS map will only need modified when + a new employee joins the IT department. A similar approach + for the less important servers may be used by replacing the old <literal>+:::::::::</literal> in their local version of <filename>/etc/master.passwd</filename> with something like this:</para> @@ -2342,16 +2332,16 @@ ellington&prompt.user; <userinput>ypcat change a few weeks later: The IT department starts hiring interns. The IT interns are allowed to use the normal workstations and the less important servers; and the IT - apprentices are allowed to login onto the main servers. You - add a new netgroup <literal>IT_INTERN</literal>, add the new - IT interns to this netgroup and start to change the - configuration on each and every machine... As the old saying + apprentices are allowed to login onto the main servers. + Add a new netgroup <literal>IT_INTERN</literal>, then add the + new IT interns to this netgroup and start to change the + configuration on each and every machine. As the old saying goes: <quote>Errors in centralized planning lead to global mess</quote>.</para> <para>NIS' ability to create netgroups from other netgroups can be used to prevent situations like these. One possibility is - the creation of role-based netgroups. For example, you could + the creation of role-based netgroups. For example, one might create a netgroup called <literal>BIGSRV</literal> to define the login restrictions for the important servers, another netgroup called <literal>SMALLSRV</literal> for the less @@ -2359,7 +2349,7 @@ ellington&prompt.user; <userinput>ypcat <literal>USERBOX</literal> for the normal workstations. Each of these netgroups contains the netgroups that are allowed to login onto these machines. The new - entries for your NIS map netgroup should look like + entries for the NIS map netgroup should look like this:</para> <programlisting>BIGSRV IT_EMP IT_APP @@ -2367,10 +2357,11 @@ SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS</programlisting> <para>This method of defining login restrictions works - reasonably well if you can define groups of machines with - identical restrictions. Unfortunately, this is the exception - and not the rule. Most of the time, you will need the ability - to define login restrictions on a per-machine basis.</para> + reasonably well when it is possible to define groups of machines + with identical restrictions. Unfortunately, this is the + exception and not the rule. Most of the time, the ability + to define login restrictions on a per-machine basis is + required.</para> <para>Machine-specific netgroup definitions are the other possibility to deal with the policy change outlined above. In @@ -2386,8 +2377,8 @@ USERBOX IT_EMP ITINTERN USERS</progra <programlisting>+@<replaceable>BOXNAME</replaceable>::::::::: +:::::::::/sbin/nologin</programlisting> - <para>Once you have completed this task for all your machines, - you will not have to modify the local versions of + <para>Once this task is completed on all the machines, + there is no longer a need to modify the local versions of <filename>/etc/master.passwd</filename> ever again. All further changes can be handled by modifying the NIS map. Here is an example of a possible netgroup map for this @@ -2429,32 +2420,33 @@ ONE SECURITY TWO (,hotel,test-domain) # [...more groups to follow]</programlisting> - <para>If you are using some kind of database to manage your user - accounts, you should be able to create the first part of the - map with your database's report tools. This way, new users + <para>If some kind of database is used to manage the user + accounts, it may be possible to create the first part of the + map using the database's reporting tools. This way, new users will automatically have access to the boxes.</para> <para>One last word of caution: It may not always be advisable - to use machine-based netgroups. If you are deploying a couple + to use machine-based netgroups. When deploying a couple of dozen or even hundreds of identical machines for student - labs, you should use role-based netgroups instead of - machine-based netgroups to keep the size of the NIS map within - reasonable limits.</para> + labs, the use of role-based netgroups instead of + machine-based netgroups may be used to keep the size of the NIS + map within reasonable limits.</para> </sect2> <sect2> <title>Important Things to Remember</title> - <para>There are still a couple of things that you will need to - do differently now that you are in an NIS environment.</para> + <para>There are still a couple of things administrators need to + do differently now that machines are in an NIS + environment.</para> <itemizedlist> <listitem> - <para>Every time you wish to add a user to the lab, you - must add it to the master NIS server - <emphasis>only</emphasis>, and <emphasis>you must remember - to rebuild the NIS maps</emphasis>. If you forget to do - this, the new user will not be able to login anywhere + <para>Every time a new user is added to the lab, they + must be added to the master NIS server + <emphasis>only</emphasis>, and <emphasis>remember + to rebuild the NIS maps</emphasis>. If this step is + missed, the new user will not be able to login anywhere except on the NIS master. For example, if we needed to add a new user <username>jsmith</username> to the lab, we would:</para> @@ -2463,16 +2455,17 @@ TWO (,hotel,test-domain) &prompt.root; <userinput>cd /var/yp</userinput> &prompt.root; <userinput>make test-domain</userinput></screen> - <para>You could also run <command>adduser jsmith</command> + <para>The user may also be added using + <command>adduser jsmith</command> instead of <command>pw useradd jsmith</command>.</para> </listitem> <listitem> <para><emphasis>Keep the administration accounts out of the - NIS maps</emphasis>. You do not want to be propagating - administrative accounts and passwords to machines that - will have users that should not have access to those - accounts.</para> + NIS maps</emphasis>. These users and passwords should + not be propagating to all machines. Especially if these + machines will have users whom should not have access to + those accounts.</para> </listitem> <listitem> <para><emphasis>Keep the NIS master and slave secure, and @@ -2482,8 +2475,9 @@ TWO (,hotel,test-domain) login to the lab.</para> <para>This is the chief weakness of any centralized - administration system. If you do not protect your NIS - servers, you will have a lot of angry users!</para> + administration system. If the NIS servers are not + protected, there will be a lot of angry users and + unhappy management!</para> </listitem> </itemizedlist> </sect2> @@ -2491,19 +2485,19 @@ TWO (,hotel,test-domain) <sect2> <title>NIS v1 Compatibility</title> - <para> FreeBSD's <application>ypserv</application> has some - support for serving NIS v1 clients. FreeBSD's NIS - implementation only uses the NIS v2 protocol, however other + <para>&os;'s <application>ypserv</application> has some + support for serving NIS v1 clients. &os;'s NIS *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201305272048.r4RKmBFF051879>