|yp_order||check the creation date of a particular map|
|obtain the name of the NIS master server for a given map/domain|
|yp_match||lookup the data corresponding to a given in key in a particular map/domain|
|yp_first||obtain the first key/data pair in a particular map/domain|
|yp_next||pass ypserv(8) a key in a particular map/domain and have it return the key/data pair immediately following it (the functions yp_first and yp_next can be used to do a sequential search of an NIS map)|
|yp_all||retrieve the entire contents of a map|
There are a few other requests which ypserv(8) is capable of handling (i.e., acknowledge whether or not you can handle a particular domain (YPPROC_DOMAIN), or acknowledge only if you can handle the domain and be silent otherwise (YPPROC_DOMAIN_NONACK)) but these requests are usually generated only by ypbind(8) and are not meant to be used by standard utilities.
On networks with a large number of hosts, it is often a good idea to use a master server and several slaves rather than just a single master server. A slave server provides the exact same information as a master server: whenever the maps on the master server are updated, the new data should be propagated to the slave systems using the yppush(8) command. The NIS Makefile (/var/yp/Makefile) will do this automatically if the administrator comments out the line which says "NOPUSH=true" ( NOPUSH is set to true by default because the default configuration is for a small network with only one NIS server). The yppush(8) command will initiate a transaction between the master and slave during which the slave will transfer the specified maps from the master server using ypxfr(8). (The slave server calls ypxfr(8) automatically from within ypserv(8); therefore it is not usually necessary for the administrator to use it directly. It can be run manually if desired, however.) Maintaining slave servers helps improve NIS performance on large networks by:
.Fx ypserv(8) is specially designed to provide enhanced security (compared to other NIS implementations) when used exclusively with
.Fx client systems. The
.Fx password database system (which is derived directly from BSD 4.4 ) includes support for shadow passwords. The standard password database does not contain users encrypted passwords: these are instead stored (along with other information) in a separate database which is accessible only by the super-user. If the encrypted password database were made available as an NIS map, this security feature would be totally disabled, since any user is allowed to retrieve NIS data.
To help prevent this,
.Fx Ns s NIS server handles the shadow password maps ( master.passwd.byname and master.passwd.byuid) in a special way: the server will only provide access to these maps in response to requests that originate on privileged ports. Since only the super-user is allowed to bind to a privileged port, the server assumes that all such requests come from privileged users. All other requests are denied: requests from non-privileged ports will receive only an error code from the server. Additionally,
.Fx Ns s ypserv(8) includes support for
.An Wietse Venema Ns s tcp wrapper package; with tcp wrapper support enabled, the administrator can configure ypserv(8) to respond only to selected client machines.
While these enhancements provide better security than stock NIS, they are by no means 100% effective. It is still possible for someone with access to your network to spoof the server into disclosing the shadow password maps.
On the client side,
.Fx Ns s getpwent(3) functions will automatically search for the master.passwd maps and use them if they exist. If they do, they will be used, and all fields in these special maps (class, password age and account expiration) will be decoded. If they are not found, the standard passwd maps will be used instead.
When using a non- Fx NIS server for passwd(5) files, it is unlikely that the default MD5-based format that
.Fx uses for passwords will be accepted by it. If this is the case, the value of the passwd_format setting in login.conf(5) should be changed to "des" for compatibility.
Some systems, such as SunOS 4.x, need NIS to be running in order for their hostname resolution functions ( gethostbyname, gethostbyaddr, etc.) to work properly. On these systems, ypserv(8) performs DNS lookups when asked to return information about a host that does not exist in its hosts.byname or hosts.byaddr maps.
.Fx Ns s resolver uses DNS by default (it can be made to use NIS, if desired), therefore its NIS server does not do DNS lookups by default. However, ypserv(8) can be made to perform DNS lookups if it is started with a special flag. It can also be made to register itself as an NIS v1 server in order to placate certain systems that insist on the presence of a v1 server ( Fx uses only NIS v2, but many other systems, including SunOS 4.x, search for both a v1 and v2 server when binding).
.Fx Ns s ypserv(8) does not actually handle NIS v1 requests, but this "kludge mode" is useful for silencing stubborn systems that search for both a v1 and v2 server.
(Please see the ypserv(8) manual page for a detailed description of these special features and flags.)
The YP subsystem was written from the ground up by
.An Theo de Raadt to be compatible to Suns implementation. Bug fixes, improvements and NIS server support were later added by
.An Bill Paul . The server-side code was originally written by
.An Peter Eriksson and
.An Tobias Reber and is subject to the GNU Public License. No Sun code was referenced.
.Fx now has both NIS client and server capabilities, it does not yet have support for ypupdated(8) or the yp_update function. Both of these require secure RPC, which
.Fx does not support yet either.
Many more manual pages should be written, especially ypclnt(3). For the time being, seek out a local Sun machine and read the manuals for there.
Neither Sun nor this author have found a clean way to handle the problems that occur when ypbind cannot find its server upon bootup.
|April 5, 1993||YP (8)|