Use ⋼ entity so that NIS is properly enclosed in <acronym> tags.
This commit is contained in:
Murray Stokely
parent
08cc311722
commit
bdd1483cee
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=21468
1 changed files with 149 additions and 149 deletions
|
|
@ -1080,14 +1080,14 @@ Exports list on foobar:
|
|||
<indexterm><primary>Linux</primary></indexterm>
|
||||
<indexterm><primary>NetBSD</primary></indexterm>
|
||||
<indexterm><primary>OpenBSD</primary></indexterm>
|
||||
<para>NIS, which stands for Network Information Services, was
|
||||
<para>⋼, which stands for Network Information Services, was
|
||||
developed by Sun Microsystems to centralize administration of &unix;
|
||||
(originally &sunos;) systems. It has now essentially become an
|
||||
industry standard; all major &unix; like systems (&solaris;, HP-UX, &aix;, Linux,
|
||||
NetBSD, OpenBSD, FreeBSD, etc) support NIS.</para>
|
||||
NetBSD, OpenBSD, FreeBSD, etc) support ⋼.</para>
|
||||
|
||||
<indexterm><primary>yellow pages</primary><see>NIS</see></indexterm>
|
||||
<para>NIS was formerly known as Yellow Pages, but because of
|
||||
<para>⋼ was formerly known as Yellow Pages, but because of
|
||||
trademark issues, Sun changed the name. The old term (and yp) is
|
||||
still often seen and used.</para>
|
||||
|
||||
|
|
@ -1096,9 +1096,9 @@ Exports list on foobar:
|
|||
<secondary>domains</secondary>
|
||||
</indexterm>
|
||||
<para>It is a RPC-based client/server system that allows a group
|
||||
of machines within an NIS domain to share a common set of
|
||||
of machines within an ⋼ domain to share a common set of
|
||||
configuration files. This permits a system administrator to set
|
||||
up NIS client systems with only minimal configuration data and
|
||||
up ⋼ client systems with only minimal configuration data and
|
||||
add, remove or modify configuration data from a single
|
||||
location.</para>
|
||||
|
||||
|
|
@ -1113,8 +1113,8 @@ Exports list on foobar:
|
|||
|
||||
<para>There are several terms and several important user processes
|
||||
that you will come across when
|
||||
attempting to implement NIS on FreeBSD, whether you are trying to
|
||||
create an NIS server or act as an NIS client:</para>
|
||||
attempting to implement ⋼ on FreeBSD, whether you are trying to
|
||||
create an ⋼ server or act as an ⋼ client:</para>
|
||||
|
||||
<indexterm>
|
||||
<primary><application>portmap</application></primary>
|
||||
|
|
@ -1133,38 +1133,38 @@ Exports list on foobar:
|
|||
</thead>
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>NIS domainname</entry>
|
||||
<entry>An NIS master server and all of its clients
|
||||
(including its slave servers) have a NIS
|
||||
domainname. Similar to an &windowsnt; domain name, the NIS
|
||||
domainname does not have anything to do with DNS.</entry>
|
||||
<entry>⋼ domainname</entry>
|
||||
<entry>An ⋼ master server and all of its clients
|
||||
(including its slave servers) have a ⋼
|
||||
domainname. Similar to an &windowsnt; domain name, the ⋼
|
||||
domainname does not have anything to do with <acronym>DNS</acronym>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><application>portmap</application></entry>
|
||||
<entry>Must be running in order to enable RPC (Remote
|
||||
Procedure Call, a network protocol used by NIS). If
|
||||
<entry>Must be running in order to enable <acronym>RPC</acronym> (Remote
|
||||
Procedure Call, a network protocol used by ⋼). If
|
||||
<application>portmap</application> is not running, it will be
|
||||
impossible to run an NIS server, or to act as an NIS
|
||||
impossible to run an ⋼ server, or to act as an NIS
|
||||
client.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><application>ypbind</application></entry>
|
||||
|
||||
<entry><quote>Binds</quote> an NIS client to its NIS
|
||||
server. It will take the NIS domainname from the
|
||||
system, and using RPC, connect to the
|
||||
<entry><quote>Binds</quote> an ⋼ client to its ⋼
|
||||
server. It will take the ⋼ domainname from the
|
||||
system, and using <acronym>RPC</acronym>, connect to the
|
||||
server. <application>ypbind</application> is the core of
|
||||
client-server communication in an NIS environment; if
|
||||
client-server communication in an ⋼ environment; if
|
||||
<application>ypbind</application> dies on a client machine, it
|
||||
will not be able to access the NIS server.</entry>
|
||||
will not be able to access the ⋼ server.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><application>ypserv</application></entry>
|
||||
<entry>Should only be running on NIS servers; this is the NIS
|
||||
<entry>Should only be running on ⋼ servers; this is the ⋼
|
||||
server process itself. If &man.ypserv.8; dies, then the
|
||||
server will no longer be able to respond to NIS requests
|
||||
server will no longer be able to respond to ⋼ requests
|
||||
(hopefully, there is a slave server to take over for
|
||||
it). There are some implementations of NIS (but not the
|
||||
it). There are some implementations of ⋼ (but not the
|
||||
FreeBSD one), that do not try to reconnect to another
|
||||
server if the server it used before dies. Often, the
|
||||
only thing that helps in this case is to restart the
|
||||
|
|
@ -1175,9 +1175,9 @@ Exports list on foobar:
|
|||
<row>
|
||||
<entry><application>rpc.yppasswdd</application></entry>
|
||||
<entry>Another process that should only be running on
|
||||
NIS master servers; this is a daemon that will allow NIS
|
||||
clients to change their NIS passwords. If this daemon
|
||||
is not running, users will have to login to the NIS
|
||||
⋼ master servers; this is a daemon that will allow ⋼
|
||||
clients to change their ⋼ passwords. If this daemon
|
||||
is not running, users will have to login to the ⋼
|
||||
master server and change their passwords there.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
|
|
@ -1191,7 +1191,7 @@ Exports list on foobar:
|
|||
<sect2>
|
||||
<title>How Does It Work?</title>
|
||||
|
||||
<para>There are three types of hosts in an NIS environment: master
|
||||
<para>There are three types of hosts in an ⋼ environment: master
|
||||
servers, slave servers, and clients. Servers act as a central
|
||||
repository for host configuration information. Master servers
|
||||
hold the authoritative copy of this information, while slave
|
||||
|
|
@ -1200,10 +1200,10 @@ Exports list on foobar:
|
|||
|
||||
<para>Information in many files can be shared in this manner. The
|
||||
<filename>master.passwd</filename>, <filename>group</filename>,
|
||||
and <filename>hosts</filename> files are commonly shared via NIS.
|
||||
and <filename>hosts</filename> files are commonly shared via ⋼.
|
||||
Whenever a process on a client needs information that would
|
||||
normally be found in these files locally, it makes a query to the
|
||||
NIS server that it is bound to instead.</para>
|
||||
⋼ server that it is bound to instead.</para>
|
||||
|
||||
<sect3>
|
||||
<title>Machine Types</title>
|
||||
|
|
@ -1214,30 +1214,30 @@ Exports list on foobar:
|
|||
<secondary>master server</secondary>
|
||||
</indexterm>
|
||||
<listitem>
|
||||
<para>A <emphasis>NIS master server</emphasis>.
|
||||
<para>A <emphasis>⋼ master server</emphasis>.
|
||||
This server, analogous to a &windowsnt;
|
||||
primary domain controller, maintains the files used by all
|
||||
of the NIS clients. The <filename>passwd</filename>,
|
||||
of the ⋼ clients. The <filename>passwd</filename>,
|
||||
<filename>group</filename>, and other various files used by the
|
||||
NIS clients live on the master server.</para>
|
||||
⋼ clients live on the master server.</para>
|
||||
|
||||
<note><para>It is possible for one machine to be an NIS
|
||||
master server for more than one NIS domain. However, this will
|
||||
<note><para>It is possible for one machine to be an ⋼
|
||||
master server for more than one ⋼ domain. However, this will
|
||||
not be covered in this introduction, which assumes a relatively
|
||||
small-scale NIS environment.</para></note>
|
||||
small-scale ⋼ environment.</para></note>
|
||||
</listitem>
|
||||
<indexterm>
|
||||
<primary>NIS</primary>
|
||||
<secondary>slave server</secondary>
|
||||
</indexterm>
|
||||
<listitem>
|
||||
<para><emphasis>NIS slave servers</emphasis>.
|
||||
<para><emphasis>⋼ slave servers</emphasis>.
|
||||
Similar to the &windowsnt; backup domain
|
||||
controllers, NIS slave servers maintain copies of the NIS
|
||||
master's data files. NIS slave servers provide the redundancy,
|
||||
controllers, ⋼ slave servers maintain copies of the ⋼
|
||||
master's data files. ⋼ 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
|
||||
to balance the load of the master server: ⋼ Clients always
|
||||
attach to the ⋼ server whose response they get first, and
|
||||
this includes slave-server-replies.</para>
|
||||
</listitem>
|
||||
<indexterm>
|
||||
|
|
@ -1245,8 +1245,8 @@ Exports list on foobar:
|
|||
<secondary>client</secondary>
|
||||
</indexterm>
|
||||
<listitem>
|
||||
<para><emphasis>NIS clients</emphasis>. NIS clients, like most
|
||||
&windowsnt; workstations, authenticate against the NIS server (or the &windowsnt;
|
||||
<para><emphasis>⋼ clients</emphasis>. ⋼ clients, like most
|
||||
&windowsnt; workstations, authenticate against the ⋼ server (or the &windowsnt;
|
||||
domain controller in the &windowsnt; workstations case) to log on.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
|
@ -1254,9 +1254,9 @@ Exports list on foobar:
|
|||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Using NIS/YP</title>
|
||||
<title>Using ⋼/YP</title>
|
||||
|
||||
<para>This section will deal with setting up a sample NIS
|
||||
<para>This section will deal with setting up a sample ⋼
|
||||
environment.</para>
|
||||
|
||||
<note><para>This section assumes that you are running FreeBSD 3.3
|
||||
|
|
@ -1278,7 +1278,7 @@ Exports list on foobar:
|
|||
currently, when you add a user to the lab, you must run
|
||||
<command>adduser</command> on all 15 machines.
|
||||
Clearly, this has to change, so you have decided to convert the
|
||||
lab to use NIS, using two of the machines as servers.</para>
|
||||
lab to use ⋼, using two of the machines as servers.</para>
|
||||
|
||||
<para>Therefore, the configuration of the lab now looks something
|
||||
like:</para>
|
||||
|
|
@ -1296,12 +1296,12 @@ Exports list on foobar:
|
|||
<row>
|
||||
<entry><hostid>ellington</hostid></entry>
|
||||
<entry><hostid role="ipaddr">10.0.0.2</hostid></entry>
|
||||
<entry>NIS master</entry>
|
||||
<entry>⋼ master</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><hostid>coltrane</hostid></entry>
|
||||
<entry><hostid role="ipaddr">10.0.0.3</hostid></entry>
|
||||
<entry>NIS slave</entry>
|
||||
<entry>⋼ slave</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><hostid>basie</hostid></entry>
|
||||
|
|
@ -1322,13 +1322,13 @@ Exports list on foobar:
|
|||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>If you are setting up a NIS scheme for the first time, it
|
||||
<para>If you are setting up a ⋼ scheme for the first time, it
|
||||
is a good idea to think through how you want to go about it. No
|
||||
matter what the size of your network, there are a few decisions
|
||||
that need to be made.</para>
|
||||
|
||||
<sect4>
|
||||
<title>Choosing a NIS Domain Name</title>
|
||||
<title>Choosing a ⋼ Domain Name</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>NIS</primary>
|
||||
|
|
@ -1336,83 +1336,83 @@ Exports list on foobar:
|
|||
</indexterm>
|
||||
<para>This might not be the <quote>domainname</quote> that you
|
||||
are used to. It is more accurately called the
|
||||
<quote>NIS domainname</quote>. When a client broadcasts its
|
||||
requests for info, it includes the name of the NIS domain
|
||||
<quote>⋼ domainname</quote>. When a client broadcasts its
|
||||
requests for info, it includes the name of the ⋼ domain
|
||||
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
|
||||
Think of the ⋼ 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
|
||||
domainname for their ⋼ domainname. This is not
|
||||
recommended as it can cause confusion when trying to debug
|
||||
network problems. The NIS domainname should be unique
|
||||
network problems. The ⋼ domainname should be unique
|
||||
within your network and it is helpful if it describes the
|
||||
group of machines it represents. For example, the Art
|
||||
department at Acme Inc. might be in the
|
||||
<quote>acme-art</quote> NIS domain. For this example,
|
||||
<quote>acme-art</quote> ⋼ domain. For this example,
|
||||
assume you have chosen the name
|
||||
<literal>test-domain</literal>.</para>
|
||||
|
||||
<indexterm><primary>SunOS</primary></indexterm>
|
||||
<para>However, some operating systems (notably &sunos;) use their
|
||||
NIS domain name as their Internet domain name.
|
||||
⋼ domain name as their Internet domain name.
|
||||
If one or more machines on your network have this restriction,
|
||||
you <emphasis>must</emphasis> use the Internet domain name as
|
||||
your NIS domain name.</para>
|
||||
your ⋼ domain name.</para>
|
||||
</sect4>
|
||||
|
||||
<sect4>
|
||||
<title>Physical Server Requirements</title>
|
||||
|
||||
<para>There are several things to keep in mind when choosing a
|
||||
machine to use as a NIS server. One of the unfortunate things
|
||||
about NIS is the level of dependency the clients have on the
|
||||
server. If a client cannot contact the server for its NIS
|
||||
machine to use as a ⋼ server. One of the unfortunate things
|
||||
about ⋼ is the level of dependency the clients have on the
|
||||
server. If a client cannot contact the server for its ⋼
|
||||
domain, very often the machine becomes unusable. The lack of
|
||||
user and group information causes most systems to temporarily
|
||||
freeze up. With this in mind you should make sure to choose a
|
||||
machine that will not be prone to being rebooted regularly, or
|
||||
one that might be used for development. The NIS server should
|
||||
one that might be used for development. The ⋼ server should
|
||||
ideally be a stand alone machine whose sole purpose in life is
|
||||
to be an NIS server. If you have a network that is not very
|
||||
heavily used, it is acceptable to put the NIS server on a
|
||||
to be an ⋼ server. If you have a network that is not very
|
||||
heavily used, it is acceptable to put the ⋼ server on a
|
||||
machine running other services, just keep in mind that if the
|
||||
NIS server becomes unavailable, it will affect
|
||||
<emphasis>all</emphasis> of your NIS clients adversely.</para>
|
||||
⋼ server becomes unavailable, it will affect
|
||||
<emphasis>all</emphasis> of your ⋼ clients adversely.</para>
|
||||
</sect4>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>NIS Servers</title>
|
||||
<title>⋼ Servers</title>
|
||||
|
||||
<para> The canonical copies of all NIS information are stored on
|
||||
a single machine called the NIS master server. The databases
|
||||
used to store the information are called NIS maps. In FreeBSD,
|
||||
<para> The canonical copies of all ⋼ information are stored on
|
||||
a single machine called the ⋼ master server. The databases
|
||||
used to store the information are called ⋼ maps. In FreeBSD,
|
||||
these maps are stored in
|
||||
<filename>/var/yp/[domainname]</filename> where
|
||||
<filename>[domainname]</filename> is the name of the NIS domain
|
||||
being served. A single NIS server can support several domains
|
||||
<filename>[domainname]</filename> is the name of the ⋼ domain
|
||||
being served. A single ⋼ server can support several domains
|
||||
at once, therefore it is possible to have several such
|
||||
directories, one for each supported domain. Each domain will
|
||||
have its own independent set of maps.</para>
|
||||
|
||||
<para>NIS master and slave servers handle all NIS requests with
|
||||
<para>⋼ master and slave servers handle all ⋼ requests with
|
||||
the <command>ypserv</command> daemon. <command>ypserv</command>
|
||||
is responsible for receiving incoming requests from NIS clients,
|
||||
is responsible for receiving incoming requests from ⋼ clients,
|
||||
translating the requested domain and map name to a path to the
|
||||
corresponding database file and transmitting data from the
|
||||
database back to the client.</para>
|
||||
|
||||
<sect4>
|
||||
<title>Setting Up a NIS Master Server</title>
|
||||
<title>Setting Up a ⋼ Master Server</title>
|
||||
<indexterm>
|
||||
<primary>NIS</primary>
|
||||
<secondary>server configuration</secondary>
|
||||
</indexterm>
|
||||
<para>Setting up a master NIS server can be relatively straight
|
||||
<para>Setting up a master ⋼ server can be relatively straight
|
||||
forward, depending on your needs. FreeBSD comes with support
|
||||
for NIS out-of-the-box. All you need is to add the following
|
||||
for ⋼ out-of-the-box. All you need is to add the following
|
||||
lines to <filename>/etc/rc.conf</filename>, and FreeBSD will
|
||||
do the rest for you.</para>
|
||||
|
||||
|
|
@ -1425,22 +1425,22 @@ Exports list on foobar:
|
|||
</step>
|
||||
<step>
|
||||
<para><programlisting>nis_server_enable="YES"</programlisting>
|
||||
This will tell FreeBSD to start up the NIS server processes
|
||||
This will tell FreeBSD to start up the ⋼ server processes
|
||||
when the networking is next brought up.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para><programlisting>nis_yppasswdd_enable="YES"</programlisting>
|
||||
This will enable the <command>rpc.yppasswdd</command>
|
||||
daemon which, as mentioned above, will allow users to
|
||||
change their NIS password from a client machine.</para>
|
||||
change their ⋼ password from a client machine.</para>
|
||||
</step>
|
||||
</procedure>
|
||||
|
||||
<note>
|
||||
<para>Depending on your NIS setup, you may need to add
|
||||
<para>Depending on your ⋼ setup, you may need to add
|
||||
further entries. See the <link
|
||||
linkend="network-nis-server-is-client">section about NIS servers
|
||||
that are also NIS clients</link>, below, for
|
||||
linkend="network-nis-server-is-client">section about ⋼ servers
|
||||
that are also ⋼ clients</link>, below, for
|
||||
details.</para>
|
||||
</note>
|
||||
|
||||
|
|
@ -1451,20 +1451,20 @@ Exports list on foobar:
|
|||
</sect4>
|
||||
|
||||
<sect4>
|
||||
<title>Initializing the NIS Maps</title>
|
||||
<title>Initializing the ⋼ Maps</title>
|
||||
<indexterm>
|
||||
<primary>NIS</primary>
|
||||
<secondary>maps</secondary>
|
||||
</indexterm>
|
||||
<para>The <emphasis>NIS maps</emphasis> are database files,
|
||||
<para>The <emphasis>⋼ maps</emphasis> are database files,
|
||||
that are kept in the <filename>/var/yp</filename> directory.
|
||||
They are generated from configuration files in the
|
||||
<filename>/etc</filename> directory of the NIS master, with one
|
||||
<filename>/etc</filename> directory of the ⋼ master, with one
|
||||
exception: the <filename>/etc/master.passwd</filename> file.
|
||||
This is for a good reason, you do not want to propagate
|
||||
passwords to your <username>root</username> and other
|
||||
administrative accounts to all the servers in the NIS domain.
|
||||
Therefore, before we initialize the NIS maps, you should:</para>
|
||||
administrative accounts to all the servers in the ⋼ domain.
|
||||
Therefore, before we initialize the ⋼ maps, you should:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>cp /etc/master.passwd /var/yp/master.passwd</userinput>
|
||||
&prompt.root; <userinput>cd /var/yp</userinput>
|
||||
|
|
@ -1474,7 +1474,7 @@ Exports list on foobar:
|
|||
(<username>bin</username>, <username>tty</username>,
|
||||
<username>kmem</username>, <username>games</username>, etc), as
|
||||
well as any accounts that you do not want to be propagated to the
|
||||
NIS clients (for example <username>root</username> and any other
|
||||
⋼ clients (for example <username>root</username> and any other
|
||||
UID 0 (superuser) accounts).</para>
|
||||
|
||||
<note><para>Make sure the
|
||||
|
|
@ -1490,10 +1490,10 @@ Exports list on foobar:
|
|||
script is available on most &unix; Operating Systems, but not on all.
|
||||
On Digital UNIX/Compaq Tru64 UNIX it is called
|
||||
<command>ypsetup</command>.
|
||||
Because we are generating maps for an NIS master, we are
|
||||
Because we are generating maps for an ⋼ master, we are
|
||||
going to pass the <option>-m</option> option to
|
||||
<command>ypinit</command>.
|
||||
To generate the NIS maps, assuming you already performed
|
||||
To generate the ⋼ maps, assuming you already performed
|
||||
the steps above, run:</para>
|
||||
|
||||
<screen>ellington&prompt.root; <userinput>ypinit -m test-domain</userinput>
|
||||
|
|
@ -1510,7 +1510,7 @@ done with the list, type a <control D>.
|
|||
master server : ellington
|
||||
next host to add: <userinput>coltrane</userinput>
|
||||
next host to add: <userinput>^D</userinput>
|
||||
The current list of NIS servers looks like this:
|
||||
The current list of ⋼ servers looks like this:
|
||||
ellington
|
||||
coltrane
|
||||
Is this correct? [y/n: y] <userinput>y</userinput>
|
||||
|
|
@ -1524,7 +1524,7 @@ ellington has been setup as an YP master server without any errors.</screen>
|
|||
<filename>/var/yp/Makefile</filename> from
|
||||
<filename>/var/yp/Makefile.dist</filename>.
|
||||
When created, this file assumes that you are operating
|
||||
in a single server NIS environment with only FreeBSD
|
||||
in a single server ⋼ environment with only FreeBSD
|
||||
machines. Since <literal>test-domain</literal> has
|
||||
a slave server as well, you must edit
|
||||
<filename>/var/yp/Makefile</filename>:</para>
|
||||
|
|
@ -1539,12 +1539,12 @@ ellington has been setup as an YP master server without any errors.</screen>
|
|||
</sect4>
|
||||
|
||||
<sect4>
|
||||
<title>Setting up a NIS Slave Server</title>
|
||||
<title>Setting up a ⋼ Slave Server</title>
|
||||
<indexterm>
|
||||
<primary>NIS</primary>
|
||||
<secondary>slave server</secondary>
|
||||
</indexterm>
|
||||
<para>Setting up an NIS slave server is even more simple than
|
||||
<para>Setting up an ⋼ slave server is even more simple than
|
||||
setting up the master. Log on to the slave server and edit the
|
||||
file <filename>/etc/rc.conf</filename> as you did before.
|
||||
The only difference is that we now must use the
|
||||
|
|
@ -1623,22 +1623,22 @@ Don't forget to update map ypservers on ellington.</screen>
|
|||
<para>These two lines force the slave to sync its maps with
|
||||
the maps on the master server. Although these entries are
|
||||
not mandatory, since the master server attempts to ensure
|
||||
any changes to its NIS maps are communicated to its slaves
|
||||
any changes to its ⋼ maps are communicated to its slaves
|
||||
and because password information is vital to systems
|
||||
depending on the server, it is a good idea to force the
|
||||
updates. This is more important on busy networks where map
|
||||
updates might not always complete.</para>
|
||||
|
||||
<para>Now, run the command <command>/etc/netstart</command> on the
|
||||
slave server as well, which again starts the NIS server.</para>
|
||||
slave server as well, which again starts the ⋼ server.</para>
|
||||
</sect4>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>NIS Clients</title>
|
||||
<title>⋼ Clients</title>
|
||||
|
||||
<para> An NIS client establishes what is called a binding to a
|
||||
particular NIS server using the
|
||||
<para> An ⋼ client establishes what is called a binding to a
|
||||
particular ⋼ server using the
|
||||
<command>ypbind</command> daemon.
|
||||
<command>ypbind</command> checks the system's default
|
||||
domain (as set by the <command>domainname</command> command),
|
||||
|
|
@ -1651,7 +1651,7 @@ Don't forget to update map ypservers on ellington.</screen>
|
|||
address. If there are several servers available (a master and
|
||||
several slaves, for example), <command>ypbind</command> will
|
||||
use the address of the first one to respond. From that point
|
||||
on, the client system will direct all of its NIS requests to
|
||||
on, the client system will direct all of its ⋼ requests to
|
||||
that server. <command>ypbind</command> will
|
||||
occasionally <quote>ping</quote> the server to make sure it is
|
||||
still up and running. If it fails to receive a reply to one of
|
||||
|
|
@ -1661,18 +1661,18 @@ Don't forget to update map ypservers on ellington.</screen>
|
|||
server.</para>
|
||||
|
||||
<sect4>
|
||||
<title>Setting Up a NIS Client</title>
|
||||
<title>Setting Up a ⋼ Client</title>
|
||||
<indexterm>
|
||||
<primary>NIS</primary>
|
||||
<secondary>client configuration</secondary>
|
||||
</indexterm>
|
||||
<para>Setting up a FreeBSD machine to be a NIS client is fairly
|
||||
<para>Setting up a FreeBSD machine to be a ⋼ client is fairly
|
||||
straightforward.</para>
|
||||
|
||||
<procedure>
|
||||
<step>
|
||||
<para>Edit the file <filename>/etc/rc.conf</filename> and
|
||||
add the following lines in order to set the NIS domainname
|
||||
add the following lines in order to set the ⋼ domainname
|
||||
and start <command>ypbind</command> upon network
|
||||
startup:</para>
|
||||
|
||||
|
|
@ -1691,8 +1691,8 @@ nis_client_enable="YES"</programlisting>
|
|||
|
||||
<note>
|
||||
<para>This line will afford anyone with a valid account in
|
||||
the NIS server's password maps an account. There are
|
||||
many ways to configure your NIS client by changing this
|
||||
the ⋼ server's password maps an account. There are
|
||||
many ways to configure your ⋼ client by changing this
|
||||
line. See the <link linkend="network-netgroups">netgroups
|
||||
section</link> below for more information.
|
||||
For more detailed reading see O'Reilly's book on
|
||||
|
|
@ -1720,17 +1720,17 @@ nis_client_enable="YES"</programlisting>
|
|||
</procedure>
|
||||
|
||||
<para>After completing these steps, you should be able to run
|
||||
<command>ypcat passwd</command> and see the NIS server's
|
||||
<command>ypcat passwd</command> and see the ⋼ server's
|
||||
passwd map.</para>
|
||||
</sect4>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>NIS Security</title>
|
||||
<title>&nis Security</title>
|
||||
|
||||
<para>In general, any remote user can issue an RPC to
|
||||
&man.ypserv.8; and retrieve the contents of your NIS maps,
|
||||
&man.ypserv.8; and retrieve the contents of your ⋼ maps,
|
||||
provided the remote user knows your domainname. To prevent
|
||||
such unauthorized transactions, &man.ypserv.8; supports a
|
||||
feature called <quote>securenets</quote> which can be used to restrict access
|
||||
|
|
@ -1779,7 +1779,7 @@ nis_client_enable="YES"</programlisting>
|
|||
NIS-related traffic should be blocked at your firewall.</para>
|
||||
|
||||
<para>Servers using <filename>/var/yp/securenets</filename>
|
||||
may fail to serve legitimate NIS clients with archaic TCP/IP
|
||||
may fail to serve legitimate ⋼ clients with archaic TCP/IP
|
||||
implementations. Some of these implementations set all
|
||||
host bits to zero when doing broadcasts and/or fail to
|
||||
observe the subnet mask when calculating the broadcast
|
||||
|
|
@ -1790,17 +1790,17 @@ nis_client_enable="YES"</programlisting>
|
|||
|
||||
<para>Using <filename>/var/yp/securenets</filename> on a
|
||||
server with such an archaic implementation of TCP/IP is a
|
||||
really bad idea and will lead to loss of NIS functionality
|
||||
really bad idea and will lead to loss of ⋼ functionality
|
||||
for large parts of your network.</para>
|
||||
|
||||
<indexterm><primary>tcpwrapper</primary></indexterm>
|
||||
<para>The use of the <application>tcpwrapper</application>
|
||||
package increases the latency of your NIS server. The
|
||||
package increases the latency of your ⋼ server. The
|
||||
additional delay may be long enough to cause timeouts in
|
||||
client programs, especially in busy networks or with slow
|
||||
NIS servers. If one or more of your client systems
|
||||
⋼ servers. If one or more of your client systems
|
||||
suffers from these symptoms, you should convert the client
|
||||
systems in question into NIS slave servers and force them
|
||||
systems in question into ⋼ slave servers and force them
|
||||
to bind to themselves.</para>
|
||||
</note>
|
||||
</sect2>
|
||||
|
|
@ -1810,12 +1810,12 @@ nis_client_enable="YES"</programlisting>
|
|||
|
||||
<para>In our lab, there is a machine <hostid>basie</hostid> that is
|
||||
supposed to be a faculty only workstation. We do not want to take this
|
||||
machine out of the NIS domain, yet the <filename>passwd</filename>
|
||||
file on the master NIS server contains accounts for both faculty and
|
||||
machine out of the ⋼ domain, yet the <filename>passwd</filename>
|
||||
file on the master ⋼ server contains accounts for both faculty and
|
||||
students. What can we do?</para>
|
||||
|
||||
<para>There is a way to bar specific users from logging on to a
|
||||
machine, even if they are present in the NIS database. To do this,
|
||||
machine, even if they are present in the ⋼ database. To do this,
|
||||
all you must do is add
|
||||
<literal>-<replaceable>username</replaceable></literal> to the end of
|
||||
the <filename>/etc/master.passwd</filename> file on the client
|
||||
|
|
@ -1879,7 +1879,7 @@ basie&prompt.root;</screen>
|
|||
machine separately, thus losing the main benefit of NIS:
|
||||
<emphasis>centralized</emphasis> administration.</para>
|
||||
|
||||
<para>The NIS developers' solution for this problem is called
|
||||
<para>The ⋼ 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
|
||||
|
|
@ -1894,9 +1894,9 @@ basie&prompt.root;</screen>
|
|||
used in the remainder of this section demonstrates this
|
||||
problem.</para>
|
||||
|
||||
<para>Let us assume that your successful introduction of NIS in
|
||||
<para>Let us assume that your successful introduction of ⋼ in
|
||||
your laboratory caught your superiors' interest. Your next
|
||||
job is to extend your NIS domain to cover some of the other
|
||||
job is to extend your ⋼ domain to cover some of the other
|
||||
machines on campus. The two tables contain the names of the
|
||||
new users and new machines as well as brief descriptions of
|
||||
them.</para>
|
||||
|
|
@ -1994,13 +1994,13 @@ basie&prompt.root;</screen>
|
|||
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
|
||||
of user and machine do...</quote> If your NIS setup is planned
|
||||
of user and machine do...</quote> If your ⋼ setup is planned
|
||||
carefully, you will only have to modify exactly one central
|
||||
configuration file to grant or deny access to machines.</para>
|
||||
|
||||
<para>The first step is the initialization of the NIS map
|
||||
<para>The first step is the initialization of the ⋼ map
|
||||
netgroup. FreeBSD's &man.ypinit.8; does not create this map by
|
||||
default, but its NIS implementation will support it once it has
|
||||
default, but its ⋼ implementation will support it once it has
|
||||
been created. To create an empty map, simply type</para>
|
||||
|
||||
<screen>ellington&prompt.root; <userinput>vi /var/yp/netgroup</userinput></screen>
|
||||
|
|
@ -2034,8 +2034,8 @@ INTERNS (,able,test-domain) (,baker,test-domain)</programlisting>
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The NIS domain for the account. You can import
|
||||
accounts from other NIS domains into your netgroup if you
|
||||
<para>The ⋼ domain for the account. You can import
|
||||
accounts from other ⋼ domains into your netgroup if you
|
||||
are one of the unlucky fellows with more than one NIS
|
||||
domain.</para>
|
||||
</listitem>
|
||||
|
|
@ -2048,12 +2048,12 @@ INTERNS (,able,test-domain) (,baker,test-domain)</programlisting>
|
|||
<indexterm><primary>netgroups</primary></indexterm>
|
||||
<para>Netgroup names longer than 8 characters should not be
|
||||
used, especially if you have machines running other
|
||||
operating systems within your NIS domain. The names are
|
||||
operating systems within your ⋼ domain. The names are
|
||||
case sensitive; using capital letters for your netgroup
|
||||
names is an easy way to distinguish between user, machine
|
||||
and netgroup names.</para>
|
||||
|
||||
<para>Some NIS clients (other than FreeBSD) cannot handle
|
||||
<para>Some ⋼ clients (other than FreeBSD) cannot handle
|
||||
netgroups with a large number of entries. For example, some
|
||||
older versions of &sunos; start to cause trouble if a netgroup
|
||||
contains more than 15 <emphasis>entries</emphasis>. You can
|
||||
|
|
@ -2070,17 +2070,17 @@ BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3</programlisting>
|
|||
users within a single netgroup.</para>
|
||||
</note>
|
||||
|
||||
<para>Activating and distributing your new NIS map is
|
||||
<para>Activating and distributing your new ⋼ map is
|
||||
easy:</para>
|
||||
|
||||
<screen>ellington&prompt.root; <userinput>cd /var/yp</userinput>
|
||||
ellington&prompt.root; <userinput>make</userinput></screen>
|
||||
|
||||
<para>This will generate the three NIS maps
|
||||
<para>This will generate the three ⋼ maps
|
||||
<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>
|
||||
check if your new ⋼ maps are available:</para>
|
||||
|
||||
<screen>ellington&prompt.user; <userinput>ypcat -k netgroup</userinput>
|
||||
ellington&prompt.user; <userinput>ypcat -k netgroup.byhost</userinput>
|
||||
|
|
@ -2133,7 +2133,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 <filename>/sbin/nologin</filename> as their
|
||||
accounts imported from ⋼ will have <filename>/sbin/nologin</filename> as their
|
||||
login shell.</para>
|
||||
</warning>
|
||||
|
||||
|
|
@ -2176,7 +2176,7 @@ ellington&prompt.user; <userinput>ypcat -k netgroup.byuser</userinput></screen>
|
|||
<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>
|
||||
entries for your ⋼ map netgroup should look like this:</para>
|
||||
|
||||
<programlisting>BIGSRV IT_EMP IT_APP
|
||||
SMALLSRV IT_EMP IT_APP ITINTERN
|
||||
|
|
@ -2205,7 +2205,7 @@ USERBOX IT_EMP ITINTERN USERS</programlisting>
|
|||
<para>Once you have completed this task for all your machines,
|
||||
you will not have to modify the local versions of
|
||||
<filename>/etc/master.passwd</filename> ever again. All
|
||||
further changes can be handled by modifying the NIS map. Here
|
||||
further changes can be handled by modifying the ⋼ map. Here
|
||||
is an example of a possible netgroup map for this
|
||||
scenario with some additional goodies:</para>
|
||||
|
||||
|
|
@ -2254,7 +2254,7 @@ TWO (,hotel,test-domain)
|
|||
to use machine-based netgroups. If you are deploying a couple of
|
||||
dozen or even hundreds of identical machines for student labs,
|
||||
you should use role-based netgroups instead of machine-based
|
||||
netgroups to keep the size of the NIS map within reasonable
|
||||
netgroups to keep the size of the ⋼ map within reasonable
|
||||
limits.</para>
|
||||
</sect2>
|
||||
|
||||
|
|
@ -2262,15 +2262,15 @@ TWO (,hotel,test-domain)
|
|||
<title>Important Things to Remember</title>
|
||||
|
||||
<para>There are still a couple of things that you will need to do
|
||||
differently now that you are in an NIS environment.</para>
|
||||
differently now that you are in an ⋼ environment.</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Every time you wish to add a user to the lab, you
|
||||
must add it to the master NIS server <emphasis>only</emphasis>,
|
||||
must add it to the master ⋼ server <emphasis>only</emphasis>,
|
||||
and <emphasis>you must remember to rebuild the NIS
|
||||
maps</emphasis>. If you forget to do this, the new user will
|
||||
not be able to login anywhere except on the NIS master.
|
||||
not be able to login anywhere except on the ⋼ master.
|
||||
For example, if we needed to add a new user
|
||||
<username>jsmith</username> to the lab, we would:</para>
|
||||
|
||||
|
|
@ -2288,7 +2288,7 @@ TWO (,hotel,test-domain)
|
|||
should not have access to those accounts.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis>Keep the NIS master and slave
|
||||
<para><emphasis>Keep the ⋼ master and slave
|
||||
secure, and minimize their downtime</emphasis>.
|
||||
If somebody either hacks or simply turns off
|
||||
these machines, they have effectively rendered many people without
|
||||
|
|
@ -2296,36 +2296,36 @@ TWO (,hotel,test-domain)
|
|||
|
||||
<para>This is the chief weakness of any centralized administration
|
||||
system. If you do
|
||||
not protect your NIS servers, you will have a lot of angry
|
||||
not protect your ⋼ servers, you will have a lot of angry
|
||||
users!</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>NIS v1 Compatibility</title>
|
||||
<title>⋼ v1 Compatibility</title>
|
||||
|
||||
<para> FreeBSD's <application>ypserv</application> has some support
|
||||
for serving NIS v1 clients. FreeBSD's NIS implementation only
|
||||
uses the NIS v2 protocol, however other implementations include
|
||||
for serving ⋼ v1 clients. FreeBSD's ⋼ implementation only
|
||||
uses the ⋼ v2 protocol, however other implementations include
|
||||
support for the v1 protocol for backwards compatibility with older
|
||||
systems. The <application>ypbind</application> daemons supplied
|
||||
with these systems will try to establish a binding to an NIS v1
|
||||
with these systems will try to establish a binding to an ⋼ v1
|
||||
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 <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
|
||||
master or slave in conjunction with older ⋼ servers that only
|
||||
support the v1 protocol. Fortunately, there probably are not any
|
||||
such servers still in use today.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="network-nis-server-is-client">
|
||||
<title>NIS Servers That Are Also NIS Clients</title>
|
||||
<title>⋼ Servers That Are Also ⋼ Clients</title>
|
||||
|
||||
<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
|
||||
domain where the server machines are also ⋼ 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
|
||||
become bound to each other. Strange failure modes can result if
|
||||
|
|
@ -2338,7 +2338,7 @@ TWO (,hotel,test-domain)
|
|||
<para>You can force a host to bind to a particular server by running
|
||||
<command>ypbind</command> with the <option>-S</option>
|
||||
flag. If you do not want to do this manually each time you
|
||||
reboot your NIS server, you can add the following lines to
|
||||
reboot your ⋼ server, you can add the following lines to
|
||||
your <filename>/etc/rc.conf</filename>:</para>
|
||||
|
||||
<programlisting>nis_client_enable="YES" # run client stuff as well
|
||||
|
|
@ -2354,10 +2354,10 @@ nis_client_flags="-S <replaceable>NIS domain</replaceable>,<replaceable>server</
|
|||
<secondary>password formats</secondary>
|
||||
</indexterm>
|
||||
<para>One of the most common issues that people run into when trying
|
||||
to implement NIS is password format compatibility. If your NIS
|
||||
to implement ⋼ is password format compatibility. If your NIS
|
||||
server is using DES encrypted passwords, it will only support
|
||||
clients that are also using DES. For example, if you have
|
||||
&solaris; NIS clients in your network, then you will almost certainly
|
||||
&solaris; ⋼ clients in your network, then you will almost certainly
|
||||
need to use DES encrypted passwords.</para>
|
||||
|
||||
<para>To check which format your servers
|
||||
|
|
@ -2397,9 +2397,9 @@ nis_client_flags="-S <replaceable>NIS domain</replaceable>,<replaceable>server</
|
|||
<para>Having followed the above steps on each of the &os; based NIS
|
||||
servers and clients, you can be sure that they all agree on which
|
||||
password format is used within your network.
|
||||
If you have trouble authenticating on an NIS client, this
|
||||
If you have trouble authenticating on an ⋼ client, this
|
||||
is a pretty good place to start looking for possible problems.
|
||||
Remember: if you want to deploy an NIS server for a heterogenous
|
||||
Remember: if you want to deploy an ⋼ server for a heterogenous
|
||||
network, you will probably have to use DES on all systems
|
||||
because it is the lowest common standard.</para>
|
||||
</sect2>
|
||||
|
|
|
|||
Loading…
Reference in a new issue