29 Jun
2020
29 Jun
'20
6:50 a.m.
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
29 Jun
29 Jun
9:37 p.m.
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(a)minnie.tuhs.org
https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
10:13 p.m.
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
5 Jul
5 Jul
12:30 p.m.
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
29 Jun
29 Jun
9:53 p.m.
On 29 Jun 2020, at 02:50, Grant Taylor via COFF <coff(a)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
10:42 p.m.
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
11:20 p.m.
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(a)minnie.tuhs.org>
wrote:
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
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.
30 Jun
30 Jun
2:06 a.m.
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
2:59 a.m.
On Mon, Jun 29, 2020 at 4:06 PM Grant Taylor via COFF <coff(a)minnie.tuhs.org>
wrote:
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.
God lord another old hack lives!!! I'm not sure if I should be proud or
ashamed.
Talk to me offline.
yes - it is now the uucico process is forked remotely. We can take this
offline.
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.
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>
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.
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.
- 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
8:26 a.m.
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@bigfoot.com **
9:19 a.m.
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
9:26 a.m.
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@bigfoot.com **
9:46 a.m.
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:
[...]
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@bigfoot.com **
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.
9:50 a.m.
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
9:47 a.m.
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
29 Jun
29 Jun
11:22 p.m.
On 29 Jun 2020, at 18:43, Grant Taylor via COFF <coff(a)minnie.tuhs.org> wrote:
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
On 6/29/20 9:53 AM, Arrigo Triulzi via COFF wrote:
It is indeed Taylor UUCP.
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 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.
30 Jun
30 Jun
2:18 a.m.
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
2:31 a.m.
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
1 Jul
1 Jul
11:32 p.m.
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
1630
days inactive
1636
days old
18 comments
6 participants
participants (6)
-
Arrigo Triulzi -
Clem Cole -
Dave Horsfall -
Grant Taylor -
Larry McVoy -
Tomasz Rola