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>
index | next in thread | raw e-mail
>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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106050008.f5508LS45713>