ypserv(NADM) 19 June 1992 ypserv(NADM) Name ypserv - network information service (NIS) server and binder processes Syntax /etc/ypserv [ -d ] [ -localonly ] /etc/ypbind [ -s ] [ -ypset ] [ -ypsetme ] ypxfrd [ -x ] Description The network information service (NIS) provides a simple network lookup service consisting of databases and processes. The databases are dbm(NS) files in a directory tree rooted at /etc/yp. These files are described in ypfiles(NF). The processes are /etc/ypserv, the NIS database lookup server, and /etc/ypbind, the NIS binder. The programmer interface to NIS is described in ypclnt(NS). The administrative tools are described in yppush(NADM), ypxfr(NADM), yppoll(NADM), ypwhich(NADM), and ypset(NADM). The tools to see the contents of NIS maps are described in ypcat(NC) and ypmatch(NC). The database generation and maintenance tools are described in ypinit(NADM), ypmake(NADM), and makedbm(NADM). Both ypserv and ypbind are daemon processes typically activated at system startup time from /etc/nfs. ypserv runs only on NIS server machines with a complete NIS database. Typically, this covers most machines in the UNIX System V environment. The optional argument, -localonly, is used to indicate that ypserv should not respond to outside requests. ypbind runs on all machines using NIS services, both NIS servers and clients. ypxfrd transfers the entire NIS maps in an efficient manner. For systems that use this daemon, map transfers will be 10 to 1,000 times faster, depending on the map. To use this daemon, ypxfrd should be run on an NIS server. ypxfr will attempt to use ypxfrd first. If that fails, it will print a warning message and then use 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 NIS 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(NS) and are supplied as C-callable functions in /usr/lib/libyp.a. There are four lookup functions, all of which are performed on a speci- fied map within some NIS domain: Match, Getfirst, Getnext, and Getall. The Match operation accepts a key and returns the associated value. The Getfirst operation returns the first key-value pair from the map and the Getnext operation can be used to enumerate the remainder. Getall ships the entire map to the requester as the response to a single RPC request. Two other functions supply information about the map, rather than map entries: Getordernumber and Getmastername. In fact, both order num- ber and master name exist in the map as key-value pairs, but the server will not return either through the normal lookup functions. (However, if you examine the map with makedbm, they will be visible.) Other functions are used within the NIS subsystem itself but are not of general interest to NIS clients. They include Doyouservethisdomain?, Transfermap, and Reinitializeinternalstate. The function of ypbind is to remember information that lets client pro- cesses 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. Typically, most UNIX System V machines will be running ypserv and ypbind. 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. This information is cached in the directory /etc/yp/binding using a filename of domainname.version. The process of binding is driven by client requests. When a request for an unbound domain comes in, the ypbind process broadcasts on the net in order to find a ypserv process that serves NIS maps within that domain. Since the binding is established by broadcasting, there must be at least one ypserv process on every net. If the client is running in C2 secure mode, then ypbind will only accept bindings to servers where the ypserv process is running as root and is using a reserved port. Once a domain is bound by a particular ypbind, that same binding is given to every client process on this 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 command. Bindings are verified before they are given out to a client process. 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 will fail immediately. In general, a bound domain is marked as unbound when the node running ypserv crashes or gets over- loaded. In such a case, ypbind will bind to any NIS server which serves maps in that domain (typically one that is less heavily loaded) available on the net. ypbind also accepts requests to set its binding for a particular domain. The request is usually generated by the NIS subsystem itself. ypset(NADM) is a command to access the Setdomain facility. It is used for unsnarling messes, not for casual use. _________________________________________________________________________ NOTE The Setdomain procedure only accepts request from processes running as root and using a reserved port. _________________________________________________________________________ Options -d The NIS service should go to the DNS (Domain Name Service) for more host information. -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 com- puters operated by untrusted individuals. It offers no real increase in security. -v Do not fork when ypxfrd is called multiple times. -ypset ypset(NADM) may be used to change the binding. This option poses serious security risks and should only be used for debug- ging the network from a remote machine. -ypsetme ypset(NADM) may be used to change the binding only if it is issued from the local machine. ypbind determines that the local machine issued the command by checking the local IP address. However, the -ypsetme option can be defeated on some networks where untrusted individuals can inject packets with illegitimate IP addresses. Files If the file /etc/yp/ypserv.log exists when ypserv starts up, log informa- tion will be written to this file when error conditions arise. /etc/yp/binding/domainname.version will be created to speed up the bind- ing process. These files cache the last successful binding created for the given domain. When a binding is requested, these files are checked for validity and then used. See also ypclnt(NS), ypfiles(NF), ypcat(NC), ypmatch(NC), yppush(NADM), ypwhich(NADM), ypxfr(NADM), ypset(NADM) Notes Both ypbind and ypserv support multiple domains. The ypserv process determines the domains it serves by looking for directories of the same name in the directory /etc/yp. It will reply to all broadcasts request- ing NIS service for that domain. Additionally, the ypbind process can maintain bindings to several domains and their servers. The default domain is, however, the one specified by the domainname(NC) command at startup time.