/var/yp/ypxfr [-a method] -f [-h host] -d [domain] [-c] [-C tid prog ipadd port] mapname
Specifies that NIS maps are to be stored in one of the following formats: btree - Recommended when creating and maintaining very large maps. dbm/ndbm - For backward compatibility. This is the default. hash - A potentially quicker method for managing small maps. Force the transfer to occur even if the version at the MASTER is not more recent than the local version. Do not send a "Clear current map" request to the local ypserv process. This flag should be used if ypserv is not running locally at the time when ypxfr is running. Otherwise, ypxfr will report that it can not talk to the local ypserv, and the transfer will fail. Get the map from host, regardless of which map is the master. If host is not specified, ypxfr will ask the NIS service for the name of the master, and try to get the map from there. The host option can be a name or an IP address in dotted numeric notation. Specify a domain other than the default domain. This option is only for use by ypserv. When ypserv invokes ypxfr, it specifies that ypxfr should call back a yppush process at the host with IP address ipaddr, registered as program number prog, listening on port port, and waiting for a response to transaction tid.
The ypxfr command moves a NIS map, specified by the mapname argument, to the local host by making use of normal NIS services. It creates a temporary map in the directory /var/yp/domain (which must already exist), fills it by enumerating the map's entries, obtains the map parameters (master and order number) and loads them into the map. Once ypxfr has accomplished these tasks, it deletes any old versions of the map and moves the temporary map to the real mapname.
If ypxfr is run interactively, it writes its output to the terminal. However, if it is invoked without a controlling terminal, and if the log file /var/yp/ypxfr.log exists, it will append all its output to that file. Since ypxfr is most often run from /var/spool/cron/crontab/root, or by ypserv, the log file can be used to retain a record of what was attempted, and the results.
For consistency between servers, ypxfr should be run periodically for every map in the NIS database. Different maps change at different rates: the services.byname map may not change for months at a time, for instance, and may therefore be checked only once a day. It is possible that mail.aliases or hosts.byname changes several times per day. In such a case, it is appropriate to check hourly for updates. A cron(8) entry should be used to perform periodic updates automatically on NIS server machines only. Rather than having a separate cron entry for each map, commands can be grouped to update several maps in a shell script. Examples (mnemonically named) are in /var/yp: ypxfr_1perday, ypxfr_2perday, and ypxfr_1perhour. They can serve as models for you to use.
See ypfiles(4) and ypserv(8) for an overview of NIS.
You must use the same database format for each map in a domain. In addition, a server serving multiple NIS domains must use the same database format for all domains.
Although a Digital UNIX NIS server that takes advantage of btree files will be able to store very large maps, NIS slave servers that lack this feature might have a much smaller limit on the number of map entries they can handle. It may not be possible to distribute very large maps from a Digital UNIX NIS master server to a slave server that lacks support for very large maps. NIS clients are not affected by these enhancements.
The following is an example of the ypxfr command used with the btree database routine to store NIS maps. ypxfr -a b group.byname
Commands: cron(8), yppush(8), ypserv(8), ypsetup(8)
Functions: btree(3), dbm(3), dbopen(3), hash(3), ndbm(3) delim off