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, nsd , runs on all NIS clients. In this instance, the daemon is responsible for remembering information necessary for communicating with the NIS server process. See the nsd(1M) man page for more information.
The nsd daemon also acts as the server daemon and runs on all NIS servers. It acts as the database server and is responsible for answering client inquiries and managing database updates. Most NIS servers are also NIS clients; they use the NIS database information.
On the NIS master server, the server process daemon, nsd, runs to answer client inquiries and to solicit information from the NIS database. The master server also runs a second daemon, /usr/etc/rpc.passwd, which allows NIS users to remotely modify their NIS password by using yppasswd and to modify some other password file fields by using ypchpass . For more information, see the yppasswd(1) and ypchpass(1) man pages.
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 by using the chkconfig command). The chkconfig flags for NIS are nsd, 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 NSD server 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, and the server daemon, determines whether or not an NIS connection is bound or unbound. A brief summary of the binding process is given below.
To obtain the IP address and port number for the NIS server process, NSD 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 are remembered by the NSD process and used to obtain NIS database information. The alternative is to supply a list of host names or IP addresses for nsd to bind to. For more information, see the /etc/config/nsd.options and /etc/nsswitch.conf files.
Figure 2-1 illustrates the binding process initiated for an ls 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, 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. For more information, see the ls(1) and getpwuid(1) man pages.
When a client boots, NSD broadcasts or multicasts, by default, to the portmap port number for the NIS service. The portmapper forwards the packet to the NIS server, if there is one running on the machine, which then determines whether or not it services the domain requested. Similarly, NSD broadcasts, asking for a new NIS server if the old server fails to respond, or it selects the next one on the list, determined by the contents of the /etc/config/NSD.options or the /etc/nsswitch.conf files. An nsd daemon runs on both the client and the server. The ypwhich (1) command gives the name of the server to which NSD is currently bound.
The NIS database is a collection of files in mdbm format. To create the database, the NIS tool makemdbm converts input files (usually ASCII) to output files. The output files have .m extensions. Each is a map. For example, the aliases map is composed of the file aliases.m.
A typical listing of NIS database files looks like this:
bootparams.m mac.byname.m passwd.byuid.m capability.byname.m mac.byvalue.m protocols.byname.m clearance.byname.m mail.aliases.m protocols.bynumber.m ethers.byaddr.m mail.byaddr.m rpc.byname.m ethers.byname.m netgroup.byhost.m rpc.bynumber.m group.bygid.m netgroup.byuser.m group.byname.m netid.byname.m group.bymember.m networks.byaddr.m hosts.byaddr.m networks.byname.m hosts.byname.m passwd.byname.m |
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. Following is a list of standard MIS maps:
bootparams hosts.byaddr netgroup.byhost protocols.bynumber capability.byname hosts.byname netgroup.byuserrpc.byname clearance.byname jlimits netid.byname rpc.bynumber ethers.byaddr mac.byname networks.byaddr services ethers.byname mac.byvalue networks.bynameservices.byname group.bygid mail.aliases passwd.byname shadow group.byname mail.byaddr passwd.byuid ypservers group.bymember 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-2 shows the list of default nicknames and full names for maps supplied in the NIS release.
Table 2-2. 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 because 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 using the crontab command 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 the ypmake command, ypmake looks at mdbm_parse to determine which maps to make. The mdbm_parse command updates the maps and calls yppush. The yppush command reads the ypservers map to determine which slave servers to contact; yppush contacts NSD on the selected slave servers and requests ypxfr service. The slave server can now transfer the maps using ypxfr. For more information on map propagation methods, see the cron(1), ypmake(1M), yppush(1M), and ypxfr(1M) man pages.
Figure 2-2 illustrates the propagation process between a master server and a slave server using ypmake.
Network files under system control can be divided into two groups: local files and global files. Local files are those that NIS first checks on the local system and may continue checking in the NIS database. Global files reside in the NIS database and are always consulted by programs using NIS. The level of system control over some files depends on the NIS syntax used within those files.
The next two sections discuss the local and global files consulted by NIS. More information on these configuration files is included in IRIX Admin: System Configuration and Operation.
Table 2-3 shows the local files that NIS consults, the use of which is determined by how they are ordered in /etc/nsswitch.conf. These files can be controlled at different levels. Two special cases, however, are /etc/aliases and /etc/passwd.
The /etc/aliases and /etc/passwd files may contain a special cookie starting with a plus sign (+). This directs the files parser to insert data from subsequent libraries at that point. This replacement is done in the files protocol library, but only if the NSD attribute compat is set in the nsswitch.conf file.
For example, a program that calls getpw ent to access /etc/passwd (a local file) first looks in the password file on your system (if there is a password entry in the nsswitch.conf file); the NIS password file is consulted only if your system's password file contains this plus sign (+) entry (see the passwd man page).
Table 2-4 shows some examples of plus (+) and minus (–) entries for the local /etc/group and /etc/passwd files. Note that the position of + and – entries in the files affects processing. The first entry (+, –, or regular) is the one that is used.
Table 2-4. Local File Entries to Control Access
Local File | Example Entry | Meaning of the Entry |
|---|---|---|
/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 the /etc/hosts.equiv file, 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 the .rhosts file.
In /etc/aliases, if there is a +:+ entry, the NIS aliases map is consulted. Otherwise, NIS is not consulted.
All global files are controlled by the /etc/nsswitch.conf file, which determines the maps, the methods, and the order in which they are looked up. The compatibility attribute to override local control of a file is set in the following manner in the nsswitch.conf file:
passwd: files(compat) [notfound=return] nis |
This line compels files to be searched in the historical manner: the files are parsed and if a +/- entry is found, the next element is called. If the requested item is not found in the file, either as a regular entry or as one of the + or - entries, then control is returned immediately, without notification, to the next name service.
For example, previously ypserv had a flag -i pertaining to the hosts map, which meant if a requested item was not found in the dbm files (NIS maps), then the request was forwarded to DNS. An IRIX server has an nsswitch.conf file just like the client, which gives a resolve order for each map. Now the line for hosts in the /var/ns/domains/domainname/nsswitch.conf file for the server and the /var/ns/nsswitch.conf.sisserv file for clients shows an entry nisserv, referring to the library for serving NIS. If you put dns after that, the name server will use DNS if a requested key is not found in the maps:
hosts: nisserv dns |
If the -i flag was previously used, the entry should exist as described. Note that ypserv no longer exists.
This section provides a quick reference to NIS daemons, files, and tools and suggests the man pages you should consult for complete information. The man pages at the end of this guide contain detailed information on the structure of the NIS system and NIS commands.
NIS daemons are as follows:
NIS configuration files are as follows:
NIS tools are as follows:
In addition to these NIS tools, the rpcinfo and crontab tools are also useful for administering NIS. For further information, please see the man page for each tool.