Communications in store-and-forward mode, UUCP
Now in the world of the Internet, the overwhelming number of all services operate online: that is, a permanent connection to the Internet and servers. If the HTTP, FTP or IRC server is unavailable, then you will immediately be notified of this immediately. It is not always possible to have the luxury of permanent online. Sometimes it's expensive, sometimes it's just technically impossible. There is a danger that the Great Russian Firewall will appear that will only allow whitelist access to resources and the availability of a “full-fledged” Internet, at best, will be only from place to place. The mode of operation in which data to be sent are saved and wait until a link appears called store-and-forward. It is this mode that conveniently allows you to work in non-permanent online conditions.
Of the common services, only email (SMTP) has something like this: you send a message and it remains on the server until it can connect to the receiving server and get a successful response code. And so on throughout the chain until the letter reaches the addressee. You can also transfer files by mail, but it is extremely inefficient due to Base64 encoding. By setting 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 tight 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 rate of forwarding attempts. If you have five minutes of network availability, it’s 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 soon be deleted.
The FidoNet network works completely in this mode. A person, for example, connects to a higher node a couple of times a day and receives a stack of letters, sends his accumulated data. It then reads and responds to received messages offline. Should FTN (FidoNet Technology Network) technology be revived and used 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 technologies. UUCP is well integrated with existing technologies.
UUCP allows you to 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 of communication between UNIX systems, long before the widespread use of the Internet.
Using modern definitions, UUCP is a F2F (friend-to-friend) network. You are clearly registering with your own hands and setting up all of your relationships with "friends." Moreover, you explicitly control message routing. Yes, it is more responsibility and effort, but it is a good protection against possible DoS attacks, from centralized servers that can apply censorship. F2F networks self-regulate: intruders and people with bad behavior are simply thrown out of the network, as happened in FidoNet. It works quite well and it has already shown in practice that the network can have global dimensions, and not just a handful of amateurs.
However, UUCP has support for unknown, anonymous users. That is, to make a publicly accessible server available for distribution of files, or even with the ability to upload them, perhaps out of the box.
UUCP does not offer anything related to cryptography. In the current reality, when there are already very few people who have modems, like telephone lines, it is already necessary to use cryptography to at least authenticate the nodes. Fortunately, you are free to do it as you prefer. If you can still close your eyes for physically isolated air-gapped, Sneakernet / FloppyNet or LAN-connected systems, then you can quickly pick up a stunnel, SSH, VPN or something similar for communication via public communication channels. Raising UUCP as a hidden service Tor or I2P becomes trivial.
Let us show how simple the UUCP configuration is by the example of communication between two computers 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 task "tcp" port, login / password for access, name of UUCP node. If we want to call SSH instead of a direct TCP connection, then it suffices to describe the new “port”:
If we want to connect to the COM port, but if it is not available, try TCP, then we will create another port and specify an alternative configuration for the system (there may be many alternatives):
At the same time, for the serial connection, we indicated to use the “g” protocol (used for unreliable communication channels, independently checks the integrity and sends the data), and for TCP, which is already a reliable communication channel, the “t” protocol.
With this configuration, we can already send a file with beta to alpha:
By default, in UUCP "~ /" is not the user's home directory, but a public area for everyone, an analogue of the "pub" directory in FTP. On my system, this is the / var / spool / uucppublic / directory. In the sys file, you can specify for each system in which directories you can send files or from which files to request them. In the same way, alpha can send a file, but it will be transmitted only when beta connects. There is a convenient utility uuto which can send a file to a given user on a given system:
And on a remote system, a 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 to the beta, then you obviously need to specify the file’s route:
UUCP allows you to send a task to execute commands on a remote system:
On the receiving system, a separate uuxqt daemon is involved in running commands that are received in this way. In the sys file, you can control which commands are allowed to run for a particular system:
In this case, only the rmail and wget.sh commands can be executed. wget.sh is an example of a self-written simple script that downloads a web page and, via UUCP, sends it in a compressed, encrypted form with minimal priority:
The e-mail is sent exactly as the uux command 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 from the Internet to the UUCP remote server, this is sufficient (this is also described here ):
To send mail from the local machine through the UUCP gateway, then, in addition to uncommenting the uucp / uux lines in the master.cf, it suffices to add to main.cf:
UUCP support in Exim and sendmail is similarly easy to configure .
Thus, we can easily get in all modern free operating systems convenient work in conditions of non-permanent connectedness of computers among themselves. You can efficiently (without the overhead of Base64 for example) transfer files and exchange e-mail with little or no body movements. In addition, performing a batch of (remote) commands is much easier than creating services managed via email.
Of the common services, only email (SMTP) has something like this: you send a message and it remains on the server until it can connect to the receiving server and get a successful response code. And so on throughout the chain until the letter reaches the addressee. You can also transfer files by mail, but it is extremely inefficient due to Base64 encoding. By setting 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 tight 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 rate of forwarding attempts. If you have five minutes of network availability, it’s 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 soon be deleted.
The FidoNet network works completely in this mode. A person, for example, connects to a higher node a couple of times a day and receives a stack of letters, sends his accumulated data. It then reads and responds to received messages offline. Should FTN (FidoNet Technology Network) technology be revived and used 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 technologies. UUCP is well integrated with existing technologies.
UUCP allows you to 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 of 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 to UUCP: for you it is always a successful return code. If in mail clients you can still save messages in drafts, then there is no similar functionality for messages from the cron daemon or git-send-email. This greatly simplifies the software.
- All participants in the network do not have a clearly defined behavior pattern: you can receive mail or files in polling mode (when you independently interrogate the remote system from time to time), you can make an explicit push. Thus, you do as you prefer and more efficiently in your operating conditions. You will be able to connect the two systems behind NAT through an intermediate node, without using any additional protocols or software services.
- The same protocol is used for receiving and sending 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 with poor or slow or short-lived communication channels.
- There is support for traffic prioritization: at the time of sending messages, you can indicate their importance (grade). So you can guarantee that a heavy large file will not interfere with the passage of small mail messages or remote commands.
- The protocol runs on top of any connections transmitting a two-way stream of bytes. This may be a serial COM port, modem, TCP, stdin / stdout of the running program. The presence of the 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 in all free operating systems. The de facto GNU Taylor UUCP implementation is used. It has not developed for many years - because there is simply nothing to finish 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. The 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 a F2F (friend-to-friend) network. You are clearly registering with your own hands and setting up all of your relationships with "friends." Moreover, you explicitly control message routing. Yes, it is more responsibility and effort, but it is a good protection against possible DoS attacks, from centralized servers that can apply censorship. F2F networks self-regulate: intruders and people with bad behavior are simply thrown out of the network, as happened in FidoNet. It works quite well and it has already shown in practice that the network can have global dimensions, and not just a handful of amateurs.
However, UUCP has support for unknown, anonymous users. That is, to make a publicly accessible server available for distribution of files, or even with the ability to upload them, perhaps out of the box.
UUCP does not offer anything related to cryptography. In the current reality, when there are already very few people who have modems, like telephone lines, it is already necessary to use cryptography to at least authenticate the nodes. Fortunately, you are free to do it as you prefer. If you can still close your eyes for physically isolated air-gapped, Sneakernet / FloppyNet or LAN-connected systems, then you can quickly pick up a stunnel, SSH, VPN or something similar for communication via public communication channels. Raising UUCP as a hidden service Tor or I2P becomes trivial.
Let us show how simple the UUCP configuration is by the example of communication between two computers 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 task "tcp" port, login / password for access, name of UUCP node. If we want to call SSH instead of a direct TCP connection, then it suffices to 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 to the COM port, but if it is not available, try TCP, then we will create another port and specify an alternative configuration for the system (there may 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 the serial connection, we indicated to use the “g” protocol (used for unreliable communication channels, independently checks the integrity and sends the data), and for TCP, which is already a reliable communication channel, the “t” protocol.
With this configuration, we can already send a file with 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 analogue of the "pub" directory in FTP. On my system, this is the / var / spool / uucppublic / directory. In the sys file, you can specify for each system in which directories you can send files or from which files to request them. In the same way, alpha can send a file, but it will be transmitted only when beta connects. There is a convenient utility uuto which can send a file to a given user on a given system:
% uuto myfile.txt remote! username
And on a remote system, a 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 to the beta, then you obviously need to specify the file’s route:
% 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 is involved in running commands that are received in this way. In the sys file, you can control which commands are allowed to run for a particular system:
% grep commands / usr / local / etc / uucp / sys commands rmail /home/uucp/wget.sh
In this case, only the rmail and wget.sh commands can be executed. wget.sh is an example of a self-written simple script that downloads a web page and, via UUCP, sends it in a compressed, encrypted form 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'
The e-mail is sent exactly as the uux command 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 from the Internet to the UUCP remote server, this is sufficient (this is also described here ):
- uncomment the lines with uucp / uux in master.cf
- add UUCP domain to relay_domains / relay_domains
- specify in transport how to relay domain:
% cat / usr / local / etc / postfix / transport cypherpunks.ru uucp: sgtp cryptoparty.ru uucp: sgtp
Here it can be seen for the cypherpunks.ru/cryptoparty.ru domains, the mail must be sent via UUCP to the “sgtp” node.
To send mail from the local machine through the UUCP gateway, then, in addition to uncommenting the uucp / uux lines in the master.cf, it suffices to 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 in all modern free operating systems convenient work in conditions of non-permanent connectedness of computers among themselves. You can efficiently (without the overhead of Base64 for example) transfer files and exchange e-mail with little or no body movements. In addition, performing a batch of (remote) commands is much easier than creating services managed via email.
Source: https://habr.com/ru/post/282493/
All Articles