unison — двусторонняя синхронизация, где конфликты — не приговор

Использование rsync для синхронизации в одну сторону или облачных драйверов, которые могут потерять данные при конфликте, — это компромиссы. unison — это файловый синхронизатор, который понимает концепцию двусторонней синхронизации, умеет определять и разрешать конфликты, а его текстовые профилы позволяют описывать сложные сценарии.

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

➤ Вариант 1 (Базовая синхронизация с профилем): создание профиля .prf, который описывает две корневые директории и правила.

# ~/.unison/myproject.prf
root = /home/user/project
root = ssh://remote-server//opt/project
ignore = Name .git
ignore = Name *.tmp

Запуск: unison myproject

➤ Вариант 2 (Автоматическое разрешение конфликтов): настройка правил в профиле для автоматических действий при конфликтах (например, всегда сохранять версию с более новой датой или сохранять обе копии).

# В профиле
auto = true
batch = true
# В случае конфликта сохранить обе версии
conflict = newer -> keep
conflict = older -> keep

➤ Вариант 3 (Скриптование и интеграция с cron): использование unison в неинтерактивном режиме (-batch) внутри скриптов для регулярной автоматической синхронизации, например, конфигурационных файлов между узлами кластера.

unison — это автоматизация сложной, осмысленной синхронизации. Он не просто копирует файлы, а проводит «согласование» состояния между двумя репликами, пытаясь сохранить изменения, сделанные с обеих сторон, и явно сигнализируя там, где это невозможно.

Это инструмент для сценариев, где нет четкого «мастера» и «слейва», а есть два равноправных узла, которые должны обмениваться данными, сохраняя их целостность и историю изменений.

P.S. unison использует собственную базу данных (.unison в корневых директориях) для отслеживания предыдущего состояния. Это делает его более умным, чем инструменты, основанные только на временных метках, но требует, чтобы эта база не терялась.

🌐 @helcode

smokeping — измерение не скорости, а стабильности сети

ping показывает потери сейчас, mtr показывает, где они. Но чтобы увидеть *характер* проблем — мимолетные пакетные потери, периодические скачки задержки — нужен долгосрочный мониторинг. SmokePing непрерывно отправляет ICMP, TCP или DNS probes к целевым хостам и рисует наглядные графики задержки и потерь, где каждый пик или полоса — это история сетевого страдания.

Сеть может быть «быстрой», но нестабильной. Первое заметит пользователь, второе — только система мониторинга, смотрящая в долгую перспективу.

➤ Вариант 1 (Мониторинг магистральных каналов): настройка targets на ключевые маршрутизаторы провайдера (8.8.8.8, 1.1.1.1) и внутренние шлюзы. График покажет, проблема локальная или на стороне ISP.

# Фрагмент конфига /etc/smokeping/config.d/Targets
+ NetworkHealth
menu = Network Health
title = Critical network paths
++ GoogleDNS
host = 8.8.8.8
++ CloudflareDNS
host = 1.1.1.1

➤ Вариант 2 (Диагностика Wi-Fi): мониторинг задержки до домашнего роутера и до точки в интернете. Регулярные «проседания» и потери на первом хопе укажут на проблемы с беспроводным покрытием или помехами.

➤ Вариант 3 (Интеграция с алертингом): хотя SmokePing — визуальный инструмент, его данные можно экспортировать или дополнять скриптами, которые анализируют rrd-файлы и запускают алерты при долговременной деградации качества.

SmokePing — это автоматизация сбора *качественных* характеристик сети. Он превращает субъективное ощущение «интернет сегодня какой-то рваный» в объективную картину с таймстемпами, которую можно предъявить провайдеру или использовать для анализа трендов.

Это инструмент не для моментальной диагностики, а для выявления хронических, плавающих проблем, которые убивают VoIP, видеоконференции и удовольствие от работы.

P.S. Дым на графике SmokePing — это не метафора. Красные «облака» потерь на графике действительно похожи на дым, поднимающийся от костра проблем.

🌐 @helcode

auditd — Большой Брат ядра Linux, который вы можете настроить

Кто что запускал? К каким файлам обращался? Какие системные вызовы вызывала программа? auditd — это подсистема ядра и демон для детального аудита событий безопасности в системе. В отличие от обычных логов, он может отслеживать не действия программ, а вызовы ядра, что позволяет логировать события, которые сама программа могла бы скрыть.

Для расследования инцидента безопасности недостаточно знать, что служба упала. Нужно знать, что происходило в системе до этого.

➤ Вариант 1 (Отслеживание доступа к критичным файлам): настройка правила для аудита всех попыток чтения или изменения файла /etc/shadow.

# auditctl -w /etc/shadow -p war -k shadow_file
# -w watch, -p permissions (r=read, w=write, x=execute, a=attribute change)
# -k key — метка для поиска в логах

➤ Вариант 2 (Мониторинг системных вызовов): аудит всех случаев использования опасного системного вызова ptrace (используется отладчиками и, увы, эксплойтами).

auditctl -a always,exit -F arch=b64 -S ptrace -k tracing

➤ Вариант 3 (Поиск по логам аудита): основной инструмент для анализа — ausearch и aureport. Например, поиск всех событий, связанных с конкретным пользователем за последний час.

ausearch -ts today -k shadow_file | aureport -f -i

auditd — это автоматизация сбора судебных доказательств (forensics). Он не предотвращает атаку, но позволяет восстановить её полную картину после факта, ответив на вопросы «что, когда, как и откуда».

Это тяжёлая артиллерия. Его включение без четкой стратегии и правил приведет к лавине событий, которые невозможно анализировать. Ценность — в целевой, точной настройке.

P.S. Правила auditd сбрасываются после перезагрузки. Для их постоянства необходимо прописывать в /etc/audit/rules.d/audit.rules или использовать augenrules.

🌐 @helcode

ncdu — визуальный археолог дискового пространства

Рекурсивный запуск du -sh *, переход в найденную большую директорию и повтор — это ритуал очистки диска. ncdu (NCurses Disk Usage) делает это за вас: сканирует выбранную директорию, сортирует результаты по размеру и предоставляет простой текстовый интерфейс для навигации и удаления файлов прямо внутри утилиты.

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

➤ Вариант 1 (Базовое сканирование): самый частый сценарий — найти, что съело место в корневой файловой системе.

ncdu /

➤ Вариант 2 (Экспорт и сравнение): можно сохранить результат сканирования в файл, а позже — загрузить и сравнить с новым, чтобы увидеть, что именно выросло.

ncdu -o scan.ndjson /var/lib/docker
# ... через неделю ...
ncdu -f scan.ndjson

➤ Вариант 3 (Удалённый анализ по SSH): сканирование удаленного сервера с передачей данных по SSH и локальным запуском интерфейса ncdu.

ssh user@server 'ncdu -o - /some/dir' | ncdu -f-

ncdu — это автоматизация самого утомительного этапа управления дисковым пространством: *поиска виновника*. Он не удалит ничего сам (без вашего подтверждения), но доведет вас до нужного файла за считанные секунды, избавив от рутины.

Это пример идеального инструмента: делает одну узкую задачу (визуализацию дискового использования) настолько хорошо, что становится незаменимым.

P.S. Клавиша d в ncdu удаляет выбранный файл/директорию. Используйте с крайней осторожностью. Всегда лучше сначала просмотреть (i), что именно собираетесь удалить.

🌐 @helcode

driftctl — детектив «дрейфа инфраструктуры» в облаке

Вы описываете инфраструктуру как код (Terraform), но кто-то вручную создал Security Group через веб-консоль или изменил тэг. Состояние реального облака расходится с состоянием, описанным в коде. Это «дрейф». driftctl сканирует ваше облако, сравнивает его с кодом в Terraform и показывает все расхождения.

«Инфраструктура как код» без проверки на дрейф — это красивая теория, которая разбивается о практику ручных правок и забытых ресурсов.

➤ Вариант 1 (Локальная проверка): запуск с указанием пути к state-файлу Terraform.

driftctl scan --from tfstate://terraform.tfstate

➤ Вариант 2 (Интеграция в CI/CD): добавление шага driftctl scan в пайплайн после применения Terraform. Если дрейф обнаружен, пайплайн может «упасть», отправить уведомление или даже попытаться автоматически импортировать ресурс обратно в управление.

# В CI, после terraform apply
driftctl scan --from tfstate://terraform.tfstate --output json://stdout | jq '.summary.total_unmanaged' 
# Если total_unmanaged > 0, FAIL

➤ Вариант 3 (Непрерывный мониторинг): запуск driftctl по расписанию (например, раз в день) с отправкой отчета в Slack, чтобы команда видела, что и когда изменилось в обход процессов.

driftctl — это автоматизация соблюдения дисциплины IaC. Он выступает в роли «полиции инфраструктуры», находя несанкционированные изменения и помогая вернуть систему к состоянию, описанному в репозитории.

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

P.S. driftctl поддерживает AWS, Azure, Google Cloud и даже GitHub. Его главный вывод: «managed» (управляется Terraform), «unmanaged» (существует только в облаке), «missing» (есть в коде, но нет в облаке).

🌐 @helcode

tcpflow — не просто сниффер, а реконструктор потоков

tcpdump показывает сырые пакеты, wireshark позволяет их анализировать. Но если нужно быстро понять, *что именно* передавалось в HTTP-сессии (картинки, файлы, тексты запросов/ответов), tcpflow — идеальный выбор. Он захватывает трафик и реконструирует потоки данных (flow), сохраняя каждый поток в отдельный файл.

Иногда нужно не анализировать заголовки, а просто «поймать» и посмотреть содержимое передачи.

➤ Вариант 1 (Реконструкция HTTP-сессии): захват трафика на порту 80 и сохранение всех потоков в файлы. В результате получаются файлы с именами вида XXX.YYY.ZZZ.AAA-NNNN-BBBB.CCCC, содержащие чистые данные, отправленные с одного IP:port на другой.

sudo tcpflow -i any port 80

➤ Вариант 2 (Поиск конкретных данных): использование в связке с grep для поиска по захваченным потокам, например, ключевых слов или кусков бинарных данных.

sudo tcpflow -i any -c port 443 | grep -i "password"

➤ Вариант 3 (Анализ передачи файлов): если через протокол (например, FTP или незашифрованный SMTP) передавался файл, tcpflow часто позволяет легко вычленить и сохранить его из потока.

tcpflow — это автоматизация задачи извлечения *смыслового содержимого* из сетевого потока. Он абстрагируется от низкоуровневых деталей TCP (последовательности, ACK) и показывает то, что пытались передать приложения.

Это инструмент для быстрой отладки, обратного инжиниринга протоколов и, да, для учебных целей по пониманию того, как данные путешествуют по сети.

P.S. ВАЖНО: Использование tcpflow (как и любого сниффера) для перехвата трафика, не предназначенного вам, без явного согласия — незаконно. Используйте только на своих системах или в изолированных средах для отладки.

🌐 @helcode

earlyoom — палач, который жертвует процессами ради системы

Когда память заканчивается, ядро Linux запускает механизм OOM Killer. Но он срабатывает слишком поздно, когда система уже глубоко в свопе и полностью неотзывчива. earlyoom (Early Out-of-Memory Daemon) постоянно мониторит доступную память и своп и *заранее* отправляет сигнал SIGTERM, а затем SIGKILL самым прожорливым процессам, чтобы спасти систему от полного краха.

Доверять встроенному OOM Killer — это как надеяться, что пожарная система сработает, когда дом уже почти сгорел.

➤ Вариант 1 (Установка и забыть): после установки пакета (earlyoom) и включения службы демон начинает работать в фоне. Он использует встроенную эвристику, отдавая предпочтение процессам, съедающим много памяти, и стараясь не трогать системные.

➤ Вариант 2 (Тонкая настройка порогов): определение, при каком проценте свободной оперативной памяти (-m) и свопа (-s) начинать отправку сигналов.

earlyoom -m 5 -s 2
# Начинать действовать, когда свободно меньше 5% RAM и 2% swap

➤ Вариант 3 (Исключение критичных процессов): можно запретить убивать определенные процессы по имени (например, -r sshd,postgres), хотя с этим стоит быть осторожным.

earlyoom — это автоматизация принципа «меньшее зло». Он признает, что в ситуации нехватки памяти кто-то должен умереть, и принимает это решение *раньше*, чем система станет неуправляемой, сохраняя работоспособность ядра и SSH-доступ для администратора.

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

P.S. В эпоху контейнеров earlyoom может работать в связке с механизмами cgroups, но его простая установка на любой сервер — это один из самых эффективных «лайфхаков» для повышения отказоустойчивости.

🌐 @helcode

gron — делаем JSON дружелюбным для grep и awk

JSON от API или конфигурационный файл в одну длинную строку или с сложной вложенностью — это кошмар для анализа в командной строке. gron (от «make JSON greppable») преобразует JSON в плоский список утверждений в формате «путь = значение». После этого можно использовать grep, sed или awk, а потом снова преобразовать обратно в JSON.

jq мощный, но его синтаксис нужно знать. Иногда нужен просто grep.

➤ Вариант 1 (Базовое «разворачивание»): преобразование сложного JSON в плоский формат.

curl -s https://api.github.com/users/octocat | gron
# Преобразует в нечто вида:
# json.avatar_url = "https://avatars.githubusercontent.com/u/583231?v=4";
# json.bio = "";
# json.blog = "https://github.blog";

➤ Вариант 2 (Поиск и фильтрация): легко найти все пути, где встречается определенное значение или ключ.

gron huge.json | grep "password" | gron --ungron
# Нашли все упоминания паролей и собрали обратно в JSON-фрагмент

➤ Вариант 3 (Создание и модификация): можно отредактировать вывод gron в текстовом редакторе, а затем собрать обратно, создав новый JSON. Удобно для простых правок в скриптах.

echo 'json.name = "New Name";' | gron --ungron

gron — это автоматизация подготовки структурированных данных к обработке классическими, универсальными текстовыми утилитами Unix. Это мост между миром структурированного JSON и философией «всё — текст».

Он не заменит jq для сложных выборок и преобразований, но для задач «найти и посмотреть» он часто оказывается интуитивно понятнее и быстрее.

P.S. Философская ценность gron в том, что он напоминает: любая сложная структура данных может (и должна) быть преобразована в форму, удобную для простых инструментов. Это краеугольный камень автоматизации в Unix-стиле.

🌐 @helcode

tmate — мгновенный совместный доступ к терминалу, как Google Docs для Shell

Отладка проблемы на удалённой машине, когда нужно показать коллеге «что я сейчас вижу», превращается в серию скриншотов или сложные инструкции. tmate (терминал-мейт) — это форк tmux, который создает сессию с общим доступом. При запуске он выдаёт уникальный SSH-адрес, по которому любой, у кого есть эта ссылка, может подключиться и видеть ваш терминал в реальном времени (или даже участвовать в работе).

Проведение живых демонстраций, совместная отладка и оперативный helpdesk перестают быть проблемой синхронизации экранов.

➤ Вариант 1 (Мгновенный сеанс помощи): вместо того чтобы просить коллегу «посмотри в логи на сервере X», вы запускаете tmate на проблемной машине, получаете ссылку и отправляете её в чат. Коллега подключается и видит ту же самую сессию.

tmate
# В выводе появится строка вида:
# SSH: ssh bG9jYWxob3N0IHBvcnQ...
# Веб: https://tmate.io/t/bG9jYWxob3N0...

➤ Вариант 2 (Демонстрация без подготовки): идеально для быстрого показа работы скрипта, настройки конфига или странного поведения в реальной среде. Не требует установки дополнительного ПО у зрителя — только SSH-клиент или браузер.

➤ Вариант 3 (Read-only режим): при создании сессии можно сразу указать режим только для чтения (tmate -R), чтобы зрители не могли вводить команды, что важно для безопасности при демонстрации на продакшене.

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

Это не инструмент для постоянного использования, а цифровой «аварийный люк» или «инструмент для презентации», который всегда под рукой.

P.S. Критически важно для безопасности: ссылка tmate предоставляет полный доступ к сессии. Отправляйте её только доверенным лицам и помните, что сессия живёт, пока активна. Для чувствительных операций используйте одноразовые сессии и завершайте их сразу после работы.

🌐 @helcode

cronic — умная обёртка для cron, которая не спамит почтой

Скрипт в cron завершился с ненулевым кодом возврата? Демон cron немедленно шлёт письмо на MAILTO. Если скрипт запускается часто и имеет ожидаемые, некритичные ошибки (например, временная недоступность сети), почтовый ящик превращается в свалку. cronic — это маленький bash-скрипт, который подавляет вывод задачи, если она завершилась успешно, и показывает его только в случае ошибки.

Правило хорошего тона: автоматизация должна молчать, когда всё хорошо, и говорить, когда есть проблема.

➤ Вариант 1 (Прямое использование в crontab): обернуть любую команду в cronic.

# Вместо этого:
# * * * * * /opt/scripts/healthcheck.sh
# Использовать это:
* * * * * /usr/bin/cronic /opt/scripts/healthcheck.sh

➤ Вариант 2 (Суть логики): cronic — это, по сути своей, умный перенаправитель вывода. Его можно реализовать своими силами, понимая принцип:

#!/bin/bash
# Упрощенная суть cronic
OUTPUT=$($@ 2>&1)
EXITCODE=$?
if [ $EXITCODE -ne 0 ]; then
  echo "Command failed with exit code $EXITCODE:"
  echo "$OUTPUT"
fi
exit $EXITCODE

➤ Вариант 3 (Использование в CI/CD): аналогичный принцип применяется в пайплайнах: этап считается неудачным и показывает логи только если команда завершилась с ошибкой. cronic формализует этот подход для cron.

cronic — это автоматизация управления уведомлениями. Он встраивает простую логику принятия решения: «стоит ли беспокоить человека этими данными?». Это следующий уровень после простого перенаправления вывода в /dev/null.

Инструмент, который экономит не время процессора, а самое ценное — внимание системного администратора.

P.S. Исходный код cronic умещается на одной странице. Это гениальный пример того, как простая идея, правильно реализованная, решает огромный пласт бытовых проблем.

🌐 @helcode

pip-audit / npm audit / cargo-audit — автоматические детективы уязвимостей в зависимостях

Установка пакетов без проверки на известные уязвимости (CVE) — это игра в русскую рулетку с безопасностью приложения. Современные менеджеры пакетов экосистем получают встроенные или отдельные инструменты аудита, которые сканируют дерево зависимостей, сверяют его с публичными базами уязвимостей и указывают на проблемные версии.

Безопасность зависимости — это ответственность не только её автора, но и того, кто её использует. Автоматизация здесь — единственный способ держать руку на пульсе.

➤ Вариант 1 (Локальная проверка): запуск аудита вручную перед деплоем или как часть pre-commit хука.

# Для Python (pip)
pip-audit
# Для Node.js (npm)
npm audit
# Для Rust (cargo)
cargo audit

➤ Вариант 2 (Интеграция в CI/CD): добавление шага аудита в пайплайн сборки. При обнаружении критической уязвимости пайплайн «падает», предотвращая попадание уязвимого кода в репозиторий или на прод.

# Пример для GitHub Actions (Python)
- name: Audit dependencies
  run: pip-audit --strict

➤ Вариант 3 (Автоматическое обновление): инструменты вроде npm audit fix или Dependabot не только находят проблемы, но и автоматически создают Pull Request с обновлением зависимостей до безопасной версии.

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

Игнорирование их предупреждений — это осознанный выбор в пользу потенциального взлома.

P.S. Помните, что эти инструменты проверяют зависимости только по известным CVE. Они не заменяют ревью кода зависимостей на предмет закладок или анализа их лицензий.

🌐 @helcode

multitail — мониторинг нескольких логов в одном окне, с цветами и правилами

Открытие пяти терминалов с tail -f для слежки за логами nginx, приложения, БД и системного журнала — это бардак на рабочем столе. multitail позволяет отображать вывод нескольких команд (чаще всего tail -f) в одном окне, с разделением на панели, цветовой подсветкой на основе регулярных выражений и даже интерактивным управлением.

Наблюдаемость должна упрощать анализ, а не множить сущности.

➤ Вариант 1 (Базовый мониторинг): запуск с указанием файлов для слежения. Ключ -s задает количество колонок.

multitail -s 2 /var/log/nginx/access.log /var/log/nginx/error.log

➤ Вариант 2 (Цветовые схемы и фильтрация): настройка правил подсветки. Например, выделить ошибки (ERROR) красным, предупреждения (WARN) — желтым, а IP-адреса — синим.

multitail -cS syslog /var/log/syslog
# -cS <схема> применяет предустановленную цветовую схему

➤ Вариант 3 (Мониторинг вывода команд): можно следить не только за файлами, но и за выводом любой команды. Например, совместить логи и метрики vmstat.

multitail -l 'tail -f /app/app.log' -l 'vmstat 1'

multitail — это автоматизация организации потока информации. Он берёт на себя задачу агрегации и визуального структурирования данных из разных источников в реальном времени, освобождая вас от ручного переключения контекста между окнами.

Это следующий шаг после tail -f, как tmux — следующий шаг после нескольких открытых терминалов.

P.S. multitail умеет намного больше: объединять вывод из нескольких источников в одну панель, выполнять действия по нажатию клавиш, вести session log. Это tmux и tail -f в одном флаконе, заточенный под задачи администрирования.

🌐 @helcode

rclone — rsync для облаков и не только

Копирование файлов между локальным диском, S3-совместимым хранилищем, Google Drive, Dropbox, SFTP-сервером и десятками других бэкендов через разные CLI-интерфейсы — это кошмар. rclone (remote clone) — это единая консольная утилита, которая предоставляет общий интерфейс для работы с 70+ облачными и не только хранилищами.

Автоматизация работы с данными не должна упираться в уникальность API каждого провайдера.

➤ Вариант 1 (Синхронизация с облаком): классический сценарий — зеркалирование локальной директории в облачное хранилище (например, Yandex Disk или Backblaze B2).

rclone sync /backups/data remote:mybucket/data

➤ Вариант 2 (Копирование между облаками): миграция данных из одного облака в другое без промежуточной загрузки на локальный диск (при поддержке провайдера).

rclone copy source:s3-bucket/path dest:google-drive/path

➤ Вариант 3 (Монтирование облака как файловой системы): использование rclone mount для доступа к файлам в облаке как к локальной директории. Полезно для чтения/записи напрямую.

rclone mount remote:mybucket /mnt/cloud --vfs-cache-mode full

rclone — это автоматизация абстракции над хранилищами. Он реализует принцип «единого интерфейса» (unified API) для самых разнообразных сервисов, позволяя писать скрипты, которые будут работать с любым из них без изменений логики.

Это швейцарский армейский нож для данных в гибридном мире, где они живут и на диске, и в десятках «облаков».

P.S. rclone обладает всеми функциями rsync (дельта-копирование, проверка хэшей, --dry-run) и многими другими: шифрование на лету, обрезка версий, веб-интерфейс для управления. Это проект, в который влюбляешься по мере изучения.

🌐 @helcode

websocat — netcat для эпохи WebSockets

Простые TCP-сокеты уступают место WebSockets в современных API и стриминговых сервисах. websocat — это CLI-инструмент, который соединяет мир командной строки с миром WebSockets. Он может выступать как клиент, сервер, прокси или мост между WS и стандартными потоками stdin/stdout.

Тестирование, отладка или автоматизация взаимодействия с WebSocket-сервисом не должны требовать написания скрипта на Python или Node.js.

➤ Вариант 1 (Интерактивный клиент): подключение к WebSocket-эндпоинту и интерактивный обмен сообщениями, как с telnet для TCP.

websocat ws://echo.websocket.org
# Вводите строки, получаете эхо-ответ.

➤ Вариант 2 (Автоматизация в скриптах): отправка заранее подготовленного JSON и чтение ответа, перенаправляя потоки.

echo '{"event":"subscribe"}' | websocat ws://api.example.com/stream

➤ Вариант 3 (Создание простого сервера или моста): запуск локального WebSocket-сервера, который перенаправляет сообщения в локальную программу или файл.

# Сервер, который всё записывает в файл
websocat -s 8080 tee logs.txt

websocat — это автоматизация доступа к современным сетевым протоколам из арсенала Unix. Он расширяет философию «всё — файл/поток» на мир WebSockets, позволяя использовать мощь пайпов, grep, jq и других утилит для работы с данными, передаваемыми по этому протоколу.

Это пример того, как классические Unix-принципы адаптируются к новым технологиям, а не отмирают.

P.S. websocat написан на Rust, самодостаточен (статически линкованный бинарник) и невероятно быстр. Это идеальный кандидат для добавления в Docker-образы для целей отладки и healthcheck'ов.

🌐 @helcode

pgrep и pkill — убийцы, которые знают имена, а не только PID

Поиск PID процесса через ps aux | grep -v grep | grep ... | awk '{print $2}' с последующим kill — это ритуал, достойный редиски. pgrep и pkill делают то же самое за одну команду, используя гибкие шаблоны для поиска по имени процесса, владельцу, аргументам командной строки и другим атрибутам.

Управление процессами должно быть декларативным («заверши все процессы python»), а не императивным («найди, извлеки, убей»).

➤ Вариант 1 (Точный поиск и завершение): завершение всех процессов с точным именем.

pkill -9 nginx

➤ Вариант 2 (Гибкое сопоставление): завершение процессов по шаблону в имени или аргументах. Ключ -f проверяет полную командную строку.

# Убить все процессы python, запущенные из скрипта backup
pkill -f "python.*backup"

➤ Вариант 3 (Сигналы и проверка): pgrep позволяет сначала проверить, какие процессы будут затронуты, прежде чем посылать сигнал. Это безопаснее.

pgrep -u www-data
# Показать PIDs всех процессов пользователя www-data
pkill -SIGTERM -u www-data
# Отправить SIGTERM всем им

pgrep/pkill — это автоматизация паттерна поиска-и-действия для управления процессами. Они инкапсулируют рутинную логику фильтрации вывода ps в простые, надёжные команды, которые меньше подвержены ошибкам (например, случайному попаданию в grep самого процесса grep).

Это не новые инструменты, но их недооценка — распространенная ошибка. Их знание — признак того, что вы работаете с системой, а не боретесь с ней.

P.S. Осторожно с pkill -f, особенно под root. Шаблон .* может совпасть с больше процессов, чем вы ожидаете. Всегда проверяйте список кандидатов через pgrep -a -f <шаблон>.

🌐 @helcode

iperf3 — не гадаем, а измеряем пропускную способность сети

Сетевые приложения тормозят, копирование файлов медленное, а «пинг» вроде нормальный. "Гадания на кофейной гуще" и тесты скорости через загрузку файлов с облака - не метод. iperf3 - это профессиональный инструмент для измерения максимальной пропускной способности сети между двумя хостами, который выдаёт точные цифры: скорость, джиттер, потери пакетов.

Скорость сети - не ощущение, а измеримая величина. Если Вы её не измеряете, Вы ей не управляете.

➤ Вариант 1 (Базовая проверка): запуск сервера на одной машине и клиента на другой.

# На сервере (принимающая сторона)
iperf3 -s

# На клиенте (отправляющая сторона)
iperf3 -c 192.168.1.100

➤ Вариант 2 (Двунаправленное тестирование): ключ -R (reverse) меняет направление, позволяя увидеть асимметрию канала (часто бывает, что загрузка быстрее отдачи).

iperf3 -c 192.168.1.100 -R

➤ Вариант 3 (Параллельные потоки и длительность): имитация реальной многопоточной нагрузки.

iperf3 -c 192.168.1.100 -P 4 -t 30
# -P 4: 4 параллельных потока
# -t 30: тест длится 30 секунд

➤ Вариант 4 (UDP-тест для чувствительных приложений): для VoIP или видеосвязи важны потери и джиттер.

iperf3 -c 192.168.1.100 -u -b 100M
# -u: UDP режим
# -b 100M: пытаемся отправить 100 мегабит/с

iperf3 - это автоматизация объективной сетевой диагностики. Он убирает фактор "кажется" и даёт цифры, на которые можно опираться при общении с провайдером или при поиске узкого места в инфраструктуре.

Полезно держать iperf3 в Docker-образе или установленным на всех ключевых серверах, чтобы быстро проверять связность при жалобах на скорость.

P.S. Версии iperf3 должны совпадать на клиенте и сервере, иначе тест может не работать или выдавать некорректные результаты.

🌐 @helcode

git worktree — параллельная работа без переключения контекста

Нужно срочно исправить баг на продакшене, но текущая ветка с новой фичей не готова к коммиту? git stash, git checkout, а потом обратно - потеря концентрации и времени. git worktree позволяет одновременно иметь несколько рабочих копий одного репозитория, привязанных к разным веткам, на диске.

Переключение контекста в разработке - главный пожиратель продуктивности. git worktree устраняет саму необходимость переключения.

➤ Вариант 1 (Создание нового worktree): добавляем новую рабочую директорию для ветки hotfix.

git worktree add ../project-hotfix hotfix
# Теперь в папке ../project-hotfix лежит код ветки hotfix

➤ Вариант 2 (Работа с несколькими фичами): можно держать отдельные папки для feature-1, feature-2 и main, не трогая основной рабочий каталог.

git worktree add ../project-feature-a feature-a
git worktree add ../project-feature-b feature-b

➤ Вариант 3 (Просмотр и очистка): увидеть все активные worktree и удалить ненужные.

git worktree list
git worktree remove ../project-hotfix

git worktree - это автоматизация управления рабочим пространством. Он позволяет мозгу не переключаться между задачами, а просто открыть новое окно терминала или редактора с уже готовым контекстом.

Это инструмент для тех, кто часто работает с несколькими ветками параллельно: поддержка старых версий, срочные хотфиксы, code review в другой ветке без потери текущего состояния.

P.S. Worktree не занимают лишнего места на диске (объекты хранятся в оригинальном репозитории), только файлы рабочей директории. Это почти бесплатный параллелизм.

🌐 @helcode