svn commit: r41757 - projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/network-servers
Tom Rhodes
trhodes at FreeBSD.org
Mon May 27 20:48:11 UTC 2013
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 ***
More information about the svn-doc-projects
mailing list