Setting up and using UUCP (with analog modems)

Question

These days, of course, we have the Internet, but back in the day, there was Unix to Unix Copy - UUCP. In its heyday it was a terrific way to get email and other simple data moving across the world, through complex routes at time, to their destinations.

These days it's hard to justify using it for practical purposes, but for nostalgic reasons, I'd like to experiment with it, and it's still present in at least some modern Linux distributions, so it seems like it's perfectly possible. I suspect there are Internet transports available for it (which are probably off topic for here, and that's okay) but I'm particularly interested in doing UUCP as it was done in the day - with actual modems. (If necessary, I can experiment using a little inexpensive PBX system and keep it off real phone lines.)

I know there was a retro UUCP project at one point where hobbyists could exchange data using the protocol, but I can't seem to find it online so I think it's disappeared.

What's involved with installing it and testing it? How difficult would it be to deploy?

Answer 1

I certainly used UUCP back in the day, for what most folks used it for back then: email and USENET. UUCP itself is mostly straightforward, albeit a bit cryptic, as was everything back then. But it's certainly something I'd file under "be amazed it worked at all".

Point to point, UUCP is pretty basic. The craziness is the whole routing side.

With the Internet, routing is buried deep in the system. The vast majority of users are unaware of it, even at a basic level.

With UUCP it was a first class concept. The whole point of the bang path was to describe not just where to go, how!to!get!there. Mind, this wasn't the absolute case. There was the idea of "well known hosts" where you could forward stuff (notably email) and it would find its way to its eventual destination, we used UUNET for that back then. There was this whole mess of processes of folks publishing public routing data. At the time, it was less about complaining about the warts of the system compared to simply praising that it worked at all!

From a practical point of view, I had my own little USENET/email node tied up via a 2400 baud Hayes Smartmodem to A Guy who I think hooked up through UCLA. At the office, we used UUNET and we also set up our clients directly from our machines. UUNET was pretty much exclusively mail and news.

For the office, we struggled getting UUCP to be seamless. We used it to move software over for installation on client system. It mostly worked, it sorta worked, but wasn't necessarily reliable for us. Or, we were just impatient. When we wanted to send a file, we typically wanted it "now", not "later", so not really wanting to wait for the retry timeouts to come around and have another go at it. All fine when things are working great, but when something goes awry, it's all timeouts and queues and other annoying "not right now" things. Our backup was typically shoving stuff over Kermit directly.

I would have like to have been able to leverage the uuxqt (I think it was) capability of running remote scripts, that way we could have done remote installs and such.

Ubiquitous connectivity pretty much spelled the demise of UUCP. Even with modems today, you're likely better off lighting up a SLIP or PPP connection and then just using normal TCP/IP protocols.

But, that said, TCP/IP is still pretty heavy weight in comparison to a simple file transfer using a reliable protocol. UUCP didn't any of the common protocols of the day (X/Y/ZMODEM, Kermit, etc.). It COULD, it just didn't. You could extend it today to do it if you were so motivated. So, if you had a modem on an TCP/IP-less micro-controller, UUCP could certainly be leveraged to get data in and out of a network of such machines.

All that said, I can see an interesting use case for it, even today.

Notably, because we have a lot of layering in our modern network systems. For example, you have a simple network: A <-> B <-> C. A can connect to B, and B to C, but not A to C.

So you can see a contrived case where, using an IP based transfer mechanism, you can have someone uucp from A to b!c, A connects to B, moves the data, then, later, B connects to C (or vice-a-versa) and finishes the job. This makes the transfer an ostensibly "single step" process for the person on A, while the UUCP process manages the hurdling of firewalls an what not.

Now would someone use UUCP for that, vs, say, rsync via cron, or something else? Eh, who knows. But, that may more simply be unfamiliarity with the process more so than inappropriateness. If we have anything today, it's a 100 and 1 different ways to move data.

Answer 2

What's involved with installing it and testing it?

How difficult would it be to deploy?

On Debian: apt-get install uucp and there are related packages uucp-lmtp (lets you send using UUCP via local SMTP server) and uucpsend (I suppose that is for sending files).

UUCP wants to contact systems (and receive contact) through a serial port that doesn't have PPP running, optionally by dialing first - dialing is accomplished by sending AT style commands through the serial port. These are in a dial file.

Each UUCP involved system needs a getty running on the serial port for UUCP to log in and its login shell must be /bin/uucico. You will need to fiddle with inittab or systemd configuration if the uucp installer doesn't do this automatically.

For testing, you can:

• connect 2 systems with a serial port via null modem cable and use a blank dial file (no modem = no dialing needed) I think -

• have something that looks like a serial port to uucp and converts it to TCP/IP.

  • Not sure of anything that works as a locally installed program.

  • You can use a second system connected via null-modem serial that takes incoming data from the serial port and forwards it over a socket. The receiving system will need a matching second system.

I might be wrong and UUCP might actually support TCP/IP somewhere.