Знали, что tar умеет потоково передавать файлы через pipe без создания архива на диске?

Большинство используют tar только для архивов, хотя в Linux его часто применяют как быстрый способ потоковой передачи файлов между системами и директориями.

Команда создаёт tar-поток в stdout и сразу передаёт его в другой процесс:

$ tar cf - project | ssh server "tar xf -"

Файлы копируются напрямую на удалённую машину без временного .tar файла и без промежуточной записи на диск.

Можно сразу включить сжатие:

$ tar czf - logs | ssh server "tar xzf -"

Такой способ часто оказывается быстрее и надёжнее scp при большом количестве мелких файлов, потому что сохраняется единый поток передачи и корректно переносятся права и структура директорий.

Этот же приём удобно использовать локально:

$ tar cf - . | (cd /backup && tar xf -)

🔥 Фактически это полноценное копирование дерева файлов через pipe без rsync, cp -a и создания временных архивов.

🚪 Linux Ready | #совет

📂 Напоминалка по NAT и работе сетевого роутера!

Например, NAT позволяет нескольким устройствам внутри локальной сети использовать один публичный IP-адрес для выхода в интернет, а обратный NAT возвращает ответы именно тому устройству, которое отправило запрос.

На картинке — наглядная схема того, как работает трансляция адресов: как роутер меняет private IP на public IP, зачем нужны порты и тд.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Перехватываем вывод процесса через tee — лог и консоль одновременно!

Частый кейс: запускаешь задачу (деплой, миграция, билд) и хочешь одновременно видеть вывод в терминале и сохранять его в файл. Обычный редирект > убирает вывод из консоли. Решается через tee.

Команда:

command 2>&1 | tee output.log

Что происходит: 2>&1 объединяет stderr и stdout; tee дублирует поток — пишет в файл и выводит в терминал.

Добавление в файл (append):

command 2>&1 | tee -a output.log

Без потери кода возврата (важно для скриптов):

set -o pipefail
command 2>&1 | tee output.log
echo $?

Без pipefail код возврата будет от tee, а не от command.
echo $? нужно вызывать сразу после пайплайна, иначе значение перезапишется.

Альтернатива:

command 2>&1 | tee output.log
exit ${PIPESTATUS[0]}

Важно: PIPESTATUS нужно читать сразу после пайплайна, иначе он перезапишется.

Пример: деплой

set -o pipefail
./deploy.sh 2>&1 | tee deploy.log

Лог сохраняется, при этом видно всё в реальном времени.

Пример: долгий билд

make -j4 2>&1 | tee build.log

stderr не теряется, но порядок строк может перемешиваться (из-за параллельности и буферизации).

Разделение потоков с сохранением, stdout в файл, stderr отдельно:

command > >(tee out.log) 2> >(tee err.log >&2)

Используется process substitution (bash). stdout/stderr остаются в консоли, но порядок между потоками не гарантируется.

Пример: отладка пайплайна

tee raw.log < data.txt | grep error | tee filtered.log

Сохраняешь и исходные данные, и результат фильтрации.

Что это даёт: полный контроль над логами без потери интерактивности; удобно для CI, деплоя, отладки; прозрачная диагностика.

🔥 Ограничения и нюансы: pipe меняет код возврата (решается pipefail или PIPESTATUS); pipefail не POSIX (bash/zsh/ksh); некоторые программы буферизуют вывод; при больших потоках — нагрузка на диск.

🚪 Linux Ready | #практика

☕️ Наткнулся на интересную статью на Хабре: «far2l 2.8.0 в Ubuntu 26.04: новые классные фичи»!

В этой статье:
• Разбираются ключевые обновления far2l 2.8.0;
• Показывается, как far2l постепенно превращается из простого порта Far Manager в мощный нативный инструмент для Linux и macOS;
• Объясняются практические улучшения для разработчиков и администраторов: перенос слов, номера строк, кликабельные ссылки, улучшенная работа с терминалами и поддержка kitty graphics protocol.

🔊 Продолжайте читать на Habr!

🚪 Linux Ready | #статья

Знали, что можно добавлять timestamp к любому выводу terminal pipeline без изменения приложения и логгера?

Во многих CLI-утилитах, shell-скриптах и legacy-сервисах отсутствуют временные метки, из-за чего сложно анализировать задержки, интервалы выполнения и последовательность событий.

Утилита ts из пакета moreutils добавляет timestamp к каждой строке stdin в реальном времени:

$ tail -f app.log | ts '%Y-%m-%d %H:%M:%S'

Теперь каждая строка получает точное время:

2026-05-22 18:41:03 request started
2026-05-22 18:41:07 request finished

Это особенно полезно при отладке конвейеров команд, shell-автоматизации, CI-логов, docker-контейнеров и long-running процессов, где нельзя быстро изменить сам источник логов.

Можно использовать свой формат времени:

$ tail -f app.log | ts '[%H:%M:%S]'

Или измерять интервалы между событиями:

$ ping 1.1.1.1 | ts -i

Иногда программы буферизуют вывод — тогда поможет:

$ stdbuf -oL -eL some-command | ts

🔥 Приём кажется небольшим, но на практике сильно упрощает анализ поведения систем и CLI-инструментов без внедрения полноценного логгирования.

🚪 Linux Ready | #совет

💅 Linux Notes — полезные заметки и статьи по Linux!

На сайте собрана большая коллекция материалов по Linux, системному администрированию и серверной инфраструктуре. Здесь можно найти шпаргалки по командам, настройку сервисов, работу с сетью, Bash, Docker, SSH, Nginx и другие практические темы, с которыми регулярно сталкиваются админы и backend-разработчики.

📌 Оставляю ссылочку: linux-notes.org

🚪 Linux Ready | #сайт

Знали, что Bash умеет потоково обрабатывать stdout и stderr через process substitution?

Когда нужно одновременно сохранить вывод в файл, показать его в терминале и отдельно обработать ошибки — многие делают временные файлы или запускают команду несколько раз.

В Bash это решается напрямую:

command > >(tee output.log)

stdout команды одновременно выводится в терминал и записывается в output.log.

stderr можно обработать отдельно:

command > >(tee out.log) 2> >(tee err.log >&2)

Теперь stdout и stderr разделены по разным log-файлам, но продолжают отображаться в терминале в реальном времени.

Можно сразу передавать поток в другие команды:

make 2> >(grep error >&2)

Или обрабатывать и логировать вывод без временных файлов:

docker logs app > >(ts > app.log)

ts обычно входит в пакет moreutils

Process substitution подключает pipe/FIFO или /dev/fd/* как обычный файл, поэтому данные обрабатываются потоково без временных файлов и без повторного запуска команды.

При раздельной обработке stdout/stderr порядок строк между потоками может отличаться от оригинального.

🔥 Крутой механизм Bash для отладки, логирования и построения сложных shell-конвейеров.

🚪 Linux Ready | #совет

📂 Напоминалка по SSH — как устанавливается защищённое соединение!

Например, SSH сначала согласовывает версии и алгоритмы шифрования, затем выполняет обмен ключами и только после этого открывает безопасную сессию для передачи команд и данных.

На картинке — полный цикл работы SSH: от TCP-подключения до шифрования команд и проверки ключей клиента.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Создаём временную RAM-директорию — быстрые файлы без лишней записи на SSD/HDD!

Иногда нужно быстрое временное хранилище: сборка проекта, кэш, распаковка архивов, временные логи или обработка больших файлов. В Linux для этого можно использовать tmpfs — файловую систему в памяти (RAM, при необходимости — с использованием swap).

Создаём директорию:

sudo mkdir -p /mnt/ramdisk

Монтируем tmpfs:

sudo mount -t tmpfs -o size=2G tmpfs /mnt/ramdisk

Что происходит: tmpfs создаёт файловую систему в памяти; size=2G — максимальный лимит, а не сразу занятая RAM; память выделяется по мере записи файлов; /mnt/ramdisk — директория монтирования.

Теперь всё, что записывается в /mnt/ramdisk, хранится в памяти и обычно значительно снижает количество записей на SSD/HDD.

Например:

cd /mnt/ramdisk

И работаешь как с обычной директорией:

cp big-archive.tar.gz /mnt/ramdisk
tar -xf big-archive.tar.gz

Практический пример: временная сборка большого frontend/backend-проекта или работа с временными файлами:

TMPDIR=/mnt/ramdisk npm run build

Некоторые инструменты используют TMPDIR для временных файлов, что может ускорить операции.

Для pip можно отдельно вынести кэш и временные файлы в RAM:

TMPDIR=/mnt/ramdisk \
PIP_CACHE_DIR=/mnt/ramdisk/pip-cache \
pip install -r requirements.txt

Проверить, что tmpfs смонтирован:

df -h

Пример:

tmpfs   2.0G   120M  1.9G   6% /mnt/ramdisk

Когда работа закончена — отмонтировать:

sudo umount /mnt/ramdisk

А также важно помнить: данные исчезают после reboot; tmpfs использует RAM и при необходимости может использовать swap; не стоит хранить там что-то важное; размер можно менять через size=; после umount директория останется, но данные tmpfs исчезнут.

🔥 Очень полезно для временных операций, где важна скорость и не нужно постоянное хранение данных.

🚪 Linux Ready | #практика

☕️ DevOps Interview — интерактивная платформа для подготовки к собеседованиям!

Это ресурс, где собраны вопросы и практические сценарии по DevOps, разбитые по ключевым темам: Docker, Kubernetes, CI/CD, облака, безопасность, мониторинг и др. Формат построен как тренажёр, можно проходить вопросы по категориям. Отдельно выделяются реальные сценарии, где разбираются проблемы и их решения.

📌 Оставляю ссылочку: interview.devopscommunity.in

🚪 Linux Ready | #сайт

Bash умеет массово генерировать пути и имена файлов без циклов и скриптов!

В Bash существует brace expansion — механизм, который разворачивает шаблоны ещё до запуска команды.

Можно мгновенно создавать структуры директорий:

$ mkdir -p build/{api,worker,nginx,db}

Shell превратит это в:

build/api
build/worker
build/nginx
build/db

Точно так же удобно генерировать наборы файлов:

$ touch app/{main,test,dev}.js

Получаются:

main.js
test.js
dev.js

Очень полезный приём для backup:

$ cp file{,.bak}

Bash автоматически развернёт команду в:

$ cp file file.bak

Brace expansion работает на уровне shell ещё до выполнения команды, поэтому не требует циклов, xargs или внешних утилит.

🔥 Это ускоряет работу с файлами, структурами развёртывания, генерацией шаблонов и автоматизацией shell-сценариев.

🚪 Linux Ready | #совет

📂 Напоминалка по перенаправлениям ввода/вывода!

Например, > перенаправляет вывод команды в файл, 2> — ошибки, а 2>&1 объединяет STDOUT и STDERR.

На картинке — основные файловые дескрипторы (STDIN, STDOUT, STDERR), примеры перенаправлений и другое.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Работа с systemctl edit — переопределение systemd unit без изменения оригинального файла!

Многие администраторы и разработчики до сих пор изменяют unit-файлы напрямую в:

/usr/lib/systemd/system/

или:

/lib/systemd/system/

Но это vendor unit-файлы, устанавливаемые пакетным менеджером. После обновления пакета изменения могут быть перезаписаны.

Правильный способ настройки сервисов в systemd — использовать override-конфигурации через:

systemctl edit

Например, добавим переменные окружения для nginx:

sudo systemctl edit nginx.service

После сохранения systemd создаст файл:

/etc/systemd/system/nginx.service.d/override.conf

Это безопасный способ переопределения параметров сервиса без изменения оригинального unit-файла.

Пример добавления переменных окружения:

[Service]
Environment="APP_ENV=production"
Environment="WORKERS=4"

После сохранения systemctl edit обычно автоматически выполняет daemon-reload, поэтому достаточно просто перезапустить сервис:

sudo systemctl restart nginx

Если unit-файлы или override-конфигурации изменялись вручную в /etc/systemd/system/, тогда дополнительно выполняют:

sudo systemctl daemon-reload

Проверить итоговую конфигурацию сервиса можно так:

systemctl cat nginx.service

Команда покажет: оригинальный unit-файл, все override-конфигурации, порядок применения настроек.

А для просмотра итоговых параметров сервиса полезно использовать:

systemctl show nginx.service

Это особенно полезно при диагностике сложных production-конфигураций.

Переопределение ExecStart, один из важных нюансов systemd — перед новым ExecStart старое значение нужно очистить. Пример:

sudo systemctl edit app.service

Override:

[Service]
ExecStart=
ExecStart=/usr/local/bin/app --port 8080

Пустой ExecStart= сбрасывает предыдущее значение из исходного unit-файла. Без очистки systemd может выдать ошибку, поскольку для сервисов с типом, отличным от Type=oneshot, допускается только один ExecStart.

Автоматический перезапуск сервиса. Для production-сервисов часто настраивают автоматический перезапуск:

[Service]
Restart=on-failure
RestartSec=5

Так systemd будет автоматически перезапускать сервис только при ошибках, а не после штатной остановки.

Systemd умеет ограничивать ресурсы процессов через cgroup. Пример ограничения памяти:

[Service]
MemoryMax=1G

Это особенно полезно для Node.js, Python, Java и других серверных приложений с непредсказуемым потреблением памяти.

Иногда требуется изменить почти весь unit-файл. Для этого используется:

sudo systemctl edit --full app.service

В этом режиме systemd создаёт полный локальный unit-файл в:

/etc/systemd/system/

который заменяет оригинальный unit из пакета.

Но использовать --full стоит осторожно — после этого вы фактически берёте поддержку unit-файла на себя и можете пропустить изменения из новых версий пакета.

Практический пример настройки сервиса:

[Service]
Environment="NODE_ENV=production"
WorkingDirectory=/srv/app
ExecStart=
ExecStart=/usr/bin/node /srv/app/server.js
Restart=on-failure
RestartSec=5
LimitNOFILE=65535
MemoryMax=1G

Так часто настраивают production-сервисы для Node.js, Go, Python, Java и других серверных приложений.

Дополнительно полезно знать:

systemctl show app.service -p FragmentPath -p DropInPaths

Команда покажет: путь к основному unit-файлу, все подключённые override-конфигурации.

🔥 Это стандартный и рекомендуемый способ настройки systemd без риска потерять изменения после обновления системы.

🚪 Linux Ready | #практика

🐱 Awesome Sysadmin — огромная база инструментов для Linux и DevOps!

В этом репозитории собраны open-source инструменты для системного администрирования: мониторинг, логирование, backup, docker, kubernetes, безопасность, networking, автоматизация и всё, что нужно для работы с серверами и инфраструктурой. По сути это готовая база полезного софта для сисадминов, DevOps и backend-разработчиков.

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

Слышали, что Bash умеет выводить set -x не в терминал, а в отдельный log-файл?

Обычно при debugging shell-скриптов используют set -x, но весь trace смешивается с обычным stdout/stderr и быстро делает вывод неудобным для чтения.

В Bash существует специальная переменная BASH_XTRACEFD, которая перенаправляет xtrace в отдельный файловый дескриптор:

$ exec {FD}>>debug.log
$ export BASH_XTRACEFD=$FD

Теперь debugging не ломает основной вывод программы:

$ bash -x ./deploy.sh

Все trace-команды уходят только в debug.log, а stdout/stderr продолжают работать как обычно.

Это особенно полезно в автоматизации, CI/CD, deploy-скриптах, где важно сохранить чистый вывод программы, но при этом иметь полную трассировку выполнения для отладки.

После завершения debugging дескриптор корректно закрывается:

$ set +x
$ exec {FD}>&-

🔥 Механизм работает внутри Bash и использует обычные файловые дескрипторы оболочки без внешних утилит.

🚪 Linux Ready | #совет

❤️ Крутая статья попалась на Хабре: Разбираем хаос в Linux-логах: journald, rsyslog и файлы!

В этой статье:
• Объясняется, как устроена система логирования в Linux;
• Разбираются различия между journald, rsyslog, syslog и классическими файлами логов;
• Показывается, как правильно настраивать логирование для PostgreSQL, Redis, Nginx, Kafka, HAProxy и др.;
• Объясняется, откуда появляются дубли логов, лишняя нагрузка на диск и проблемы с ротацией;

🔊 Продолжай читать на Habr!

🚪 Linux Ready | #статья