svn commit: r41757 - projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/network-servers

[Benjamin Kaduk]

On Mon, 27 May 2013, Tom Rhodes wrote:

> 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)
> @@ -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

I think this sentence is not quite right with these changes -- there is no 
subject who is doing the attempting.  I think referring to "an attempt to 
implement these restrictions [...] would require [...]" would be better.

> -	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

This sentence is incomplete as well, it is dependent on the previous one.

> +	entry, could cause significant trouble.  It may be feasible to

This comma is not needed.

> +	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

The "allow or forbid logins" clause seems to be dangling, here; a rewrite 
as "logins would be allowed or forbidden for all members of the netgroup" 
should help.

> +	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>

s/modified/modification/

>
>       <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>

"a hostname" and "they" have mismatching pluralness.

> 	</listitem>
>
> 	<listitem>
> @@ -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

s/modified/modification/

> +	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>
> @@ -2429,32 +2420,33 @@ ONE       SECURITY
> -	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

"use of [...] may be used" is redundant.

> +	map within reasonable limits.</para>
>     </sect2>
[...]
> +	  <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

The person remembering to rebuild the maps is not the new user, but the 
text here implies that they are one and the same.  Probably just ", and 
the NIS maps must be rebuilt" is consistent with the new style of the 
document.

> +	    missed, the new user will not be able to login anywhere

"missed" is a strange word, here.  Perhaps "skipped" or "omitted"?

> 	    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)
> -	      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

propagating vs. propagated is an interesting question, here.

-Ben

> +	    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
>
> *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***