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.
Map Full Name
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.
Meaning of the Entry
Get all password information from the NIS password database.
Get all user account information for gw from NIS.
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.
Get all user account information from NIS and disallow any subsequent entries (local or NIS) for fran.
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:
The default location of NIS database files. For more information, see the ypfiles man page.
Specifies an alternate NIS password filename. Default password file is /etc/passwd. Must be used in conjunction with the /etc/config/ypmaster.options PWFILE variable. For more information, see the rpc.passwd man page.
NIS tools are as follows:
A low-level tool for building an mdbm file that is a valid NIS map. You can use makemdbm to build or rebuild databases not built from /var/yp/mdbm_parse. You can also use mdbm_dump to disassemble a map so that you can see the key-value pairs that comprise it. In addition, you can modify the disassembled form with standard tools (such as editors, awk, grep, and cat). The disassembled form is in the form required for input back into makemdbm. See the makedbm(1M) man page for more information.
Lists the contents of an NIS map. Use it when you do not care which server's map version you see. If you need to see a particular server's map, use the rlogin or rsh commands to gain access to that server, and use makemdbm. For details on ypcat, see the ypcat(1) man page.
Changes select NIS password fields. As the NIS user, you can change your full name, your home directory, and your default shell environment. Use yppasswd to change your NIS password. See the ypchpass(1) man page for details on the distinction between the two.
Constructs many maps from files located in /etc, such as /etc/hosts, /etc/passwd, and others. The database initialization tool ypinit does all such construction automatically. Also, it constructs initial versions of maps required by the system but not built from files in /etc; an example is the map ypservers. Use this tool to set up the master NIS server and the slave NIS servers for the first time. Use ypinit to construct initial versions of maps rather than as an administrative tool for running systems. See the ypinit(1M) man page for details.
Builds several commonly changed components of the NIS database from several ASCII files normally found in /etc: bootparams, passwd, hosts, group, netgroup, networks, protocols, rpc, and services, and the file /etc/aliases. The /var/yp/ypmake.log file is the log file for all ypmake activity. For more information, see the ypmake(1M) man page.
Prints the value for one or more specified keys in an NIS map. Again, you have no control over which server's version of the map you are seeing. See the ypmatch(1) man page for details on using ypmatch.
Allows NIS users to remotely change their NIS passwords. For details see the yppasswd(1M) man page.
Asks nsd for the information it holds internally about a single map. See the yppoll(1M) man page for details on using yppoll.
Runs on the master NIS server. It requests each of the nsd processes within a domain to transfer a particular map, waits for a summary response from the transfer agent, and prints out the results for each server. For more information, see the yppush(1M) man page.
Tells an nsd process (the local one, by default) to get NIS services for a domain from a named NIS server. By default, nsd disallows the use of ypset. See the ypset(1M) man page for details on enabling ypset.
Tells you which NIS server a node is using at the moment for NIS services, or which NIS server is master of some named map. For more information, see the ypwhich(1M) man page.
Moves an NIS map from one NIS server to another, using NIS itself as the transport medium. You can run it interactively, or periodically from crontab. Also, nsd uses ypxfr as its transfer agent when it is asked to transfer a map. You can create the file /var/yp/ypxfr.log to log all ypxfr activity. See the ypxfr(1M) man page for details.
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.