ypbind.c: if a client program asks ypbind for the name of the server
for a particular domain, and there isn't a binding for that domain
available yet, ypbind needs to supply a status value along with its
failure message. Set yprespbody.ypbind_error before returning from
a ypbindproc_domain request.
yplib.c: properly handle the error status messages ypbind now has the
ability to send us. Add a ypbinderr_string() function to decode the
error values.
ypwhich.c: handle ypbind errors correctly: yperr_string() can't handle
ypbind_status messages -- use ypbinderr_string instead.
one ypbind broadcast can yield several responses. This can lead to
some confusion: the syslog message from ypbind will indicate a rebinding
to the first server that responds, but we may subsequently change our
binding to another server when the other responses arrive. This results
in ypbind reporting 'server OK' to one address and ypwhich reporting a
binding to another.
The behavior of the rpc_received() function has been changed to prevent
this: subsequent responses received after a binding has already been
established are ignored. Rebinding gratuitously each time we get a
new response is silly anyway.
Also backed out the non-fix I made in my last ypbind commit. (Pass
me the extra large conical hat, please.)
(At some point I'm going to seriously re-work ypbind and the _yp_dobind()
library function to bring them in line with SunOS's documented behavior:
binding requests are supposed to be 'client-driven.' The _yp_dobind()
function should be responsible for retrying connections in response to
calls from client programs rather than having ypbind broadcasting
continously until a server responds. The current setup works okay in
normal operation, but we broadcast far too often than we should.)
ypbind is supposed to create it but it doesn't. This is because when
it checks the return value for the attempted open() of
/var/yp/binding/DOMAIN.VERSION, it tests only for a value of -1. This
is bogus because open() doesn't return -1 in this case. Now it checks
for < 0 instead.
This should make life easier for many NIS-newbies who would otherwise
be left scratching their heads wondering why the NIS client stuff won't
work despite their best efforts. ("I set the domain name on my machine,
and /var/yp exists, but when I start ypbind and try a 'ypcat passwd,'
it says it can't bind to a server for this domain! Please help!")
*long, heavy sigh*
Fixes to ypbind:
- Correctly report the fact that we've bound to a new server when
logging the 'server OK' message.
- Report 'server not responding' just once instead of every
5 seconds while searching for a new server. (Prevents overstuffing
the syslog.)
- Apply patch from Sebstian Strollo to implement '-s' (secure) flag.
ypbind will reject connections from servers that do not originate
from a reserved TCP port.
- Apply patch from Sebastian Strollo to detect when a YP server has
crashed and come back up on a different port number.
The existing ypbind exhibits some truly anti-social behavior. After
initially establishing a binding with an NIS server, the following events
take place:
- ypbind waits for 60 seconds before trying to broadcast a ping again
- after the 60 seconds expires, ypbind sends out broadcasts every 5 seconds
come hell or high water.
These broadcasts travel far and wide, even to NIS servers in other domains
which dutifully log the packets even though they don't respond to them.
This leads to lots of unnecessary traffic and bloated log files.
This behavior has been fixed/changed. Here's what happens now:
- We still broadcast every 5 seconds at startup, just like before.
- Once bound, we send out packets once every 60 seconds to the server
we're bound to AND NO ONE ELSE.
- If we fail to receive a reply from our server within FAIL_THRESHOLD
seconds, we assume our server has croaked and go back to broadcasting
everywhere every 5 seconds again until somebody answers. FAIL_THRESHOLD
is currently set to 20 seconds.
Other fixes/improvements:
- ypbind now logs 'server not responding' and 'server OK' messages where
appropriate.
Thanks to Thomas Graichen <graichen@omega.physik.fu-berlin.de> for
reporting the problem and guilt-tripping me into fixing it. :)
Bill Paul
David Greenman
Garrett Wollman