Servers have different versions of an NIS map

Because NIS propagates maps among servers, occasionally you find different versions of the same map at NIS servers on the network. This version discrepancy is normal if transient, but abnormal otherwise.

Most commonly, normal map propagation is prevented when an NIS server or router between NIS servers is down. When all NIS servers and the routers between them are running, ypxfr(1Mnis) should succeed.

If a particular slave server has problems updating maps, log in to that server and run ypxfr interactively. If ypxfr fails, it will tell you why it failed, and you can fix the problem. If ypxfr succeeds, but you suspect it has occasionally failed, create a log file to enable logging of messages. As NIS administrator on the slave server, enter:

cd /var/yp
touch ypxfr.log

This saves all output from ypxfr. The output resembles the output ypxfr displays when run interactively, but each line in the log file is timestamped. (You may see unusual orderings in the timestamps. This is normal--the timestamp tells you when ypxfr started to run. If copies of ypxfr ran simultaneously but their work took different amounts of time, they may actually write their summary status line to the log files in an order different from that in which they were invoked.) Any pattern of intermittent failure shows up in the log. When you have fixed the problem, turn off logging by removing the log file. If you forget to remove it, it will grow without limit.

While still logged in to the problem NIS slave server, inspect root's crontab file and the ypxfr shell scripts it invokes. Typographical errors in these files cause propagation problems, as do failures to refer to a shell script within /var/spool/cron/crontabs/root or failures to refer to a map within any shell script.

Also, make sure that the NIS slave server is in the map ypservers within the domain. If it is not, it still operates perfectly as a server, but yppush will not tell it when a new copy of a map exists.

If the NIS slave server's problem is not obvious, you can work around it while you debug it using rcp(1tcp) or tftp(1tcp) to copy a recent version of the inconsistent map from any healthy NIS server. You must not do this remote copy as root, but you can probably do it while logged in as daemon. For instance, here is how you might transfer the map busted on the slave server:

chmod go+w /var/yp/mydomain
su daemon
rcp ypmaster:/var/yp/mydomain/busted.\ /var/yp/mydomain
exit
chown root /var/yp/mydomain/busted.
chmod go-w /var/yp/mydomain

Here the ``'' character has been escaped in the command line so that it will be expanded on ypmaster, instead of locally on ypslave. The map files should be owned by root, so you must change their ownership after the transfer.