[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Linux-cluster] notes on clustering NIS master (ypserv)



Here are some brief notes on using RHCS to cluster an NIS (ypserv) master. 
These are intended mainly as search-engine fodder, in case anyone is looking 
for info on the same process in the future.

NIS was written long, long before HA clustering. The NIS utilities
make assumptions about hostnames that conflict badly with RHCS. In
particular, the use of a virtual IP (for example, vdirectory) to separate
the NIS server from a single physical machine breaks because the name
returned by gethostbyname (for example, "server1" or "server2") differs
from the virtual server. There's no way to instruct the NIS processes (yperv, 
yppush, etc.) to communicate over specified interfaces.

This difference between the VIP name that should be associated with the NIS
service and the name of the physical server comes up in several places:

[1] When running "ypinit -m" to initialize the NIS master,
    the hostname of the master server is queried by the yphelper
    program within /var/yp/Makefile and that value is encoded into the
    DBM map files. This means that, for example, "server1" would be encoded
    in the NIS maps. If the NIS (ypserv) process fails over to the other 
    cluster node ("server2"), then NIS clients will refuse to accept updates,
    since they appear to come from the machine "server2", even if the VIP
    for the directory service ("vdirectory") also fails over to server2.

    This can be circumvented by editing the /var/yp/Makefile to avoid using
    yphelper, but to instead specify the name of the virtual server
    ("vdirectory"), as in changing from:
    	DBLOAD = $(YPBINDIR)/makedbm -c -m `$(YPBINDIR)/yphelper --hostname`
    to:
    	DBLOAD = $(YPBINDIR)/makedbm -c -m vdirectory.fqdn
   

[2] The yppush program compares the value of gethostbyname on the server to
    the name of the master server encoded in the DBM files. Since
    they will not be equal, maps will not be pushed to clients. The
    /var/yp/Makefile can be set not to push maps to clients (which
    is actually the default), and NIS clients can poll the server to
    retrieve maps.

    In our case, I created a "ypxfr-all" script to enumerate and transfer maps
    using ypxfr, and modified /var/yp/Makefile to connect to each NIS slave
    and trigger the slave to request maps from the master.



I hope this helps someone.

Mark




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]