On 6/30/20 9:42 AM, Ed Ravin wrote:
> What problems are you running into?
Running uucico as anybody other than the _uucp user (Apple has
apparently renamed "uucp" to "_uucp") will end up with failed
connections, I believe related to a line error. Yet the exact same
configuration and uucico command work just fine when run as the _uucp
user. This may be related to what line / port type that I'm using; pipe
to ssh.
This underlying issue also manifests itself when running uucp, uuto, and
(I assume but have not tested) uux as they kick off a uucico process
unless told not to do so.
Either allowing the failing call to time out (< 2 minutes) or killing
it, and then subsequently running uucico as the _uucp user transfers
files correctly, both sending and receiving.
I'm trying to ascertain why uucico fails when started by someone other
than the _uucp user. I don't know if this is something specific to
macOS Catalina 10.15.15 and / or a difference with *BSD vs Linux where
I'm more used to.
I have a group of four other Linux systems (3 × Gentoo, 1 × Ubuntu)
exchanging files perfectly, even when run as something other than the
uucp user. All systems, including macOS, are running Taylor UUCP. (No
known relation.)
> Other than filesystem quirks (UUCP temp filenames or target filenames
> might be case sensitive, which would cause a surprise when running
> on HFS),
I know that file name case is not an issue. I assume that macOS
Catalina 10.15.15 is using HFS+.
> or setting up a daemon via Launchd,
Everything is currently initiated on the macOS side. It does not allow
any externally initiated inbound connections, for various reasons.
So, my normal user calls uucp / uuto / uux, which in turn calls uucico,
which in turn may call uuxqt as necessary.
> I don't think there are that many MacOS-specific issues that would
> trip you up.
I had to berate macOS to get it to play nice, despite it coming from
Apple with macOS Catalina 10.15.15.
- I had to disable System Integrity Protection (a trip in and of itself).
- Remount root read-write so that I could edit the config files.
- chown uucp related binaries to _uucp:
- chmod uucp related binaries to setuid & setgid
- chmod permissions on the uucp spool directory
- create the uucp public directory
I'm using an ssh (STDIO) pipe (not port forwarding) between macOS and
one of the Linux systems. The ssh configuration works perfectly fine.
The _uucp user on macOS can log into the remote system without being
prompted for passwords. (SSH keys are wonderful. Especially when
forcing commands.)
I don't believe the SSH aspect is the root of the problem. Though it
may be related.
I think it's not the root of the problem because things work perfectly
when running uucico as the _uucp user.
Similarly, if I add "-r" to the uucp / uuto / uux commands run by the
non-_uucp user, so that they only spool their request and don't actually
start uucico and subsequently run uucico as the _uucp user, everything
works as expected. non-_uucp users files / commands get queued as
expected. uucico works as expected when run as _uucp.
I say that SSH /may/ be related because I do see the ssh pipe command
sequence when starting uucico as someone other than _uucp. But I think
that the ssh connection is working and that the problem is actually a
UUCP issue. I say this because uulog shows a connection and a
subsequent line error.