[COFF] UUCP on macOS / *BSD

[Clem Cole]

On Mon, Jun 29, 2020 at 4:06 PM Grant Taylor via COFF <coff at 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
> mentioned.
>
> 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?
>
> "e"
>
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".
>
Excellent.


>
> 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.
Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200629/5b532dc2/attachment-0001.htm>