Attachment 14937 Details for Bug 27882 – file.diff

[patch] file.diff

file.diff (text/plain), 9.26 KB, created by Eric S. Van Gyzen on 2001-06-05 01:10:01 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Eric S. Van Gyzen

Created: 2001-06-05 01:10:01 UTC

Size: 9.26 KB

patch

obsolete

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

Actions: View | Diff

Attachments on bug 27882: 14937