SUMMARY: Help! NIS hates me...

From: Lance Jones (lj@fox.vet.purdue.edu)
Date: Wed Jan 27 1993 - 10:24:44 CST


Better late than never... :^)

My original question was:

> Over the weekend we upgraded our NIS master from 4.0.3 to 4.1.1 and NIS has
> stopped working. Basically, when ypserv starts it immediately fails with the
> message logged to ypserv.log : "ypserv: Unable to register service for udp".
> I've looked at the source for ypserv and know that this means that there is a
> problem between the portmapper and ypserv. Subsequently, ypbind and ypupdated
> fail to stay running. Also, ypserv leaves a core file in /
>
> Starting up the yp daemons by hand causes them to stay around in memory, but
> they do nothing. A ypwhich gets: "Domain vet.purdue.edu not bound"
>
> Noteworthy information:
> 1 - we are running C2
> 2 - we have checked our installation of NIS against another here on campus
> and found that we do have permissions on various directories/files set the
> same
> 3 - we have rebuilt libc with routines for using DNS (currently we are not
> using the "-b" flag in the NIS makefile, but we have tested it that way).
> 4 - we have installed patch 100482 which replaces ypserv and portmap although
> the patch doesn't seem to address our problem (NIS doesn't work with either
> the original or patched files)
> 5 - rpcinfo -p does not show any entries for any yp daemons. The yp daemon
> entries are in /etc/rpc and in the corresponding YP database

The problem turned out to be a two-parter:

1) Either because of a problem with the install procedure or, more likely,
because of SSAT (stoopid system administrator tricks) the ifconfig statement in
/etc/rc.boot that configures the loopback interface wasn't set up properly,
therefore the ypserv daemon couldn't contact the portmapper. Apparently the
problem must have resolved itself after the boot sequence was completed
because starting the daemons by hand caused them to stay running. However....

2) I applied some patches from Sun that replaced various yp daemons. One of
the patches (100482-04) adds the file /var/yp/securenets which tells yp what
subnets valid yp requests can be accepted from. Unfortunately, after having
installed this patch, I did a 'ypinit -m' to reinitialize things not realizing
that this would not restore or recreate the securenets file. So in short,
before I finally realized the error of mine and Suns ways I had a working yp
master that didn't trust anybody!

The patches I applied were:
100342-03 (replaces: /usr/etc/ypbind)
100482-04 (replaces: /usr/etc/ypserv, /usr/etc/ypxfrd
                 adds: /var/yp/securenets)

These patches are obtainable from:
ftp.uu.net:/systems/sun/sun-dist (security-related patches only)
princeton.edu:/pub/sun-fixes (fairly complete set of patches)
qiclab.scn.rain.com:/pub/sunos-patches (even more complete set)

Thanks to the following people for their assistance:
Andy Feldt (feldt@phyast.nhn.uoknor.edu)
Mike Raffety <miker@il.us.swissbank.com>
lemke@MITL.COM (Kennedy Lemke)
riess@csq.uta.edu (Bill Riess)
rodo@auspex.com (Rod Livingood)
Shirley Stephan (stephan3@llnl.gov)



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:25 CDT