• Choose a category
• All
• Classic-Fiction

% rpcinfo -b ypserv 1

131.40.52.138.3.255 poi

131.40.52.27.3.166 onaga

131.40.52.28.3.163 mahimahi

In this example, all NIS servers on the local network answer the rpcinfo broadcast request to the null procedure of the ypserv daemon. If poi should not be an NIS server, then the network will be prone to periods of intermittent failure if clients bind to it. Failure to fully decommission a host as an NIS server — leaving empty NIS map directories, for example — may cause this problem.

There's another possibility for NIS failure that rpcinfo cannot detect: there may be NIS servers on the network, but no servers for the client's NIS domain. In the previous example, poi may be a valid NIS server in another domain, in which case it is operating properly by responding to the rpcinfo broadcast. You might not be able to get ypbind started on an NIS client because all of the servers are in the wrong domain, and therefore the client's broadcasts are not answered. The rpcinfo -b test is a little misleading because it doesn't ask the NIS RPC daemons what domains they are serving, although the client's requests will be domain-specific. Check the servers that reply to an rpcinfo -b and ensure that they serve the NIS domain used by the clients experiencing NIS failures.

If a client cannot find an NIS server, ypbind hangs the boot sequence with errors of the form:

WARNING: Timed out waiting for NIS to come up

Using rpcinfo as shown helps to determine why a particular client cannot start the NIS service: if no host replies to the rpcinfo request, then the broadcast packet is failing to reach any NIS servers. If the NIS domain name and the broadcast address are correct, then it may be necessary to override the broadcast-based search and hand ypbind the name and address of a valid NIS server. Tools for examining and altering NIS bindings are the subject of the next section.

* * *

[8] The rpcbind daemon and the old portmapper provide the same RPC service. The portmapper implements Version 2 of the portmap protocol (RPC program number 100000), where the rpcbind daemon implements Versions 3 and 4 of the protocol, in addition to Version 2. This means that the rpcbind daemon already implements the functionality provided by the old portmapper. Due to this overlap in functionality and to add to the confusion, many people refer to the rpcbind daemon as the portmapper.

NIS tools

Tools discussed to this point help to dissect the session and transport layers under an application such as NIS. The application and the utilities that analyze its behavior and performance all rely on a well-behaved network. Assuming that the lower layers are in place, NIS-oriented tools fine-tune the NIS system and help resolve problems that are caused by information in the NIS maps, rather than the way in which the maps are accessed. The tools described in this section alter client-server bindings, locate NIS servers and information for a particular map, and look up keys in maps.

Key lookup

ypmatch is a grep-like command for NIS maps. ypmatch finds a single key in an NIS map and prints the data associated with that key:

% ypmatch help-request aliases

john.goodman

% ypmatch onaga hosts

131.40.52.27 onaga

This procedure differs from using grep on the ASCII source file that produced the map in two ways:

ypmatch can be run from any client, while the NIS map source files may only exist on a server with limited user access. Therefore, users who need to parse maps such as the password, ipnodes, or hosts files must use NIS-oriented tools to gather their data.

The client may be bound to an NIS server with a corrupted map set or one that is out-of-date with the NIS master server. In this case, the output of ypmatch will not agree with the output of grep run on the ASCII source file.

Associated with ypmatch is ypcat, which is the equivalent of cat for NIS files. It writes the entire map file to the standard output:

% ypcat hosts

131.40.52.121 vineyard