ypserv(1M) ypserv(1M)
NAME
ypserv, ypbind, ypxfrd - Network Information Service (NIS) server, binder, and transfer processes
SYNOPSIS
log_file]
log_file]
Remarks
The Network Information Service (NIS) was formerly known as Yellow Pages (YP). The functionality remains the same; only the name has
changed.
DESCRIPTION
The Network Information Service (NIS) provides a simple network lookup service consisting of databases and processes. The databases are
ndbm files in a directory tree rooted at (see ndbm(3X)). These files are described in ypfiles(4). The processes are which is the NIS
database lookup server, and which is the NIS binder. Both and are daemon processes activated at system startup time when the or variable
is set to 1, for and the variable is set to 1, for in the file.
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 which
is described in domainname(1).
The daemon transfers entire NIS maps in an efficient manner. For systems that use this daemon, map transfers will be faster, depending on
the map. should be run on the master server. (see ypxfr(1M)) will attempt to use first. If that fails, it will use the older transfer
method. The daemon is activated at system startup time when the or variable is set to 1 in the file.
The daemon's primary function is to look up information in its local database of NIS maps. It runs only on NIS server machines providing
data from NIS databases.
The operations performed by are defined for the implementor by the YP Protocol Specification, and for the programmer by the header file
Communication to and from is by means of RPC. Lookup functions are described in ypclnt(3C) and are supplied as C-callable functions in the
TI-RPC library
These four functions: and perform a lookup on a specific map within a NIS domain. The operation matches a key to a record in the database
and returns its associated value. The operation returns the first key-value pair (record) from the map, and can be used to enumerate
(sequentially retrieve) the remainder of the records. returns all records in the map to the requester as the response to a single RPC
request.
A number of special keys in the DBM files can alter the way in which operates. The keys of interest are:
The presence of this key makes
forward host lookups that cannot be satisfied by the DBM files to a DNS server.
This key makes
answer only questions coming from clients on reserved ports.
This is a special key in the form
"YP_MULTI_hostname addr1, ..., addrN".
A client looking for hostname receives the closest address.
Two functions supply information about the map itself and not the map entries. These functions are and 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 mas-
ter 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 or they are visible (see makedbm(1M) or yppoll(1M)). Other functions are used within the NIS subsystem and are not of
general interest to NIS clients. These include:
The daemon remembers information that lets client processes on its machine communicate with a process. The daemon must run on every
machine using NIS services, both NIS servers and clients. The 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 remembers is called a binding: the association of a NIS domain name with the NIS server. This information is cached
in the directory in the file called For example, if domain_name is then the information is cached in
Client requests drive the binding process. As a request for an unbound domain comes in, the process broadcasts on the network, if the file
does not exist, trying to find a process serving maps within that NIS domain. If the binding should be established by broadcasting, at
least one process must exist on every network. If the file is present, then will try to bind to one of the NIS servers in the order of its
listing in the file. If was unable to bind to any one of the servers available in the list, it will try establishing a binding by broad-
casting. The file, containing the list of NIS servers is created by invoking with the option (see ypinit(1M)). If is invoked with a
option, will try to establish a binding by broadcast immaterial of the availability of the file that is, the option overrides the existence
of the file Once a binding is established for a client, it is given to subsequent client requests. Execute to query the process (local and
remote) for its current binding (see ypwhich(1)).
Bindings are verified before they are given to a client process. If is unable to transact with the 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 crashes or is overloaded. In such a case, binds to
any NIS server (typically one that is less heavily loaded) that is available on the network.
The daemon also accepts requests to set its binding for a particular domain. accesses the facility; it is for unsnarling messes and is not
for casual use.
Options
recognizes the following options:
Log diagnostic and error messages to the file,
log_file.
If is started without the option, writes its messages to if that file exists.
If is started without the option, writes its messages directly to the system console,
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.
The NIS service must approach the DNS for more host
information. This requires the existence of a correct file pointing at a machine running This option enables DNS
forwarding regardless of whether or not the flag is set in the hosts maps. See makedbm(1M). In the absence of an
file, complains, but ignores the option.
Operate in the verbose mode, printing diagnostic
messages to stderr.
recognizes the following options:
Log diagnostic and error messages to the file,
log_file. See the description above.
Enable secure mode in
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
significant increase in security. This option should be used in conjunction with the broadcast mode and is transport
specific.
Allow to be used to change the binding (see ypset(1M)). For maximum security, this option should be used only when debug-
ging the network from a remote machine.
Allow 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.
When is invoked with this option, will try to establish a binding by broadcast even though the file exists. That is, the
option overrides the existence of this file.
If is used in conjunction with the or option, then the binds using the method and the binding can be changed by using
the command. If is invoked with the or option, the NIS servers list in the file is used for initial binding and the
binding can be changed by using the command.
WARNINGS
NIS uses ndbm files to store maps. Therefore, it is subject to the 1024 byte limitations described in the section of the ndbm(3X) man page.
Starting with ONCplus version B.11.31.02, the NIS Version 1 protocol is no longer available.
AUTHOR
and were developed by Sun Microsystems, Inc.
FILES
This file caches the last successful binding created for the given domain, domain_name, in order to to speed up the binding process. When
a binding is requested, this file is checked for validity and then used.
This file is read by both
and at startup time. It defines the hosts and networks which are granted access to information in the served domain.
This file is read by
It contains a list of IP addresses that will receive a binding from.
This file is read by
It contains the list of NIS servers that will attempt to bind to, if is not invoked with a option.
SEE ALSO
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), yppasswd(3N), ndbm(3X), ypfiles(4).
ypserv(1M)