Comments 24
Хорошая статья о том, как в UNIX с помощью < , | и > сделать всё
Хорошая
Простите за снобизм, но это не так. Хабр будто бы вырождается в Пикабу, рассказывая о таких вещах, которые, в общем-то, должны знать все
То есть вы считаете, что на Хабре нет места неопытным в системном администрировании читателям (и, видимо, во многих других IT-областях тоже), которые только осваивают эту науку, либо просто узнают какие-то заинтересовавшие их внезапно нюансы?
Нет, я считаю, что первый скилл джуниора, который он должен уже иметь, это способность заглянуть в гугл/стековерфлоу с запросами вроде такого:
site:habr.com tar+ssh
Неопытным в системном администрировании
надо читать официальную документацию.
Резервное копирование системы:
https://help.ubuntu.ru/wiki/backup
https://wiki.archlinux.org/title/Synchronization_and_backup_programs_(Русский)
https://wiki.archlinux.org/title/Dd_(Русский)
https://wiki.archlinux.org/title/Full_system_backup_with_tar
Может просто не надо засирать хабр бестолковыми переводами, учитывая, что на хабре есть намного более полезные статьи на эту тему.
Всё описанное в переводе отлично ужимается в один абзац "Удалённое исполнение кода"
должны знать все
Вы лично про магию < | > откуда узали? Возможно, кто-то узнает из habr.com и перейдет на светлую сторону ;)
я был как-то изначально в курсе
Не у всех это заложено в прошивку.
Если про прошивку (закладываему в институте ;-) ) то у меня в нее был заложен Фортран для ЕС ЭВМ (а еще — Алгол для БЭСМ-6).
А остальное пришлось, таки да, изучать после института, многое — попутно. Что касается перенаправления потоков ввода и ввода (< и >)- это какая-то очень старая идея, по крайней мере в Фортране ЕС ЭВМ она уже была с каких-то незапамятных (для меня времен): были стандартные номера (5 и 6 ЕМНИП) которые назначались на конкретные наборы данных в JCL. А вот каналов (| AKA pipe) — таки да, не было, это была идея из Unix (AFAIK оригинальная). Но в СССР Unix было мало, потому как основные производители копировали совсем другие, глубоко проприетарные, системы. Так что с Unix я в советское время не работал. Но книжки разные читал, в какой-то из них и про каналы прочел, и идея мне понравилась — как раз, потому что требовалась, а не было.
А в COMMAND.COM полноценных каналов — соединияющих две работающие одновременно прграммы — не было: DOS, как все, наверное, знают была системой однозадачной, поэтому программы запускались по очереди, а каналы между ними в COMMAND.COM эмулировались через временные файлы.
А Windows (оригинальной, 3.х) вообще не было своего shell и, соответственно, каналов — видимо поэтому программисты на Windows, для кого она была первой системой, каналы часто не знают и не любят. Но я не из их числа.
Не стреляйте в пианиста, он играет, как умеет. У переводчика план по валу.
Хоть я и согласен с вами по сути, но надо ж понимать бизнес-модель Хабра. Его владельцы хотят кушать, а кроме как с компаний денег взять особо не с кого. Компании тоже хотят кушать, и чтобы о них на забывали, каждый день на канале должно появляться новое чтиво для гиков, чтобы повтыкать за утренним кофе.
Учитывая, же какой треш тут гонят новостнюки, то лучше пусть будет хоть это. Не самая плохая статья для перевода.
Какие все великие ;) Есть много о чем не заглядываешь в man, так как давно его отштудировал и тут вдруг на форуме рассказывают про ключик -bv у sendmail.
Только я всегда убираю эту идиотскую v из параметров, которая только засирает экран. Ну и рекомендация отключать сжатие для ускорения передачи файла по сети вызывает лёгкое недоумение. Впрочем, чего ждать от индуса.
И замечание для переводчика. Как можно видеть, символ приглашения у автора гуляет между $ и #. При этом для оригинала это не критично — там подсветка работает нормально, а вот на хабре вся строчка превращается в комментарий. Рекомендую все приглашения в примерах сделать виде $
Спасибо, исправлю
рекомендация отключать сжатие для ускорения передачи файла по сети вызывает лёгкое недоумение
20 лет назад это было актуально, когда процессоров с AES не было. Да и сейчас тоже, очень легко включить сжатие уже сжатых файлов внутри сжатого архива.
Ну и рекомендация отключать сжатие для ускорения передачи файла по сети вызывает лёгкое недоумение
использование дефолтного сжатия (однопоточный gzip) на гигабитном канале обычно приводит к существенному снижению скорости копирования.
lz4 или ztsd тут куда более уместны (последний умеет даже адаптивную степень сжатия)
Это все конечно хорошо. Но подскажите, как сделать так, чтобы, к примеру, скорость резервного копирования быстрого raid-массива по сети 10 Гбит/с не утыкалась в производительность шифрования ssh.
nfs
не уверен, что во всех версиях/конфигах openssh так, но сейчас проверил, у меня по умолчанию выбирается chacha20-poly1305, который, конечно, быстрый, но ускоренный аппаратно aes всё-таки быстрее.
попробуйте ssh -c aes128-gcm@openssh.com, на моих серверах гигабайт в секунду получается, как раз под 10G сеть )
На приёмнике:
nc -l 1337 > ~/newfile.bin
На источнике:
<file.bin nc host 1337
Контроль целостности на вас (md5sum руками или воткнуть в оба пайпа). Чинить сбои передачи можно через par2 или просто повторной пересылкой. Сбои будут. Редко и некстати.
Использование утилиты tar по сети через SSH