DESCRIPTION
The ypxfr utility copies an NIS database (or map) from one NIS server to another using NIS services. In
.Fx , ypxfr is generally invoked by ypserv(8) when it receives a map transfer request from yppush(8). The ypxfr utility is used primarily in environments where several NIS servers are in use in a single domain. One server, the NIS master, maintains the canonical copies of all NIS maps, and all the other servers, the NIS slaves, copy new versions of the maps from the master whenever any updates are made (i.e., when a user updates their password via yppasswd(1)). When run, ypxfr creates a temporary database file in /var/yp/[domainmame], and fills it with the contents of mapname as supplied by the specified source host. When the entire map has been transfered, ypxfr deletes the original copy of mapname and moves the temporary copy into its place. When the transfer is complete, ypxfr will attempt to send a ’clear current map’ request to the local ypserv(8) process to clear any possible references it may still have to the stale map.
Note that all files created by ypxfr are owner readable and writable only for security reasons. Since the NIS maps and the directory in which they reside are normally owned by root, this prevents non-privileged users from making unauthorized modifications.
In order to maintain consistency across all NIS servers, ypxfr can be run periodically in a cron(8) job. Maps which change infrequently need only be updated once a day (preferably late at night when system usage is lowest), whereas those that are subject to frequent changes (such a passwd.byname and passwd.byuid) should be updated perhaps once every hour. Using cron(8) to automatically update the NIS maps is not strictly mandatory since all updates should be propagated by yppush(8) when /var/yp/Makefile is run on the NIS master server, however it is good practice on large networks where possible outages could cause NIS servers to fall out of sync with each other.
When ypxfr is invoked without a controlling terminal, e.g. from inside ypserv(8), it logs all its output using the syslog(3) facility.
NOTES
The
.Fx version of ypxfr has support for a special map transfer protocol which works in conjunction with the
.Fx rpc.ypxfrd(8) server. This protocol allows it to transfer raw map database files from the NIS master server and can be many times faster than the standard transfer method, particularly for very large NIS maps. The ypxfr utility will check to see if the rpc.ypxfrd(8) server is registered on the NIS master server and attempt to use it if it is present. If it is not it will fall back to the standard transfer method, copying the map contents from ypserv(8) and creating new maps instead. Note that while the
.Fx ypxfrd protocol is conceptually similar to the SunOS ypxfrd protocol, the
.Fx protocol is not compatible with Sun’s, therefore it will not work with Sun’s ypxfrd server.
.Fx slave systems can still transfer maps from any non- Fx NIS server, however they will only be able to take advantage of the faster protocol if the master server is also running
.Fx .
OPTIONS
The following options and flags are supported by ypxfr:
