To be prepared for managing NIS, you should understand NIS software elements and the tools available for controlling its operation. This chapter contains the prerequisite information. It identifies NIS client and server daemons and their interactions, and describes a special daemon interaction called binding. It also explains how the NIS database is created and maintained, and how local client files and global files are used when NIS is in effect. Finally, this chapter provides a quick reference guide to NIS software and NIS management tools.
This chapter contains these sections:
Which NIS daemons are running on a system depends on the system's function in the NIS environment: clients, master servers, and slave servers each run a particular set of daemons.
Table 2-1 lists the daemons required for each type of system for NIS to function correctly.
The binder daemon, ypbind(1M), runs on all NIS clients. This daemon is responsible for remembering information necessary for communicating with the NIS server process, ypserv(1M).
The server daemon, ypserv, runs on all NIS servers. The ypserv daemon is the database server and is responsible for answering client inquiries. It is also responsible for managing database updates. Most NIS servers are also NIS clients; they use the NIS database information. As NIS clients, NIS servers also run the binder daemon, ypbind.
The NIS master server also runs the server process daemon, ypserv, to answer client inquiries. The NIS master server typically runs the binder process daemon, ypbind, to solicit information from the NIS database. The master server also runs a third daemon, /usr/etc/rpc.passwd, which allows NIS users to remotely modify their NIS password with yppasswd(1) and to modify some other password file fields with ypchpass(1).
On IRIX, NIS daemons are started by the master network script, /etc/init.d/network, if the NIS daemon flags are set on (flags can be set with the chkconfig(1M) command). There are three chkconfig flags for NIS: yp, ypserv, and ypmaster (see Chapter 4, “Setting Up and Testing NIS,” for more details).
In binding, a process remembers the address at which the ypserv process is listening for requests. In the NIS environment, when an application on a client needs information that is normally derived from certain local files, the application solicits the information from the NIS database on a selected NIS server. The relationship between the binder daemon, ypbind, and the server daemon, ypserv, determines whether or not an NIS connection is bound or unbound. A brief summary of the binding process is given below.
An application, through library routines, contacts the local portmap(1M) program to determine the appropriate port number for ypbind. The portmap program returns the port number to use to contact ypbind. Port numbers are defined in /etc/rpc. Once the local system has the port number for ypbind, it requests an IP address and port number for an NIS server process, ypserv, within its domain.
To obtain the IP address and port number for the NIS server process, ypbind broadcasts for any NIS server within its domain. The first NIS server process to respond with its IP address and port number, whether local or remote, is the process that is used to service the request. The IP address for the physical NIS server and the port number for the NIS server process, ypserv, are remembered by the ypbind process and used to obtain NIS database information. The association between the binder daemon, ypbind, and the server daemon, ypserv, must be present for binding to occur.
Figure 2-1 illustrates the binding process initiated for an ls(1) command. Before the ls command can list the contents of a directory, it needs to translate the file's user ID into a user's name. ls uses the library routine getpwuid(3C), which accesses the local /etc/passwd file and the NIS password file as appropriate. In an NIS environment, this entails accessing the password map in the NIS database. Note that the general process is the same whether binding occurs on the local system or between remote systems.
When a client boots, ypbind broadcasts, by default, asking for an NIS server. Similarly, ypbind broadcasts asking for a new NIS server if the old server fails to respond. The ypwhich(1) command gives the name of the server to which ypbind is currently bound.
The NIS database is a collection of files in dbm format. To create the database, the NIS tool makedbm(1M) converts input files (usually ASCII) to pairs of output files. The output files have .dir and .pag extensions. Each pair is a map. For example, the aliases map is composed of the files aliases.dir and aliases.pag.
A typical listing of NIS database files looks like this:
aliases.dir host.addr.dir netid.byname.dir pw.name.dir aliases.pag host.addr.pag netid.byname.pag pw.name.pag bootparams.dir host.name.dir nets.addr.dir pw.uid.dir bootparams.pag host.name.pag nets.addr.pag pw.uid.pag ether.addr.dir mail.byaddr.dir nets.name.dir rpc.nbr.dir ether.addr.pag mail.byaddr.pag nets.name.pag rpc.nbr.pag ether.name.dir netgrp.dir proto.name.dir svc.name.dir ether.name.pag netgrp.pag proto.name.pag svc.name.pag grp.gid.dir netgrp.hist.dir proto.nbr.dir ypservers.dir grp.gid.pag netgrp.hist.pag proto.nbr.pag ypservers.pag grp.name.dir netgrp.usr.dir pw.name.dir grp.name.pag netgrp.usr.pag pw.name.pag |
The NIS application is capable of making and updating a particular set of maps automatically. These are known as standard maps and are derived from regular ASCII files. The maps included in a standard set vary with each NIS release. Nonstandard maps are maps that have no ASCII form or maps that are created for vendor- or site-specific applications; NIS does not automatically know how to make or update nonstandard maps. NIS can serve any number of standard (default) and nonstandard maps.
Table 2-2 shows the standard NIS maps.
Table 2-2. Standard Set of NIS Maps
bootparams | hosts.byname | netid.byname | protocols.bynumber |
ethers.byaddr | mail.aliases | networks.byaddr | rpc.bynumber |
ethers.byname | mail.byaddr | networks.byname | services.byname |
group.bygid | netgroup.byhost | passwd.byname | ypservers |
group.byname | netgroup.byuser | passwd.byuid |
|
hosts.byaddr | netgroup | protocols.byname |
|
In most cases, the format of the data in NIS default maps is identical to the format within the ASCII files.
Some maps have default nicknames to make administration easier. The ypcat(1) command, a general NIS database print program, with the –x option prints a list of default map nicknames and their corresponding full names. Table 2-3 shows the list of default nicknames and full names for maps supplied in the NIS release.
Table 2-3. Default Nicknames for Maps
Map Nickname | Map Full Name |
|---|---|
aliases | mail.aliases |
ethers | ethers.byname |
group | group.byname |
hosts | hosts.byaddr |
networks | networks.byaddr |
passwd | passwd.byname |
protocols | protocols.bynumber |
rpc | rpc.bynumber |
services | services.byname |
For example, the command ypcat hosts is translated into ypcat hosts.byaddr since there is no map called hosts.
Propagating an updated database from master server to slave servers ensures database consistency between all NIS clients. Databases can be updated in two ways: periodically with crontab(1) and interactively from the command line (see Chapter 5, “Maintaining NIS,” for details on map propagation methods).
The propagation process varies depending on the propagation method. For example, when a map is updated and propagated using ypmake(1M), ypmake looks at /var/yp/make.script and /var/yp/local.make.script (if it exists) to determine which maps to make. /var/yp/make.script calls makedbm(1M), which updates the maps and calls yppush(1M). yppush reads the ypservers map to determine which slave servers to contact; yppush contacts ypserv on the selected slave servers and requests ypxfr(1M) service. The slave server can now transfer the maps with ypxfr.
Figure 2-2 illustrates the propagation process between a master server and a slave server using ypmake.
When a system becomes an NIS client, it completely relinquishes control over some network-related files and maintains varying levels of control over others. The amount of control relinquished on certain files depends upon the NIS syntax used within the file.
These network-related files can be divided into two groups: local files and global files. Local files are those files that NIS first checks on the local system and may continue checking in the NIS database. Global files are those files that reside in the NIS database and are always consulted by programs using NIS. The next two sections discuss the local and global files consulted by NIS. More information on these configuration files is included in the IRIX Advanced Site and Server Administration Guide.
Table 2-4 shows the local files that NIS consults. Local files allow levels of control. For example, a program that calls getpwent(3C) to access /etc/passwd (a local file) first looks in the password file on your system; the NIS password file is consulted only if your system's password file contains a plus sign (+) entry (see passwd(4)).
Table 2-4. Local Files Consulted by NIS
Local File |
|---|
/etc/group |
/etc/hosts.equiv |
/etc/passwd |
/etc/aliases |
.rhosts |
If shadow passwords are used (/etc/shadow exists on the local system), the NIS password file isn't consulted at all.
The /etc/group and /etc/passwd files may have plus (+) or minus (–) entries to designate levels of local control. Table 2-5 shows some examples of +/– entries for the local /etc/group and /etc/passwd files. Note that the position of +/– entries in the files does affect processing. The first entry, +/– or regular, is the one that is used.
Table 2-5. Local File Entries to Control Access
Local File | Example Entry | Meaning of the Entry |
|---|---|---|
/etc/group | +: | Get all group information from the NIS group database. |
| +angels:::mark,john | Assign the users mark and john to the group angels. mark and john's group password (if any) and group ID is taken from the NIS angels group entry. |
| -spies | Disallow subsequent entries, both local and NIS, for the group spies. |
/etc/passwd | +: | Get all password information from the NIS password database. |
| +gw: | Get all user account information for gw from NIS. |
| +@marketing: | Allow anyone in the marketing netgroup (see “Using Netgroups” in Chapter 5 for details) to log in using NIS account information. |
| +nb::::Nancy Doe:/usr2/nb:/bin/csh (shown wrapped; entry is one line) | Get the user password, user ID, and group ID from NIS. Get the user's name, home directory, and default shell from the local entry. |
| -fran: | Get all user account information from NIS and disallow any subsequent entries (local or NIS) for fran. |
| -@engineering: | Disallow any subsequent entries (local or NIS) for all members in the netgroup engineering. |
In /etc/hosts.equiv, if there are + or – entries whose arguments are @ symbols and netgroups, the NIS netgroup map is consulted; otherwise NIS is not consulted. This rule also applies to .rhosts.
In /etc/aliases, if there is a +:+ entry, the NIS aliases map is consulted. Otherwise, NIS is not consulted.
Table 2-6 shows the global files that NIS consults. Local copies of these files are ignored when NIS is running, except in the cases noted below.
Table 2-6. Global Files Consulted by NIS
Global Files |
|---|
/etc/bootparams |
/etc/ethers |
/etc/hosts |
/etc/netgroup |
/etc/networks |
/etc/protocols |
/etc/rpc |
/etc/services |
The information in global files is network-wide data, and only NIS accesses it. However, you must make sure each client has an entry for itself in /etc/hosts when booting. If NIS is running, NIS checks only global files; NIS does not consult global files on your local system. For bootparams, services and rpc, the files on the local system are consulted only if the answer is not in the NIS database. By default, the local file /etc/hosts is not consulted if NIS is running. To change the default, edit /etc/resolv.conf as specified in the resolver(4) manual page.
This section provides a quick reference to NIS daemons, files, and tools and suggests the manual pages you should consult for complete information. The manual pages at the end of this guide contain detailed information on the structure of the NIS system and NIS commands.
In addition to these NIS tools, the rpcinfo(1M) and crontab tools are also useful for administering NIS.