Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!cmcl2!husc6!rice!sun-spots-request
From: stevo@elroy.jpl.nasa.gov (Steve Groom)
Newsgroups: comp.sys.sun
Subject: Re: Problem with interfacing YP and BIND
Message-ID: <13037@elroy.Jpl.Nasa.Gov>
Date: 2 Feb 89 07:17:39 GMT
References: <8901190331.AA26877@csd360b.erim.org>
Sender: usenet@rice.edu
Organization: Image Analysis Systems Grp, JPL
Lines: 33
Approved: Sun-Spots@rice.edu
Original-Date: 25 Jan 89 17:10:43 GMT
X-Sun-Spots-Digest: Volume 7, Issue 133, message 7 of 13

jgarb@erim.org (Joe Garbarino) writes:
>Under SunOS V3.5, interacting with the named required staring up the yp
>server with ypserv -i.  Under SunOS V4.0, this was changed.  Now you must
>modify the yp makefile (/var/yp/Makefile) to do a makedbm -b when the
>hosts database is made.  However, due to the ypserv bug, the server still
>does not contact the named.  When I was running V4.0 I received a fixed
>ypserv from Sun Tech Support; I believe the problem is fixed in SunOS
>V4.0.1.

Be careful with the ypserv from SunOS 4.0.1.  If ypserv loses contact with
the nameserver (because named or the machine it's running on crashes),
then YP goes to lunch and never comes back.  Evidently ypserv caches the
port number that named is listening on, and doesn't forget about it if
contact is lost.  Thus killing and restarting named (or rebooting the
machine it's running on) will cause ypserv to lose contact with the
nameserver until ypserv is restarted.  The solution is to kill and restart
ypserv after named is running again, but this can be difficult if YP is
dead and you can't log in :-).  The fix for us was to go back to the 4.0
version of ypserv.  The problem has been reported to Sun, and the cause
and fix were suggested by them.

This bug bit us at a bad time.  Both I and my co-SA were in Miami at the
SUG conference (my boss says "never again!"), and the folks back home were
dead in the water.  We have had problems with named dying from time to
time, and when it went, so did YP.  We spent several hours on the phone
talking them through backing out of YP completely.  Only after we returned
did we figure out exactly what went wrong.  (No, don't suggest fixing
named, we've been puzzled by that one for a long time.  It sometimes tries
to dereference a date value and ...)

Steve Groom, Jet Propulsion Laboratory, Pasadena, CA 91109
Internet: stevo@elroy.jpl.nasa.gov   UUCP: {ames,cit-vax}!elroy!stevo
Disclaimer: (thick German accent) "I know noothingg! Noothingg!"