chris@gargoyle.UUCP (Chris Johnston) (01/16/86)
We are a news feed for several machines in the area and are having
problems keeping our /usr/spool partition manageable.
When my 4.2 uucp trys to speak with a system V uucp my uucp dies, the
SysV uucp says RLOGIN instead of ROK.
UUCP crsp (1/15-2:49-5437) SUCCEEDED (call to crsp )
UUCP crsp (1/15-2:49-5437) HANDSHAKE FAILED (LOGIN)
When the sysV systems call me they log a message in their LOGFILE and
recover.
gargoy!uucp (1/15-4:30:17) (C,1998,0) OK (MODEM tty17 15)
gargoy!uucp (1/15-4:30:32) (C,1998,0) TIMEOUT (LOGIN)
gargoy!uucp (1/15-4:30:36) (C,1998,0) SUCCEEDED (call to gargoy )
gargoy!uucp (1/15-4:30:45) (C,1998,0) OK (startup)
gargoy!uucp (1/15-4:30:47) (C,1998,0) OK (conversation complete tty17 45)
Can someone send me the fixes to the berkeley uucico or explain how
to get the SysV uucico to say the right thing?
Thanks!
Chris Johnston ...!ihnp4!gargoyle!chris chris%uchicago@csnet-relay.arparobin@itcatl.UUCP (Robin Cutshaw) (01/17/86)
> 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
guy@sun.uucp (Guy Harris) (01/17/86)
> 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
rjk@mrstve.UUCP (Richard Kuhns) (01/20/86)
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