NIS questions - summary

From: Ju-Lien Lim (
Date: Fri Jul 25 1997 - 09:33:24 CDT

>My original questions were as follows:
>(1) If I have 3 NIS slaves that are bound to each of themselves... now if I
>were going to move my NIS master onto a different subnet, what would the
>ramifications be? Can someone suggest what I need to do to make sure that
>this transition happens smoothly. This is a temporary move (1 week) but
>unfortunately, they're doing a lot of renovations here...
>(2) I'm having some trouble setting up a NIS client for this same domain but
>the client happens to be in a different subnet... is there some kind of
>special setup I need to do for the client to bind to the domain?
>I wish to thank everyone who responded and summarize their responses:
>Gregory M Polanski (
>Thomas V. Myers (
>Glenn Satchell (
>Thierry Davin (
>Fred Vegliante (
>Matthew Sams (
>Sam Shaffer (
>You will have to bind explicitly the NIS slaves to the IP address of the nis
>master. NIS for SunOS cannot go across subnets. You will need a master or
>slave at that net. NIS for Solaris works across subnets. Create a directory
>at client's /var/yp/binding/master_server_full_name. You can have an NIS
>master on a different subnet than slave server. The NIS master needs to
>have the slave servers listed in the map pservers.
>In general, you need to have at least one NIS slave server, be it master or
>slave, on each subnet. The NIS clients broadcast a request and these
>broadcasts do not go through the routers. Alternatively, you can specify an
>explicity server for a node. Keep in mind that NIS binding won't work if
>your netmask doesn't correspond on the client and server side. There is no
>broadcast required to communicate between these systems. There would be a
>problem between a client and any master (slave or not) if they are
>broadcasting and on different subnets. Check the answerbook (Solaris) or
>answer the question after the sys-unconfig and reboot.
>As client cannot broadcast (typically) through a router, use the following:
>ypbind -ypset
>ypset -h hostname
>This will tell the client to bind to THIS particular host (hostname) and not
>attempt to broadcast. Make sure that the client knows of the masters address
>i.e. it has to be in the local /etc/hosts file and maybe the NIS hosts file
>as well.
>To safely physically move the existing master node is not a problem. If
>they're bound to themselves then all should transition smoothly. Any clients
>bound to the master will hang though. The trick will be to update the master
>with it's new IP address by editting the hosts file, pushing out the changes
>and then immediately shutting down the master, moving it to the new subnet
>and bringing it up with it's new address. To do so, change it's entry in the
>hosts map, /etc/hosts file (and DNS) to the new IP address, shut it down and
>reboot it on the new network segment. The slave servers contact the master
>by name, not IP address so they'll keep working just fine. Of course, if
>there are any machines still running on the old subnet you'll have to make
>sure there's an NIS slave there while the master server is relocated. For
>Solaris 2.x run ypinit -c and specify the name(s) of the NIS servers to bind
>to. For Solaris 1.x you need to run 'ypbind -ypsetme' and then
>'/usr/etc/yp/ypset <ip address of nis server>'. Make sure to sepcify the ip
>address, since the system won't be capable of resolving NIS requests until it
>binds. These steps force a change from the default which is to broadcast on
>the local subnet for a yp server.
>If the master goes to a different subnet, a good bet is that it's IP address
>changes. Now the clients cannot fetch new maps. Any updates are unavailable
>to those slaves and their clients. Old data is still available, though. Any
>NIS client should have one NIS master/slave on the same subnet as the client
>is. Once a client binds to a slave server, it doesn't matter where the master
>server is. Master server can be put on any subnet provided the clients can
>see at least one slave server on th same subnet.

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:59 CDT