encfs / gocryptfs — прозрачное шифрование для параноиков (и прагматиков)

Ручное шифрование архивов с чувствительными данными паролем перед отправкой в облако или на флешку — это дополнительный шаг, который легко забыть. encfs и его более современный аналог gocryptfs создают виртуальную зашифрованную файловую систему поверх обычной директории. Файлы сохраняются на диск в зашифрованном виде, но примонтированная директория предоставляет доступ к ним в открытом виде.

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

➤ Вариант 1 (Персональное облачное хранилище): создание зашифрованной директории внутри синхронизируемой папки (Nextcloud, Dropbox). В облако попадают только нечитаемые шифроблоки, но локально вы работаете с обычными файлами.

# Создание зашифрованного хранилища
gocryptfs -init ~/my-secret-vault
# Монтирование для работы
gocryptfs ~/my-secret-vault ~/vault
# Теперь файлы в ~/vault видны в чистом виде, а в ~/my-secret-vault лежат зашифрованные

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

➤ Вариант 3 (Резервное копирование): бэкап-скрипт может работать с уже зашифрованной директорией, ему не нужно знать пароль. Это защищает данные на ленточном накопителе или у стороннего провайдера бэкапов.

encfs/gocryptfs — это автоматизация безопасности данных на уровне файловой системы. Они реализуют принцип «шифрования в состоянии покоя» (encryption at rest) для конкретных данных, а не для всего диска, с минимальными накладными расходами и максимальным удобством.

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

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

🌐 @helcode

Привет, коллеги! Нужен ваш мозг на 5 минут 🧠

Я пишу новую статью для Хабра — чистая практика, код, автоматизация — но столкнулся с классической проблемой автора: тем в голове много, а понять, какая будет максимально полезна именно вам, сложно.

Поэтому перекладываю эту задачу на вас, моих самых подкованных читателей:

Какая одна задача из вашей рутины (администрирование, DevOps, разработка) бесит больше всего и кричит с просьбой автоматизации, но вы всё откладываете?

Например:

«Как написать свой простой мониторинг с уведомлениями в Telegram, если надоел Zabbix?»

«Какие лайфхаки в bash-скриптах реально спасают от ночных кошмаров?»

«Как заставить Python-скрипты и Bash дружить в одной таске?»

Почему вам стоит кинуть идею?

➤ Закроете свою боль. Статья будет сделана под запрос сообщества.

➤ Получите готовое решение. Не просто теория, а работающие скрипты.

➤ Повлияете на контент. Канал и дальше будет рассказывать о том, что вам важно.

Кидайте ваши варианты в комментарии! Что будем автоматизировать всем миром?

P.S. Если стесняетесь писать публично — можете прислать идею мне в личку (@helcodeadm).

🌐 @helcode

logwatch / logcheck — автоматический дайджест того, что система хотела вам сказать

Ежедневный ручной просмотр ключевых логов (/var/log/syslog, secure, nginx/access.log) на предмет аномалий — это скучная и неблагодарная работа, которую легко забросить. logwatch и logcheck анализируют логи за прошедший день, агрегируют события, фильтруют рутину и отправляют администратору краткий, осмысленный отчет по почте.

Система, которая не может сама рассказать о своем здоровье, обрекает администратора на роль археолога, постоянно раскапывающего её прошлое.

➤ Вариант 1 (Ежедневный отчет logwatch): после установки logwatch по умолчанию настраивается на ежедневный запуск через cron.daily и отправку подробного отчета на root@localhost. В отчет входит статистика по аутентификациям (SSH), использованию диска, загрузке процессора и подозрительным событиям.

# Ручной запуск для просмотра отчета за сегодня
logwatch --range Today --output stdout

➤ Вариант 2 (logcheck для оперативного реагирования): logcheck работает иначе. Он постоянно отслеживает логи, фильтрует известные нормальные сообщения через правила в /etc/logcheck/ignore.d.*/, а все неопознанные (необычные) события немедленно отправляет администратору. Это система раннего предупреждения.

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

Эти инструменты — это автоматизация первого, самого утомительного этапа анализа логов: фильтрации сигнала из шума. Они не заменяют полноценный SIEM, но предоставляют бесплатный и эффективный базовый уровень наблюдаемости для любой системы.

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

P.S. Главная польза от внедрения таких систем — «эффект кресла-качалки». Вы можете спокойно уйти в отпуск, зная, что если что-то важное случится, система отправит вам письмо. А если писем нет — всё в порядке.

🌐 @helcode

aria2 — не wget, и не curl. Это загрузчик, который думает о производительности

Скачивание больших файлов, ISO-образов или резервных копий по одному соединению, которое может оборваться на 99% — это тест на стрессоустойчивость. aria2 — это загрузочная утилита, поддерживающая многопоточность, сегментированную загрузку, докачку и работу с множественными источниками (HTTP, HTTPS, FTP, BitTorrent, Metalink).

Процесс загрузки не должен быть пассивным ожиданием. Он должен использовать доступные ресурсы сети максимально эффективно.

➤ Вариант 1 (Многопоточная загрузка с докачкой): базовая команда для скачивания файла с разбивкой на 16 потоков и сохранением состояния сессии.

aria2c -x 16 -s 16 --continue=true "https://example.com/bigfile.iso"

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

aria2c -i urls.txt --max-concurrent-downloads=5

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

aria2c --enable-rpc --rpc-listen-all --dir=/downloads
# Далее можно добавлять задания через curl к API

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

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

P.S. В сочетании с cron или системными таймерами `aria2` может использоваться для регулярного автоматического скачивания обновлений, дампов баз данных с удаленных серверов или синхронизации больших наборов данных.

🌐 @helcode

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