os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

In NIS section:

Browse source 
- Add various missing tags, change some tags for more "accurate" ones
- Some punctuation fixes
- s/id/ID for consistency with the rest of docs
- Typo fixing
This commit is contained in:
Marc Fonvieille 2004-06-23 16:38:42 +00:00
parent f494c2e6fe
commit 91b82e0fad
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=21248
1 changed files with 32 additions and 32 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

64
en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
View file

@ -4105,7 +4105,7 @@ nis_client_enable="YES"</programlisting>
account should also be a member of the group
<groupname>wheel</groupname>. If there is something
wrong with NIS, this account can be used to log in
remotely, become root, and fix things.</para>
remotely, become <username>root</username>, and fix things.</para>
</note>
</step>
@ -4132,7 +4132,7 @@ nis_client_enable="YES"</programlisting>
&man.ypserv.8; and retrieve the contents of your NIS maps,
provided the remote user knows your domainname. To prevent
such unauthorized transactions, &man.ypserv.8; supports a
feature called securenets which can be used to restrict access
feature called <quote>securenets</quote> which can be used to restrict access
to a given set of hosts. At startup, &man.ypserv.8; will
attempt to load the securenets information from a file called
<filename>/var/yp/securenets</filename>.</para>
@ -4275,13 +4275,13 @@ basie&prompt.root;</screen>
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,
machine separately, thus losing the main benefit of NIS:
<emphasis>centralized</emphasis> administration.</para>
<para>The NIS developers' solution for this problem is called
<emphasis>netgroups</emphasis>. Their purpose and semantics
can be compared to the normal groups used by &unix; file
systems. The main differences are the lack of a numeric id
systems. The main differences are the lack of a numeric ID
and the ability to define a netgroup by including both user
accounts and other netgroups.</para>
@ -4311,22 +4311,22 @@ basie&prompt.root;</screen>
<tbody>
<row>
<entry>alpha, beta</entry>
<entry><username>alpha</username>, <username>beta</username></entry>
<entry>Normal employees of the IT department</entry>
</row>
<row>
<entry>charlie, delta</entry>
<entry><username>charlie</username>, <username>delta</username></entry>
<entry>The new apprentices of the IT department</entry>
</row>
<row>
<entry>echo, foxtrott, golf, ...</entry>
<entry><username>echo</username>, <username>foxtrott</username>, <username>golf</username>, ...</entry>
<entry>Ordinary employees</entry>
</row>
<row>
<entry>able, baker, ...</entry>
<entry><username>able</username>, <username>baker</username>, ...</entry>
<entry>The current interns</entry>
</row>
</tbody>
@ -4346,27 +4346,27 @@ basie&prompt.root;</screen>
<row>
<!-- Names taken from "Good Omens" by Neil Gaiman and Terry
Pratchett. Many thanks for a brilliant book. -->
<entry>war, death, famine, pollution</entry>
<entry><hostid>war</hostid>, <hostid>death</hostid>, <hostid>famine</hostid>, <hostid>pollution</hostid></entry>
<entry>Your most important servers. Only the IT
employees are allowed to log onto these
machines.</entry>
</row>
<row>
<!-- gluttony was omitted because it was too fat -->
<entry>pride, greed, envy, wrath, lust, sloth</entry>
<entry><hostid>pride</hostid>, <hostid>greed</hostid>, <hostid>envy</hostid>, <hostid>wrath</hostid>, <hostid>lust</hostid>, <hostid>sloth</hostid></entry>
<entry>Less important servers. All members of the IT
department are allowed to login onto these machines.</entry>
</row>
<row>
<entry>one, two, three, four, ...</entry>
<entry><hostid>one</hostid>, <hostid>two</hostid>, <hostid>three</hostid>, <hostid>four</hostid>, ...</entry>
<entry>Ordinary workstations. Only the
<emphasis>real</emphasis> employees are allowed to use
these machines.</entry>
</row>
<row>
<entry>trashcan</entry>
<entry><hostid>trashcan</hostid></entry>
<entry>A very old machine without any critical data.
Even the intern is allowed to use this box.</entry>
</row>
@ -4376,7 +4376,7 @@ basie&prompt.root;</screen>
<para>If you tried to implement these restrictions by separately
blocking each user, you would have to add one
-<replaceable>user</replaceable> line to each system's
<literal>-<replaceable>user</replaceable></literal> line to each system's
<filename>passwd</filename>
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
@ -4392,7 +4392,7 @@ basie&prompt.root;</screen>
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
independent of each other; no more <quote>for each combination
independent of each other: no more <quote>for each combination
of user and machine do...</quote> 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.</para>
@ -4492,7 +4492,7 @@ ellington&prompt.user; <userinput>ypcat -k netgroup.byuser</userinput></screen>
get the list of netgroups for a user.</para>
<para>The client setup is quite simple. To configure the server
<replaceable>war</replaceable>, you only have to start
<hostid>war</hostid>, you only have to start
&man.vipw.8; and replace the line</para>
<programlisting>+:::::::::</programlisting>
@ -4502,15 +4502,15 @@ ellington&prompt.user; <userinput>ypcat -k netgroup.byuser</userinput></screen>
<programlisting>+@IT_EMP:::::::::</programlisting>
<para>Now, only the data for the users defined in the netgroup
<replaceable>IT_EMP</replaceable> is imported into
<replaceable>war</replaceable>'s password database and only
<literal>IT_EMP</literal> is imported into
<hostid>war</hostid>'s password database and only
these users are allowed to login.</para>
<para>Unfortunately, this limitation also applies to the ~
<para>Unfortunately, this limitation also applies to the <literal>~</literal>
function of the shell and all routines converting between user
names and numerical user IDs. In other words,
<command>cd ~<replaceable>user</replaceable></command> will not work,
<command>ls -l</command> will show the numerical id instead of
<command>ls -l</command> will show the numerical ID instead of
the username and <command>find . -user joe -print</command> will
fail with <errorname>No such user</errorname>. To fix this, you will
have to import all user entries <emphasis>without allowing them
@ -4524,7 +4524,7 @@ ellington&prompt.user; <userinput>ypcat -k netgroup.byuser</userinput></screen>
<quote>Import all entries but replace the shell with
<filename>/sbin/nologin</filename> in the imported
entries</quote>. You can replace any field
in the passwd entry by placing a default value in your
in the <literal>passwd</literal> entry by placing a default value in your
<filename>/etc/master.passwd</filename>.</para>
<!-- Been there, done that, got the scars to prove it - ue -->
@ -4532,7 +4532,7 @@ ellington&prompt.user; <userinput>ypcat -k netgroup.byuser</userinput></screen>
<para>Make sure that the line
<literal>+:::::::::/sbin/nologin</literal> is placed after
<literal>+@IT_EMP:::::::::</literal>. Otherwise, all user
accounts imported from NIS will have /sbin/nologin as their
accounts imported from NIS will have <filename>/sbin/nologin</filename> as their
login shell.</para>
</warning>
@ -4559,8 +4559,8 @@ ellington&prompt.user; <userinput>ypcat -k netgroup.byuser</userinput></screen>
interns. The IT interns are allowed to use the normal
workstations and the less important servers; and the IT
apprentices are allowed to login onto the main servers. You
add a new netgroup IT_INTERN, add the new IT interns to this
netgroup and start to change the config on each and every
add a new netgroup <literal>IT_INTERN</literal>, add the new IT interns to this
netgroup and start to change the configuration on each and every
machine... As the old saying goes: <quote>Errors in
centralized planning lead to global mess</quote>.</para>
@ -4568,11 +4568,11 @@ ellington&prompt.user; <userinput>ypcat -k netgroup.byuser</userinput></screen>
be used to prevent situations like these. One possibility
is the creation of role-based netgroups. For example, you
could create a netgroup called
<replaceable>BIGSRV</replaceable> to define the login
<literal>BIGSRV</literal> to define the login
restrictions for the important servers, another netgroup
called <replaceable>SMALLSRV</replaceable> for the less
called <literal>SMALLSRV</literal> for the less
important servers and a third netgroup called
<replaceable>USERBOX</replaceable> for the normal
<literal>USERBOX</literal> for the normal
workstations. Each of these netgroups contains the netgroups
that are allowed to login onto these machines. The new
entries for your NIS map netgroup should look like this:</para>
@ -4594,7 +4594,7 @@ USERBOX IT_EMP ITINTERN USERS</programlisting>
The first of them adds a netgroup with the accounts allowed to
login onto this machine, the second one adds all other
accounts with <filename>/sbin/nologin</filename> as shell. It
is a good idea to use the ALL-CAPS version of the machine name
is a good idea to use the <quote>ALL-CAPS</quote> version of the machine name
as the name of the netgroup. In other words, the lines should
look like this:</para>
@ -4606,7 +4606,7 @@ USERBOX IT_EMP ITINTERN USERS</programlisting>
<filename>/etc/master.passwd</filename> ever again. All
further changes can be handled by modifying the NIS map. Here
is an example of a possible netgroup map for this
scenario with some additional goodies.</para>
scenario with some additional goodies:</para>
<programlisting># Define groups of users first
IT_EMP (,alpha,test-domain) (,beta,test-domain)
@ -4671,7 +4671,7 @@ TWO (,hotel,test-domain)
maps</emphasis>. If you forget to do this, 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
<quote>jsmith</quote> to the lab, we would:</para>
<username>jsmith</username> to the lab, we would:</para>
<screen>&prompt.root; <userinput>pw useradd jsmith</userinput>
&prompt.root; <userinput>cd /var/yp</userinput>
@ -4713,7 +4713,7 @@ TWO (,hotel,test-domain)
server even though they may never actually need it (and they may
persist in broadcasting in search of one even after they receive a
response from a v2 server). Note that while support for normal
client calls is provided, this version of ypserv does not handle
client calls is provided, this version of <application>ypserv</application> does not handle
v1 map transfer requests; consequently, it cannot be used as a
master or slave in conjunction with older NIS servers that only
support the v1 protocol. Fortunately, there probably are not any
@ -4723,7 +4723,7 @@ TWO (,hotel,test-domain)
<sect2 id="network-nis-server-is-client">
<title>NIS Servers That Are Also NIS Clients</title>
<para> Care must be taken when running ypserv in a multi-server
<para> Care must be taken when running <application>ypserv</application> in a multi-server
domain where the server machines are also NIS clients. It is
generally a good idea to force the servers to bind to themselves
rather than allowing them to broadcast bind requests and possibly
@ -4781,7 +4781,7 @@ nis_client_flags="-S <replaceable>NIS domain</replaceable>,<replaceable>server</
<note><para>The format of passwords already in
<filename>/etc/master.passwd</filename> will not be updated until
a user changes their password for the first time <emphasis>after</emphasis>
a user changes his password for the first time <emphasis>after</emphasis>
the login capability database is rebuilt.</para></note>
<para>Next, in order to ensure that passwords are encrypted with the