🚀 go-pugleaf

> When my 4.2 uucp trys to speak with a system V uucp my uucp dies, the
> SysV uucp says RLOGIN instead of ROK.
> Chris Johnston   ...!ihnp4!gargoyle!chris   chris%uchicago@csnet-relay.arpa

We had the same problem with two 4.2 sites talking to each other.  The
problem we had dealt with USERFILE entries.  If we used an entry like

	Usite,site X1 /usr/spool

we would get the RLOGIN problems but if we used

	Usite, X1 /usr/spool

it would work OK.  I was told that if a space or tab is placed after the
comma it would work but I haven't tried it.  Note that Usite was the login
name for site.

-robin

> When my 4.2 uucp trys to speak with a system V uucp my uucp dies, the
> SysV uucp says RLOGIN instead of ROK.

...

> Can someone send me the fixes to the berkeley uucico or explain how
> to get the SysV uucico to say the right thing?

There's no bug in the 4.2BSD UUCP, so there are no fixes, and the SysV
uucico is probably saying the right thing - it was never told to let you log
in, so it didn't.  Previous UUCPs let you log in even if they weren't told
to do so.

From various flavors of the UUCP documentation:

	USERFILE
	This file contains accessibility information...

	3. When a remote computer logs in, the login name that it
	   uses *must* appear in the USERFILE.  There may be several
	   lines with the same login name but one of them must either
	   have the name of the remote system or must contain a *null*
	   system name.

(The S5R2 and Sun UNIX 2.0 UUCP documentation say the same thing modulo a
couple of typographical changes.)

In practice, however, on pre-System V UUCPs, the check, as implemented by
"callback" in "chkpth.c", *only* checks that the login name in question
appears in the USERFILE; the *first* entry to match that name is used.  This
entry is also used to specify whether the connection should be accepted or
whether the called machine should call the calling machine back to establish
the connection.

In System V UUCPs, the check, as implemented by "callcheck" in "chkpth.c",
is more stringent.  If an entry appears with the same login name *and* the
same machine, that line is used; otherwise, if a line with that login name
and a null machine name is found, it is used.  If a line is found which has
that machine name but a different login name, or no login name, is found,
however, any subsequent lines with the same login name and no machine name
are ignored.  This is also the line used for callback checking.

If *no* such line is found, the pre-System V UUCPs will let the call go
through; the System V UUCP will NOT let the call go through and return
RLOGIN as the error.

So the problem is that the System V UUCP strictly implements the rules that
UUCP is documented to follow, which mean there must be an entry in the
USERFILE file for *every* login name used by UUCP.  Pre-System V UUCPs
didn't enforce this restriction, so people got used to setting up their
USERFILE without an entry for every login name.  The administrator on the
other end may have set up the USERFILE on their system in pre-System V
style; unfortunately, that won't work.  (Note that all this is taken from
the System V, Release 2, VAX Version 1 UUCP; lord knows what AT&T sends out
with 3Bs.)

Honey Danber uses a different set of control files, so it's all different
there.

	Guy Harris

In article <3169@sun.uucp> guy@sun.uucp (Guy Harris) writes:
>....  (Note that all this is taken from
>the System V, Release 2, VAX Version 1 UUCP; lord knows what AT&T sends out
>with 3Bs.)
>
>Honey Danber uses a different set of control files, so it's all different
>there.
>
>	Guy Harris

I can't swear to it, but based on what I've seen from other systems running
Honey Danber, that's what AT&T sends out with 3Bs.
-- 
Rich Kuhns		{ihnp4, decvax, etc...}!pur-ee!pur-phy!mrstve!rjk