Date: 07 Feb 1999 17:54:58 +0100 From: Dag-Erling Smorgrav <des@flood.ping.uio.no> To: current@FreeBSD.ORG Subject: NIS woes Message-ID: <86k8xuf925.fsf@niobe.ewox.org>
next in thread | raw e-mail | index | archive | help
I have a very simple NIS configuration at home: niobe is the server
and luna, my scratch box, is the client. Niobe runs 4.0-CURRENT, and
luna runs 3.0-RELEASE until 'make world' finishes on niobe so I can
make installworld over NFS. In addition to being the NIS and NFS
server, niobe is also its own NIS client, and I have no trouble at all
looking up NIS maps on niobe.
Luna, however, seems absolutely allergic to NIS. Everything is
configured correctly as far as I can see - the NIS domain name is set
correctly, the portmapper is running, 'ypbind -ypsetme' is running.
Nothing happens: ypwhich fails with "ypwhich: can't yp_bind: reason:
Domain not bound "; 'ypset -h luna.ewox.org -d ewox.org
niobe.ewox.org' hangs for 60 seconds, then fails with "ypset: can't
yp_bind, reason: Can't communicate with ypbind"; 'rpcinfo -p' prints
the list header, then hangs forever (i.e. longer than I can be
buggered to wait for it to give up).
Here are backtraces for ypset and rpcinfo:
luna# gdb `which ypset` 527
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-freebsd),
Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)...
/root/527: No such file or directory.
Attaching to program `/usr/sbin/ypset', process 527
Reading symbols from /usr/lib/libc.so.3...(no debugging symbols found)...done.
Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...
done.
0x280834b8 in _select ()
(gdb) bt
#0 0x280834b8 in _select ()
#1 0x28098d8d in clntudp_create ()
#2 0x2808f9b7 in pmap_getport ()
#3 0x28098935 in clntudp_bufcreate ()
#4 0x28098af7 in clntudp_create ()
#5 0x804885f in exit ()
#6 0x80489bb in exit ()
#7 0x804870d in exit ()
(gdb)
luna# gdb `which rpcinfo` 553
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-freebsd),
Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)...
/root/553: No such file or directory.
Attaching to program `/usr/bin/rpcinfo', process 553
Reading symbols from /usr/lib/libc.so.3...(no debugging symbols found)...done.
Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...
done.
0x28083cd8 in nanosleep ()
(gdb) bt
#0 0x28083cd8 in nanosleep ()
#1 0x2809e843 in sleep ()
#2 0x28098713 in _yp_dobind ()
#3 0x28098986 in yp_bind ()
#4 0x28099694 in _yp_check ()
#5 0x28068aa3 in getrpcbynumber ()
#6 0x80495e1 in clnt_sperrno ()
#7 0x8048c55 in clnt_sperrno ()
#8 0x8048a09 in clnt_sperrno ()
(gdb)
Specifying the server explicitly on the ypbind command line
('ypbind -S ewox.org,niobe.ewox.org') doesn't help.
Running the server in debug mode shows absolutely no activity of any
kind from luna. There's nothing wrong with the network connection
(LPIP); interfaces and routes are set up correctly on both sides, and
nfs, ssh etc. work flawlessly. Luna's IP address is in one of the
ranges listed in /var/yp/securenets. Niobe runs named, and luna is set
up to use it. Niobe does not run any kind of firewall or IP filter
which might block out RPC traffic.
Any suggestions?
DES
--
Dag-Erling Smørgrav - des@flood.ping.uio.no
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86k8xuf925.fsf>