From owner-svn-doc-projects@FreeBSD.ORG Wed Jun 5 02:59:46 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 3A9C73F2; Wed, 5 Jun 2013 02:59:46 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id 1CAEC1D78; Wed, 5 Jun 2013 02:59:46 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r552xj10097205; Wed, 5 Jun 2013 02:59:45 GMT (envelope-from trhodes@svn.freebsd.org) Received: (from trhodes@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r552xjBZ097204; Wed, 5 Jun 2013 02:59:45 GMT (envelope-from trhodes@svn.freebsd.org) Message-Id: <201306050259.r552xjBZ097204@svn.freebsd.org> From: Tom Rhodes Date: Wed, 5 Jun 2013 02:59:45 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-projects@freebsd.org Subject: svn commit: r41842 - projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/network-servers X-SVN-Group: doc-projects MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: Wed, 05 Jun 2013 02:59:46 -0000 Author: trhodes Date: Wed Jun 5 02:59:45 2013 New Revision: 41842 URL: http://svnweb.freebsd.org/changeset/doc/41842 Log: Wording fixes. Suggested by: bjk 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 Wed Jun 5 02:33:36 2013 (r41841) +++ projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Wed Jun 5 02:59:45 2013 (r41842) @@ -2157,27 +2157,28 @@ basie&prompt.root; - Attempting to implement these restrictions by separately - blocking each user, there would have to be an addition of the + An attempt to implement these restrictions by separately + blocking each user, would require the addition of the -user line to - each system's passwd. One for each user + each system's passwd. One line 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 + 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. Handling this situation with netgroups offers several 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 + would be assigned to one or more netgroups and logins would + be allowed or forbidden 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 for each combination 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. + needs modification to grant or deny access to machines. The first step is the initialization of the NIS map netgroup. &os;'s &man.ypinit.8; does not create this map @@ -2205,7 +2206,7 @@ INTERNS (,able,test-domain) (,baker, The name of the host(s) where the following items are valid. If a hostname is not specified, the entry is - valid on all hosts. If a hostname is specified, they + valid on all hosts. If a hostname is specified, it will need to be micro-managed within this configuration. @@ -2320,8 +2321,8 @@ ellington&prompt.user; ypcat shell. - After this change, the NIS map will only need modified when - a new employee joins the IT department. A similar approach + After this change, the NIS map will only need modification + when 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 @@ -2438,7 +2439,7 @@ TWO (,hotel,test-domain) One last word of caution: It may not always be advisable to use machine-based netgroups. When deploying a couple of dozen or even hundreds of identical machines for student - labs, the use of role-based netgroups instead of + labs, role-based netgroups instead of machine-based netgroups may be used to keep the size of the NIS map within reasonable limits. @@ -2454,12 +2455,11 @@ TWO (,hotel,test-domain) 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 - 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 jsmith to the lab, we - would: + and the NIS maps will need rebuilt. If + this step is omitted, 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 jsmith to + the lab, we would: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp @@ -2472,8 +2472,9 @@ TWO (,hotel,test-domain) Keep the administration accounts out of the - NIS maps. These users and passwords should - not be propagating to all machines. Especially if these + NIS maps. This is undesirable as it will + create a security risk. These users and passwords should + not be propagated to all machines. Especially if these machines will have users whom should not have access to those accounts.