Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!sdd.hp.com!decwrl!sgi!arc@kaibab.wpd.sgi.com From: arc@kaibab.wpd.sgi.com (Andrew Cherenson) Newsgroups: comp.sys.sgi Subject: Re: Please help with yp binding problem Message-ID: <82644@sgi.sgi.com> Date: 25 Jan 91 23:38:41 GMT References: <12194@ccncsu.ColoState.EDU> Sender: guest@sgi.sgi.com Reply-To: arc@sgi.com (Andrew Cherenson) Distribution: usa Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 37 In article <12194@ccncsu.ColoState.EDU> jamison@yuma.acns.colostate.edu (Jamie Gulden) writes: > > I am having a problem with yp (NIS) and was hoping someone could >help out. > > PROBLEM: When a 4D/25 is bound to a yp server that goes down it won't > rebind to a different server. > > INFO: 4D/25TG w/ IRIX 3.3.1 and NSF 3.3 > 3 sun servers running SunOS 4.1.1 > > WHAT HAPPENS: The PI is running ypbind and ypwhich returns the hostname > of one of the servers. The PI will bind to any of the three servers > at boot depending on which responds first. If that server goes down > the PI will start printing the following message: > >yp server not responding for domain ".VIS.ColoState.EDU"; still trying (v2) > > Typing ypwhich returns that the domain is not bound. The only way > I have been able to get it to rebind to a different server is to > reboot the system. > > WHAT I HAVE TRIED: Looking in the IRIS NFS manual under debugging a > yp {client|server} the exact error message is given but all of the > suggestions it gives are allready being done (ypserv is running on > all machines and none of the machines or the network are overworked, > the domain name is correct on all machines, other machines are > getting services off of the other two servers just fine). Our suns > work fine and will rebind when needed to a different server. Also > ypset won't let me set the server. > > Any help would be greatly appreciated, thanks apriori, Jamie. > Jamie determined that the PI was using the Internet standard "1-style" broadcast IP address and the Suns were using the retrograde "0-style" address. See Section 8.3.4 in the Network Communications Guide for details.