NIS keeps database information is in so-called maps containing
key-value pairs. 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.
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 host name as well as for an IP-address.
Accordingly, two NIS maps are derived from it, called hosts.byname
and hosts.byaddr, respectively. Table-
lists
common maps and the files they are generated form.
Table:
Some standard NIS maps and the corresponding files.
There are other files and maps you may find support for in some NIS package or other. These may contain information for applications not discussed in this book, such as the bootparams map that may used by some BOOTP servers, or which currently don't have any function in (like the ethers.byname and ethers.byaddr maps).
For some maps, people commonly use nicknames, which are shorter and therefore easier to type. To obtain a full list of nicknames understood by your NIS tools, run the following command:
The NIS server 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 will be created only on the master server's host. From there, they are distributed to all slaves.
You will have noticed that we have been talking about ``networks'' very vaguely all the time; of course there's a distinctive concept in NIS that refers to such a network, that is the 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, I will therefore always specify which type of domain I mean.
NIS domains have a purely administrative function only. They are mostly invisible to users, except for the sharing of passwords between all machines in the domain. Therefore, the name given to a 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 super user and type:
NIS domains determine which NIS server an application will query. For instance, the login program on a host at the Winery should, of course, only query the Winery's NIS server (or one of them, if there were 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, namely how a client finds out which server to connect to. The simplest approach would be to have 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, traditional NIS implementations rely on a special daemon called ypbind to detect a suitable NIS server in their NIS domain. Before being able to perform any NIS queries, any 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 potentially fastest one and will be used in all subsequent NIS queries. After a certain interval has elapsed, or if the server becomes unavailable, ypbind will probe for active servers again.
Now, the arguable point about dynamic binding is that you rarely need it, and that it introduces a security problem: ypbind blindly believes whoever answers, which could be a humble NIS server as well as a malicious intruder. Needless to say this becomes especially troublesome if you manage your password databases over NIS. To guard against this, NYS does not use ypbind by default, but rather picks up the server host name from a configuration file.