ypserv(8yp)

Name

ypserv, ypbind − yellow pages server and binder processes

Syntax

/usr/etc/ypserv [−l]
/etc/ypbind [−S]domainname, servername,...

Description

The yellow pages (YP) service provides a simple network lookup service consisting of databases and processes. The databases are dbm() files in a directory tree rooted at /etc/yp. These files are described in ypfiles(.). The processes are /usr/etc/ypserv, the YP database lookup server, and /etc/ypbind, the YP binder. The programmatic interface to YP is described in ypclnt(.). Administrative tools are described in yppush(,), ypxfr(,), yppoll(,), and ypwhich(.). Tools you can use to view the contents of YP maps are described in ypcat(,), and ypmatch(.). Database generation and maintenance tools are described in ypinit(,), ypmake(,), and makedbm(.).

Both ypserv and ypbind are daemon processes typically activated at system startup time from /etc/rc.local. The ypserv command runs only on a YP server machine with a complete YP database. The ypbind command runs on all machines using YP services; that is, YP servers and clients.

The ypserv daemon’s primary function is to look up information in its local database of YP maps. The ypserv operations are defined for the programmer in the header file <rpcsvc/yp_prot.h>.

Communication with ypserv is by means of RPC calls. Lookup functions are described in ypclnt(,), and are supplied as C-callable functions in /lib/libc.

There are four lookup functions, which are performed on a specified map within some YP domain: Match, Get_first, Get_next, and Get_all. The Match operation takes a key and returns the associated value. The Get_first operation returns the first key-value pair from the map, and the Get_next operation returns the remaining key-value pairs. The Get_all operation ships the entire map to the requester.

The Get_order_number and Get_master_name functions supply information about the map, rather than the map entries. Both the order number and the master name exist in the map as key-value pairs, but the server does not return either through the normal lookup functions. (If the map is examined with makedbm(,), however, they are visible.)

Other functions are used within the YP subsystem itself, and are not of general interest to YP clients. They include: the Do_you_serve_this_domain?, the Transfer_map, and the Reinitialize_internal_state functions.

The purpose of the ypbind daemon is to store information that lets client processes on a single node communicate with a ypserv process. The ypbind function must run on every machine that has YP client service requirements. The ypbind function must be started through an entry in the /etc/rc.local file.

The -l option toggles log messages. When toggled on, the portmap messages are logged to the /var/adm/portmap.log file. Related ypserv messages are logged to the /var/yp/ypserv.log file. Any fatal errors, such as not being able to open the /etc/securenets file, or access denials, are logged to stdout.

The −S option allows the system administrator to lock ypbind to a particular domain and set of servers. Up to four servers can be specified. The ypserv function may or may not be running on the same node, but must be running somewhere on the network. The servers with the −S option must have entries in the local /etc/hosts file.

The information ypbind stores is called a binding, which is the association of a domain name with the internet address of the YP server and the port on that host at which the ypserv process is listening for service requests. The process of binding is driven by client requests. As a request for an unbound domain comes in, the ypbind process broadcasts on the net trying to find a ypserv process that serves maps within that domain. Because the binding is established by broadcasting, there must be at least one ypserv process on every net. Once a domain is bound by a particular ypbind, that same binding is given to every client process on the node. The ypbind process on the local node or a remote node may be queried for the binding of a particular domain by using the ypwhich(1yp) command.

Bindings are verified before they are given out to a client process. If ypbind is unable to communicate with the ypserv process to which it is bound, it marks the domain as unbound, tells the client process that the domain is unbound, and tries to bind the domain once again. Requests received for an unbound domain fail immediately. In general, a bound domain is marked as unbound when the node running ypserv crashes or gets overloaded. When the node gets overloaded, ypbind tries to bind any YP server (typically one that is less-heavily loaded) available on the net.

The ypbind process also accepts requests to set its binding for a particular domain. The request is usually generated by the YP subsystem itself.

Notes

If the file /etc/yp/ypserv.log exists when ypserv starts up, log information is written to ypserv.log when error conditions occur.

Files

/etc/securenets
Specifies which YP clients are permitted to request maps