Date: Mon, 4 Jun 2001 20:08:21 -0400 (EDT) From: "Eric S. Van Gyzen" <esv@vangyzen.net> To: FreeBSD-gnats-submit@freebsd.org Subject: docs/27882: docs: Misspellings, Grammar Errors, Punctuation Errors Message-ID: <200106050008.f5508LS45713@hiro.vangyzen.net>
next in thread | raw e-mail | index | archive | help
>Number: 27882 >Category: docs >Synopsis: docs: Misspellings, Grammar Errors, Punctuation Errors >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Mon Jun 04 17:10:01 PDT 2001 >Closed-Date: >Last-Modified: >Originator: Eric S. Van Gyzen <esv@vangyzen.net> >Release: FreeBSD 4.3-STABLE i386 >Organization: >Environment: System: FreeBSD hiro.vangyzen.net 4.3-STABLE FreeBSD 4.3-STABLE #0: Tue Apr 24 13:30:09 EDT 2001 vangyzen@hiro.vangyzen.net:/usr/src/sys/compile/HIRO i386 Modified File: $FreeBSD: doc/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.41 2001/05/28 13:41:56 sheldonh Exp $ >Description: See the following "diff" for a full description of the problems I fixed. Most were obvious typos. I am fairly certain that none of my fixes altered the semantics of the content. Incidentally, this is a pretty good introduction to NIS. Thanks! >How-To-Repeat: N/A >Fix: *** chapter.sgml.orig Mon Jun 4 19:36:12 2001 --- chapter.sgml Mon Jun 4 19:48:23 2001 *************** *** 1456,1462 **** master's data files. NIS slave servers provide the redundancy, which is needed in important environments. They also help to balance the load of the master server: NIS Clients always ! attach to the NIS server, whose response they get first, and this includes slave-server-replies.</para> </listitem> <listitem> --- 1456,1462 ---- master's data files. NIS slave servers provide the redundancy, which is needed in important environments. They also help to balance the load of the master server: NIS Clients always ! attach to the NIS server whose response they get first, and this includes slave-server-replies.</para> </listitem> <listitem> *************** *** 1552,1558 **** that it is part of. This is how multiple servers on one network can tell which server should answer which request. Think of the NIS domainname as the name for a group of hosts ! that are related in someway way.</para> <para>Some organizations choose to use their Internet domainname for their NIS domainname. This is not recommended as it can --- 1552,1558 ---- that it is part of. This is how multiple servers on one network can tell which server should answer which request. Think of the NIS domainname as the name for a group of hosts ! that are related in some way.</para> <para>Some organizations choose to use their Internet domainname for their NIS domainname. This is not recommended as it can *************** *** 1641,1647 **** </listitem> </itemizedlist> ! <para>Now, everything you have to do is to run the command <command>/etc/netstart</command> as superuser. It will setup everything for you, using the values you defined in <filename>/etc/rc.conf</filename>.</para> --- 1641,1647 ---- </listitem> </itemizedlist> ! <para>Now, all you have to do is to run the command <command>/etc/netstart</command> as superuser. It will setup everything for you, using the values you defined in <filename>/etc/rc.conf</filename>.</para> *************** *** 1815,1822 **** <para>These two lines force the slave to sync its maps with the maps on the master server. Although this is not mandatory, because the master server ! tries to make sure any changes to it's NIS maps are ! communicated to it's slaves, the password information is so vital to systems that depend on the server, that it is a good idea to force the updates. This is more important on busy networks where map updates might not always --- 1815,1822 ---- <para>These two lines force the slave to sync its maps with the maps on the master server. Although this is not mandatory, because the master server ! tries to make sure any changes to its NIS maps are ! communicated to its slaves, the password information is so vital to systems that depend on the server, that it is a good idea to force the updates. This is more important on busy networks where map updates might not always *************** *** 1857,1863 **** <title>Setting up an NIS client</title> <para>Setting up a FreeBSD machine to be a NIS client is fairly ! straight forward.</para> <itemizedlist> <listitem> --- 1857,1863 ---- <title>Setting up an NIS client</title> <para>Setting up a FreeBSD machine to be a NIS client is fairly ! straightforward.</para> <itemizedlist> <listitem> *************** *** 2044,2050 **** 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 modify each ! machine separately, thus loosing the main benefit of NIS, <emphasis>centralized</emphasis> administration.</para> <para>The NIS developers' solution for this problem is called --- 2044,2050 ---- 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 modify each ! machine separately, thus losing the main benefit of NIS, <emphasis>centralized</emphasis> administration.</para> <para>The NIS developers' solution for this problem is called *************** *** 2122,2128 **** </row> <row> <!-- gluttony was omitted because it was too fat ;-) --> ! <entry>pride, greed, envy, wraith, lust, sloth</entry> <entry>Less important servers. All members of the IT department are allowed to login onto these machines.</entry> </row> --- 2122,2128 ---- </row> <row> <!-- gluttony was omitted because it was too fat ;-) --> ! <entry>pride, greed, envy, wrath, lust, sloth</entry> <entry>Less important servers. All members of the IT department are allowed to login onto these machines.</entry> </row> *************** *** 2148,2161 **** -<replaceable>user</replaceable> line to 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 ! 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> <para>Handling this situation with netgroups offers several advantages. Each user need not be handled separately; ! you assign a user to one or netgroup 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 --- 2148,2161 ---- -<replaceable>user</replaceable> line to 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 <emphasis>will</emphasis> eventually forget to add the lines for new users during day-to-day operations. After all, Murphy was an optimist.</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 *************** *** 2194,2200 **** <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 a realm of darkness, horror and utter confusion.</para> </listitem> <listitem> --- 2194,2200 ---- <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> </listitem> <listitem> *************** *** 2231,2237 **** <programlisting>BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] ! BIGGRP3 (,joe32,domain) (,joe33,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3</programlisting> <para>You can repeat this process if you need more than 225 --- 2231,2237 ---- <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 *************** *** 2250,2256 **** <filename>netgroup</filename>, <filename>netgroup.byhost</filename> and <filename>netgroup.byuser</filename>. Use &man.ypcat.1; to ! check if your new NIS map are available:</para> <screen> ellington&prompt.user; <userinput>ypcat -k netgroup</userinput> --- 2250,2256 ---- <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> <screen> ellington&prompt.user; <userinput>ypcat -k netgroup</userinput> >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106050008.f5508LS45713>