Museum

Home

Lab Overview

Retrotechnology Articles

Online Manuals

⇒ ypserv(1M) — A/UX 3.0.1

Media Vault

Software Library

Restoration Projects

Artifacts Sought

Related Articles

yppush(1M)

ypset(1M)

ypxfr(1M)

ypcat(1)

ypmatch(1)

ypwhich(1)

ypclnt(3N)

ypfiles(4)




ypserv(1M) ypserv(1M)
NAME ypserv, ypbind - provide Network Information Service (NIS) service SYNOPSIS ypserv ypbind [-s] [-secure] [-v] [-ypset] [-ypsetme] ARGUMENTS -s Specifies that the server to which ypbind binds must be using a reserved port. -secure Same as the -s option. -v Specifies verbose mode, in which ypbind writes status information on the terminal. -ypset Specifies that ypbind can allow its binding to be changed by both remote and local processes. See ypset(1M) for details about changing a binding. -ypsetme Specifies that ypbind can allow its binding to be changed by a local process only. See ypset(1M) for details about changing a binding. DESCRIPTION ypserv and ypbind are daemons that provide, in conjunction with the NIS maps and other NIS processes, a simple network look-up service. The maps are in dbm(3X) format and are stored in the /etc/yp hierarchy. The maps are described in ypfiles(4). The processes are /etc/ypserv, the NIS map look-up server, and /etc/ypbind, the NIS binder. The programming interface to NIS is described in ypclnt(3N). Administrative commands are described in yppush(1M), ypxfr(1M), yppoll(1M), ypwhich(1M), and ypset(1M). Commands that display 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). The ypserv Daemon The ypserv daemon is typically activated at system startup from /etc/inittab on systems that have a complete set of NIS maps. That is, ypserv runs on the NIS master and slave server systems. The purpose of ypserv is to look up information in its local database of NIS maps. The operations performed by ypserv January 1992 1



ypserv(1M) ypserv(1M)
are defined for the implementor in Appendix D, ``NIS Protocol Specification,'' in A/UX Network Applications Programming, and for the programmer by the header file <rpcsvc/yp_prot.h>. Communications to and from ypserv are by remote procedure call (RPC). Look-up functions are described in ypclnt(3N) and are supplied as C-callable functions in /lib/libc.a. There are four look-up functions, all of which are performed on a specified map within some NIS domain: Match Returns the associated value for a specified key. Get_first Returns the first key-value pair from the map. Get_next Returns the next key-value pair from the map. Get_all Returns the entire map to the requester. Both the order number and the host name of the master server are stored in the map as key-value pairs, but they are not returned by the four look-up functions. Two other functions return the order number and name of the master server: Get_order_number Returns the order number as stored in the map. Get_master_name. Returns the host name of the master server as stored in the map. Other functions are used within the NIS 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 ypbind Daemon The ypbind daemon is typically activated at system startup from /etc/inittab and runs on all systems that use NIS services; that is, on the NIS master server, slave servers, and client systems. The purpose of ypbind is to maintain information that allows client processes on the local system to communicate with a local or remote ypserv process. This information is called a binding, which is the association of a domain name with the Internet address of the NIS server and the port on that server at which the ypserv process listens for service requests. The process of binding is driven by client 2 January 1992



ypserv(1M) ypserv(1M)
requests. When a request for an unbound domain is received, ypbind broadcasts on the network, trying to find a ypserv process that serves maps within that domain. Because the binding is established by broadcasting, there must be at least one ypserv process on every network. Once a domain is bound by a particular ypbind, that same binding is given to every client process on the system. You can query the ypbind process on the local system or on a remote system for the binding of a particular domain by using the ypwhich(1) command. Bindings are verified before they are given out to a client process. If ypbind is unable to contact the ypserv process to which it's bound, ypbind 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 fail immediately. In general, a bound domain is marked as unbound when the system running ypserv crashes or becomes overloaded. In such a case, ypbind binds any available NIS server (typically one that is less heavily loaded). The ypbind daemon also accepts requests to set its binding for a particular domain. The request is usually generated by the NIS subsystem itself, but in the rare event that you need to set a binding, you can run ypset, which uses the Set_domain facility. STATUS MESSAGES AND VALUES If the file /etc/yp/ypserv.log exists when ypserv starts up, log information is written to this file when error conditions arise. FILES /etc/ypbind Executable file /etc/ypserv Executable file SEE ALSO yppush(1M), ypset(1M), ypxfr(1M) ypcat(1), ypmatch(1), ypwhich(1) in A/UX Command Reference ypclnt(3N), ypfiles(4) in A/UX Programmer's Reference Chapter 4, ``Setting Up the Network Information Service,'' in A/UX Network System Administration January 1992 3

Typewritten Software • bear@typewritten.org • Edmonds, WA 98026