From owner-svn-doc-projects@FreeBSD.ORG Tue May 28 20:24:09 2013 Return-Path: Delivered-To: svn-doc-projects@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B7FD736B; Tue, 28 May 2013 20:24:09 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by mx1.freebsd.org (Postfix) with ESMTP id 4007C35E; Tue, 28 May 2013 20:24:08 +0000 (UTC) X-AuditID: 12074425-b7f986d00000082c-13-51a51135051a Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id D6.CA.02092.53115A15; Tue, 28 May 2013 16:19:01 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id r4SKJ18V029556; Tue, 28 May 2013 16:19:01 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r4SKIwPo020692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 May 2013 16:19:00 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r4SKIvRE005453; Tue, 28 May 2013 16:18:57 -0400 (EDT) Date: Tue, 28 May 2013 16:18:57 -0400 (EDT) From: Benjamin Kaduk To: Tom Rhodes Subject: Re: svn commit: r41757 - projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/network-servers In-Reply-To: <201305272048.r4RKmBFF051879@svn.freebsd.org> Message-ID: References: <201305272048.r4RKmBFF051879@svn.freebsd.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixCmqrWsquDTQ4OhrC4sfHw8xWSw8s5rZ 4u+GDywOzB4zPs1nCWCM4rJJSc3JLEst0rdL4MqYckmr4JFNxZT3PUwNjJf1uxg5OSQETCQm HZrADGGLSVy4t54NxBYS2Mco8W+ZRRcjF5C9kVHi9qbzLBDOISaJVateMUI4DYwSp6Z2ALVz cLAIaEt0d0aCdLMJqEjMfLMRbJIIkH334GkmEJtZwEZiwoMF7CC2sECexOole1lBbE4BK4lP E9eygYzhFXCQ6D3FDHGEpcSaN28ZQWxRAR2J1funsIDYvAKCEidnPmGBGGkp8W/tL9YJjIKz kKRmIUktYGRaxSibklulm5uYmVOcmqxbnJyYl5dapGuhl5tZopeaUrqJERSk7C6qOxgnHFI6 xCjAwajEwxvwdUmgEGtiWXFl7iFGSQ4mJVHe5bxLA4X4kvJTKjMSizPii0pzUosPMUpwMCuJ 8F5aCVTOm5JYWZValA+TkuZgURLnvZFy019IID2xJDU7NbUgtQgmK8PBoSTBe5ofaKhgUWp6 akVaZk4JQpqJgxNkOA/QcH8BoBre4oLE3OLMdIj8KUZFKXHefSAJAZBERmkeXC8sibxiFAd6 RZh3GkgVDzABwXW/AhrMBDRYnHkxyOCSRISUVANjSmfk2ysC7M4nP91Yx7pb9us0HgErNn9u JtU1m7fNmvG0JXyx/K1/OUG9IXdPHGc7b1R5xvMTk+4rjaq4/v+NAr/dargOrPl8d+33zQti w1MdNnXkm3+6GzXdwPTitXDWLzPOb31c4ra29ER/d8+E0AUiPbGpj26JnY2wyfr7bfOxhyfm sTyfrcRSnJFoqMVcVJwIANSrZyT9AgAA Cc: svn-doc-projects@freebsd.org, doc-committers@freebsd.org X-BeenThere: svn-doc-projects@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for doc projects trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 20:24:09 -0000 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; > > > > - If you tried to implement these restrictions by separately > - blocking each user, you would have to add one > + Attempting to implement these restrictions by separately > + blocking each user, there would have to be an addition of the > -user 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 passwd 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 > - will eventually forget to add the lines > - for new users during day-to-day operations. After all, Murphy > - was an optimist. > + each system's passwd. 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. > > 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 for each combination > - of user and machine do... 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. > + of user and machine do... If the NIS setup is planned > + carefully, only one central configuration file > + needs modified to grant or deny access to machines. s/modified/modification/ > > 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 > + 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 > > ellington&prompt.root; vi /var/yp/netgroup > > - and start adding content. For our example, we need at > + and begin adding content. For our example, we need at > least four netgroups: IT employees, IT apprentices, normal > employees and interns. > > @@ -2202,10 +2194,10 @@ INTERNS (,able,test-domain) (,baker, > > > 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. > + 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. "a hostname" and "they" have mismatching pluralness. > > > > @@ -2320,9 +2310,9 @@ ellington&prompt.user; ypcat > shell. > > > - 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 > + 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 +::::::::: in their local version > of /etc/master.passwd with something like > this: > @@ -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. > + 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. > [...] > + Every time a new user is added to the lab, they > + must be added to the master NIS server > + only, and remember > + to rebuild the NIS maps. 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 jsmith to the lab, we > would: > @@ -2463,16 +2455,17 @@ TWO (,hotel,test-domain) > - NIS maps. 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. > + NIS maps. 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. > > > Keep the NIS master and slave secure, and > > *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***