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

[brem belguebli]

Interesting.

But why bothering with making your ypserv clustered, as, clients, when
configured in non broadcast or ypset mode
(Unix : /var/lib/yp/binding/ypservers, Linux: /etc/yp.conf) are able to
automatically and almost instantaneously switch to a slave server.

With this kind of setup, which is the most common I have seen in a lot
of companies (managing thousands of Unix/Linux servers), the only thing
to care about is to promote a slave server by regenerating the maps by
changing the Makefile and run a single make.

    
On Thu, 2010-05-20 at 13:48 -0400, bergman at merctech.com wrote:
> 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
> 
> 
> 
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster