Для начала, вспомним некоторые базовые вещи ОС Unix.  Любой процесс в Unix имеет три открытых файла по умолчанию, (но он  может их потом закрыть/переоткрыть, например перенаправляя вывод в log file): 0 (stdin) 1 (stdout) 2 (stderr) примечание: stderr, отличается от stdout тем, что он не использует буфер для вывода. Процессы unix могут выполняться асинхронно, как параллельно, так и последовательно, например:   Разберем приведенную вязь команд по косточкам:  cmd1 & cmd2; — вначале параллельно запустятся cmd1 и cmd2 (cmd3 && cmd4) & (cmd5 || cmd6) — после завершения cmd1,параллельно запустятся условные цепочки cmd3,cmd4 и cmd5,cmd6. При этом: cmd4 запуститься если cmd3 завершиться успешно, то есть ее код возврата будет 0, cmd6, только в том случае, если cmd5 вернёт ненулевой код возврата. Мне нравится термин конвейер для таких цепочек команд. Конвейер, помимо асинхронного выполнения, может синхронизировать выполнение процессов по вводу/выводу, используя специальный тип файла: pipe, или по русски канал.Pipe — специальный тип файла, реализующий очередь FIFO (First Input, First Output) в Unix. Pipe может быть именованным или нет. Проще всего перенаправлять стандартные открытые файлы. Используя различные комбинацию конвейера и каналов, можно решить самые разные задачи администратора. Приведу примеры из собственной практики синхронизации через неименованные каналы:  Прокомментирую последний пример: Тут используется команда netcat (или nc), которая открывает сетевой канал для проброса канала tar/untar.  При копировании больших объёмов, это может дать в разы большую скорость, чем стандартное scp. Например, у меня при копировании 1500G backup database c одной VM на другую, скорость выросла в пять раз без сильной нагрузки на CPU. Понятно, что при копировании между ЦОД, нужно учитывать открытость такого трафика для перехвата. Когда команды запускаются из под одной учетной записи, и команды работают с нужной информацией через stdin/stdout, особых проблем нет. Но вот реальный пример, когда oracle imp, умеет писать dump последовательно только в файл, которые указан параметром FILE=.У вас не хватает пространства, чтобы выгрузить нужные данные, но можно сжать полученные данные используя  Named Pipe и  потоковую компрессию данных.   Как сделать imp из полученного архива, предлагаю подумать самим в качестве задания.  Разумеется, с именованными каналами, можно использовать netcat, для организации межсерверной коммуникации. ssh — универсальный инструмент администратора. В стандартной реализации ssh, существует возможность создать специальный шифрованный канал - ssh tunnel.  Пример использования ssh tunnel для проброса VNC:2 удаленного порта 5902 доступного только для 127.0.0.1 на vm2 на локальный порт 5902 машины vm1. После входа на vm2 командой:  вы можете запустить на vm1 локальный vncviwer :2 и попасть на vnc:2 на машине vm2.   Схематично это можно показать так:  Здесь через локальный порт (-L) подключались к удаленному через ssh tunnel.  Для проброса удаленного порта (-R) на пользовательский комп, поступают аналогично. Например надо подключится к домашней postgresql базе с рабочего компа подключившись из дома к рабочей машине: Здесь мы свой домашний 5432 порт пробрасываем на удаленную машину.  По проекту, потребовалось RDP подключение с рабочего notebook через VPN и цепочку hosts на windows машину. При этом, напрямую подключиться к каждой из цепочки машин невозможно, только последовательно.  В целом, подключение выглядит так : Идем стандартным путем, используем туннель + ssh jump:  Где:  -i vm1.key — файл private key пользователя user@vm1 -J (Jump), подключится к user@vm1 через  gateuser@gatehost, само подключение к gateuser@gatehost, так как постоянно работаю через него, прописано у меня в ~/.ssh/config -L 127.0.0.1:3390:win1:3389 — создание сквозного ssh tunnel между my (127.0.0.1:3390) и (win1:3389) через машину user@vm1. То есть, пробрасывается открытый на vm1 конец канала vm1:3389 — win1:3389 Все работало отлично, но в один из черных дней погибает vm1...  Сервера расположены не у нас, процедура перенастройки требует согласования и времени, вот только доступ на win1 понадобился вот прямо сейчас! Рядом с vm1 расположен еще один сервер vm2, но  доступа с его IP на win1 нет. Было принято решение (с получением «добра» от начальника), поднять второй IP от первого vm1 на втором vm2 и ходить через него. Сеть наша, лишних в ней нет, поэтому: сказано — сделано: Вот только засада, ssh не умеет указывать какой IP использовать при подключении через ssh tunnel. То есть при попытке подключения предыдущей командой окончилось неудачей, так как соединение к win1 идет через default IP ( для этого сервера 192.168.45.57),  а «волшебного ключа», для указание ssh tunnel через какой удаленный IP ему подключаться дальше — не существует в текущей версии ssh. Ключа --remote-bind-address  -   не существует: Начались поиски решения, найденные варианты не подошли по разным причинам:  route add --host ... iptables -t nat -I POSTROUTING ... Но все же решение Было найдено. Помог netcat + named pipe. Итак вот оно, решение!: Я в принципе знал сам принцип, но вот использовать такой трюк для проброса RDP между локальными IP не додумался, да и на удивление, такое решение нашлось далеко не сразу.  Надеюсь, данная статья поможет многим администраторам разобраться с каналами, и их использованием в своей работе.  Администратор баз данных, unix, windows, VMS