Commit Graph

57 Commits

Author SHA1 Message Date
Bill Paul
a00f731551 In environments with multiple NIS servers (a master and several slaves)
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.)
1995-04-15 23:35:46 +00:00
Bill Paul
2d91aab798 First crack at a man page for ypbind. 1995-04-09 21:59:06 +00:00
Bill Paul
9f3db41ff5 Fix long standing bogosity in ypbind: if /var/yp/binding doesn't exist,
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*
1995-04-02 03:10:55 +00:00
Bill Paul
6a4f61a2ab Submitted by: Sebastian Strollo <seb@erix.eriksson.se>
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.
1995-02-26 04:42:48 +00:00
Bill Paul
5d645648b1 ypbind jumbo patch :)
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. :)
1995-02-16 01:21:44 +00:00
David Greenman
c0ba84e4a3 Don't return the address of a stack variable. 1994-09-23 10:25:38 +00:00
Garrett Wollman
dd784d3e70 Copying YP programs over from 1.1.5, with a slightly different directory
structure than before.
1994-08-08 01:03:58 +00:00