whimper NIS kerfluffle

Wed Jul 21 16:09:22 PDT 2004

First, an unrelated rant:  Why does Sun feel it necessary to have
Solaris's resolver, as the first step in any resolution attempt, perform
a reverse lookup on the IPs listed in /etc/resolv.conf?  I mean, I know
I *should* have in-addr.arpa zones for the various blocks I administer,
but is it really necessary to break forward resolution in this
particular and somewhat obscure manner?  Furrfu!

Now, onto the NIS kerfluffle:

I've got a box.  It's a Solaris box.  It's an NIS client.  It, like any
good Solaris NIS client, tries to start NIS at boot.  It can't.  Rather,
as far as I can tell, it won't.

I've done all the standard things -- check /etc/hosts to ensure the
hostnames (and various versions of the FQDN for good measure) of each
NIS master are listed correctly.  Check the interface configuration to
ensure it's putting data on the wire properly.  Verified /var/yp/* is
correct.  And so forth.

I've even narrowed the NIS master list in ypinit -c down to a single
host.  I've tried using its IP rather than the hostname.  I've tried
blowing away /var/yp and starting from scratch.  I've tried moving over
a known-good client's /usr/lib/netsvc/yp.

Nada.  When ypbind starts, even if I just start it manually, ypwhich
continues to claim it can't bind to a master.  *any* master.  Which is
annoying.

rpcinfo -b 100004 1 from another client on the same network verifies
that this misbehaving host is indeed an NIS client.  rpcinfo -p on the
misbeahving host...

...hangs.  As does any other rpcinfo attempt, as long as ypbind is
running.  As soon as it's killed, rpcinfo behaves just as it should.

There are no log entries from inetd or rpcbind regarding this little
issue.  Running rpcbind -D produces nothing when this occurs.  There's
no tli_* log message indicating a socket or door problem.

but, pkill ypbind, and things behave swimmingly in rpc-land.

To add insult to injury, if I start things up using
/usr/lib/netsvc/ypbind -ypsetme, then follow this with a /usr/sbin/ypset
<name_of_master>, NIS starts just fine on this misbegotten doorstop.
ypwhich gives the correct info.  ypcat <mapname> works, for any value of
mapname the server may contain.  In short, NIS works.

Interestingly, starting ypbind -broadcast sometimes works, sometimes
won't, depending on which slave answers the broadcast first.  They'll
all allow this cheese grater's ypwhich to report the master it's bound
to, but sometimes ypcat <mapname> will fail with an RPC error.

Grr.  Argh.

I'm no RPC guru.  In fact, RPC bothers me on many levels.  But I can't
for the life of me see what's causing this problem.  I've been staring
at it off and on for two days now, and I think I've just overthought it.
Am I missing something simple?  Is there some bit of NIS trivia I've
managed to overlook?

Anyone?  Buehler?

-- 
Mark C. Langston            GOSSiP Project          Sr. Unix SysAdmin
mark at bitshift.org   http://sufficiently-advanced.net    mark at seti.org
Systems & Network Admin      Distributed               SETI Institute
http://bitshift.org         P2P Antispam          http://www.seti.org

*whimper* NIS kerfluffle

whimper NIS kerfluffle