[COFF] UUCP on macOS / *BSD

[gtaylor at tnetconsulting.net (Grant Taylor)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7006 bytes --]

On 6/29/20 11:20 AM, Clem Cole wrote:
> I can try to pull some info from long ago paged out memory.

Some effort would be appreciated.  But please don't dig too deeply or 
disturb too much accumulated dust.  ;-)

> I havent had to run UUCP since the late 1990s.   By the Stellar time, 
> we were on the Internet and UUCP had pretty much become unnecessary 
> for most folks.

TCP/IP and the Internet serve me quite well.  But I've found that the 
background store-and-forward nature of UUCP is nice for some things. 
Particularly when one of the systems in the path is offline or not 
readily accessible.

I recently moved a 4.7 GB DVD around between three systems just to see 
if I could.  It worked quite well.  It took ~2 minutes per hop.  The 
email notification at the end was nice too.

I was doing some reading of the Taylor UUCP manual last night and 
learned that uux can operate on files that are on other systems.

    uux sys1!diff sys2!file1 sys3!file2

Something like that.

I've not had a need for that yet.  But I do like the idea.

> BSD was originally based on V7 UUCP with some fixes.   Eventually 
> Honey-Dan-Ber came out in the very early 1980s and most of the 
> commercial UNIX's licensed/relicensed/redistributed it. V7 and HDB were 
> the versions that built the USENET.

#respect

> As Larry said, V7 definition needed a baby sister, HDB got to the point 
> that it pretty much worked without having to watch it too much.

Good to know.

> The biggest issue was that disks were much smaller in those days and 
> overflow of the spool area was not uncommon.

Ah.  That makes sense.

I would think that the byte count / size of the file would be checked 
before the transfer was started.  But maybe that's the benefit of 
learning from 40 years of experience that others have had.

I can also see how multiple inbound connections ~> copies could 
complicate things too.

> Taylor UUCP was much later and was a mostly FOSS implementation of 
> H-D-B.   I never ran it.

I know that Taylor UUCP supports a TCP mode.  I don't know if HDB 
supported a TCP mode or not.  I assume that the old V7 did not.

> The original ORA UUCP manual (that Tim actually wrote the first draft) 
> was always the definitive guide to running.

I'll look that up.

I naively see the O'Reilly UUCP book as the definitive source often 
mentioned.

As I type that I wonder if ORA is O'Reilly Associates.  <thinking emoji>

> What protocol is it running?

"e"

> Chesson's 'g' protocol (which was the default).

I want ~> need to learn more about the protocols.

> How is the chatting being done?   That's were most issues tended occur.

Chat isn't really happening.

chat "" ""

My understanding is that chat is needed to log into the remote system. 
Seeing as how I'm using SSH with key based authentication, there really 
isn't any typical log in process.  The SSH connection is running uucico 
as the remote command.  So it's really (local) uucico talking to SSH's 
STDIO which is (remotely) running uucico.

> Remember the expect(1) program was created by the folks at NIST 
> modelling after Ber's version of chat for H-D-B.  My guess is that 
> something in macOS's way of running login might be doing something 
> unexpected and confusing uucico.

I'm trying to ""dial out from macOS into Linux.

Saying "trying" is somewhat of a misnomer as it is working perfectly 
when I run uucico as the _uucp user.

The only apparent problem is related to users other than the _uucp user 
prompting the call.  I need to do some more investigating on this.

I can initiate actions as my normal user; uucp, uuto, etc. and they 
properly queue actions.  They also spur a call, which fails.  If I 
subsequently spur a call as the _uucp user, things work perfectly fine.

> I might suggest try debugging with two computers talking over a serial 
> link.   Just add a USB to serial to each of your systems.   Set up a 
> login one link and get the other side to open the other.

I agree with your logic.  However, I think that I'm past anything 
related to the UUCP chat.

More specifically, I think my problem is related to the SSH ""serial 
(line alternative).

> The hard part is Apple dorked the login scheme from traditional 
> UNIX/so you'll need to make sure it does not try to do something 
> too funny.

ACK

I have a handicap of of not knowing what's macOS issues vs what's simply 
a difference from the BSD family vs Linux what I'm used to.

> Basically you need to be able to run cu (or the equiv) from one system 
> to the other and login in a normal user.

cu targetSystemName seems to work.

I get "Connected." followed by "Shere=targetSystemName".

Note:  I've got the remote system automatically launching uucico.  This 
works perfectly fine when running uucico as the _uucp user.

> If you can do that and nothing is screwy, then try to login at user 
> uucp and see if uucico is properly forked.

Perhaps I should clarify somethings:

  - All of my systems are using the same configuration.
     - Think template with some values adjusted as necessary.
  - UUCP on all systems ssh out to to other systems as the host name.
     - hostA logs into hostB and hostC as the hostA user.
     - hostB logs into hostA and hostC as the hostB user.
     - hostC logs into hostA and hostB as the hostC user.
  - All systems have an account on the systems that they log into.
     - Random 63 character passwords that I no longer have.
  - SSH keys are used for all authentication.
  - SSH automatically launches uucico.
     - command:  ssh targetSystemName /usr/sbin/uucico
     - authorized_keys:  command="/usr/sbin/uucico" ...

> Maybe the answer is pull an old getty/login pair off BSD and set up a 
> daemon to fake it so that Apple login stuff is not in the way.  But the 
> trick is that once you make that work, you can then set upuucp theway it 
> was expected to run.

Given that the UUCP link works, seemingly perfectly fine, when run as 
the _uucp user, I think this is more a macOS (BSD?) issue than it is a 
UUCP link issue.

> FWIW:  ssh did not exist when UUCP transitioned to running on IP - so I 
> suspect it was never really, debugged worked out.   There was no need.

I've got multiple other systems running the same config and they are 
working perfectly fine.

My issues came into being when I started trying to add a macOS system to 
the UUCP network.

> Just so you know, a couple of UUCP of ethernet were done.  I wrote the 
> first one (the e protocol) for the Masscomp systems, which I gave back 
> to Sam and Keith was in the BSD release.   IIRC there were a couple of 
> others that different people did also.

UUCP of Ethernet?  Please elaborate.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200629/a0378e37/attachment.bin>