NIS keeps database information in files called maps,
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.[1]
The maps themselves are usually generated from master text files such as
/etc/hosts or /etc/passwd. For
some files, several maps are created, one for each search key type. For
instance, you may search the hosts file for a hostname
as well as for an IP address. Accordingly, two NIS maps are derived from it,
called hosts.byname and hosts.byaddr.
Table 13-1 lists common maps and the files from
which they are generated.
Table 13-1. Some Standard NIS Maps and Corresponding Files
| Master File | Map(s) | Description |
|---|
| /etc/hosts | hosts.byname, hosts.byaddr | Maps IP addresses to host names |
| /etc/networks | networks.byname, networks.byaddr | Maps IP network addresses to network names |
/etc/passwd | passwd.byname, passwd.byuid | Maps encrypted passwords to user login names |
/etc/group | group.byname, group.bygid | Maps Group IDs to group names |
/etc/services | services.byname, services.bynumber | Maps service descriptions to service names |
| /etc/rpc | rpc.byname, rpc.bynumber | Maps Sun RPC service numbers to RPC service names |
| /etc/protocols | protocols.byname, protocols.bynumber | Maps protocol numbers to protocol names |
| /usr/lib/aliases | mail.aliases | Maps mail aliases to mail alias names |
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 bootparams map that is used by Sun's
bootparamd server.
For some maps, people commonly use nicknames, which are
shorter and therefore easier to type. Note that these nicknames are understood
only by ypcat and ypmatch, two tools for
checking your NIS configuration. To obtain a full list of nicknames understood
by these tools, run the following command:
$ ypcat -x
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" |
The NIS server program is traditionally called ypserv. 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 master
server, and the others slave servers. Maps are
created only on the master server's host. From there, they are distributed to
all slaves.
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
NIS domain. 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.
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 brewery and
winery respectively. Another quite
common scheme is to simply use the DNS domain name for NIS as well.
To set and display the NIS domain name of your host, you can use the
domainname command. When invoked without any argument, it
prints the current NIS domain name; to set the domain name, you must
become the superuser:
NIS domains determine which NIS server an application will query. For
instance, the login 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.
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 ypbind
to detect a suitable NIS server in their NIS domain. Before performing any
NIS queries, an application first finds out from
ypbind which server to use.
ypbind 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, ypbind
probes for active servers again.
Dynamic binding is useful only when your network provides more than one
NIS server. Dynamic binding also introduces a security problem.
ypbind 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 ypbind 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.
