NetWatch: диагностика сети в одном TUI

netwatch - это TUI-утилита для диагностики сети в реальном времени. В одном окне она показывает интерфейсы, соединения, health checks, topology и анализ пакетов.

Установка:

brew install matthart1983/tap/netwatch

cargo install netwatch-tui

Запуск:

netwatch

Для полного режима с health probes и анализом пакетов:

sudo netwatch

Что умеет

netwatch показывает live RX/TX по интерфейсам, активные соединения с PID и именем процесса, проверки gateway и DNS, topology map, traceroute и контроль пакетов с декодированием DNS, TLS, HTTP, ICMP и DHCP. Есть экспорт pcap и incident recorder для коротких сетевых сбоев.

Shift+R  — включить rolling recorder на 5 минут
Shift+F  — заморозить текущее окно инцидента
Shift+E  — экспортировать incident bundle

Если нужен конфиг:

netwatch --generate-config

AI Insights

Отдельно в проект уже встроили AI Insights: можно раз в 15 секунд отправлять срез сети в LLM и получать подсказки по аномалиям, подозрительным DNS и деградации соединений. По умолчанию этот режим выключен.

Вывод

netwatch - это удобный сетевой TUI, который объединяет интерфейсы, соединения, DNS, health checks и packet capture в одном окне.

LinuxCamp | #utils

sk(skim): fuzzy search быстрее fzf на Rust

sk - это утилита берет список строк из stdin, открывает интерактивный выбор и фильтрует строки по нечеткому совпадению. Проект активно развивается: постоянно выходят релизы с обновлениями производительности и интерфейса.

Установка:

cargo install skim

Запуск на простом списке:

printf "nginx\npostgres\nredis\ndocker\n" | sk

Как использовать

sk читает входной поток и дает быстро выбрать нужную строку. Это удобно для файлов, процессов, веток Git, истории команд и любых списков, которые уже умеет отдавать shell. Есть сценарии с find, git branch и shell integration.

Примеры:

find . -type f | sk

git branch | sk

ps aux | sk

Если нужно превью выбранного файла:

find . -type f | sk --preview 'bat --color=always {}'

Почему полезен

skim полезен там, где уже есть длинный текстовый вывод и нужен быстрый интерактивный выбор. Не писать длинные grep, не листать сотни строк руками, а просто сузить список и выбрать нужное.

Вывод

skim(sk) - это простой способ превратить любой список строк в удобный интерактивный выбор. Одна утилита, один pipe, и терминал становится заметно быстрее.

LinuxCamp | #utils

netcat (nc): утилита, которая просто открывает TCP и UDP

netcat (nc) - это консольная утилита для работы с TCP и UDP. Через нее можно открыть соединение, поднять простой listener, проверить порт, отправить данные в сокет или быстро посмотреть, отвечает ли сервис. Во многих Linux-системах это одна из самых базовых сетевых утилит.

Базовые примеры

Проверить, открыт ли TCP-порт:

nc -zv 127.0.0.1 80

Проверить сразу несколько портов:

nc -zv 127.0.0.1 22 80 443

Проверить UDP-порт:

nc -zvu 127.0.0.1 53

Поднять listener на порту:

nc -lv 9000

Подключиться к нему с другой стороны:

nc 127.0.0.1 9000

Где полезен

nc удобен для быстрой сетевой диагностики. Проверить доступность сервиса, убедиться что порт слушает, вручную отправить запрос в TCP-соединение, посмотреть сырой ответ, протестировать локальный listener без лишних инструментов.

Например, можно руками отправить HTTP-запрос:

printf "GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n" | nc example.com 80

Или быстро проверить, слушает ли порт внутри сервера:

nc -zv localhost 5432

Даже можно отправить файл не используя ssh, rsync или scp:

На принимающей стороне:

nc -l 9000 > output.bin

На отправляющей стороне:

nc -N <хост получателя> 9000 < input.bin

Это просто сырая передача байтов через TCP-соединение.

Что важно

У netcat есть разные реализации: openbsd-netcat, gnu netcat, ncat. Из-за этого некоторые флаги могут немного отличаться. Но базовые сценарии обычно одинаковые: connect, listen, scan, send data.

Вывод

nc - это простой и полезный инструмент для TCP/UDP-проверок. Когда нужно быстро понять, жив ли порт и что реально отвечает по сокету, netcat обычно оказывается самым коротким путем.

LinuxCamp | #utils

isd: systemd, но в нормальном TUI

isd расшифровывается как interactive systemd. Это TUI-утилита для работы с systemd units: сервисами, таймерами, сокетами и user/system unit’ами. Вместо постоянного набора systemctl status, journalctl, restart, enable можно открыть один интерфейс и искать нужные юниты через fuzzy search.

Что умеет

Внутри можно быстро переключаться между system и user units, смотреть превью статуса, открывать вывод в pager/editor, работать с командами через command palette и не писать каждый раз длинные systemctl-команды руками. Запуск выглядит просто:

isd

Установить можно через uv, nix или AppImage. Например, если используешь uv:

uv tool install isd-tui
isd

Где полезно

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

systemctl status nginx
journalctl -u nginx -f
systemctl restart nginx

С isd это можно делать из одного TUI, не вспоминая каждый раз точное имя юнита.

Вывод

isd не заменяет знание systemctl, но сильно ускоряет повседневную работу с systemd. Хорошая штука для серверов, dev-машин и ситуаций, когда юнитов много, а руками искать их уже надоело.

LinuxCamp | #utils

Как вам такое DE, братва?

LinuxCamp

Linux впервые в истории взял 5% в Steam

Доля пользователей Linux на Steam достигла 5% по данным опроса Valve за март 2026 года.

Для контекста, как Linux рос:

ноябрь 2024 — 2%
ноябрь 2025 — 3%
март 2026 — 5.33%

При ~132 млн пользователей Steam в месяц это около 7 млн геймеров на Linux.

Расклад по платформам в марте:

Windows — 92.33% (-4.28%)
Linux — 5.33% (+3.10%)
macOS — 2.35%

LinuxCamp | #news

Shellfirm: защита от опасных команд в терминале

Shellfirm — это предохранитель для shell-команд. Он перехватывает рискованные команды перед выполнением и просит дополнительное подтверждение. Например, если ты случайно запускаешь что-то вроде:

rm -rf /
git reset --hard
kubectl delete namespace prod

Shellfirm может остановить выполнение и показать предупреждение.

Как работает

Утилита встраивается в shell через hook и проверяет команду перед запуском. Установка:

cargo install shellfirm

Инициализация:

shellfirm init

После перезапуска shell можно проверить:

git reset --hard

Команда не выполнится молча: Shellfirm должен показать предупреждение.

Вывод

Shellfirm — простой предохранитель для терминала. Можно использовать как дополнительный слой проверки перед выполнением опасных действий.

LinuxCamp | #utils

socktop: удаленный мониторинг сервера по WebSockets

socktop — это TUI-мониторинг для удалённых Linux-машин. На сервере запускается лёгкий агент, а ты со своей машины подключаешься к нему через WebSocket и смотришь метрики в терминале. По стилю похоже на top/btop, но с удалённым подключением.

Что показывает

В интерфейсе есть CPU, память, swap, диски, сеть, температуры и список процессов. Агент не крутит постоянный сборщик метрик в фоне: он собирает данные по запросу клиента. Когда никто не подключён, нагрузка почти нулевая.

Как запустить

Установка через cargo:

cargo install socktop
cargo install socktop_agent

На сервере:

socktop_agent --port 3000

На своей машине:

socktop ws://SERVER_IP:3000/ws

Для локального демо без отдельного сервера:

socktop --demo

Важный нюанс

Если открываешь агент не только в локальной сети, лучше включить TLS и токен.

SOCKTOP_TOKEN=changeme socktop_agent --enableSSL --port 8443

Подключение:

socktop --tls-ca /path/to/cert.pem \
  "wss://SERVER_IP:8443/ws?token=changeme"

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

Вывод

socktop полезен, когда хочется смотреть состояние удалённого сервера без SSH-сессии с htop, iotop и кучей отдельных команд.
Для домашней лаборатории, Raspberry Pi, dev-серверов и небольших стендов очень приятный вариант.

LinuxCamp | #utils

Бэкапы БД отдельным контейнером

container-db-backup — Docker-образ для регулярных бэкапов баз данных. Поддерживает PostgreSQL, MySQL/MariaDB, MongoDB, Redis, SQLite, MSSQL, CouchDB и InfluxDB. Бэкапы можно складывать в локальную папку, S3-compatible storage, MinIO, Wasabi или Azure.

Как работает

Ты добавляешь отдельный контейнер рядом с базой, задаёшь параметры через env-переменные, а он по расписанию делает dump. Пример для PostgreSQL:

services:
  db-backup:
    image: docker.io/tiredofit/db-backup:latest
    volumes:
      - ./backups:/backup
    environment:
      - DB01_TYPE=pgsql
      - DB01_HOST=postgres
      - DB01_NAME=app
      - DB01_USER=app
      - DB01_PASS=secret
      - DEFAULT_BACKUP_INTERVAL=1440
      - DEFAULT_COMPRESSION=ZSTD


DB01, DB02, DB03 — это разные backup job’ы. Так можно одним контейнером бэкапить несколько баз.

Что умеет

Можно настроить расписание, сжатие, checksum, шифрование, очистку старых архивов, pre/post hooks и уведомления при ошибках в email, Matrix, Mattermost или Rocket.Chat. Ручной запуск тоже есть:

docker exec -it db-backup backup-now

А для отдельной задачи:

docker exec -it db-backup backup01-now

Важный нюанс

Бэкап это не только файл в папке. Его нужно периодически проверять восстановлением. У образа есть restore-скрипт, но поддержка восстановления заявлена только для MariaDB, Postgres и MongoDB. Для остальных лучше заранее проверить свой сценарий руками.

Вывод

container-db-backup — удобный вариант, если хочется быстро добавить scheduled backups в Docker Compose без отдельного cron-скрипта. Но после настройки обязательно проверь restore, иначе это не бэкап, а просто архив с надеждой.

LinuxCamp | #utils

Не все любят AI

Пока Linux ядро стремительно превращается в вайбкод проект, многие другие опенсорс тулзы запрещают любые AI-контрибьюции

- QEMU — "Политика проекта – отклонять любые контрибьюции, если есть основания полагать, что они включают в себя AI-сгенерированный контент или основаны на нём».

- NetBSD — код, сгенерированный AI, «считается потенциально заражённым кодом и не должен попадать в коммит».

- Zig — полный запрет на использование AI в любом виде:

«Никакого LLM-сгенерированного контента», «Никаких LLM для перевода», «Никаких LLM для поиска багов»

- OBS Studio — «Код должен быть написан человеком».

LinuxCamp | #news

Системные вызовы и syscall в Linux: как программа стучится в ядро

Каждый раз, когда программа читает файл, открывает сокет или печатает строку в терминал, она не делает это сама. Она просит об этом ядро. Механизм этой просьбы называется системным вызовом syscall.

Что это

Syscall - это запрос программы к ядру на операцию, которую ей не дают сделать напрямую: доступ к диску, сети, памяти, процессам. Это единственный легальный вход из твоего кода внутрь ядра.

Два пространства

Программы работают в user space с урезанными правами. Ядро и железо живут в kernel space. Между ними стену ставит сам процессор: приложения крутятся в кольце защиты ring 3, ядро в ring 0. Дёрнуть драйвер диска из обычного процесса нельзя, можно только попросить ядро.

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

Примеры

Базовые сисколы, на которых держится почти всё:

int fd = open("file.txt", O_RDONLY); // открыть файл
read(fd, buf, 1024);                 // прочитать данные
write(1, "hello\\n", 6);             // записать в stdout
close(fd);                           // закрыть

А ещё fork() порождает новый процесс, execve() запускает программу, mmap() выделяет память. В Linux x86-64 их несколько сотен.

Под капотом

То, что в C выглядит как обычная функция, на деле оказывается переходом в ядро. Номер сисколла кладётся в регистр rax, аргументы в rdi, rsi, rdx, а инструкция syscall передаёт управление ядру:

mov rax, 1     ; номер вызова write
mov rdi, 1     ; fd = stdout
mov rsi, msg   ; адрес буфера
mov rdx, 6     ; длина
syscall        ; прыжок в kernel space

libc

Руками syscall почти никто не пишет: между тобой и ядром стоит glibc. Функция write() из unistd.h это тонкая обёртка: разложить аргументы по регистрам и вызвать syscall. Поэтому «функция» и «системный вызов» не одно и то же: printf() это функция libc, а write() под ней уже настоящий syscall.

strace

Хочешь увидеть все сисколы программы вживую:

strace ./program     # все вызовы подряд
strace -c ls         # сводка с подсчётом и таймингами

Вывод покажет каждый open, read и write с аргументами и кодом возврата. Незаменимо для отладки и реверса.

Итог

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

LinuxCamp | #utils

Кто трогал сервер: ищем следы в Linux

Иногда на сервере что-то сломалось, а вопрос один:

кто заходил, когда заходил и что менял?

В Linux часть ответов можно найти без отдельного мониторинга. Но важно понимать: стандартные логи показывают не всё, а историю команд легко удалить.

Кто заходил на сервер

Посмотреть последние входы пользователей:

last

Неудачные попытки входа:

lastb

Текущие активные сессии:

who
w

Для SSH обычно полезно смотреть auth-логи:

grep "sshd" /var/log/auth.log

На RHEL/CentOS/AlmaLinux путь чаще такой:

grep "sshd" /var/log/secure

Кто выполнял команды

У каждого пользователя есть история shell:

cat ~/.bash_history

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

echo 'export HISTTIMEFORMAT="%F %T "' >> ~/.bashrc
source ~/.bashrc

После этого history будет показывать время выполнения команд:

history

Кто менял файлы

Посмотреть время изменения файла:

stat /etc/nginx/nginx.conf

Найти файлы, изменённые за последний день:

find /etc/nginx -type f -mtime -1 -ls

За последние 60 минут:

find /etc/nginx -type f -mmin -60 -ls

Но stat и find покажут время изменения, а не имя пользователя, который это сделал. Если нужно именно кто изменил файл, заранее включают auditd:

apt install auditd

Добавить наблюдение за файлом:

auditctl -w /etc/nginx/nginx.conf -p wa -k nginx_config

Потом искать события:

ausearch -k nginx_config

Вывод

last, auth.log, history, stat и find помогают быстро понять, что происходило на сервере. Но если нужно точно знать, кто менял важные файлы, лучше заранее включить auditd. Без него Linux часто покажет когда файл изменили, но не всегда покажет кем.

LinuxCamp | #utils