mirror of https://github.com/tLDP/LDP
1221 lines
54 KiB
Plaintext
1221 lines
54 KiB
Plaintext
<chapter id="X-087-2-nis"><title>The Network <?lb>Information System</title>
|
|
<indexterm id="idx-configuringNIS-1" class="startofrange"><primary>configuring</primary><secondary>NIS</secondary></indexterm>
|
|
<indexterm><primary>NIS (Network Information System)</primary></indexterm>
|
|
<indexterm id="idx-NIS-1" class="startofrange"><primary>NIS (Network Information System)</primary></indexterm>
|
|
<indexterm><primary>networks</primary><secondary>synchronizing passwords</secondary></indexterm>
|
|
<indexterm><primary>hostname</primary><secondary>resolution</secondary></indexterm>
|
|
|
|
<para>
|
|
When you're running a local area network, your overall goal is usually to
|
|
provide an environment for your users that makes the network transparent. An
|
|
important stepping stone is keeping vital data such as user account
|
|
information synchronized among all hosts. This provides users with the freedom
|
|
to move from machine to machine without the inconvenience of having to remember
|
|
different passwords and copy data from one machine to another. Data that is
|
|
centrally stored doesn't need to be replicated, so long as there is some
|
|
convenient means of accessing it from a network-connected host. By storing
|
|
important administrative information centrally, you can make ensure
|
|
consistency of that data, increase flexibility for the users by
|
|
allowing them to move from host to host in a transparent way, and make the
|
|
system administrator's life much easier by maintaining a single copy of
|
|
information to maintain when required.
|
|
</para>
|
|
|
|
<para>
|
|
We previously discussed an important example of this concept that is used on
|
|
the Internet—the Domain Name System (DNS). DNS serves a limited range of
|
|
information, the most important being the mapping between hostname and
|
|
IP address. For other types of information, there is no such specialized
|
|
service. Moreover, if you manage only a small LAN with no Internet
|
|
connectivity, setting up DNS may not seem to be worth the trouble.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary sortas="etc/hosts file">/etc/hosts file</primary></indexterm>
|
|
This is why Sun developed the <emphasis>Network Information
|
|
System</emphasis> (NIS). NIS provides generic database access facilities that
|
|
can be used to distribute, for example, information contained in the
|
|
<filename>passwd</filename> and <filename>groups</filename> files to all
|
|
hosts on your network. This makes the network appear as a single system,
|
|
with the same accounts on all hosts. Similarly, you can use NIS
|
|
to distribute the hostname information from <filename>/etc/hosts</filename>
|
|
to all machines on the network.
|
|
</para>
|
|
|
|
<para>
|
|
NIS is based on RPC, and comprises a server, a client-side library, and
|
|
several administrative tools. Originally, NIS was called <emphasis>Yellow
|
|
Pages</emphasis>, or YP, which is still used to refer to it.
|
|
Unfortunately, the name is a trademark of British Telecom, which required
|
|
Sun to drop that name. As things go, some names stick with people, and so
|
|
YP lives on as a prefix to the names of most NIS-related commands such as
|
|
<command>ypserv</command> and <command>ypbind</command>.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Thümmler, Swen</primary></indexterm>
|
|
<indexterm><primary>yp-linux command</primary></indexterm>
|
|
Today, NIS is available for virtually all Unixes, and there are even
|
|
free implementations. BSD Net-2 released one that has
|
|
been derived from a public domain reference implementation donated by
|
|
Sun. The library client code from this release had been in the Linux
|
|
<filename>libc</filename> for a long time, and the administrative programs
|
|
were ported to Linux by
|
|
Swen Thümmler.<footnote id="X-087-2-FNNI01"><para>
|
|
Swen can be reached at
|
|
<systemitem role="emailaddr">swen@uni-paderborn.de</systemitem>. The NIS clients
|
|
are available as <filename>yp-linux.tar.gz</filename> from
|
|
<systemitem role="sitename">metalab.unc.edu</systemitem> in
|
|
<filename>system/Network</filename>.
|
|
</para>
|
|
</footnote>
|
|
An NIS server is missing from the reference implementation, though.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Eriksson, Peter</primary></indexterm>
|
|
<indexterm><primary>NYS</primary></indexterm>
|
|
<indexterm><primary>host.conf file</primary></indexterm>
|
|
Peter Eriksson developed a new
|
|
implementation called NYS.<footnote id="X-087-2-FNNI02"><para>
|
|
Peter may be reached at
|
|
<systemitem role="emailaddr">pen@lysator.liu.se</systemitem>.
|
|
The current version of NYS is 1.2.8.
|
|
</para>
|
|
</footnote>
|
|
It supports both plain NIS and Sun's much enhanced NIS+. NYS not only
|
|
provides a set of NIS tools and a server, but also adds a whole new
|
|
set of library functions that need to be compiled into your
|
|
<filename>libc</filename> if you wish to use it. This includes a new
|
|
configuration scheme for hostname resolution that replaces the current
|
|
scheme using <filename>host.conf</filename>.
|
|
</para>
|
|
|
|
|
|
<para>
|
|
<indexterm><primary>NIS (Network Information System)</primary><secondary>GNU libc</secondary></indexterm>
|
|
<INDEXTERM><PRIMARY>Kukuk, Thorsten</PRIMARY></INDEXTERM>
|
|
<INDEXTERM><PRIMARY>GNU libc (NIS support)</PRIMARY></INDEXTERM>
|
|
<INDEXTERM><PRIMARY>libc6 (NIS support)</PRIMARY></INDEXTERM>
|
|
The GNU libc, known as <filename>libc6</filename> in the Linux community,
|
|
includes an updated version of the traditional NIS support developed by
|
|
Thorsten Kukuk.<footnote id="X-087-2-FNNI04"><para>
|
|
Thorsten may be reached at
|
|
<systemitem role="emailaddr">kukuk@uni-paderborn.de</systemitem>.
|
|
</para>
|
|
</footnote> It supports all of the
|
|
library functions that NYS provided and also uses the enhanced configuration
|
|
scheme of NYS. You still need the tools and server, but using GNU <filename>libc</filename> saves
|
|
you the trouble of having to meddle with patching and recompiling the library.
|
|
</para>
|
|
|
|
<para>
|
|
This chapter focuses on the NIS support included in the GNU <filename>libc</filename> rather than
|
|
the other two packages. If you do want to run any of these packages, the
|
|
instructions in this chapter may or may not be enough. For additional
|
|
information, refer to the NIS-HOWTO or a book such as <emphasis>Managing
|
|
NFS and NIS</emphasis> by Hal Stern (O'Reilly).
|
|
</para>
|
|
|
|
<sect1><title>Getting Acquainted with NIS</title>
|
|
<para>
|
|
<indexterm><primary>NIS (Network Information System)</primary><secondary>databases</secondary></indexterm>
|
|
<indexterm id="idx-NISmap-1" class="startofrange"><primary>NIS (Network Information System)</primary><secondary>maps</secondary></indexterm>
|
|
NIS keeps database information in files called <emphasis>maps</emphasis>,
|
|
which contain key-value pairs. An example of a key-value pair is a user's login
|
|
name and the encrypted form of their login password. Maps are stored on a
|
|
central host running the NIS server, from which clients may retrieve the
|
|
information through various RPC calls. Quite frequently, maps are stored in DBM
|
|
files.<footnote id="X-087-2-FNNI05"><para>DBM is a simple database management library that uses hashing techniques
|
|
to speed up search operations. There's a free DBM implementation from the
|
|
GNU project called <filename>gdbm</filename>, which is part of most Linux
|
|
distributions.
|
|
</para>
|
|
</footnote>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary sortas="etc/hosts file">/etc/hosts file</primary></indexterm>
|
|
<indexterm><primary sortas="etc/passwd file">/etc/passwd file</primary></indexterm>
|
|
<indexterm><primary>hosts.byname file</primary></indexterm>
|
|
<indexterm><primary>hosts.byaddr file</primary></indexterm>
|
|
<indexterm><primary sortas="etc/networks file">/etc/networks file</primary></indexterm>
|
|
<indexterm><primary sortas="etc/group file">/etc/group file</primary></indexterm>
|
|
<indexterm><primary sortas="etc/services file">/etc/services file</primary></indexterm>
|
|
<indexterm><primary sortas="etc/rpc file">/etc/rpc file</primary></indexterm>
|
|
<indexterm><primary sortas="etc/protocols file">/etc/protocols file</primary></indexterm>
|
|
<indexterm><primary sortas="etc/aliases file">/etc/aliases file</primary></indexterm>
|
|
The maps themselves are usually generated from master text files such as
|
|
<filename>/etc/hosts</filename> or <filename>/etc/passwd</filename>. For
|
|
some files, several maps are created, one for each search key type. For
|
|
instance, you may search the <filename>hosts</filename> file for a hostname
|
|
as well as for an IP address. Accordingly, two NIS maps are derived from it,
|
|
called <filename>hosts.byname</filename> and <filename>hosts.byaddr</filename>.
|
|
<xref linkend="X-087-2-nis.table.maps"> lists common maps and the files from
|
|
which they are generated.
|
|
</para>
|
|
|
|
<table id="X-087-2-nis.table.maps">
|
|
<title>Some Standard NIS Maps and Corresponding Files</title>
|
|
<tgroup cols=3>
|
|
<thead>
|
|
<row>
|
|
<entry>Master File</entry>
|
|
<entry>Map(s)</entry>
|
|
<entry>Description</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry><filename>/etc/hosts</filename></entry>
|
|
<entry><para>
|
|
<filename>hosts.byname</filename>, <filename>hosts.byaddr</filename></para></entry>
|
|
<entry><para>
|
|
Maps IP addresses to host names</para></entry>
|
|
</row>
|
|
<row>
|
|
<entry><filename>/etc/networks</filename></entry>
|
|
<entry><para>
|
|
<filename>networks.byname</filename>, <filename>networks.byaddr</filename></para></entry>
|
|
<entry><para>
|
|
Maps IP network addresses to network names</para></entry>
|
|
</row>
|
|
<row>
|
|
<entry><para>
|
|
<filename>/etc/passwd</filename></para></entry>
|
|
<entry><para>
|
|
<filename>passwd.byname</filename>, <filename>passwd.byuid</filename></para></entry>
|
|
<entry><para>
|
|
Maps encrypted passwords to user login names</para></entry>
|
|
</row>
|
|
<row>
|
|
<entry><para>
|
|
<filename>/etc/group</filename></para></entry>
|
|
<entry><para>
|
|
<filename>group.byname</filename>, <filename>group.bygid</filename></para></entry>
|
|
<entry><para>
|
|
Maps Group IDs to group names</para></entry>
|
|
</row>
|
|
<row>
|
|
<entry><para>
|
|
<filename>/etc/services</filename></para></entry>
|
|
<entry><para>
|
|
<filename>services.byname</filename>, <filename>services.bynumber</filename></para></entry>
|
|
<entry>Maps service descriptions to service names</entry>
|
|
</row>
|
|
<row>
|
|
<entry><filename>/etc/rpc</filename></entry>
|
|
<entry><para>
|
|
<filename>rpc.byname</filename>, <filename>rpc.bynumber</filename></para></entry>
|
|
<entry><para>
|
|
Maps Sun RPC service numbers to RPC service names</para></entry>
|
|
</row>
|
|
<row>
|
|
<entry><filename>/etc/protocols</filename></entry>
|
|
<entry><para>
|
|
<filename>protocols.byname</filename>, <filename>protocols.bynumber</filename></para></entry>
|
|
<entry><para>
|
|
Maps protocol numbers to protocol names</para></entry>
|
|
</row>
|
|
<row>
|
|
<entry><filename>/usr/lib/aliases</filename></entry>
|
|
<entry><filename>mail.aliases</filename></entry>
|
|
<entry><para>
|
|
Maps mail aliases to mail alias names</para></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>
|
|
You may find support for other files and maps in other NIS packages.
|
|
These usually contain information for applications not discussed in this book,
|
|
such as the <filename>bootparams</filename> map that is used by Sun's
|
|
<command>bootparamd</command> server.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>displaying</primary><secondary>NIS map nicknames</secondary></indexterm>
|
|
<indexterm><primary>ypcat</primary><secondary>command</secondary></indexterm>
|
|
<indexterm><primary>NIS (Network Information System)</primary><secondary>nicknames</secondary></indexterm>
|
|
<indexterm><primary>NIS (Network Information System)</primary><secondary>maps</secondary></indexterm>
|
|
For some maps, people commonly use <emphasis>nicknames</emphasis>, which are
|
|
shorter and therefore easier to type. Note that these nicknames are understood
|
|
only by <command>ypcat</command> and <command>ypmatch</command>, two tools for
|
|
checking your NIS configuration. To obtain a full list of nicknames understood
|
|
by these tools, run the following command:
|
|
|
|
<screen>
|
|
$ <userinput>ypcat -x</userinput>
|
|
Use "passwd" for "passwd.byname"
|
|
Use "group" for "group.byname"
|
|
Use "networks" for "networks.byaddr"
|
|
Use "hosts" for "hosts.byaddr"
|
|
Use "protocols" for "protocols.bynumber"
|
|
Use "services" for "services.byname"
|
|
Use "aliases" for "mail.aliases"
|
|
Use "ethers" for "ethers.byname"
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm id="idx-NISserver-1" class="startofrange"><primary>NIS (Network Information System)</primary><secondary>servers</secondary></indexterm>
|
|
<indexterm><primary>ypserv command</primary></indexterm>
|
|
<indexterm><primary>servers</primary><secondary>ypserv command</secondary></indexterm>
|
|
<indexterm><primary>servers</primary><secondary>NIS</secondary></indexterm>
|
|
<INDEXTERM><PRIMARY>servers</PRIMARY><SECONDARY>master</SECONDARY></INDEXTERM>
|
|
<INDEXTERM><PRIMARY>servers</PRIMARY><SECONDARY>slave</SECONDARY></INDEXTERM>
|
|
<INDEXTERM><PRIMARY>master servers</PRIMARY></INDEXTERM>
|
|
<INDEXTERM><PRIMARY>slave servers</PRIMARY></INDEXTERM>
|
|
The NIS server program is traditionally called <command>ypserv</command>. For
|
|
an average network, a single server usually suffices; large networks may
|
|
choose to run several of these on different machines and different segments
|
|
of the network to relieve the load on the server machines and routers.
|
|
These servers are synchronized by making one of them the <emphasis>master
|
|
server</emphasis>, and the others <emphasis>slave servers</emphasis>. Maps are
|
|
created only on the master server's host. From there, they are distributed to
|
|
all slaves.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>NIS (Network Information System)</primary><secondary>domains</secondary></indexterm>
|
|
<indexterm><primary>choosing</primary><secondary>NIS domain</secondary></indexterm>
|
|
<indexterm><primary>domains</primary><secondary>NIS</secondary></indexterm>
|
|
We have been talking very vaguely about “networks.” There's a
|
|
distinctive term in NIS that refers to a collection of all hosts that share
|
|
part of their system configuration data through NIS: the
|
|
<emphasis>NIS domain</emphasis>. Unfortunately, NIS domains
|
|
have absolutely nothing in common with the domains we encountered in DNS. To
|
|
avoid any ambiguity throughout this chapter, we will therefore always specify
|
|
which type of domain we mean.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>setting</primary><secondary>NIS domain</secondary></indexterm>
|
|
<indexterm><primary>domains</primary><secondary>NIS</secondary></indexterm>
|
|
<indexterm><primary>domainname command</primary></indexterm>
|
|
NIS domains have a purely administrative function. They are mostly
|
|
invisible to users, except for the sharing of passwords between all
|
|
machines in the domain. Therefore, the name given to an NIS domain is
|
|
relevant only to the administrators. Usually, any name will do, as long
|
|
as it is different from any other NIS domain name on your local network.
|
|
For instance, the administrator at the Virtual Brewery may choose to
|
|
create two NIS domains, one for the Brewery itself, and one for the
|
|
Winery, which she names <systemitem role="sitename">brewery</systemitem> and
|
|
<systemitem role="sitename">winery</systemitem> respectively. Another quite
|
|
common scheme is to simply use the DNS domain name for NIS as well.
|
|
</para>
|
|
|
|
<para>
|
|
To set and display the NIS domain name of your host, you can use the
|
|
<command>domainname</command> command. When invoked without any argument, it
|
|
prints the current NIS domain name; to set the domain name, you must
|
|
become the superuser:
|
|
|
|
<screen>
|
|
# <userinput>domainname brewery</userinput>
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
NIS domains determine which NIS server an application will query. For
|
|
instance, the <command>login</command> program on a host at the Winery should,
|
|
of course, query only the Winery's NIS server (or one of them, if there
|
|
are several) for a user's password information, while an application on
|
|
a Brewery host should stick with the Brewery's server.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>NIS (Network Information System)</primary><secondary>locating servers</secondary></indexterm>
|
|
<indexterm><primary>ypbind command</primary></indexterm>
|
|
<indexterm><primary>NIS (Network Information System)</primary><secondary>security</secondary></indexterm>
|
|
One mystery now remains to be solved: how does a client find out which
|
|
server to connect to? The simplest approach would use a configuration
|
|
file that names the host on which to find the server. However, this approach
|
|
is rather inflexible because it doesn't allow clients to use different servers
|
|
(from the same domain, of course) depending on their availability. Therefore,
|
|
NIS implementations rely on a special daemon called <command>ypbind</command>
|
|
to detect a suitable NIS server in their NIS domain. Before performing any
|
|
NIS queries, an application first finds out from
|
|
<command>ypbind</command> which server to use.
|
|
</para>
|
|
|
|
<para>
|
|
<command>ypbind</command> probes for servers by broadcasting to the local IP
|
|
network; the first to respond is assumed to be the fastest one and
|
|
is used in all subsequent NIS queries. After a certain interval has
|
|
elapsed, or if the server becomes unavailable, <command>ypbind</command>
|
|
probes for active servers again.
|
|
</para>
|
|
|
|
<para>
|
|
Dynamic binding is useful only when your network provides more than one
|
|
NIS server. Dynamic binding also introduces a security problem.
|
|
<command>ypbind</command> blindly believes whoever answers, whether it be a
|
|
humble NIS server or a malicious intruder. Needless to say, this
|
|
becomes especially troublesome if you manage your password databases over NIS.
|
|
To guard against this, the Linux <command>ypbind</command> program provides
|
|
you with the option of probing the local network to find the local NIS server,
|
|
or configuring the NIS server hostname in a configuration file.
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-nis.nisplus"><title>NIS Versus NIS+</title>
|
|
<indexterm><primary>NIS+</primary></indexterm>
|
|
<para>
|
|
NIS and NIS+ share little more than their name and a common goal. NIS+ is
|
|
structured entirely differently from NIS. Instead of a flat namespace with
|
|
disjoint NIS domains, NIS+ uses a hierarchical namespace similar to that of
|
|
DNS. Instead of maps, so-called <emphasis>tables</emphasis> are used that
|
|
are made up of rows and columns, in which each row represents an object in the
|
|
NIS+ database and the columns cover properties of the objects that NIS+
|
|
knows and cares about. Each table for a given NIS+ domain comprises those of
|
|
its parent domains. In addition, an entry in a table may contain a link to
|
|
another table. These features make it possible to structure information in
|
|
many ways.
|
|
</para>
|
|
|
|
<para>
|
|
NIS+ additionally supports secure and encrypted RPC, which helps greatly to
|
|
solve the security problems of NIS.
|
|
</para>
|
|
|
|
<para>
|
|
Traditional NIS has an RPC Version number of 2, while NIS+ is Version 3.
|
|
At the time we're writing, there isn't yet a good working implementation
|
|
of NIS+ for Linux, so it isn't covered here.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-nis.clients"><title>The Client Side of NIS</title>
|
|
<indexterm><primary>NIS (Network Information System)</primary><secondary>clients</secondary></indexterm>
|
|
<indexterm><primary>getpwnam( )</primary></indexterm>
|
|
<indexterm><primary>getpwuid( )</primary></indexterm>
|
|
<para>
|
|
<?troff .hw get-pwnam>
|
|
If you are familiar with writing or porting network applications, you
|
|
may notice that most of the NIS maps listed previously correspond to library
|
|
functions in the C library. For instance, to obtain <filename>passwd</filename>
|
|
information, you generally use the <function>getpwnam</function> and
|
|
<function>getpwuid</function> functions, which return the account information
|
|
associated with the given username or numerical user ID, respectively.
|
|
Under normal circumstances, these functions perform the requested
|
|
lookup on the standard file, such as <filename>/etc/passwd</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
An NIS-aware implementation of these functions, however, modifies this
|
|
behavior and places an RPC call to the NIS server, which looks up the username
|
|
or user ID. This happens transparently to the application. The function may
|
|
treat the NIS data as though it has been appended to the original
|
|
<filename>passwd</filename> file so both sets of information are available
|
|
to the application and used, or as though it has completely replaced it so
|
|
that the information in the local <filename>passwd</filename> is ignored
|
|
and only the NIS data is used.
|
|
</para>
|
|
|
|
<para>
|
|
For traditional NIS implementations, there were certain conventions for
|
|
which maps were replaced and which were appended to the original information.
|
|
Some, like the <filename>passwd</filename> maps, required kludgy modifications
|
|
of the <filename>passwd</filename> file which, when done incorrectly, would
|
|
open up security holes. To avoid these pitfalls, NYS and the GNU <filename>libc</filename> use a
|
|
general configuration scheme that determines whether a particular set of
|
|
client functions uses the original files, NIS, or NIS+, and in which order.
|
|
This scheme will be described later in this chapter.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-nis.server"><title>Running an NIS Server</title>
|
|
|
|
<para>
|
|
<indexterm><primary>configuring</primary><secondary>NIS</secondary></indexterm>
|
|
After so much theoretical techno-babble, it's time to get our hands
|
|
dirty with actual configuration work. In this section, we will cover the
|
|
configuration of an NIS server. If an NIS server is running on your network,
|
|
you won't have to set up your own; in this case, you may safely skip this
|
|
section.
|
|
</para>
|
|
|
|
<para>
|
|
Note that if you are just going to experiment with the server, make
|
|
sure you don't set it up for an NIS domain name that is already in use
|
|
on your network. This may disrupt the entire network service and make a
|
|
lot of people very unhappy and very angry.
|
|
</para>
|
|
|
|
<para>
|
|
<INDEXTERM><PRIMARY>servers</PRIMARY><SECONDARY>master</SECONDARY></INDEXTERM>
|
|
<INDEXTERM><PRIMARY>servers</PRIMARY><SECONDARY>slave</SECONDARY></INDEXTERM>
|
|
<INDEXTERM><PRIMARY>master servers</PRIMARY></INDEXTERM>
|
|
<INDEXTERM><PRIMARY>slave servers</PRIMARY></INDEXTERM>
|
|
There are two possible NIS server configurations: master and slave. The slave
|
|
configuration provides a live backup machine, should your master server
|
|
fail. We will cover the configuration only for a master server here.
|
|
The server documentation will explain the differences, should you wish
|
|
to configure a slave server.
|
|
</para>
|
|
|
|
<para>
|
|
There are currently two NIS servers freely available for Linux: one contained
|
|
in Tobias Reber's <filename>yps</filename> package, and the other in Peter
|
|
Eriksson's <filename>ypserv</filename> package. It doesn't matter which one
|
|
you run.
|
|
</para>
|
|
|
|
<para>
|
|
After installing the server program (<command>ypserv</command>) in
|
|
<filename>/usr/sbin</filename>, you should create the directory that
|
|
is going to hold the map files your server is to distribute. When
|
|
setting up an NIS domain for the <systemitem
|
|
role="sitename">brewery</systemitem> domain, the maps would go to
|
|
<filename>/var/yp/brewery</filename>. The server determines whether it is
|
|
serving a particular NIS domain by checking if the map directory
|
|
is present. If you are disabling service for some NIS domain, make
|
|
sure to remove the directory as well.
|
|
<indexterm class="endofrange" startref="idx-NISmap-1">
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>NIS (Network Information System)</primary><secondary>creating maps</secondary></indexterm>
|
|
<indexterm><primary>creating</primary><secondary>NIS maps</secondary></indexterm>
|
|
<indexterm><primary>dbmload program</primary></indexterm>
|
|
<indexterm><primary>makedbm program</primary></indexterm>
|
|
Maps are usually stored in DBM files to speed up lookups. They are created
|
|
from the master files using a program called <command>makedbm</command> (for
|
|
Tobias's server) or <command>dbmload</command> (for Peter's server).
|
|
</para>
|
|
<?troff .wcon_off>
|
|
<para>
|
|
Transforming a master file into a form that <command>dbmload</command> can
|
|
parse usually requires some <command>awk</command> or <command>sed</command>
|
|
magic, which tends to be a little tedious to type and hard to remember.
|
|
Therefore, Peter Eriksson's <filename>ypserv</filename> package contains a
|
|
Makefile (called <filename>ypMakefile</filename>) that manages the conversion
|
|
of the most common master files for you. You should install it as
|
|
<filename>Makefile</filename> in your map directory and edit it to reflect
|
|
the maps you want the NIS server to share. Towards the top of the file, you'll
|
|
find
|
|
<?troff .ne 10>
|
|
the <systemitem role="keyword">all</systemitem>
|
|
target that lists the services <command>ypserv</command> offers. By default, the line looks
|
|
something like this:
|
|
|
|
<screen>
|
|
all: ethers hosts networks protocols rpc services passwd group netid
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>checking</primary><secondary>NIS</secondary></indexterm>
|
|
If you don't want to produce, for example, the
|
|
<filename>ethers.byname</filename> and <filename>ethers.byaddr</filename>
|
|
maps, simply remove the <systemitem role="keyword">ethers</systemitem>
|
|
prerequisite from this rule. To test your setup, you can start with just
|
|
one or two maps, like the <filename>services.</filename>* maps.
|
|
</para>
|
|
|
|
<para>
|
|
After editing the <filename>Makefile</filename>, while in the map directory,
|
|
type <userinput>make</userinput>. This will automatically generate and install the
|
|
maps. You have to make sure to update the maps whenever you change the master
|
|
files, otherwise the changes will remain invisible to the network.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>checking</primary><secondary>NIS</secondary></indexterm>
|
|
The section “Setting Up an NIS Client with GNU libc&rdquo
|
|
will explain how to configure the NIS client code. If your setup doesn't
|
|
work, you should try to find out whether requests are arriving at your
|
|
server. If you specify the <option>––debug</option>
|
|
command-line flag to <command>ypserv</command>, it prints debugging
|
|
messages to the console about all incoming NIS queries and the results
|
|
returned. These should give you a hint as to where the problem
|
|
lies. Tobias's server doesn't have this option.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-nis.securenets"><title>NIS Server Security</title>
|
|
<para>
|
|
<indexterm><primary>NIS (Network Information System)</primary><secondary>security</secondary></indexterm>
|
|
<indexterm><primary>security</primary><secondary>using NIS</secondary></indexterm>
|
|
NIS used to have a major security flaw: it left your password file
|
|
readable by virtually anyone in the entire Internet, which made for
|
|
quite a number of possible intruders. As long as an intruder knew your
|
|
NIS domain name and the address of your server, he could simply send
|
|
it a request for the <filename>passwd.byname</filename> map and
|
|
instantly receive all your system's encrypted passwords. With a fast
|
|
password-cracking program like <command>crack</command> and a good
|
|
dictionary, guessing at least a few of your users' passwords is rarely
|
|
a problem.
|
|
</para>
|
|
|
|
<para>
|
|
<INDEXTERM><PRIMARY>securenets option</PRIMARY></INDEXTERM>
|
|
<INDEXTERM><PRIMARY>NIS (Network Information System)</PRIMARY><SECONDARY>securenets option</SECONDARY></INDEXTERM>
|
|
<INDEXTERM><PRIMARY SORTAS="etc/ypserv.securenets file">/etc/ypserv.securenets file</PRIMARY></INDEXTERM>
|
|
This is what the <emphasis>securenets</emphasis> option is all
|
|
about. It simply restricts access to your NIS server to certain hosts,
|
|
based on their IP addresses or network numbers. The latest version of
|
|
<command>ypserv</command> implements this feature in two ways. The
|
|
first relies on a special configuration file called
|
|
<filename>/etc/ypserv.securenets</filename> and the second
|
|
conveniently uses the <filename>/etc/hosts.allow</filename> and
|
|
<filename>/etc/hosts.deny</filename> files we already encountered in
|
|
<xref linkend="X-087-2-appl">.<footnote id="X-087-2-FNNI06"><para> To
|
|
enable use of the <filename>/etc/hosts.allow</filename> method, you may
|
|
have to recompile the server. Please read the instructions in the
|
|
<filename>README</filename> included in the distribution.
|
|
</para>
|
|
</footnote>
|
|
Thus, to restrict access to hosts from within the Brewery, their
|
|
network manager would add the following line to
|
|
<filename>hosts.allow </filename>:
|
|
<screen>
|
|
ypserv: 172.16.2.
|
|
</screen>
|
|
</para>
|
|
<?troff .Nd 10>
|
|
<para>
|
|
This would let all hosts from IP network <systemitem
|
|
role="sitename">172.16.2.0</systemitem> access the NIS server. To
|
|
shut out all other hosts, a corresponding entry in
|
|
<filename>hosts.deny</filename> would have to read:
|
|
|
|
<screen>
|
|
ypserv: ALL
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
IP numbers are not the only way you can specify hosts or networks in
|
|
<filename>hosts.allow</filename> and <filename>hosts.deny</filename>. Please
|
|
refer to the <filename>hosts_access(5)</filename> manual page on your system
|
|
for details. However, be warned that you <emphasis>cannot</emphasis> use host
|
|
or domain names for the <systemitem role="keyword">ypserv</systemitem> entry.
|
|
If you specify a hostname, the server tries to resolve this hostname—but
|
|
the resolver in turn calls <command>ypserv</command>, and you fall into an
|
|
endless loop.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary sortas="etc/ypserv.securenets file">/etc/ypserv.securenets file</primary></indexterm>
|
|
To configure <systemitem role="keyword">securenets</systemitem> security
|
|
using the <filename>/etc/ypserv.securenets</filename> method, you need
|
|
to create its configuration file, <filename>/etc/ypserv.securenets</filename>.
|
|
This configuration file is simple
|
|
in structure. Each line describes a host or network of hosts that will be
|
|
allowed access to the server. Any address not described by an entry in this
|
|
file will be refused access. A line beginning with a # will be
|
|
treated as a comment. Example 13-1 shows what a simple <filename>/etc/ypserv.securenets</filename>
|
|
would look like:
|
|
</para>
|
|
|
|
<example id="X-087-2-nis.securenets.file">
|
|
<title>Sample ypserv.securenets File</title>
|
|
<screen>
|
|
# allow connections from local host -- necessary
|
|
host 127.0.0.1
|
|
# same as 255.255.255.255 127.0.0.1
|
|
#
|
|
# allow connections from any host on the Virtual Brewery network
|
|
255.255.255.0 172.16.1.0
|
|
#
|
|
</screen>
|
|
</example>
|
|
|
|
<para>
|
|
The first entry on each line is the netmask to use for the entry, with
|
|
<systemitem role="keyword">host</systemitem> being treated as a special
|
|
keyword meaning “netmask 255.255.255.255.” The second entry
|
|
on each line is the IP address to which to apply the netmask.
|
|
</para>
|
|
|
|
<para>
|
|
A third option is to use the secure portmapper instead of the
|
|
<option>securenets</option> option in
|
|
<command>ypserv</command>. The secure portmapper
|
|
(<filename>portmap-5.0</filename>) uses the <filename>hosts.allow</filename> scheme as well, but
|
|
offers this for all RPC servers, not just <command>ypserv</command>.<footnote id="X-087-2-FNNI07"><para>
|
|
The secure portmapper is available via anonymous FTP from
|
|
<systemitem role="sitename">ftp.win.tue.nl</systemitem> below the
|
|
<filename>/pub/security/</filename> directory.
|
|
</para>
|
|
</footnote>
|
|
However, you should not use both the <option>securenets</option> option and the secure
|
|
portmapper at the same time, because of the overhead this
|
|
authorization incurs.
|
|
</para>
|
|
|
|
<indexterm class="endofrange" startref="idx-NISserver-1">
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-nis.yp"><title>Setting Up an NIS Client with GNU libc</title>
|
|
<para>
|
|
<indexterm><primary>configuring</primary><secondary>NIS</secondary></indexterm>
|
|
<indexterm id="idx-NISclient-2" class="startofrange"><primary>NIS (Network Information System)</primary><secondary>clients</secondary></indexterm>
|
|
<indexterm><primary>NIS (Network Information System)</primary><secondary>GNU libc</secondary></indexterm>
|
|
We will now describe and discuss the configuration of an NIS client using
|
|
the GNU libc library support.
|
|
</para>
|
|
<?troff .Nd 10>
|
|
|
|
<para>
|
|
<indexterm id="idx-filenameypconffilename-1" class="startofrange"><primary sortas="etc/yp.conf file">/etc/yp.conf file</primary></indexterm>
|
|
<indexterm><primary>setting</primary><secondary>NIS domain</secondary></indexterm>
|
|
<indexterm><primary>NIS (Network Information System)</primary><secondary>domains</secondary></indexterm>
|
|
<indexterm><primary>domains</primary><secondary>NIS</secondary></indexterm>
|
|
Your first step should be to tell the GNU libc NIS client which server to use
|
|
for NIS service. We mentioned earlier that the Linux <command>ypbind</command>
|
|
allows you to configure the NIS server to use. The default behavior is to
|
|
query the server on the local network. If the host you are configuring is
|
|
likely to move from one domain to another, such as a laptop, you
|
|
would leave the <filename>/etc/yp.conf</filename> file empty and it would
|
|
query on the local network for the local NIS server wherever it happens to be.
|
|
</para>
|
|
|
|
<para>
|
|
A more secure configuration for most hosts is to set the server name in the
|
|
<filename>/etc/yp.conf</filename> configuration file. A very simple file for a
|
|
host on the Winery's network may look like this:
|
|
|
|
<screen>
|
|
# yp.conf - YP configuration for GNU libc library.
|
|
#
|
|
ypserver vbardolino
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
<?troff .hw argument>
|
|
The <systemitem role="keyword">ypserver</systemitem> statement tells your host
|
|
to use the host supplied as the NIS server for the local domain. In this
|
|
example we've specified the NIS server as <systemitem role="sitename">vbardolino</systemitem>. Of course, the IP address corresponding to
|
|
<systemitem role="sitename">vbardolino</systemitem> must be set
|
|
in the <filename>hosts</filename> file; alternatively, you may use the
|
|
IP address itself with the <systemitem role="keyword">server</systemitem>
|
|
argument.
|
|
</para>
|
|
|
|
<para>
|
|
In the form shown in the example, the
|
|
<command>ypserver</command> command tells
|
|
<command>ypbind</command> to use the named server regardless of what the
|
|
current NIS domain may be. If, however, you are moving your machine between
|
|
different NIS domains frequently, you may want to keep information for several
|
|
domains in the <filename>yp.conf</filename> file. You can have information on
|
|
the servers for various NIS domains in <filename>yp.conf</filename> by
|
|
specifying the information using the
|
|
<systemitem role="keyword">domain</systemitem> statement. For instance, you
|
|
might change the previous sample file to look like this for a laptop:
|
|
|
|
<screen>
|
|
# yp.conf - YP configuration for GNU libc library.
|
|
#
|
|
domain winery server vbardolino
|
|
domain brewery server vstout
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
This lets you bring up the laptop in either of the two domains by simply
|
|
setting the desired NIS domain at boot time using the
|
|
<command>domainname</command> command. The NIS client then uses whichever
|
|
server is relevant for the current domain.
|
|
</para>
|
|
|
|
<para>
|
|
There is a third option you may want to use. It covers the case when you
|
|
don't know the name or IP address of the server to use in a particular domain,
|
|
but still want the ability use a fixed server on certain domains. Imagine
|
|
we want to insist on using a specified server while operating within the
|
|
Winery domain, but want to probe for the server to use while
|
|
in the Brewery domain. We would modify our <filename>yp.conf</filename>
|
|
file again to look like this instead:
|
|
|
|
<screen>
|
|
# yp.conf - YP configuration for GNU libc library.
|
|
#
|
|
domain winery server vbardolino
|
|
domain brewery broadcast
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
The <systemitem role="keyword">broadcast</systemitem> keyword tells
|
|
<command>ypbind</command> to use whichever NIS server it finds for the domain.
|
|
<indexterm class="endofrange" startref="idx-filenameypconffilename-1">
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>ypcat</primary><secondary>utility</secondary></indexterm>
|
|
<indexterm><primary>checking</primary><secondary>NIS</secondary></indexterm>
|
|
After creating this basic configuration file and making sure it is
|
|
world-readable, you should run your first test to connect
|
|
to your server. Make sure to choose a map your server distributes, like
|
|
<filename>hosts.byname</filename>, and try to retrieve it by using the
|
|
<command>ypcat</command> utility:
|
|
</para>
|
|
|
|
<para>
|
|
<screen>
|
|
# <userinput>ypcat hosts.byname</userinput>
|
|
172.16.2.2 vbeaujolais.vbrew.com vbeaujolais
|
|
172.16.2.3 vbardolino.vbrew.com vbardolino
|
|
172.16.1.1 vlager.vbrew.com vlager
|
|
172.16.2.1 vlager.vbrew.com vlager
|
|
172.16.1.2 vstout.vbrew.com vstout
|
|
172.16.1.3 vale.vbrew.com vale
|
|
172.16.2.4 vchianti.vbrew.com vchianti
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>rpcinfo command</primary></indexterm>
|
|
The output you get should resemble that just shown. If you get an error
|
|
message instead that says: <literal>Can't bind to server which serves
|
|
domain</literal>, then either the NIS domain name you've set doesn't
|
|
have a matching server defined in <filename>yp.conf</filename>, or the server
|
|
is unreachable for some reason. In the latter case, make sure that a
|
|
<command>ping</command> to the host yields a positive result, and that it is
|
|
indeed running an NIS server. You can verify the latter by using
|
|
<command>rpcinfo</command>, which should produce the following output:
|
|
|
|
<screen>
|
|
# <userinput>rpcinfo -u</userinput> <replaceable>serverhost</replaceable> <userinput>ypserv</userinput>
|
|
program 100004 version 1 ready and waiting
|
|
program 100004 version 2 ready and waiting
|
|
</screen>
|
|
</para>
|
|
<INDEXTERM startref="idx-NISclient-2" class=endofrange>
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-nis.nsswitch"><title>Choosing the Right Maps</title>
|
|
<para>
|
|
<indexterm id="idx-filenamensswitchconffilename-1" class="startofrange"><primary sortas="etc/nsswitch.conf file">/etc/nsswitch.conf file</primary></indexterm>
|
|
<indexterm><primary>choosing</primary><secondary>NIS maps</secondary></indexterm>
|
|
Having made sure you can reach the NIS server, you have to decide which
|
|
configuration files to replace or augment with NIS maps. Commonly, you
|
|
will want to use NIS maps for the host and password lookup functions. The
|
|
former is especially useful if you do not have the BIND name service. The
|
|
password lookup lets all users log into their accounts from any system in the
|
|
NIS domain; this usually goes along with sharing a central
|
|
<filename>/home</filename> directory among all hosts via NFS. The password
|
|
map is explained detail in the next section.
|
|
</para>
|
|
|
|
<para>
|
|
Other maps, like <filename>services.byname</filename>, don't provide such
|
|
dramatic gains, but do save you some editing work. The
|
|
<filename>services.byname</filename> map is valuable if you install
|
|
any network applications that use a service name not in the standard
|
|
<filename>services</filename> file.
|
|
</para>
|
|
|
|
<para>
|
|
Generally, you want to have some choice of when a lookup function uses the
|
|
local files, when it queries the NIS server, and when it uses other servers
|
|
such as DNS. GNU libc allows you to configure the order in which a function
|
|
accesses these services. This is controlled through the
|
|
<filename>/etc/nsswitch.conf</filename> file, which stands for
|
|
<emphasis>Name Service Switch</emphasis>, but of course isn't limited to
|
|
the name service. For any of the data lookup functions supported by GNU libc,
|
|
the file contains a line naming the services to use.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>services.byname map</primary></indexterm>
|
|
The right order of services depends on the type of data each service is
|
|
offering. It is unlikely that the <filename>services.byname</filename> map
|
|
will contain entries differing from those in the local
|
|
<filename>services</filename> file; it will only contain additional entries.
|
|
So it appears reasonable to query the local files first and check NIS only
|
|
if the service name isn't found. Hostname information, on the other hand,
|
|
may change very frequently, so DNS or the NIS server should always have the
|
|
most accurate account, while the local <filename>hosts</filename> file is
|
|
only kept as a backup if DNS and NIS should fail. For hostnames, therefore,
|
|
you normally want to check the local file last.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>gethostbyname( )</primary></indexterm>
|
|
<indexterm><primary>gethostbyaddr( )</primary></indexterm>
|
|
<indexterm><primary>getservbyname( )</primary></indexterm>
|
|
The following example shows how to force <function>gethostbyname</function>
|
|
and <function>gethostbyaddr</function> to look in NIS and DNS before the
|
|
<filename>hosts</filename> file and how to have the
|
|
<function>getservbyname</function> function look in the local files before
|
|
querying NIS. These resolver functions will try each of the listed services
|
|
in turn; if a lookup succeeds, the result is returned; otherwise, they will
|
|
try the next service in the list. The file setting for these priorities is:
|
|
</para>
|
|
|
|
<screen>
|
|
# small sample /etc/nsswitch.conf
|
|
#
|
|
hosts: nis dns files
|
|
services: files nis
|
|
</screen>
|
|
|
|
<para>
|
|
The following is a complete list of services and locations that may be used
|
|
with an entry in the <filename>nsswitch.conf</filename> file. The actual maps,
|
|
files, servers, and objects queried depend on the entry name. The
|
|
following can appear to the right of a colon:
|
|
</para>
|
|
|
|
<variablelist>
|
|
<varlistentry><term><systemitem role="keyword">nis</systemitem></term>
|
|
<listitem><para>
|
|
Use the current domain NIS server. The location of the server queried
|
|
is configured in the <filename>yp.conf</filename> file, as shown in the
|
|
previous section. For the <systemitem role="keyword">hosts</systemitem> entry,
|
|
the <filename>hosts.byname</filename> and <filename>hosts.byaddr</filename>
|
|
maps are queried.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term><systemitem role="keyword">nisplus</systemitem> or
|
|
<systemitem role="keyword">nis+</systemitem></term>
|
|
<listitem><para>
|
|
Use the NIS+ server for this domain. The location of the server is obtained
|
|
from the <filename>/etc/nis.conf</filename> file.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term><systemitem role="keyword">dns</systemitem></term>
|
|
<listitem><para>
|
|
Use the DNS name server. This service type is useful only with the
|
|
<systemitem role="keyword">hosts</systemitem> entry. The name servers queried
|
|
are still determined by the standard <filename>resolv.conf</filename> file.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term><systemitem role="keyword">files</systemitem></term>
|
|
<listitem><para>
|
|
Use the local file, such as the <filename>/etc/hosts</filename> file for the
|
|
<systemitem role="keyword">hosts</systemitem> entry.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term><systemitem role="keyword">compat</systemitem></term>
|
|
<listitem><para>
|
|
Be compatible with older file formats. This option can be used when either
|
|
NYS or glibc 2.x is used for NIS or NIS+ lookups. While these versions
|
|
normally can't interpret older NIS entries in <filename>passwd</filename>
|
|
and <filename>group</filename> files,
|
|
<systemitem role="keyword">compat</systemitem> option allows them to work with
|
|
those formats.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term><systemitem role="keyword">db</systemitem></term>
|
|
<listitem><para>
|
|
Look up the information from DBM files located in the
|
|
<filename>/var/db</filename> directory. The corresponding NIS map name is used for that file.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>
|
|
Currently, the NIS support in GNU libc caters to the following
|
|
<filename>nsswitch.conf</filename> databases:
|
|
<systemitem role="keyword">aliases</systemitem>,
|
|
<systemitem role="keyword">ethers.group</systemitem>,
|
|
<systemitem role="keyword">hosts</systemitem>,
|
|
<systemitem role="keyword">netgroup</systemitem>,
|
|
<systemitem role="keyword">network</systemitem>,
|
|
<systemitem role="keyword">passwd</systemitem>,
|
|
<systemitem role="keyword">protocols</systemitem>,
|
|
<systemitem role="keyword">publickey</systemitem>,
|
|
<systemitem role="keyword">rpc</systemitem>,
|
|
<systemitem role="keyword">services</systemitem>, and
|
|
<systemitem role="keyword">shadow</systemitem>.
|
|
More entries are likely to be added.
|
|
</para>
|
|
|
|
<para>
|
|
<xref linkend="X-087-2-nis.fig.switch"> shows a more complete example that
|
|
introduces another feature of <filename>nsswitch.conf</filename>. The
|
|
<systemitem role="keyword">[NOTFOUND=return]</systemitem> keyword in the
|
|
<systemitem role="keyword">hosts</systemitem> entry tells the NIS client to
|
|
return if the desired item couldn't be found in the NIS or DNS database. That
|
|
is, the NIS client will continue searching the local files
|
|
<emphasis>only</emphasis> if calls to the NIS and DNS servers fail for some
|
|
other reason. The local files will then be used only at boot time and as a
|
|
backup when the NIS server is down.
|
|
</para>
|
|
|
|
<example id="X-087-2-nis.fig.switch">
|
|
<title>Sample nsswitch.conf File</title>
|
|
<screen>
|
|
# /etc/nsswitch.conf
|
|
#
|
|
hosts: nis dns [NOTFOUND=return] files
|
|
networks: nis [NOTFOUND=return] files
|
|
services: files nis
|
|
protocols: files nis
|
|
rpc: files nis
|
|
</screen>
|
|
</example>
|
|
|
|
<para>
|
|
GNU libc provides some other actions that are described in the
|
|
<filename>nsswitch</filename> manpage.
|
|
</para>
|
|
|
|
<indexterm class="endofrange" startref="idx-filenamensswitchconffilename-1">
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-nis.passwd"><title>Using the passwd and group Maps</title>
|
|
<para>
|
|
<indexterm id="idx-NISfilenamepasswdfilenamemaps-1" class="startofrange"><primary>NIS (Network Information System)</primary><secondary>passwd maps</secondary></indexterm>
|
|
<indexterm id="idx-passwordsnetwork-wide-1" class="startofrange"><primary>passwords</primary><secondary>network-wide</secondary></indexterm>
|
|
<indexterm><primary>networks</primary><secondary>passwords</secondary></indexterm>
|
|
<indexterm><primary>Local Area Networks (LANs)</primary><secondary>passwords</secondary></indexterm>
|
|
One of the major applications of NIS is synchronizing user and account
|
|
information on all hosts in an NIS domain. Consequently, you usually keep
|
|
only a small local <filename>/etc/passwd</filename> file, to which
|
|
site-wide information from the NIS maps is appended. However, simply
|
|
enabling NIS lookups for this service in <filename>nsswitch.conf</filename>
|
|
is not nearly enough.
|
|
</para>
|
|
|
|
<para>
|
|
When relying on the password information distributed by NIS, you first
|
|
have to make sure that the numeric user IDs of any users you have in
|
|
your local <filename>passwd</filename> file match the NIS server's idea of
|
|
user IDs. Consistency in user IDs is important for other purposes as
|
|
well, like mounting NFS volumes from other hosts in your network.
|
|
</para>
|
|
<?troff .wcon_off>
|
|
|
|
<para>
|
|
<indexterm><primary sortas="etc/passwd file">/etc/passwd file</primary></indexterm>
|
|
<indexterm><primary sortas="etc/group file">/etc/group file</primary></indexterm>
|
|
If any of the numeric IDs in <filename>/etc/passwd</filename> or
|
|
<filename>/etc/group</filename> differ from those in the maps, you have to
|
|
adjust file ownerships for all files that belong to that user. First, you
|
|
should change all uids and gids in <filename>passwd</filename> and
|
|
<filename>group</filename> to the new values, then find that all files
|
|
that belong to the users just changed and change their
|
|
ownership. Assume <systemitem role="userid">news</systemitem>
|
|
used to have a user ID of 9 and <systemitem role="userid">okir</systemitem>
|
|
had a user ID of 103, which were changed to some other value; you could
|
|
then
|
|
<?troff .ne 10>
|
|
issue the following commands as root:
|
|
|
|
<screen>
|
|
# <userinput>find / -uid 9 -print >/tmp/uid.9</userinput>
|
|
# <userinput>find / -uid 103 -print >/tmp/uid.103</userinput>
|
|
# <userinput>cat /tmp/uid.9 | xargs chown news</userinput>
|
|
# <userinput>cat /tmp/uid.103 | xargs chown okir</userinput>
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
It is important that you execute these commands with the new
|
|
<filename>passwd</filename> file installed, and that you collect all
|
|
filenames before you change the ownership of any of them. To update the
|
|
group ownerships of files, use a similar method with the gid instead of the
|
|
uid, and chgrp instead of chown.
|
|
</para>
|
|
|
|
<para>
|
|
<?troff .hw information>
|
|
Once you do this, the numerical uids and gids on your system will
|
|
agree with those on all other hosts in your NIS domain. The next step
|
|
is to add configuration lines to <filename>nsswitch.conf</filename>
|
|
that enable NIS lookups for user and group information:
|
|
|
|
<screen>
|
|
# /etc/nsswitch.conf - passwd and group treatment
|
|
passwd: nis files
|
|
group: nis files
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>login command and NIS maps</primary></indexterm>
|
|
This affects where the <command>login</command> command and all its
|
|
friends look for user information. When a user tries to log in,
|
|
<command>login</command> queries the NIS maps first, and if this
|
|
lookup fails, falls back to the local files. Usually, you will remove
|
|
almost all users from your local files, and only leave entries for
|
|
<systemitem role="userid">root</systemitem> and generic accounts like
|
|
<systemitem role="userid">mail</systemitem> in it. This is because
|
|
some vital system tasks may have to map uids to usernames or vice
|
|
versa. For example, administrative <command>cron</command> jobs may
|
|
execute the <filename>su</filename> command to temporarily become
|
|
<systemitem role="userid">news</systemitem>, or the UUCP subsystem may
|
|
mail a status report. If <systemitem role="userid">news</systemitem>
|
|
and <systemitem role="userid">uucp</systemitem> don't have entries in
|
|
the local <filename>passwd</filename> file, these jobs will fail
|
|
miserably during an NIS brownout.
|
|
</para>
|
|
|
|
<para>
|
|
Lastly, if you are using either the old NIS implementation (supported by the
|
|
<systemitem role="keyword">compat</systemitem> mode for the
|
|
<filename>passwd</filename> and <filename>group</filename> files in the
|
|
NYS or glibc implementations), you must insert the unwieldy special entries
|
|
into them. These entries represent where the NIS derived records will
|
|
be inserted into the database of information. The entries can be added
|
|
anywhere, but are usually just added to the end. The entries to add for the
|
|
<filename>/etc/passwd</filename> file are:
|
|
|
|
<screen>
|
|
<userinput>+::::::</userinput>
|
|
</screen>
|
|
|
|
and for the <filename>/etc/groups</filename> file:
|
|
|
|
<screen>
|
|
<userinput>+:::</userinput>
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
With both glibc 2.x and NYS you can override parameters in a user’s
|
|
record received from the NIS server by creating entries with a “+”
|
|
prepended to the login name, and exclude specified users by creating
|
|
entries with a “-” prepended to the login name.
|
|
For example the entries:
|
|
|
|
<screen>
|
|
<userinput>+stuart::::::/bin/jacl</userinput>
|
|
<userinput>-jedd::::::</userinput>
|
|
</screen>
|
|
|
|
would override the shell specified for the user
|
|
<systemitem role="userid">stuart</systemitem> supplied by the NIS server,
|
|
and would disallow the user <systemitem role="userid">jedd</systemitem> from
|
|
logging in on this machine. Any fields left blank use the information
|
|
supplied by the NIS server.
|
|
</para>
|
|
|
|
<para>
|
|
There are two big caveats in order here. First, the setup as described up to
|
|
here works only for login suites that don't use shadow passwords. The
|
|
intricacies of using shadow passwords with NIS will be discussed in the next
|
|
section.
|
|
Second, the login commands are not the only ones that access the
|
|
<filename>passwd</filename> file—look at the <command>ls</command>
|
|
command, which most people use almost constantly. Whenever compiling a long
|
|
listing, <command>ls</command> displays the symbolic names for user
|
|
and group owners of a file; that is, for each uid and gid it encounters,
|
|
it has to query the NIS server. An NIS query takes slightly longer to
|
|
perform than the equivalent lookup in a local file. You may find that sharing
|
|
your <filename>passwd</filename> and <filename>group</filename> information
|
|
using NIS causes a noticable reduction in the performance of some programs that
|
|
use this information frequently.
|
|
</para>
|
|
|
|
<para>
|
|
Still, this is not the whole story. Imagine what happens if a user wants to
|
|
change her password. Usually, she will invoke <command>passwd</command>, which
|
|
reads the new password and updates the local <filename>passwd</filename> file.
|
|
This is impossible with NIS, since that file isn't available locally anymore,
|
|
but having users log into the NIS server whenever they want to change their
|
|
passwords is not an option, either. Therefore, NIS provides a drop-in
|
|
replacement for <command>passwd</command> called <command>yppasswd</command>,
|
|
which handles password changes under NIS. To change the password
|
|
on the server host, it contacts the <command>yppasswdd</command> daemon on
|
|
that host via RPC, and provides it with the updated password information.
|
|
Usually you install <command>yppasswd</command> over the normal program by
|
|
doing something like this:
|
|
|
|
<indexterm><primary>yppasswd</primary></indexterm>
|
|
<screen>
|
|
# <userinput>cd /bin</userinput>
|
|
# <userinput>mv passwd passwd.old</userinput>
|
|
# <userinput>ln yppasswd passwd</userinput>
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
At the same time, you have to install <command>rpc.yppasswdd</command> on the
|
|
server and start it from a network script. This will effectively hide any of
|
|
the contortions of NIS from your users.
|
|
</para>
|
|
|
|
<indexterm class="endofrange" startref="idx-passwordsnetwork-wide-1">
|
|
<indexterm class="endofrange" startref="idx-NISfilenamepasswdfilenamemaps-1">
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-nis.shadow"><title>Using NIS with Shadow Support</title>
|
|
<para>
|
|
<indexterm><primary>NIS (Network Information System)</primary><secondary>shadow passwords and</secondary></indexterm>
|
|
<indexterm><primary>shadow passwords and NIS</primary></indexterm>
|
|
Using NIS in conjunction with shadow password files is somewhat problematic.
|
|
First we have some bad news: using NIS defeats the goals of shadow passwords.
|
|
The <filename>shadow</filename> password scheme was designed to prevent
|
|
nonroot users from having access to the encrypted form of the login
|
|
passwords. Using NIS to share <filename>shadow</filename> data by necessity
|
|
makes the encrypted passwords available to any user who can listen to the NIS
|
|
server replies on the network. A policy to enforce users to choose
|
|
“good” passwords is arguably better than trying to shadow
|
|
passwords in an NIS environment. Let's take a quick look at how you do it,
|
|
should you decide to forge on ahead.
|
|
</para>
|
|
|
|
<para>
|
|
In libc5 there is no real solution to sharing <filename>shadow</filename> data
|
|
using NIS. The only way to distribute password and user information by NIS is
|
|
through the standard <filename>passwd.*</filename> maps. If you do have
|
|
shadow passwords installed, the easiest way to share them is to generate a
|
|
proper <filename>passwd</filename> file from <filename>/etc/shadow</filename>
|
|
using tools like <command>pwuncov</command>, and create the NIS maps from
|
|
that file.
|
|
</para>
|
|
|
|
<indexterm><primary sortas="etc/shadow file">/etc/shadow file</primary></indexterm>
|
|
<para>
|
|
Of course, there are some hacks necessary to use NIS and shadow passwords at
|
|
the same time, for instance, by installing an <filename>/etc/shadow</filename>
|
|
file on each host in the network, while distributing user information, through
|
|
NIS. However, this hack is really crude and defies the goal of NIS,
|
|
which is to ease system administration.
|
|
</para>
|
|
|
|
<para>
|
|
<INDEXTERM><PRIMARY>GNU libc (NIS support)</PRIMARY></INDEXTERM>
|
|
<INDEXTERM><PRIMARY>libc6 (NIS support)</PRIMARY></INDEXTERM>
|
|
The NIS support in the GNU libc library (libc6) provides support for shadow
|
|
password databases. It does not provide any real solution to making your
|
|
passwords accessible, but it does simplify password management in
|
|
environments in which you do want to use NIS with shadow passwords.
|
|
To use it, you must create a <filename>shadow.byname</filename> database
|
|
and add the following line to your <filename>/etc/nsswitch.conf</filename> :
|
|
|
|
<screen>
|
|
<userinput># Shadow password support</userinput>
|
|
<userinput>shadow: compat</userinput>
|
|
</screen>
|
|
</para>
|
|
|
|
|
|
<para>
|
|
<?troff .hw chapter>
|
|
If you use shadow passwords along with NIS, you must try to maintain some
|
|
security by restricting access to your NIS database. See <xref linkend="X-087-2-nis.securenets">” earlier in this chapter.
|
|
</para>
|
|
|
|
</sect1>
|
|
<INDEXTERM startref="idx-configuringNIS-1" class=endofrange>
|
|
<INDEXTERM startref="idx-NIS-1" class=endofrange>
|
|
</chapter>
|
|
|