![[Go to CFHT Home Page]](/images/cfht-icon.gif){kind=icon}
Man Pages 
Back to Software Index 
Manpage Top Level
/usr/lib/netsvc/yp/ypbind [-broadcast] [-ypset|-ypsetme]
/usr/lib/netsvc/yp/ypxfrd
ypbind is installed with the SUNW nisu package bundled with Solaris 2.x
ypserv and ypxfrd come with the unbundled SUNW nsktu Naming Services Transition Kit.
The Network Information Service (NIS ) provides a simple network lookup service consisting of databases and processes. The databases are ndbm(3) files in a directory tree rooted at /var/yp. These files are described in ypfiles(4) . The processes are /usr/lib/netsvc/yp/ypserv, the NIS database lookup server, and /usr/lib/netsvc/yp/ypbind, the NIS binder. The programmatic interface to the NIS service is described in ypclnt(3N) . Administrative tools are described in yppush(1M) , ypxfr(1M) , yppoll(1M) , ypwhich(1M) , and ypset(1M) . Tools to see the contents of NIS maps are described in ypcat(1) , and ypmatch(1) . Database generation and maintenance tools are described in ypinit(1M) , ypmake(1M) , and makedbm(1M) .
Both ypserv and ypbind are daemon processes typically activated at system startup time from /etc/init.d/rpc or /etc/init.d/yp. ypserv runs only on NIS server machines with a complete NIS database. ypbind runs on all machines using the NIS services, both NIS servers and clients.
ypxfrd transfers entire NIS maps in an efficient manner. For systems that use this daemon, map transfers are 10 to 100 times faster, depending on the map. To use this daemon, ypxfrd should be run on the master server. See the /etc/init.d/yp file. ypxfr attempts to use ypxfrd first, if that fails, it prints a warning and then uses the older transfer method.
The ypserv daemon’s primary function is to look up information in its local database of NIS maps. The operations performed by ypserv are defined for the implementor by the YP Protocol Specification, and for the programmer by the header file rpcsvc/yp_prot.h. Communication to and from ypserv is by means of RPC calls. Lookup functions are described in ypclnt(3N) , and are supplied as C-callable functions in the C library. There are four lookup functions, all of which are performed on a specified map within some NIS 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 get_next can be used to enumerate the remainder. get_all ships the entire map to the requester as the response to a single RPC request.
There are a number of special keys in the DBM files that can alter the way in which ypserv operates. The keys of interest are:
Two other functions supply information about the map, rather than map entries: get_order_number, and get_master_name. In fact, both order number and master name exist in the map as key-value pairs, but the server will not return either through the normal lookup functions. If you examine the map with makedbm(1M) , however, they are visible. Other functions are used within the NIS service subsystem itself, and are not of general interest to NIS clients. They include do_you_serve_this_domain?, transfer_map, and reinitialize_internal_state.
The function of ypbind is to remember information that lets client processes on a single node communicate with some ypserv process. ypbind must run on every machine which has NIS client processes; ypserv may or may not be running on the same node, but must be running somewhere on the network.
The information ypbind remembers is called a binding -- the association of a domain name with the internet address of the NIS server, and the port on that host at which the ypserv process is listening for service requests. ypbind only binds to servers running on hosts listed in /var/yp/binding/domainname/ypservers. This file is created during the ypinit -c (1M) process.
The process of binding is driven by client requests. As a request for an unbound domain comes in, the ypbind process attempts to connect to the next server in the list trying to find a ypserv process that serves maps within that domain.
If the -broadcast option is used, then the server list is ignored and ypbind broadcasts for servers. In this case, there must be at least one ypserv process on the local subnet. Once a domain is bound by a particular ypbind, the 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 using the ypwhich(1) command.
Bindings and rebindings are handled transparently by the C library routines. If ypbind is unable to speak to 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 wait until the domain requested is bound. In general, a bound domain is marked as unbound when the node running ypserv crashes or gets overloaded. In such a case, ypbind binds another NIS server (typically one that is less-heavily loaded) according to the binding rules above.
ypbind also accepts requests to set its binding for a particular domain. The request is usually generated by the NIS subsystem itself. ypset(1M) is a command used to access the set_domain facility. It can be used for unsnarling messes. Note: the set_domain procedure only accepts requests from processes running as root.
If the file /var/yp/ypserv.log exists when ypserv starts up, log information will be written to this file when error conditions arise.
The file /var/yp/binding/domainname/ypservers is
used to list the NIS
server hosts that ypbind is willing to bind to.
The Network Information Service (NIS ) was formerly known as Sun Yellow Pages (YP ). The functionality of the two remains the same; only the name has changed. The name Yellow Pages is a registered trademark in the United Kingdom of British Telecommunications plc, and may not be used without permission.