Author: Evi Nemeth, Garth Snyder, and Trent Hein
This article is excerpted from the newly published book Linux Administration Handbook, Second Edition.
The unit of sharing in NIS is the record, not the file. A record usually corresponds to one line in a config file. A master server maintains the authoritative copies of system files, which are kept in their original locations and formats and are edited with a text editor just as before. A server process makes the contents of the files available over the network. A server and its clients constitute an NIS “domain.”
Data files are preprocessed into database files by the Berkeley DB hashing library to improve the efficiency of lookups. After editing files on the master server, you use make to tell NIS to convert them to their hashed format.
Only one key can be associated with each entry, so a system file may have to be translated into several NIS “maps.” For example, the /etc/passwd file is translated into two different maps called passwd.byname and passwd.byuid. One map is used to look up entries by username and the other to look up entries by UID. Either map can be used to enumerate the entries in the passwd file. However, because hashing libraries do not preserve the order of records, there is no way to reconstruct an exact duplicate of the original file (unless it was sorted).
NIS allows you to replicate the network maps on a set of slave servers. Providing more than one server helps relieve the load on the master and helps keep clients working even when some servers become unavailable. Whenever a file is changed on the master server, the corresponding NIS map must be pushed out to the slaves so that all servers provide the same data. Clients do not distinguish between the master server and the slaves.
In the traditional NIS implementation, you must place at least one NIS server on every physical network. Clients use IP broadcasting to locate servers, and broadcast packets are not forwarded by routers and gateways. The ypset command can point a client at a particular server; however, at the first hint of trouble, the client attempts to locate a new server by broadcasting. Unless a server on the client’s network responds, this sequence of events can cause the client to hang.
This system causes a lot of problems, not least of which is that it is extremely insecure. An intruder can set up a rogue NIS server that responds to broadcasts and either provides bogus data or delivers a denial of service attack by allowing binding and then blocking on actual requests. These days, the preferred management technique is to give each client an explicit list of its legitimate NIS servers. This system also has the advantage that the servers need not be on the local subnet.
Under Linux, servers are listed in /etc/yp.conf. Here’s an example for the NIS domain atrustnis:
domain atrustnis server 10.2.2.3 domain atrustnis server 10.2.2.4
There is one line for each server; if one server goes down, NIS fails over to another. Note that the servers are given in the form of IP addresses. yp.conf accepts hostnames, but these hostnames must then be resolvable at boot time (i.e., enumerated in the /etc/hosts file or resolvable through DNS).
If you must use broadcast mode, the syntax is
domain atrustnis broadcast
Understanding how NIS works
NIS’s data files are stored in the directory /var/yp. Each NIS map is stored in a hashed format in a subdirectory of the NIS directory named for the NIS domain. There is one map (file) for each key by which a file can be searched. For example, in the domain cssuns, the DB files for the /etc/passwd maps might be
/var/yp/cssuns/passwd.byname/var/yp/cssuns/passwd.byuid
The passwd file is searchable by both name and UID, so two maps are derived from it.
The makedbm command generates NIS maps from flat files. However, you need not invoke this command directly; a Makefile in /var/yp generates all the common NIS maps. After you modify a system file, cd to /var/yp and run make. The make command checks the modification time of each file against the modification times of the maps derived from it and runs makedbm for each map that needs to be rebuilt.
Maps are copied from the master server to the slave servers by the ypxfr command. ypxfr is a pull command; it must be run on each slave server to make that server import the map. Slaves usually execute ypxfr every so often just to verify that they have the most recent maps; you can use cron to control how often this is done.
The default implementation of map copying is somewhat inefficient. Linux furnishes a daemon called rpc.ypxfrd that can be run on the master server to speed responses to ypxfr requests. rpc.ypxfrd sidesteps the normal NIS protocol and simply hands out copies of the map files.
yppush is a “push” command that’s used on the master server. It actually does not transfer any data but rather instructs each slave to execute a ypxfr. The yppush command is used by the Makefile in the NIS directory to ensure that newly updated maps are propagated to slaves.
The special map called ypservers does not correspond to any flat file. This map contains a list of all the servers of the domain. It’s automatically constructed when the domain is set up with ypinit (see Configuring NIS servers on page 518). Its contents are examined when the master server needs to distribute maps to slaves.
After initial configuration, the only active components of the NIS system are the ypserv and ypbind daemons. ypserv runs only on servers (both master and slave); it accepts queries from clients and answers them by looking up information in the hashed map files.
| NIS query procedure |
ypbind runs on every machine in the NIS domain, including servers. The C library contacts the local ypbind daemon when it needs to answer an administrative query (provided that /etc/nsswitch.conf says to do so). ypbind locates a ypserv in the appropriate domain and returns its identity to the C library, which then contacts the server directly.
Current Linux versions of ypbind periodically check to be sure they are dealing with the most responsive server for an NIS domain. This is an improvement over the traditional implementation, which fixates on a particular server. Another feature unique to Linux is that clients can bind to different NIS domains for different maps.
NIS includes a number of minor commands that examine maps, find out which version of a map each server is using, and control the binding between clients and servers. A complete list of NIS commands and daemons is given in table below.
NIS commands and daemons
|
Program |
Description |
|
ypserv |
Is the NIS server daemon, started at boot time |
|
ypbind |
Is the NIS client daemon, started at boot time |
|
domainname |
Sets the NIS domain a machine is in (run at boot time) |
|
ypxfr |
Downloads current version of a map from master server |
|
ypxfrd |
Serves requests from ypxfr (runs on master server) |
|
yppush |
Makes slave servers update their versions of a map |
|
makedbm |
Builds a hashed map from a flat file |
|
ypmake |
Rebuilds hashed maps from flat files that have changed |
|
ypinit |
Configures a host as a master or slave server |
|
ypset |
Makes ypbind connect to a particular server |
|
ypwhich |
Finds out which server the current host is using |
|
yppoll |
Finds out what version of a map a server is using |
|
ypcat |
Prints the values contained in an NIS map |
|
ypmatch |
Prints map entries for a specified key |
|
yppasswd |
Changes a password on the NIS master server |
|
ypchfn |
Changes GECOS information on the NIS master server |
|
ypchsh |
Changes a login shell on NIS master server |
|
yppasswdd |
Is the server for yppasswd, ypchsh, and ypchfn |
|
ypupdated a |
Is the server for updating NIS maps (managed by inetd) |
a. Must be specifically enabled with ypbind –ypsetme or ypbind –ypset (dangerous)
Now that you know the basics, tomorrow we’ll cover the advantages and disadvantages of NIS.
© Copyright Pearson Education. All rights reserved.
