ypserv, ypbind, ypxfrd - Network Information Service (NIS) server,
binder, and transfer processes
/usr/lib/netsvc/yp/ypserv [-l log_file]
/usr/lib/netsvc/yp/ypbind [-l log_file] [-s] [-ypset|-ypsetme]
The Network Information Service (NIS) was formerly known as Yellow
Pages (YP). The functionality remains the same; only the name has
The Network Information Service (NIS) provides a simple network lookup
service consisting of databases and processes. The databases are
files in a directory tree rooted at /var/yp (see ypfiles(4)). The
processes are /usr/lib/netsvc/yp/ypserv, the NIS database lookup
server, and /usr/lib/netsvc/yp/ypbind, the NIS binder. Both ypserv
and ypbind are daemon processes activated at system startup time when
the NIS_MASTER_SERVER or NIS_SLAVE_SERVER variable is set to 1, for
ypserv, and the NIS_CLIENT variable is set to 1, for ypbind, in the
The NIS programmatic interface is described in ypclnt(3C).
Administrative tools are described in ypwhich(1), yppoll(1M),
yppush(1M), ypset(1M) and ypxfr(1M). Tools to see the contents of NIS
maps (databases) are described in ypcat(1) and ypmatch(1). Database
generation and maintenance tools are described in makedbm(1M),
ypinit(1M), and ypmake(1M). The command to set or show the default
NIS domain is domainname(1).
ypxfrd transfers entire NIS maps in an efficient manner. For systems
that use this daemon, map transfers will be faster, depending on the
map. ypxfrd should be run on a server running HP-UX release 10.0.
ypxfr (see ypxfr(1M)) will attempt to use ypxfrd first. If that
fails, it will use the older transfer method. The ypxfrd daemon is
activated at system startup time when the NIS_MASTER_SERVER or
NIS_SLAVE_SERVER variable is set to 1 in the /etc/rc.config.d/namesvrs
The ypserv daemon's primary function is to look up information in its
local collection of NIS maps. It runs only on NIS server machines
providing data from NIS databases. Communication to and from ypserv
is by means of RPC. Lookup functions are described in ypclnt(3C).
Four lookup functions perform on a specific map within a NIS domain:
Match, Get_first, Get_next, and Get_all. The Match operation matches
Hewlett-Packard Company - 1 - HP-UX Release 11i: November 2000
a key to a record in the database and returns its associated value.
The Get_first operation returns the first key-value pair (record) from
the map, and Get_next enumerates (sequentially retrieves) the
remainder of the records. Get_all returns all records in the map to
the requester as the response to a single RPC request.
Two other functions supply information about the map other than normal
map entries: Get_order_number and Get_master_name. The order number
is the time of last modification of a map. The master name is the
host name of the machine on which the master map is stored. Both
order number and master name exist in the map as special key-value
pairs, but the server does not return these through the normal lookup
functions. (If you examine the map with makedbm or yppoll (see
makedbm(1M) or yppoll(1M)), they will be visible.) Other functions are
used within the NIS system and are not of general interest to NIS
clients. They include:
The ypbind daemon remembers information that lets client processes on
its machine communicate with a ypserv process. The ypbind daemon must
run on every machine using NIS services, both NIS servers and clients.
The ypserv daemon may or may not be running on a NIS client machine,
but it must be running somewhere on the network or be available
through a gateway.
The information that ypbind remembers is called a binding: the
association of a NIS 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. This information is cached in the
directory /var/yp/binding using a filename in the form
Client requests drive the binding process. As a request for an
unbound domain comes in, the ypbind process broadcasts on the network
trying to find a ypserv process serving maps within that NIS domain.
Since the binding is established by broadcasting, at least one ypserv
process must exist on every network. Once a binding is established
for a client, it is given to subsequent client requests. Execute
ypwhich to query the ypbind process (local and remote) for its current
binding (see ypwhich(1)).
Bindings are verified before they are given to a client process. If
ypbind is unable to transact with the ypserv process it is bound to,
it marks the domain as unbound, tells the client process that the
domain is unbound, and tries to bind again. Requests received for an
unbound domain fail immediately. Generally, a bound domain is marked
as unbound when the node running ypserv crashes or is overloaded. In
such a case, ypbind binds to any NIS server (typically one that is
Hewlett-Packard Company - 2 - HP-UX Release 11i: November 2000
less heavily loaded) that is available on the network.
The ypbind daemon also accepts requests to set its binding for a
particular domain. ypset accesses the Set_domain facility; it is for
unsnarling messes and is not for casual use.
ypserv recognizes the following options:
-l log_file Log diagnostic and error messages to the file,
If ypserv is started without the -l option, ypserv
writes its messages to /var/yp/ypserv.log if that
If ypbind is started without the -l option, ypbind
writes its messages directly to the system
Information logged to the file includes the date
and time of the message, the host name, the
process id and name of the function generating the
message, and the message itself. Note that
different services can share a single log file
since enough information is included to uniquely
identify each message.
ypbind recognizes the following options:
-l log_file Log diagnostic and error messages to the file,
log_file. See the description above.
-s Secure. When specified, only NIS servers bound to
a reserved port are used. This allows for a
slight increase in security in completely
controlled environments, where there are no
computers operated by untrusted individuals. It
offers no real increase in security.
-ypset Allow ypset to be used to change the binding (see
ypset(1M)). For maximum security, this option
should be used only when debugging the network
from a remote machine.
-ypsetme Allow ypset to be issued from this machine (see
ypset(1M)). Security is based on IP address
checking, which can be defeated on networks where
untrusted individuals may inject packets. This
option is not recommended.
Hewlett-Packard Company - 3 - HP-UX Release 11i: November 2000
ypserv, ypbind, and ypxfrd were developed by Sun Microsystems, Inc.
/var/yp/binding/domainname.version These files cache the last
successful binding created for the
given domain, in order to to speed
up the binding process. When a
binding is requested, these files
are checked for validity and then
/var/yp/securenets This file is read by ypxfrd and
ypserv. It contains a list of IP
addresses that these servers will
allow a binding to.
/var/yp/secureservers This file is read by ypbind. It
contains a list of IP addresses
that ypbind will receive a binding
domainname(1), ypcat(1), ypmatch(1), yppasswd(1), ypwhich(1),
makedbm(1M), rpcinfo(1M), ypinit(1M), ypmake(1M), yppasswdd(1M),
yppoll(1M), yppush(1M), ypset(1M), ypxfr(1M), ypclnt(3C),
Hewlett-Packard Company - 4 - HP-UX Release 11i: November 2000