one thing that fascinates me about UUCP is it's decentralized
ad-hoc, peer to peer nature. With modems and analog phone
lines being a thing of the past, what are viable options to
connect uucp nodes directly in the 21st century and what are
their requirements?
- UUCP over IP (obviously requires IP connectivity)
- GSM Network? (is anyone using this?)
- UUCP over IP (obviously requires IP connectivity)All but the very old UUCP packages I've seen (DECUS UUCP) will run over
- null modem cables (only local connections)As long as you can get a login prompt. There's a project, tty0tty. This
Hi all,
one thing that fascinates me about UUCP is it's decentralized ad-hoc,
peer to peer nature.
With modems and analog phone lines being a thing of the past, what
are viable options to connect uucp nodes directly in the 21st century
and what are their requirements?
- UUCP over IP (obviously requires IP connectivity)
- GSM Network? (is anyone using this?)
- Ham Radio? (pretty sure UUCP over Ham is a thing)
- exchanging USB sticks or similar media (good ol' sneaker net)
- null modem cables (only local connections)
The last three options would be independent of intermediate
infrastructure. Though the UUCP over IP option whould of course work
in an ad hoc mesh wireless network.
Are there other options? Any experience with any of these?
I have used UUCP over SSH over IP a few times in the past. SSH is used
as the transport for the UUCP character stream via STDIN & STDOUT. It doesn't involve any port forwarding.
What is the point of this? I mean, UUCP is/was used primarily
for remote login and to transfer files, which both are native
functionalities of SSH.
I have used UUCP over SSH over IP a few times in the past. SSH is usedWhat is the point of this? I mean, UUCP is/was used primarily for remote login and to transfer files, which both are native functionalities of SSH.
as the transport for the UUCP character stream via STDIN & STDOUT. It doesn't involve any port forwarding.
eternal@notreally.com (Juancho) writes:
I have used UUCP over SSH over IP a few times in the past. SSH is usedWhat is the point of this? I mean, UUCP is/was used primarily for remote
as the transport for the UUCP character stream via STDIN & STDOUT. It
doesn't involve any port forwarding.
login and to transfer files, which both are native functionalities of SSH.
UUCP was primarily a store-and-forward, source routed file transfer >mechanism. Some files were metadata, saying what should be done with >companion files--thus, email. Drawing a blank on remote login?
In article <173921308610.26577.4951890872054731139@media.vsta.org>,
Andy Valencia <vandys@vsta.org> wrote:
eternal@notreally.com (Juancho) writes:
UUCP was primarily a store-and-forward, source routed file transfer >>mechanism. Some files were metadata, saying what should be done with >>companion files--thus, email. Drawing a blank on remote login?I have used UUCP over SSH over IP a few times in the past. SSH is used >>> > as the transport for the UUCP character stream via STDIN & STDOUT. It >>> > doesn't involve any port forwarding.What is the point of this? I mean, UUCP is/was used primarily for remote >>> login and to transfer files, which both are native functionalities of SSH. >>
Perhaps Juancho meant remote command execution,
a la uux?
On 2025-02-11, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <173921308610.26577.4951890872054731139@media.vsta.org>,
Andy Valencia <vandys@vsta.org> wrote:
eternal@notreally.com (Juancho) writes:
UUCP was primarily a store-and-forward, source routed file transfer >>>mechanism. Some files were metadata, saying what should be done with >>>companion files--thus, email. Drawing a blank on remote login?I have used UUCP over SSH over IP a few times in the past. SSH is used >>>> > as the transport for the UUCP character stream via STDIN & STDOUT. It >>>> > doesn't involve any port forwarding.What is the point of this? I mean, UUCP is/was used primarily for remote >>>> login and to transfer files, which both are native functionalities of SSH. >>>
Perhaps Juancho meant remote command execution,
a la uux?
I was thinking about the "ct" and "cu" commands of the uucp suite.
Juancho <eternal@notreally.com> wrote:
I was thinking about the "ct" and "cu" commands of the uucp suite.
`cu` is just a serial communications program; it lets you use a
serial port and whatever that serial port is connected to;
historically it also had some syntactic sugar to connect to
systems that the administrator had put in the local UUCP
configuration. Fundamentally it only lets you execute remote
commands in so far as the thing on the other end of the serial
port you use it with lets you do that, and `cu` itself is just
the communications agent. I still occasionally use `cu` to talk
to little embedded devices and things like that. Critically,
I doubt you could do `cu thathost!thishost` and expect it to
work (what if all outgoing lines from `thishost` were busy at
the time?).
Similarly, `ct` does more or less the same thing, but assumes
that a line is connected to a modem, and knows how to dial a
phone number (back in the bad old days this was a lot more
complex than having a Hayes compatible modem that understood the
"AT" command set); in that sense, it's a little less flexible
than `cu`. But again, it's just a communications agent, not a
remote execution/login program itself.
`uux`, on the other hand, was actually designed to run commands
on some remote system: `uux seismo!me /bin/ls` or something
more involved like, `uux ucbvax!seismo!me /bin/ls` or whatever.
Still, this isn't exactly "remote login."
On 2025-02-11, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
Juancho <eternal@notreally.com> wrote:
I was thinking about the "ct" and "cu" commands of the uucp suite.
`cu` is just a serial communications program; it lets you use a
serial port and whatever that serial port is connected to;
historically it also had some syntactic sugar to connect to
systems that the administrator had put in the local UUCP
configuration. Fundamentally it only lets you execute remote
commands in so far as the thing on the other end of the serial
port you use it with lets you do that, and `cu` itself is just
the communications agent. I still occasionally use `cu` to talk
to little embedded devices and things like that. Critically,
I doubt you could do `cu thathost!thishost` and expect it to
work (what if all outgoing lines from `thishost` were busy at
the time?).
Similarly, `ct` does more or less the same thing, but assumes
that a line is connected to a modem, and knows how to dial a
phone number (back in the bad old days this was a lot more
complex than having a Hayes compatible modem that understood the
"AT" command set); in that sense, it's a little less flexible
than `cu`. But again, it's just a communications agent, not a
remote execution/login program itself.
`uux`, on the other hand, was actually designed to run commands
on some remote system: `uux seismo!me /bin/ls` or something
more involved like, `uux ucbvax!seismo!me /bin/ls` or whatever.
Still, this isn't exactly "remote login."
In other words, it was common practice, before the Internet was
mainstream, to use cu/ct to login into other UNIX systems through serial >lines and modems. Or my Xenix memories may be failing me.
I was thinking about the "ct" and "cu" commands of the uucp suite.
On 2/11/25 11:45, Juancho wrote:
I was thinking about the "ct" and "cu" commands of the uucp suite.
+1
On the systems I log into, the `cu` command comes from the UUCP package.
On 2/8/25 23:49, Juancho wrote:
What is the point of this? I mean, UUCP is/was used primarily
for remote login and to transfer files, which both are native
functionalities of SSH.
Consider you have three systems; A, B, and C, connected like this:
[A]---[B]---[C]
Now consider that A and C are separated by sufficient distance that
there isn't a network between them. Finally consider B to be a notebook
that can travel between A and C.
UUCP makes it trivial to transfer a file from A to C or vice versa even though there isn't end-to-end connectivity between A and C.
This is one of the uses for UUCP's store-and-forward networking.
Now consider using SSH to communicate between A & B to carry the UUCP
traffic and similarly between B & C.
SSH provides encrypted and authenticated transport that UUCP can ride
across.
I can send a file from A to C with one command. SSH et al can't do that because there is a lack of end-to-end communications.
The other thing that UUCP over SSH provides is asynchronous operations.
I can cause UUCP to transfer the file in very short order and move on
with things. Conversely SSH commands ten to be blocking and require
other methods to not hijack the controlling terminal.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 156:51:54 |
| Calls: | 9,700 |
| Files: | 13,732 |
| Messages: | 6,179,576 |