[COFF] UUCP on macOS / *BSD

[COFF] UUCP on macOS / *BSD

[gtaylor]

Does anyone have any experience with UUCP on macOS or *BSD systems that 
would be willing to help me figure something out?

I'm working on adding a macOS X system to my micro UUCP network and 
running into some problems.

   - uuto / uucp copy files from my non-root / non-(_)uucp user to the 
UUCP spool.  But the (demand based) ""call (pipe over SSH) is failing.
   - running "uucico -r1 -s <remote system name> -f" as the (_)uucp user 
(via sudo) works.
   - I'm using the pipe port type and running things over an SSH connection.
      - The (_)uucp user can ssh to the remote system as expected 
without any problems or being prompted for a password.  (Service 
specific keys w/ forced command.)

I noticed that the following files weren't set UID or GID like they are 
on Linux.  But I don't know if that's a macOS and / or *BSD difference 
when compared to Linux.

/usr/bin/uucp
/usr/bin/uuname
/usr/bin/uustat
/usr/bin/uux
/usr/sbin/uucico
/usr/sbin/uuxqt

Adding the set UID & GID bits allowed things to mostly work.

Aside:  Getting the contemporary macOS so that I could edit the 
(/usr/share/uucp/) sys & port files was a treat.

I figured that it was worth inquiring if anyone had any more experience 
/ tips / gotchas before I go bending ~> breaking things even more.

Thank you.



-- 
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/20200628/41c730f3/attachment.bin>

[COFF] UUCP on macOS / *BSD

[lm]

So UUCP, depending which version, really needed a baby sitter.  I think
the latest one was sort of reliable but my ancient memory is that you
had to unwedge things on a daily basis.

On Sun, Jun 28, 2020 at 06:50:27PM -0600, Grant Taylor via COFF wrote:
> Does anyone have any experience with UUCP on macOS or *BSD systems that
> would be willing to help me figure something out?
> 
> I'm working on adding a macOS X system to my micro UUCP network and running
> into some problems.
> 
>   - uuto / uucp copy files from my non-root / non-(_)uucp user to the UUCP
> spool.  But the (demand based) ""call (pipe over SSH) is failing.
>   - running "uucico -r1 -s <remote system name> -f" as the (_)uucp user (via
> sudo) works.
>   - I'm using the pipe port type and running things over an SSH connection.
>      - The (_)uucp user can ssh to the remote system as expected without any
> problems or being prompted for a password.  (Service specific keys w/ forced
> command.)
> 
> I noticed that the following files weren't set UID or GID like they are on
> Linux.  But I don't know if that's a macOS and / or *BSD difference when
> compared to Linux.
> 
> /usr/bin/uucp
> /usr/bin/uuname
> /usr/bin/uustat
> /usr/bin/uux
> /usr/sbin/uucico
> /usr/sbin/uuxqt
> 
> Adding the set UID & GID bits allowed things to mostly work.
> 
> Aside:  Getting the contemporary macOS so that I could edit the
> (/usr/share/uucp/) sys & port files was a treat.
> 
> I figured that it was worth inquiring if anyone had any more experience /
> tips / gotchas before I go bending ~> breaking things even more.
> 
> Thank you.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 
> 



> _______________________________________________
> COFF mailing list
> COFF at minnie.tuhs.org
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff


-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[COFF] UUCP on macOS / *BSD

[gtaylor]

On 6/29/20 9:37 AM, Larry McVoy wrote:
> So UUCP, depending which version, really needed a baby sitter.  I think
> the latest one was sort of reliable but my ancient memory is that you
> had to unwedge things on a daily basis.

Hum.  That's interesting.  I'd be curious to know more about that.

Thus far, I'm messing with Taylor UUCP 1.x or higher.  (No known relation.)



-- 
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/5f09eac2/attachment.bin>

[COFF] UUCP on macOS / *BSD

[dave]

On Mon, 29 Jun 2020, Larry McVoy wrote:

> So UUCP, depending which version, really needed a baby sitter.  I think 
> the latest one was sort of reliable but my ancient memory is that you 
> had to unwedge things on a daily basis.

I found that HoneyDanBer was quite reliable, and there was only the one 
configuration file (IIRC).

-- Dave

[COFF] UUCP on macOS / *BSD

[arrigo]

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

On 29 Jun 2020, at 02:50, Grant Taylor via COFF <coff at minnie.tuhs.org> wrote:
> Does anyone have any experience with UUCP on macOS or *BSD systems that would be willing to help me figure something out?

I run UUCP on OpenBSD for some very remote sites connected with satellite modems (using UUCP-over-IP, not pure UUCP, where the dial-up script initiates the UUCP exchange). UUCP was recently removed from the base OpenBSD distribution but is still available as a package.

I honestly cannot see it work on macOS because I cannot even remotely imagine Apple having any interest whatsoever in ensuring that it works with the various changes they made to “standard Unix” (launchd, sandboxing, read-only /, etc.).

Are you trying to configure dial-up UUCP or UUCP-over-IP with uucpd?

Arrigo

[COFF] UUCP on macOS / *BSD

[gtaylor]

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

On 6/29/20 9:53 AM, Arrigo Triulzi via COFF wrote:
> I run UUCP on OpenBSD for some very remote sites connected with 
> satellite modems (using UUCP-over-IP, not pure UUCP, where the dial-up 
> script initiates the UUCP exchange). UUCP was recently removed from 
> the base OpenBSD distribution but is still available as a package.

Do you by chance recall what UUCP software was being used?  Was it by 
chance Taylor UUCP?  Or was it some other UUCP package in OpenBSD?

> I honestly cannot see it work on macOS because I cannot even remotely 
> imagine Apple having any interest whatsoever in ensuring that it works 
> with the various changes they made to “standard Unix” (launchd, 
> sandboxing, read-only /, etc.).

I'll be the first to admit that it was a very ... convoluted process to 
get it to work on macOS (X) Catalina 10.15.5.

1)  Boot into recovery mode.
2)  Log into my local account.
3)  Disable System Integrity Protection.
4)  Boot into normal mode.
5)  Remount the root file system read-write:  mount -uw /
6)  Update /usr/share/uucp/* as necessary.
7)  Boot into recovery mode.
8)  Enable SIP.

I did have to enable Set UID & GID on some of the UUCP binaries.  -  I 
don't know if this is a macOS thing that's broken or if it's a 
difference in how UUCP operates on BSD or something else I'm ignorant of.

Currently, it seems like UUCP is largely working, save for the fact that 
users other than _uucp (yes, including the leading underscore) can't 
access the SSH key file that's used as part of the pipe transport.

I should document what I'm doing, both as notes for my self (self 
serving) and for others (good of the community).

> Are you trying to configure dial-up UUCP or UUCP-over-IP with uucpd?

I'm trying to configure UUCP-over-SSH.  It's probably closer to 
UUCP-over-modem than it is UUCP-over-IP (TCP).  The ""modem pipe is the 
ssh command which remotely connects to the destination host (using keys 
to authenticate) and launching uucico through the SSH connection STDIO.



-- 
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/8e92716b/attachment.bin>

[COFF] UUCP on macOS / *BSD

[clemc]

I can try to pull some info from long ago paged out memory.  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.

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

> Do you by chance recall what UUCP software was being used?  Was it by
> chance Taylor UUCP?  Or was it some other UUCP package in OpenBSD?
>
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.

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.  The
biggest issue was that disks were much smaller in those days and overflow
of the spool area was not uncommon.

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

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

>
> > Are you trying to configure dial-up UUCP or UUCP-over-IP with uucpd?
>
> I'm trying to configure UUCP-over-SSH.  It's probably closer to
> UUCP-over-modem than it is UUCP-over-IP (TCP).  The ""modem pipe is the
> ssh command which remotely connects to the destination host (using keys
> to authenticate) and launching uucico through the SSH connection STDIO.
>
What protocol is it running?   Chesson's 'g' protocol (which was the
default).  How is the chatting being done?   That's were most issues tended
occur.   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 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.  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.  Basically you need to be
able to run cu (or the equiv) from one system to the other and login in a
normal user.   If you can do that and nothing is screwy, then try to login
at user uucp and see if uucico is properly forked.

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 up uucp the way it
was expected to run.

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

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200629/931fafb8/attachment-0001.htm>

[COFF] UUCP on macOS / *BSD

[gtaylor]

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

[COFF] UUCP on macOS / *BSD

[clemc]

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>

[COFF] UUCP on macOS / *BSD

[rtomek]

On Mon, Jun 29, 2020 at 02:06:04PM -0600, Grant Taylor via COFF wrote:
> On 6/29/20 11:20 AM, Clem Cole wrote:
> >I can try to pull some info from long ago paged out memory.
> 
[...]
> 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.
[...]

So, assuming that I understood your problem
 - and given that I know close to nothing about uucp
 - and given that I know close to nothing about MacOS pecularities

I wonder if your problem could be solved by setting up a small crontab
entry for user _uucp, where a script would be called every minute and
check, if there is previous instance of it running and if there are
some jobs in the queue, and do the stuff when the answer were no and
yes, respectively.

Special user moving files over ssh, normal users putting files in the
queue.

-- 
Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola at bigfoot.com             **

[COFF] UUCP on macOS / *BSD

[gtaylor]

On 6/29/20 8:26 PM, Tomasz Rola wrote:
> So, assuming that I understood your problem
>   - and given that I know close to nothing about uucp
>   - and given that I know close to nothing about MacOS pecularities
> 
> I wonder if your problem could be solved by setting up a small crontab 
> entry for user _uucp, where a script would be called every minute 
> and check, if there is previous instance of it running and if there 
> are some jobs in the queue, and do the stuff when the answer were no 
> and yes, respectively.

You're quite close to what I've seen on other systems.  It would 
probably also work on the current problem system as a work around.  But 
I don't think it will solve the underlying problem.

There is an underlying utility that's part of the UUCP suite named 
"uucico" and it's job is to connect to itself and transfer files.  It 
has a function where it will see if there is any work (UUCP terms) and 
if there is, do it.

So I've frequently seen uucico run on an hourly cron job on a number of 
systems.

I do believe that would work around the problem.

I'm trying to understand what the problem is that is actually happening 
so that I can use things properly and not need to rely on the workaround.

Incidentally, other Linux systems running the same software with the 
same config don't need the workaround.  :-|

> Special user moving files over ssh, normal users putting files in 
> the queue.

There's some more nuance to it than that.  But, sure, that's the gist of it.

Subsystem that runs as a dedicated user moving files between systems, 
over SSH in this case.  Normal users use other commands to ask said 
subsystem to do work on their behalf.

Said subsystem includes creating and managing a queue structure, 
determining if / when to connect (call) a remote system, transferring 
files both ways, dealing with failures, and retrying.

Oh, ya, said subsystem is an industry standard across most Unixes and 
some other platforms.



-- 
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/aa3afdb7/attachment.bin>

[COFF] UUCP on macOS / *BSD

[rtomek]

On Mon, Jun 29, 2020 at 09:19:20PM -0600, Grant Taylor via COFF wrote:
[...]
> Incidentally, other Linux systems running the same software with the
> same config don't need the workaround.  :-|
[...]

You might want to see if all copies of uucp on your many systems were
compiled from the same source. In case of Debian, package maintainers
sometimes add a bit from themselves, from what I have gathered.

-- 
Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola at bigfoot.com             **

[COFF] UUCP on macOS / *BSD

[rtomek]

On Tue, Jun 30, 2020 at 05:26:48AM +0200, Tomasz Rola wrote:
> On Mon, Jun 29, 2020 at 09:19:20PM -0600, Grant Taylor via COFF wrote:
> [...]
> > Incidentally, other Linux systems running the same software with the
> > same config don't need the workaround.  :-|
> [...]
> 
> You might want to see if all copies of uucp on your many systems were
> compiled from the same source. In case of Debian, package maintainers
> sometimes add a bit from themselves, from what I have gathered.

And BTW, looking how they did it on systems where things worked might
give you a clue, too. For example, when you install a package, there
might be a script setting thing up in a correct way.

HTH

-- 
Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola at bigfoot.com             **

[COFF] UUCP on macOS / *BSD

[gtaylor]

On 6/29/20 9:46 PM, Tomasz Rola wrote:
> And BTW, looking how they did it on systems where things worked might 
> give you a clue, too. For example, when you install a package, there 
> might be a script setting thing up in a correct way.

Agreed.  I have four systems in this current micro UUCP network, one 
Ubuntu and three Gentoo, all working happily with each other.

The macOS system that I am working on adding to the mix is the cranky 
one.  And even then, it's only cranky if you don't sweet talk it.  If 
you do sweet talk it, it works like it should.

Here, sweet talk means adding "-r" to uuto and uucp, then calling uucico 
as the UUCP user.



-- 
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/3f91e63f/attachment.bin>

[COFF] UUCP on macOS / *BSD

[gtaylor]

On 6/29/20 9:26 PM, Tomasz Rola wrote:
> You might want to see if all copies of uucp on your many systems were 
> compiled from the same source. In case of Debian, package maintainers 
> sometimes add a bit from themselves, from what I have gathered.

I can almost guarantee that the copy on macOS, Ubuntu, and (multiple) 
Gentoo boxen are /not/ compiled from the same source code.

But, that's one of the nice things about UUCP, it's a standard and 
things /should/ be interoperable.

I think I'm tilting at something macOS specific.



-- 
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/cc867fae/attachment-0001.bin>

[COFF] UUCP on macOS / *BSD

[arrigo]

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

On 29 Jun 2020, at 18:43, Grant Taylor via COFF <coff at minnie.tuhs.org> wrote:
> 
> On 6/29/20 9:53 AM, Arrigo Triulzi via COFF wrote:
>> I run UUCP on OpenBSD for some very remote sites connected with satellite modems (using UUCP-over-IP, not pure UUCP, where the dial-up script initiates the UUCP exchange). UUCP was recently removed from the base OpenBSD distribution but is still available as a package.
> 
> Do you by chance recall what UUCP software was being used?  Was it by chance Taylor UUCP?  Or was it some other UUCP package in OpenBSD?

It is indeed Taylor UUCP.

> I did have to enable Set UID & GID on some of the UUCP binaries.  -  I don't know if this is a macOS thing that's broken or if it's a difference in how UUCP operates on BSD or something else I'm ignorant of.

Yes, UUCP binaries do have setuid set, even on OpenBSD. Indeed, in the interest of removing setuid binaries, UUCP was completely removed from base OpenBSD and moved to packages.

> Currently, it seems like UUCP is largely working, save for the fact that users other than _uucp (yes, including the leading underscore) can't access the SSH key file that's used as part of the pipe transport.

The key file won't normally work if permissions are more permissive than 0600 so that is not surprising. Is it doing tunnelling between two ports, i.e. using -L etc.? I'm assuming you are then using uucpd on the remote end listening on the appropriate, forwarded, port which would suggest that you don't need UUCP to setup the connection as long as it has access to the local forwarded port?

> I should document what I'm doing, both as notes for my self (self serving) and for others (good of the community).

Also for debugging purposes, i.e. showing us so that we can see the issues you discuss :)

>> Are you trying to configure dial-up UUCP or UUCP-over-IP with uucpd?
> 
> I'm trying to configure UUCP-over-SSH.  It's probably closer to UUCP-over-modem than it is UUCP-over-IP (TCP).  The ""modem pipe is the ssh command which remotely connects to the destination host (using keys to authenticate) and launching uucico through the SSH connection STDIO.

Right, never did that in my life… I set things up when (open)SSH was v1.2 and port forwarding not quite there yet.

Arrigo 

[COFF] UUCP on macOS / *BSD

[gtaylor]

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

On 6/29/20 11:22 AM, Arrigo Triulzi via COFF wrote:
> It is indeed Taylor UUCP.

Cool.  Thank you for the confirmation.

> Yes, UUCP binaries do have setuid set, even on OpenBSD.

That clarifies setuid.  Can the same be said about setgid?

> Indeed, in the interest of removing setuid binaries, UUCP was 
> completely removed from base OpenBSD and moved to packages.

That seems understandable, especially for OpenBSD.

I think many distros are simply removing UUCP as an antiquated package.

> The key file won't normally work if permissions are more permissive 
> than 0600 so that is not surprising.

Agreed.  I also tried it any way and got the expected error from OpenSSH 
saying that it was ignoring the key file with bad permissions.

I was, still am, naively expecting that uucp / uuto / uux are run as 
normal users (not root and not the uucp user) to copy files to the uucp 
queue directory structure, and then something will cause the uucp user 
to initiate the outbound connection as the uucp user.  I think this 
later part is where my understanding breaks down.

> Is it doing tunnelling between two ports, i.e. using -L etc.? I'm 
> assuming you are then using uucpd on the remote end listening on the 
> appropriate, forwarded, port which would suggest that you don't need 
> UUCP to setup the connection as long as it has access to the local 
> forwarded port?

No.

sys:
system targetHost
call-login targetHost
called-login targetHost
port targetHost

port:
port targetHost
type pipe
command /usr/bin/ssh targetHost.fqdn /usr/sbin/uucico

> Also for debugging purposes, i.e. showing us so that we can see the 
> issues you discuss :)

What would you like me to show / share?

> Right, never did that in my life… I set things up when (open)SSH 
> was v1.2 and port forwarding not quite there yet.

ACK

I've got this same type of configuration working quite well with 
multiple Linux systems.

macOS mostly works.



-- 
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/4a474c09/attachment-0001.bin>

[COFF] UUCP on macOS / *BSD

[gtaylor]

On 6/29/20 2:18 PM, Grant Taylor via COFF wrote:
> sys:
> system targetHost
> call-login targetHost
> called-login targetHost
> port targetHost
> 
> port:
> port targetHost
> type pipe
> command /usr/bin/ssh targetHost.fqdn /usr/sbin/uucico

I should probably include details about how SSH is configured:

uucp user's ~/.ssh/config file:
Host *
	User shortName	# matches the output of uuname -l

Calling system's ~/.ssh/authorized_keys file:
command="/usr/sbin/uucico" ...typical contents...

The uucp user can successfully ssh to the target system without being 
prompted for username or password.  uucico starts automatically.



-- 
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/a98200e5/attachment.bin>

[COFF] UUCP on macOS / *BSD

[gtaylor]

On 6/28/20 6:50 PM, Grant Taylor wrote:
> Does anyone have any experience with UUCP on macOS or *BSD systems that 
> would be willing to help me figure something out?

I ended up getting this to work.

I don't know if it was a macOSism or a *BSDism, but the root of the 
problem was crossing between users via setuid / setgid in relation to 
OpenSSH.

Two different versions of macOS behaved differently.

macOS Yosemite 10.10.5 runs the underlying ssh pipe command as the user 
account that initiates the uucp / uuto / uux.

macOS Catalina 10.15.15 runs the underlying ssh pipe command as the 
_uucp user, NOT the account that initiates the uucp / uuto / uux.

As such, on macOS Yosemite 10.10.5, I have to have the normal user's ssh 
public key in the authorized_keys file on the remote system.

Conversely, on macOS Catalina 10.15.15, I have to have the _uucp user's 
ssh public key in the authorized_keys file on the remote system.

I don't know why macOS Yosemite 10.10.5 and macOS Catalina 10.15.15 are 
behaving differently, but they are.

These inconsistencies made identifying which client ssh config file -- 
nominally ~/.ssh/config -- was used cumbersome.

For some unknown reason, I couldn't rely on "~/" or defaults to specify 
the _uucp user's key (Identity) file or the known_hosts file on macOS 
Catalina 10.15.15, despite the fact that it was running as the _uucp 
user.  I ended up having to hard code the paths, as they were defaulting 
to the original user account that initiated the uucp / uuto / uux.

I can only surmise that something is fundamentally different between 
Linux and macOS in how it does things when changing user accounts via 
setuid & setgid as I did not have any of these problems on multiple 
Linux machines.  I can further surmise that something is different 
between macOS Yosemite 10.10.5 and macOS Catalina 10.15.15.  I don't 
know if this is related to System Integrity Protection or something else.



-- 
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/20200701/daf260d8/attachment.bin>