Сейчас в мире Интернета преобладающее количество всех служб работают в режиме online: то есть постоянное соединение с Интернетом и серверами. Если HTTP, FTP или IRC сервер недоступен, то вам об этом сразу же явно сообщат. Не всегда есть возможность иметь такую роскошь как постоянный online. Иногда это дорого, иногда просто технически невозможно. Есть опасность что появится Великий Российский Firewall который будет разрешать только whitelist доступ к ресурсам и доступность «полноценного» Интернета, в лучшем случае, будет только от места к месту. Режим работы при котором данные для отправки сохраняются и ожидают пока появится связь называется store-and-forward. Именно этот режим удобно позволяет работать в условиях непостоянного online.



Из широкораспространённых сервисов только email (SMTP) имеет что-то похожее на это: вы отправляете сообщение и оно сохраняется на сервере до тех пор, пока он не сможет соединиться с принимающим сервером и получить успешный код ответа. И так по всей цепочки пока письмо не дойдёт до адресата. По почте можно передавать и файлы, но крайне неэффективно из-за Base64 кодирования. Заранее настроив почтовый сервер, можно отправлять на специальные адреса сообщения в которых будут команды для выполнения — то есть удалённое выполнение команд не требующих интерактивного вмешательства и гарантированных жёстких сроков выполнения.

Однако SMTP серверы всё же рассчитаны на более-менее постоянное присутствие в сети. При недоступности удалённых серверов он будет уменьшать частоту попыток пересылки. Если у вас появилось пять минут доступности сети, то не факт что в это время SMTP сервер попробует повторить попытку. Как правило, через несколько дней он напомнит о том что сообщение до сих пор не может быть доставлено и вскоре будет удалено.

Полностью в таком режиме работает сеть FidoNet. Человек, например, пару раз в день подключается к вышестоящей ноде и получает пачку писем, отправляет свою накопившуюся. Затем в offline режиме читает и отвечает на полученные сообщения. Стоит ли возрождать FTN (FidoNet Technology Network) технологии и снова их использовать? Лично я считаю что нет: FTN создавалась любителями для домашних компьютеров. Я бы сказал что FTN это UUCP (UNIX-to-UNIX CoPy) для «бедных», для тех у кого нет UNIX-like операционных систем. Кроме того, весь FTN софт стоит особняком от Интернет технологий. UUCP же хорошо интегрируется с существующими технологиями.

UUCP позволяет удобно разрешить проблему создания store-and-forward сервисов. Он был очень популярен в 70-х и 80-х годах и был де-факто стандартом связи между UNIX системами, задолго до широкого распространения Интернета.

• Поведение системы, находись она подключённой к сети, или находясь в offline — не отличимо. Если вы отправляете файл или почтовое сообщение по UUCP: для вас это всегда успешный код возврата. Если в почтовых клиентах вы ещё можете сохранить сообщения в черновиках, то подобного функционала для сообщений от cron демона или git-send-email нет. Это значительно упрощает ПО.
• У всех участников сети нет чётко заданной модели поведения: вы можете принимать почту или файлы в режиме polling (когда самостоятельно время от времени опрашиваете удалённую систему), можете сделать явный push. Тем самым, вы делаете как вам удобнее и эффективнее в ваших условиях эксплуатации. Вы в состоянии будете связать две системы находящиеся за NAT-ом через промежуточный узел, без использования каких-либо дополнительных протоколов или программных служб.
• Для приёма и отсылки писем и файлов используется один и тот же протокол — нет разделения, например, на SMTP и POP3. Более того, приём и отправка данных происходят параллельно в пределах одного канала связи, что повышает его эффективность использования.
• UUCP позволяет продолжить оборванную передачу данных, не начинать с нуля. Это бесценно при плохих или медленных или короткоживущих каналах связи.
• Есть поддержка приоритезации трафика: в момент отправки сообщений вы можете указать их важность (grade). Так можно гарантировать что тяжёлый большой файл не будет мешать прохождению небольших почтовых сообщений или удалённых команд.
• Протокол работает поверх любых соединений передающих двусторонний поток байт. Это может быть последовательный COM-порт, модем, TCP, stdin/stdout запущенной программы. Наличие IP протокола не имеет значения.
• В отличии от электронной почты Интернета, нет ограничений связанных с 7-битными каналами связи. Вы можете передавать бинарные файлы без дополнительных Base64/whatever преобразований, что существенно экономит трафик.
• UUCP доступен во всех свободных операционных системах. Де-факто используется GNU Taylor UUCP реализация. Она уже много лет не развивается — потому-что в ней просто нечего доделывать, она работает.
• Все популярные почтовые серверы Интернета типа sendmail, Exim и Postfix из коробки имеют возможность интеграции с UUCP. Сами по себе утилиты имеют классический UNIX way подход: делай одну небольшую вещь, но делай её хорошо. В отличии от FTN сетей, вы можете прозрачно связывать UUCP и Интернет ресурсы воедино.

Используя современные определения, UUCP является F2F (friend-to-friend) сетью. Вы явно руками самостоятельно прописываете и настраиваете все ваши взаимосвязи с «друзьями». Более того, вы явно управляете маршрутизацией сообщений. Да, это бОльшая ответственность и трудозатраты, но зато хорошая защита от возможных DoS атак, от централизованных серверов которые могут применять цензуру. F2F сети саморегулируются: злоумышленников и людей с плохим поведением из сети просто выкинут, как это происходило в FidoNet. Это работает достаточно хорошо и это на практике уже показало что сеть может иметь глобальные масштабы, а не только быть у кучки любителей.

Однако в UUCP есть и поддержка неизвестных (unknown), анонимных пользователей. То есть сделать публичный всем доступный сервер для раздачи файлов, или даже с возможностью их закачивания, возможно из коробки.

UUCP не предлагает ничего связанного с криптографией. В текущих реалиях, когда модемы уже мало у кого есть, как и телефонные линии, использовать криптографию хотя бы для аутентификации нод уже необходимо. Благо вы вольны делать это как вам удобнее. Если для физически изолированных air-gapped, Sneakernet/FloppyNet или соединённым по ЛВС систем на это ещё можно закрыть глаза, то для связи по публичным каналам связи можно быстро поднять stunnel, SSH, VPN или что-то подобное. Поднять UUCP в виде скрытого сервиса Tor или I2P становится тривиально.

Покажем насколько проста конфигурация UUCP на примере связи двух компьютер через Интернет. Один не делает никаких исходящих соединений (назовём его alpha), в отличии от второго (назовём его 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

Это вся конфигурация. Мы задачи порт «tcp», логин/пароль для доступа, названия UUCP нод. Если мы хотим вызывать SSH вместо прямого TCP соединения, то достаточно описать новый «порт»:

beta% cat /usr/local/etc/uucp/port
port ssh
type pipe
command ssh -o batchmode=yes alpha.com

Если мы хотим соединяться по COM-порту, но при его недоступности попытаться TCP, то создадим ещё один порт и укажем альтернативную конфигурацию для системы (альтернатив может быть много):

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

При этом, для последовательного соединения мы указали использовать протокол «g» (используется для ненадёжных каналов связи, самостоятельно проверяет целостность и перепосылает данные), а для TCP, который уже является надёжным каналом связи, протокол «t».

При такой конфигурации мы уже можем послать файл с beta на alpha:

beta% uucp myfile.txt alpha!~/myfile.txt

По-умолчанию в UUCP "~/" это не домашняя директория пользователя, а публичная область для всех, аналог «pub» директории в FTP. В моей системе это директория /var/spool/uucppublic/. В sys файле вы можете для каждой системы указать в какие директории можно посылать файлы или из каких их запрашивать. Таким же образом и alpha может послать файл, но он будет передан только когда beta подсоединится. Есть удобная утилита uuto которая может отправить файл заданному пользователю на заданную систему:

% uuto myfile.txt remote!username

А на удалённой remote системе пользователь может вызвать uupick которая ему покажет список всех отосланных ему файлов и позволит, например, их переместить в указанную директорию.

Если вам надо отправить файл на gamma систему, имеющую связь с beta, то вы явно должны указать маршрут следования файла:

% uucp myfile.txt beta!gamma!~/myfile.txt

UUCP позволяет посылать задание на выполнение команд на удалённой системе:

% uux "remote!service nginx restart"
% uux "remote!zfs snap zroot@backup"

На принимающей системе отдельный uuxqt демон занимается запуском принимаемых таким образом команд. В sys файле вы можете управлять тем, какие команды разрешено запускать той или иной системе:

% grep commands /usr/local/etc/uucp/sys
commands rmail /home/uucp/wget.sh

В данном случае можно выполнять только команду rmail и wget.sh. wget.sh это пример самописного простого скрипта который скачает Web-страницу и через UUCP отправит её в сжатом зашифрованном виде с минимальным приоритетом:

#!/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'

Электронная почта отправляется именно как uux команда вызывающая rmail утилиту которая, фактически, связывается с локальным sendmail сервером и посылает тело сообщения в него. Например, для того чтобы Postfix смог отсылать принимаемую из Интернета почту на UUCP удалённый сервер, то достаточно (также это описано здесь):

• раскомментировать строчки с uucp/uux в master.cf
• добавить UUCP домен в relay_domains/relay_domains
• указать в transport как производить relay на домен:
  

  % cat /usr/local/etc/postfix/transport
  cypherpunks.ru uucp:sgtp
  cryptoparty.ru uucp:sgtp
  

  
  Тут видно для доменов cypherpunks.ru/cryptoparty.ru почту нужно слать через UUCP на «sgtp» ноду.
  

Чтобы отсылать почту с локальной машины через UUCP шлюз, то кроме раскомментирования uucp/uux строк в master.cf, достаточно добавить в main.cf:

default_transport = uucp:uucp-gateway

Поддержка UUCP в Exim и sendmail аналогично просто настраивается.

Таким образом, мы легко можем получить во всех современных свободных операционных системах удобную работу в условиях непостоянной связанности компьютеров между собой. Можно эффективно (без накладных расходов на Base64 например) передавать файлы и обмениваться электронной почтой практически без лишних телодвижений. Кроме того, выполнять пачкой (batch) удалённые команды куда проще чем через создание сервисов управляемых через email.