• Choose a category
• All
• Classic-Fiction

If the log file /var/yp/ypserv.log exists when ypserv is started, error and warning messages will be written to this file. If an NIS server receives a service request for a domain it cannot serve, it logs messages such as:

ypserv: Domain financials not supported (broadcast)

indicating that it ignored a broadcast request for an unknown domain. If each server handles only its default domain, binding attempts overheard from other domains generate large numbers of these log messages. Running multiple NIS domains on a single IP network is best done if every server can handle every domain, or if you turn off logging. If not, you will be overwhelmed with these informational error messages that do nothing but grow the log file.

ypserv keeps the file open while it is running, so a large log file must be cleaned up by truncating it:

# cat /dev/null > /var/yp/ypserv.log

Removing the file with rm clears the directory entry, but does not free the disk space because the ypserv process still has the file open. If you have multiple domains with distinct servers on a single network, you probably shouldn't enable NIS logging.

The ypbind daemon

The ypbind daemon is central to NIS client operation. Whenever any system is running ypbind, it is an NIS client — no matter what else it is doing. Therefore, it will be worth our effort to spend some time thinking about ypbind.

When ypbind first starts, it finds a server for the host's default domain. The process of locating a server is called binding the domain. If processes request service from other domains, ypbind attempts to locate servers for them as needed. ypbind reads a file like /var/yp/binding/bedrock/ypservers to get the name of an NIS server to bind to. If the NIS server chosen for a domain crashes or begins to respond slowly due to a high load, ypbind selects the next NIS server in the ypservers file to re-bind. The NIS timeout period varies by implementation, but is usually between two and three minutes. Each client can be bound to several domains at once; ypbind manages these bindings and locates servers on demand for each newly referenced NIS domain.

A client in the NIS server-client relationship is not just a host, but a process on that host that needs NIS map information. Every client process must be bound to a server, and they do so by asking ypbind to locate a server on their behalf. ypbind keeps track of the server to which it is currently directing requests, so new client binding requests can be answered without having to contact an NIS server. ypbind continues to use its current server until it is explicitly told, as the result of an NIS RPC timeout, that the current server is not providing prompt service. After an RPC timeout, ypbind will try the next server in the ypservers file in an attempt to locate a faster NIS server. Because all client processes go through ypbind, we usually don't make a distinction between the client processes and the host on which they are running — the host itself is called the NIS client.

Once ypbind has created a binding between a client and a server, it never talks to the server again. When a client process requests a binding, ypbind simply hands back the name of the server to which the queries should be directed. Once a process has bound to a server, it can use that binding until an error occurs (such as a server crash or failure to respond). A process does not bind its domain before each NIS RPC call.

Domain bindings are shown by ypwhich:

% domainname

nesales

% ypwhich

wahoo

Here, ypwhich reports the currently bound server for the named domain. If the default or the named domain is not bound, ypwhich reports an error:

gonzo% ypwhich -d financials

Domain financials not bound on gonzo

An NIS client can be put back in standalone operation by modifying /etc/nsswitch.conf:

client# cp /etc/nsswitch.files /etc/nsswitch.conf

NIS server as an NIS client

Previously, we recommended that NIS servers also be NIS clients. This has a number of important effects on the network's behavior.