Store-and-forward communications, UUCP
Now in the world of the Internet, the predominant number of all services operate online: that is, a permanent connection to the Internet and servers. If an HTTP, FTP or IRC server is unavailable, then you will be explicitly informed about this immediately. It is not always possible to have such a luxury as permanent online. Sometimes it’s expensive, sometimes it’s just technically impossible. There is a danger that the Great Russian Firewall will appear which will allow only whitelist access to resources and the availability of a “full-fledged" Internet, at best, will only be from place to place. An operating mode in which data for sending is stored and waiting until a connection appears called store-and-forward. It is this mode that conveniently allows you to work in conditions of unstable online.
Of the widespread services, only email (SMTP) has something similar to this: you send a message and it is stored on the server until it can connect to the receiving server and receive a successful response code. And so throughout the chain until the letter reaches the addressee. Files can also be transferred by mail, but it is extremely inefficient due to Base64 encoding. Having set up the mail server in advance, you can send messages to special addresses in which there will be commands for execution - that is, remote execution of commands that do not require interactive intervention and guaranteed tough deadlines.
However, SMTP servers are still designed for a more or less permanent presence on the network. If remote servers are unavailable, it will reduce the frequency of forwarding attempts. If you have five minutes of network availability, it is not a fact that at this time the SMTP server will try to try again. As a rule, in a few days he will remind you that the message still cannot be delivered and will be deleted soon.
Fully in this mode, the FidoNet network works. A person, for example, connects to a higher node a couple of times a day and receives a packet of letters, sends his accumulated one. Then it reads offline and responds to received messages. Is it worth reviving FTN (FidoNet Technology Network) technology and using it again? Personally, I think not: FTN was created by amateurs for home computers. I would say that FTN is UUCP (UNIX-to-UNIX CoPy) for the "poor", for those who do not have UNIX-like operating systems. In addition, all FTN software stands apart from Internet technology. UUCP integrates well with existing technologies.
UUCP can conveniently solve the problem of creating store-and-forward services. It was very popular in the 70s and 80s and was the de facto standard for communication between UNIX systems, long before the widespread use of the Internet.
Using modern definitions, UUCP is an F2F (friend-to-friend) network. You are clearly prescribing and setting up all your relationships with “friends” yourself. Moreover, you explicitly control message routing. Yes, it’s a lot of responsibility and labor, but it’s a good defense against possible DoS attacks, from centralized servers that can use censorship. F2F networks are self-regulating: attackers and people with bad behavior will simply be kicked out of the network, as happened in FidoNet. This works quite well, and in practice it has already shown that the network can have a global scale, and not just be with a handful of fans.
However, UUCP also has support for unknown, anonymous users. That is, to make a public server accessible to everyone to distribute files, or even with the ability to upload them, perhaps out of the box.
UUCP does not offer anything related to cryptography. In current realities, when few people have modems, like telephone lines, it is already necessary to use cryptography, at least for authentication of nodes. Fortunately, you are free to do it as you prefer. If for physically isolated air-gapped, Sneakernet / FloppyNet or LAN-connected systems this can still be ignored, then for communication via public communication channels you can quickly raise stunnel, SSH, VPN or something like that. Raising UUCP as a hidden Tor or I2P service becomes trivial.
Let us show how simple the UUCP configuration is by the example of two computers connecting via the Internet. One does not make any outgoing connections (let's call it alpha), unlike the second (let's call it beta).
This is the whole configuration. We have tasks “tcp” port, login / password for access, names of UUCP nodes. If we want to call SSH instead of a direct TCP connection, then just describe the new “port”:
If we want to connect via the COM port, but if TCP is unavailable, we will create another port and indicate an alternative configuration for the system (there can be many alternatives):
At the same time, for a serial connection, we indicated to use the “g” protocol (used for unreliable communication channels, independently checks the integrity and sends data), and for TCP, which is already a reliable communication channel, the “t” protocol.
With this configuration, we can already send the file from beta to alpha:
By default in UUCP "~ /" is not the user's home directory, but a public area for everyone, an analog of the "pub" directory in FTP. On my system, this is the directory / var / spool / uucppublic /. In the sys file, you can specify for each system in which directories you can send files or from which to request them. In the same way, alpha can send a file, but it will only be transmitted when beta connects. There is a convenient uuto utility that can send a file to a given user on a given system:
And on a remote remote system, the user can call uupick which will show him a list of all the files sent to him and allow, for example, to move them to the specified directory.
If you need to send a file to a gamma system that has a connection with beta, then you must explicitly indicate the route of the file:
UUCP allows you to send a task to execute commands on a remote system:
On the receiving system, a separate uuxqt daemon starts the commands received in this way. In the sys file you can control which commands are allowed to run on a particular system:
In this case, you can only run the rmail and wget.sh commands. wget.sh is an example of a self-written simple script that downloads a Web page and sends it in compressed encrypted form with UUCP with minimal priority:
E-mail is sent just like the uux command that calls the rmail utility, which, in fact, communicates with the local sendmail server and sends the message body to it. For example, in order for Postfix to be able to send mail received from the Internet to a UUCP remote server, it is enough (this is also described here ):
To send mail from the local machine through the UUCP gateway, in addition to uncommenting the uucp / uux lines in master.cf, just add to main.cf:
UUCP support in Exim and sendmail is similarly easy to configure .
Thus, we can easily get convenient work in all modern free operating systems in the conditions of unstable interconnection of computers among themselves. You can efficiently (without the overhead on Base64 for example) transfer files and exchange e-mail with virtually no unnecessary gestures. In addition, executing a batch of remote commands is much easier than through the creation of services managed via email.
Of the widespread services, only email (SMTP) has something similar to this: you send a message and it is stored on the server until it can connect to the receiving server and receive a successful response code. And so throughout the chain until the letter reaches the addressee. Files can also be transferred by mail, but it is extremely inefficient due to Base64 encoding. Having set up the mail server in advance, you can send messages to special addresses in which there will be commands for execution - that is, remote execution of commands that do not require interactive intervention and guaranteed tough deadlines.
However, SMTP servers are still designed for a more or less permanent presence on the network. If remote servers are unavailable, it will reduce the frequency of forwarding attempts. If you have five minutes of network availability, it is not a fact that at this time the SMTP server will try to try again. As a rule, in a few days he will remind you that the message still cannot be delivered and will be deleted soon.
Fully in this mode, the FidoNet network works. A person, for example, connects to a higher node a couple of times a day and receives a packet of letters, sends his accumulated one. Then it reads offline and responds to received messages. Is it worth reviving FTN (FidoNet Technology Network) technology and using it again? Personally, I think not: FTN was created by amateurs for home computers. I would say that FTN is UUCP (UNIX-to-UNIX CoPy) for the "poor", for those who do not have UNIX-like operating systems. In addition, all FTN software stands apart from Internet technology. UUCP integrates well with existing technologies.
UUCP can conveniently solve the problem of creating store-and-forward services. It was very popular in the 70s and 80s and was the de facto standard for communication between UNIX systems, long before the widespread use of the Internet.
- The behavior of the system, whether it is connected to the network, or being offline - is not distinguishable. If you send a file or email via UUCP: this is always a successful return code for you. If you can still save messages in draft messages in mail clients, then there is no similar functionality for messages from the cron daemon or git-send-email. This greatly simplifies the software.
- All network participants do not have a clearly defined behavior model: you can receive mail or files in polling mode (when you yourself occasionally interrogate a remote system), you can make an explicit push. Thus, you make it more convenient and efficient for you in your operating conditions. You will be able to connect the two systems located behind the NAT th through an intermediate node, without using any additional protocols or software services.
- The same protocol is used to receive and send letters and files - there is no separation, for example, into SMTP and POP3. Moreover, the reception and sending of data occur in parallel within the same communication channel, which increases its efficiency of use.
- UUCP allows you to continue dangling data transfer, not to start from scratch. This is invaluable for poor or slow or short-lived communication channels.
- There is support for prioritizing traffic: at the time of sending messages you can indicate their importance (grade). This way you can guarantee that a heavy large file will not interfere with the passage of small mail messages or remote commands.
- The protocol works on top of any connections that transmit a two-way byte stream. It can be a serial COM port, modem, TCP, stdin / stdout of the running program. The presence of an IP protocol does not matter.
- Unlike Internet e-mail, there are no restrictions associated with 7-bit communication channels. You can transfer binary files without additional Base64 / whatever conversions, which significantly saves traffic.
- UUCP is available on all free operating systems. The de facto used GNU Taylor UUCP implementation. It has not been developing for many years - because there is simply nothing to complete in it, it works.
- All popular Internet mail servers such as sendmail, Exim and Postfix out of the box have the ability to integrate with UUCP. Utilities themselves have a classic UNIX way approach: do one small thing, but do it well. Unlike FTN networks, you can transparently link UUCP and Internet resources together.
Using modern definitions, UUCP is an F2F (friend-to-friend) network. You are clearly prescribing and setting up all your relationships with “friends” yourself. Moreover, you explicitly control message routing. Yes, it’s a lot of responsibility and labor, but it’s a good defense against possible DoS attacks, from centralized servers that can use censorship. F2F networks are self-regulating: attackers and people with bad behavior will simply be kicked out of the network, as happened in FidoNet. This works quite well, and in practice it has already shown that the network can have a global scale, and not just be with a handful of fans.
However, UUCP also has support for unknown, anonymous users. That is, to make a public server accessible to everyone to distribute files, or even with the ability to upload them, perhaps out of the box.
UUCP does not offer anything related to cryptography. In current realities, when few people have modems, like telephone lines, it is already necessary to use cryptography, at least for authentication of nodes. Fortunately, you are free to do it as you prefer. If for physically isolated air-gapped, Sneakernet / FloppyNet or LAN-connected systems this can still be ignored, then for communication via public communication channels you can quickly raise stunnel, SSH, VPN or something like that. Raising UUCP as a hidden Tor or I2P service becomes trivial.
Let us show how simple the UUCP configuration is by the example of two computers connecting via the Internet. One does not make any outgoing connections (let's call it alpha), unlike the second (let's call it beta).
alpha% cat / usr / local / etc / uucp / config nodename alpha alpha% cat / usr / local / etc / uucp / passwd betalogin betapassword alpha% cat / usr / local / etc / uucp / sys system beta called-login betalogin ------------------------> 8 ------------------------ beta% cat / usr / local / etc / uucp / config nodename beta beta% cat / usr / local / etc / uucp / call alpha betalogin betapassword beta% cat / usr / local / etc / uucp / port port tcp type tcp beta% cat / usr / local / etc / uucp / sys call-login * call-password * time any system alpha port tcp address alpha.com
This is the whole configuration. We have tasks “tcp” port, login / password for access, names of UUCP nodes. If we want to call SSH instead of a direct TCP connection, then just describe the new “port”:
beta% cat / usr / local / etc / uucp / port port ssh type pipe command ssh -o batchmode = yes alpha.com
If we want to connect via the COM port, but if TCP is unavailable, we will create another port and indicate an alternative configuration for the system (there can be many alternatives):
beta% cat / usr / local / etc / uucp / port port tcp type tcp port serial type direct device / dev / cuaU0 speed 115200 beta% cat / usr / local / etc / uucp / sys call-login * call-password * time any system alpha port serial protocol g alternate port tcp address alpha.com protocol t
At the same time, for a serial connection, we indicated to use the “g” protocol (used for unreliable communication channels, independently checks the integrity and sends data), and for TCP, which is already a reliable communication channel, the “t” protocol.
With this configuration, we can already send the file from beta to alpha:
beta% uucp myfile.txt alpha! ~ / myfile.txt
By default in UUCP "~ /" is not the user's home directory, but a public area for everyone, an analog of the "pub" directory in FTP. On my system, this is the directory / var / spool / uucppublic /. In the sys file, you can specify for each system in which directories you can send files or from which to request them. In the same way, alpha can send a file, but it will only be transmitted when beta connects. There is a convenient uuto utility that can send a file to a given user on a given system:
% uuto myfile.txt remote! username
And on a remote remote system, the user can call uupick which will show him a list of all the files sent to him and allow, for example, to move them to the specified directory.
If you need to send a file to a gamma system that has a connection with beta, then you must explicitly indicate the route of the file:
% uucp myfile.txt beta! gamma! ~ / myfile.txt
UUCP allows you to send a task to execute commands on a remote system:
% uux "remote! service nginx restart" % uux "remote! zfs snap zroot @ backup"
On the receiving system, a separate uuxqt daemon starts the commands received in this way. In the sys file you can control which commands are allowed to run on a particular system:
% grep commands / usr / local / etc / uucp / sys commands rmail /home/uucp/wget.sh
In this case, you can only run the rmail and wget.sh commands. wget.sh is an example of a self-written simple script that downloads a Web page and sends it in compressed encrypted form with UUCP with minimal priority:
#! / bin / sh -e
WORKDIR = / home / uucp / wget_dir
name = "$ 1"
url = "$ 2"
wget --output-document - "$ url" | xz -9 | gpg \
--homedir /home/uucp/.gnupg --compress-level 0 --encrypt \
--recipient 0xHIDDEN> $ WORKDIR / "$ name" .xz.gpg
uuto --grade 9 $ WORKDIR / "$ name" .xz.gpg 'sgtp! vpupkin'
E-mail is sent just like the uux command that calls the rmail utility, which, in fact, communicates with the local sendmail server and sends the message body to it. For example, in order for Postfix to be able to send mail received from the Internet to a UUCP remote server, it is enough (this is also described here ):
- uncomment lines with uucp / uux in master.cf
- add UUCP domain to relay_domains / relay_domains
- specify in transport how to relay to the domain:
% cat / usr / local / etc / postfix / transport cypherpunks.ru uucp: sgtp cryptoparty.ru uucp: sgtp
Here you can see for cypherpunks.ru/cryptoparty.ru domains mail should be sent via UUCP to the “sgtp” node.
To send mail from the local machine through the UUCP gateway, in addition to uncommenting the uucp / uux lines in master.cf, just add to main.cf:
default_transport = uucp: uucp-gateway
UUCP support in Exim and sendmail is similarly easy to configure .
Thus, we can easily get convenient work in all modern free operating systems in the conditions of unstable interconnection of computers among themselves. You can efficiently (without the overhead on Base64 for example) transfer files and exchange e-mail with virtually no unnecessary gestures. In addition, executing a batch of remote commands is much easier than through the creation of services managed via email.
