that ypxfr is supposed to log messages to /var/yp/ypxfr.log if it exists,
using syslog() makes more sense, especially since ypserv does the same
thing already. Try to use stderr by default, and use syslog() if stderr
is not a tty.
Also update the man page to reflect this change.
NIS maps (get rid of extraneous slash a la /var/yp//domainname).
Have ypxfr log all output to /var/yp/ypxfr.log if stdin is not a
tty. This should allow logging to be done when ypxfr is called from
inside ypserv in response to a yppush request.
Update man page to reflect the change (and fix a typo).
This is a ported/modified version of the ypxfr program from the yps-0.21
package from the NYS project. This program is normally invoked by ypserv
when it receives a yppush command from an NIS master. It can also be
run from the command line to grab copies of maps when initializing a
slave server.
This program has been hacked in the following ways:
- rpcgen'ed new yp_xdr.c, yp_svc.c and yp_clnt.c files. The old ones were
rather grody.
- Changed certain function names (prefended a _ to them) to avoid conflicts
with certain functions lurking within libc. One major problem here is
that ypxfr needs to bind to a YP master in order to work correctly,
but it can't use the _yp_bind function inside libc because that
function only lets you bind to a domain, not a specific host. Lots
of head scratching here.
- Converted from GDBM to DB at gunpoint.
- Removed lots of really nasty looking DEBUG code to try to reduce clutter.
- Incorporated some of the library code supplied with yps-0.21 on which
ypxfr was dependent.
This program still needs to be cleaned up just as a matter of principle:
I get all icky just looking at it sometimes.
When we get an EN8 response while we're already sending the file using
the i protocol, this can happen:
In send.c, flocal_send_await_reply() is called. This function calls
flocal_send_fail() to process the aborted transfer. After this, we run
into the branch that calls ffileseekend() to force the end of the
actual transfer.
Now flocal_send_fail() frees qtrans, but qtrans is still used later!
I propose to fix this by moving the usfree_send(qtrans) out of
flocal_send_fail(), as in the patch I append to this mail.
...
I have found a race condition in the uucp 1.05 code. The typical result
is that the connections mysteriously fails with "conversation failed",
even while all files were transmitted. This is the problem:
At least for the i protocol, the code to send a packet can receive and
process packets after sending.
In several places in the code, we send a command and then prepare to
receive an answer.
Now the answer might already arrive during the call that sends the
command while we aren't ready to process it.
The general solution is IMHO first to do all preparations and only as a
last step to send out the command.
Reviewed by: John Dyson
Submitted by: Johannes Stille
Several files in uucp/libunix included <sys/dir.h> and defined dirent
as direct, but <sys/dir.h> defines direct as dirent. This macro
recursion is not allowed by cpp in traditional mode. The 2.0 mkdep
uses cpp in traditional mode (another bug) so cpp prints a error
message and exits with a nonzero status. The error status leaks out
of the pipe (another bug) so mkdep "succeeds". It may even succeed.
saying that 4.4 uses f_size in statfs, yet we're using b_size. Anyway,
I've configured things to match our current environment.
Reviewed by:
Submitted by:
Message-Id: <199404171501.LAA01245@stark.UUCP>
To: freebsd-hackers@freefall.cdrom.com
Subject: Make world and UUCP
Sender: freebsd-hackers-owner@freefall.cdrom.com
Precedence: bulk
It would be much more convenient if "make world" didn't clobber my
UUCP configuration files in /etc/uucp. Perhaps the easiest fix would
be to change the names of the sample configuration files:
config -> config.sample
ports -> ports.sample
...
Message-Id: <199404241154.OAA00260@tigger.cirion.fi>
Subject: uucp error
Index: gun/libexec/uucp FreeBSD-1.1-GAMMA
Apparently-To: FreeBSD-bugfiler@freefall.cdrom.com
Sender: freebsd-bugs-owner@freefall.cdrom.com
Precedence: bulk
Description:
When calling remote uucp site dialing succeeds, but standard
login chat fails. Debug file shows that uucico does not see
any characters send from remote.
Repeat-By:
use sio drivers, 16450 base serial and standard taylor configuration
provided with the GAMMA release. Run uucico and observer.
Fix:
define HAVE_BSD_TTY instead of HAVE_POSIX_TTY in common_source/policy.h
and recompile.
