Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

ypserv(1m) [hpux man page]

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)
Man Page