On Mon, Jun 29, 2020 at 4:06 PM Grant Taylor via COFF <coff@minnie.tuhs.org> wrote:

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
That just basic UUCP how Dan originally designed it.

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.
Yes and no.  The problem was USENET (a.k.a. net.noise) had so little signal to noise ratio that one jack**s could send stuff that caused constipation

I know that Taylor UUCP supports a TCP mode.  I don't know if HDB
supported a TCP mode or not. 
The basic package from AT&T did not, but different protocols were available as source.  At the risk of taking Larry's ire, the key is that in practice people had the sources.  So I passed on my original 'e' protocol, as did others.

I assume that the old V7 did not.
Right, but IIRC by the time of BSD 4.3 and later Sam or Keith had updated the UCB version so more than just g was in there. 

> 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

As I type that I wonder if ORA is O'Reilly Associates.  <thinking emoji>
Yes -- Tim and I famously shared a card table as a desk at Masscomp.  He was out contract tech writer.   ORA was (is) his firm.  He wrote a couple of manuals for us, plus one our second in house tech writer wrote the original Make manual.   Tim proposed publishing some of the work he did for us (including Steve's Make) as the original 6 'UNIX in Nutshell' books[I still have them].   He did the X11 books for us and we (re)negotiated the deal.  That was what got the ORA enterprise going.  I also joke that ORA is the most successful and longest living part of Masscomp.

> What protocol is it running?

God lord another old hack lives!!! I'm not sure if I should be proud or ashamed.

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

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

> 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.
yes - it is now the uucico process is forked remotely.  We can take this offline.


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.
Understand -- IIRC Perry Flinn used rsh/rexec originally (it was his hack one afternoon between our two machines).  Once we got it working, I wrote the e protocol to make it more efficient. 
I'm trying to ""dial out from macOS into Linux.
Good idea.

Again, I might try to do this serial line to make the macOS was right before you tried to add things like ssh mix.   


Saying "trying" is somewhat of a misnomer as it is working perfectly
when I run uucico as the _uucp user.
uucico and the back end all runs as uucp/bin (or later uucp/uucp IICR -- I bet Tim's book tells you).  IIRC the uucp and uux command needs to be setuid also because they will be working files in the spool directories.  Look at the V7 root and usr file systems that Warren has.  Duplicate >>exactly<< the ownership of directories, commands and backend there and make sure you have that working.   As I said, I would do this on a serial line to start.

If that works, then you know you have the base system working as expected.


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.
They needs to be make the setuid setting os V7 or BSD.

I agree with your logic.  However, I think that I'm past anything
related to the UUCP chat.
It's more than just chat...  you need to get the subsystem working - so set it up exactly as how it was expected and you will have fewer surprises.


More specifically, I think my problem is related to the SSH ""serial
(line alternative).
Possible,m but it sounds like some of the commands/backend/databases are not consistent. 
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.
I would suspect most of it is Apple, but I don't know.   They are not likely to have messed much with uucp.  Taylor tried to match HDB and was targeted for later BSD systems [post the AT&T court case].

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.
uucico must run as UUCP --- the _uucp user is not traditional uucp - BTW. 

> 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:

  - SSH keys are used for all authentication.
  - SSH automatically launches uucico.
Probably ok, but UUCP did not work that way.   Your choice, but I would try to make it work as expected, described in the original V7 document and Tim's manual/book - the UUCP Administrator's guide. 

     - command:  ssh targetSystemName /usr/sbin/uucico
     - authorized_keys:  command="/usr/sbin/uucico" ...
Can't help you.   IICR uucico was traditionally in /usr/lib/uucp

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.
Be careful of seems to work.   It means transfers are working once to kick start it.  But are things being queued properly and is all the backup starting up right with the proper users.   I don't think this is a BSDism as much as a macOS thing.

My issues came into being when I started trying to add a macOS system to
the UUCP network.
Fair enough -- it means the mac is not configured properly.   But taking the configs from a Linux box is not a good idea here because between the Linux changed and the things Apple changed you're likely to have wrong configs.

UUCP of Ethernet?  Please elaborate.

dyslexia-r-me    UUCP >>over<< ethernet.  

Further adventures are probably better left offline.