Managing NFS and NIS, 2nd Edition - Mike Eisler [44]
# vi /etc/hosts
# cd /var/yp
# make
...New hosts map is built and distributed...
Without any arguments, make builds all maps that are out-of-date with respect to their ASCII source files. When more than one map is built from the same ASCII file, for example the passwd.byname and passwd.byuid maps built from /etc/passwd, they are all built when make is invoked.
When a map is rebuilt, the yppush utility is used to check the order number of the same map on each NIS server. If the maps are out-of-date, yppush transfers the map to the slave servers, using the server names in the ypservers map. Scripts to rebuild maps and push them to slave servers are part of the NIS Makefile, which is covered in Section 4.2.3.
Map transfers done on demand after source file modifications may not always complete successfully. The NIS slave server may be down, or the transfer may timeout due to severe congestion or server host loading. To ensure that maps do not remain out-of-date for a long time (until the next NIS map update), NIS uses the ypxfr utility to transfer a map to a slave server. The slave transfers the map after checking the timestamp on its copy; if the master's copy has been modified more recently, the slave server will replace its copy of the map with the one it transfers from the server. It is possible to force a map transfer to a slave server, ignoring the slave's timestamp, which is useful if a map gets corrupted and must be replaced. Under Solaris, an additional master server daemon called ypxfrd is used to speed up map transfer operations, but the map distribution utilities resort to the old method if they cannot reach ypxfrd on the master server.
The map transfer — both in yppush and in ypxfr — is performed by requesting that the slave server walk through all keys in the modified map and build a map containing these keys. This seems quite counterintuitive, since you would hope that a map transfer amounts to nothing more than the master server sending the map to the slave server. However, NIS was designed to be used in a heterogeneous environment, so the master server's DBM file format may not correspond to that used by the slave server. DBM files are tightly tied to the byte ordering and file block allocation rules of the server system, and a DBM file must be created on the system that indexes it. Slave servers, therefore, have to enumerate the entries in an NIS map and rebuild the map from them, using their own local conventions for DBM file construction. Indeed, it is theoretically possible to have NIS server implementation that does not use DBM. When the slave server has rebuilt the map, it replaces its existing copy of the map with the new one. Schedules for transferring maps to slave servers and scripts to be run out of cron are provided in the next section.
Regular map transfers
Relying on demand-driven updates is overly optimistic, since a server may be down when the master is updated. NIS includes the ypxfr tool to perform periodic transfers of maps to slave servers, keeping them synchronized with the master server even if they miss an occasional yppush. The ypxfr utility will transfer a map only if the slave's copy is out-of-date with respect to the master's map.
Unlike yppush, ypxfr runs on the slave. ypxfr contacts the master server for a map, enumerates the entries in the map, and rebuilds a private copy of the map. If the map is built successfully, ypxfr replaces the slave server's copy of the map with the newly created one. Note that doing a yppush from the NIS master essentially involves asking each slave server to perform a ypxfr operation