SUMMARY: NIS Problem

From: Randy Holt (randy@santa-ynez.dazixco.ingr.com)
Date: Mon Dec 09 1991 - 20:58:03 CST


First a hearty thanks to those who replied:

david@srv.PacBell.COM (David St. Pierre)
feldt@phyast.nhn.uoknor.edu (Andy Feldt)
stumpf@sun8.psychologie.uni-freiburg.de (Michael Stumpf)
zjat02@trc.amoco.com (Jon A. Tankersley)
scott@dsg.tandem.com (Scott Hazen Mueller)
mike@fionn.lbl.gov (Michael Helm)
ajs6143@eerpf001.boeing.com ( Andy J. Stefancik )

Everyone suggested pretty much the same thing, either completely remake the
NIS maps or shut down the 4.0.3 servers. The list is short so here it is:

------------------
It sounds like your yp slaves are not getting completely up-to-date
maps. Make sure the netid map is always propagated when any other map
is updated. Also, you could remove the yp databases on the slaves and
remake them from scratch to make sure they are up-to-date at least for
starting things in the right direction...

------------------
Go back and shut down all the ypservs. Do the ypinit -m, then do a bunch
of ypinit -s dazixco.
If that doesn't work, eliminate the 4.0.3 slaves.
Clean everything out in /var/yp on the slave servers and re-run ypinit -s.

------------------
I have a vague recollection of problems mixing 4.0.3 &
4.1(.x) ypservers. Too long ago for me to remember the
details. Perhaps experimenting with ypset would get you
to a more stable network (not to mention getting
everything to 4.1.1; but I suppose you must have some
reason for sticking with 4.0.3).

------------------
It sounds like your NIS maps are not getting pushed from the
master to the slaves, or your slave maps are corrupt.
Or another really remote possibility is your MASTER
NIS server is the only station with a good network connections
and path.
I would use etherfind to watch the appropriate NIS server.
I would then do a make in /var/yp, make sure the
monitored station is bound to one of the slaves. Compare the
traffic when bound to the good master, to that of the dysfunctional
slave.

------------------
I don't think that in.routd should affect your local NIS
domaine. That would only be for ftping outside your domaine.
If everything operates when bound to the master, then the
hosts file should be ok.
How do things work if your bound to ra or yoda?
If you have the book "MAnaging NIS & NFS by Hal Sterne"
check the section on renegade slave servers.

------------------
That was a problem in 4.0.3. I can't remember if there was a patch or not.
It was a real pain. The 4.0.3 network code was pretty bad. The 4.1+ is
much better, but still has some bugs.

I had already done most all of that except read the section Hal wrote. I
know you are going to laugh bur here was the solution:

------------------
        From: david@srv.PacBell.COM (David St. Pierre)

are you perhaps running NIS with the "B=-b" flag for DNS and forgetting
that each YP server has to have a working /etc/resolv.conf?
you don't say what's in your hosts file ... if you're using DNS and running
one or more copies of named, you should make sure that each NIS server
has to run named or else resolve to someone who is.

We had just changed over to domain style naming and we were under the
assumption we had a local name server. After reading this my heart jumped
into my throat and I hurriedly removed B=-b from /var/yp/Makefile and
remade the YP maps. ALL IS WELL AGAIN!!!

Thanks again for jogging my memory!!

If you have any questions please contact me.
---------------------------------------------------------------------------

Randy Holt |
Internal Support and Delivery | "Do not allow past ignorance
Phone # : (303) 581-1511 | to drive current decisions"
FAX # : (303) 581-0603 |
Mail Stop : COBOU | -G. Babb
E-mail : randy@dazixco.ingr.com |

---------------------------------------------------------------------------



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:21 CDT