LinuxCamp | DevOps

Замечал странную штуку: дел не так уж много, но любое – как будто через сопротивление? Не то чтобы лень. Просто не делается и все тут! Зато видосики на Ютубе залетают на ура... Попался годный разбор, советую посмотреть, если тоже чувствуешь, что превращаешься в апатичного зомби 👉🏼 https://t.me/Manifestans Мысль, которая зашла: когда перестаешь понимать "чего хочу Я", даже нормальная жизнь ощущается, как каторга. Кликай сюда, чтобы разобраться, что с тобой происходит и как снова начать испытывать ощущение, что ты живешь, а не существуешь.

Herdr: tmux для AI-агентов Herdr - терминальный мультиплексор для работы с AI-агентами. По смыслу похоже на tmux: есть сессии, workspace’ы, вкладки и панели. Но сверху добавлена важная штука: Herdr понимает состояние агентов: кто работает, кто завис, кто ждёт подтверждения, а кто уже закончил. Можно держать несколько агентов в одном терминале и быстро видеть их статус:

blocked — ждёт ввода или approval
working — выполняет задачу
done    — закончил работу
idle    — завершён и просмотрен

Панели - это реальные terminal-процессы, а не перерисованная GUI-обёртка. Поэтому внутри можно запускать Claude Code, Codex, Copilot CLI, Cursor agent CLI, opencode, Kimi Code CLI и другие агенты. Как запустить Установка:

curl -fsSL https://herdr.dev/install.sh | sh

Через Homebrew:

brew install herdr

Запуск в папке проекта:

herdr

Базовое управление похоже на tmux:

ctrl+b, затем v        split pane
ctrl+b, затем c        new tab
ctrl+b, затем w        switch workspace
ctrl+b, затем q        detach

После detach процессы продолжают работать. Открыл другой терминал, снова запустил herdr и вернулся в ту же сессию. Важный нюанс Herdr не GUI и не Electron-приложение. Он живёт прямо в терминале. Но это всё равно отдельный мультиплексор. Если у тебя уже всё построено на tmux, нужно будет понять, удобно ли добавлять ещё один слой поверх привычного workflow. Вывод Herdr полезен, если ты реально работаешь с несколькими AI-агентами параллельно. Это не замена tmux для всех задач, а более специализированный терминальный менеджер под agentic coding. 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

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

✅ 16 июня в 17:00 разберем как в 10 раз увеличить скорость разработки с помощью КодГрифон – AI-оркестратор для всего цикла разработки: от бизнес-запроса и плана до кода, проверок, документации, метрик и релиза.

  На вебинаре вы узнаете: 🔹где именно в вашей разработке теряется скорость 🔹как понять, какие этапы можно ускорить с помощью AI-среды 🔹как работать в закрытом контуре и не терять контроль над кодом и контекстом 🔹какие метрики смотреть, чтобы оценить реальный эффект 🔹как применить КодГрифон под конкретный кейс вашей команды

Также участники получат подарок — бесплатные глифы для тестирования КодГрифон 🔥

➡️ Регистрация на вебинар

Системные вызовы и 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

Не все любят AI Пока Linux ядро стремительно превращается в вайбкод проект, многие другие опенсорс тулзы запрещают любые AI-контрибьюции - QEMU — "Политика проекта – отклонять любые контрибьюции, если есть основания полагать, что они включают в себя AI-сгенерированный контент или основаны на нём». - NetBSD — код, сгенерированный AI, «считается потенциально заражённым кодом и не должен попадать в коммит». - Zig — полный запрет на использование AI в каком бы то ни было виде. «Никакого LLM-сгенерированного контента», «Никаких LLM для перевода», «Никаких LLM для поиска багов», «Никаких обсуждений использования чатботов/LLM-сервисов». - OBS Studio — «Код должен быть написан человеком».

SRE тут? Нашли для вас подкаст, который вполне может пополнить ряд любимых. Коллеги из Авито создали «В SREду на кухне», периодически собираются, зовут на запись гостей и обсуждают то, о чём не принято говорить в опенспейсе. Например, вот темы недавних выпусков: — GitOps не волшебная таблетка; — Зачем продукту бюджет ошибок; — Роняем прод, чтобы стать сильнее: всё о Chaos Engineering; — SRE больше не нужны. AI переписал правила. Отвечая на вопрос «А при чём здесь комьюнити?» — все дополнительные инсайты, статьи и мысли на темы выпусков ребята выкладывают в канал «Avito SREда». И там уже собралась активная аудитория коллег-инженеров.

Ядро Linux уже чисто ИИ пишет За последние пару недель количество новых коммитов, помеченных как “Assisted-by” ИИ-ассистентом (например, Claude), буквально взлетело. Каждый день отправляются огромные пачки изменений, написанных в режиме вайб-кодинга 🫶

На Stepik запустили мощный курс по «Troubleshooting Docker и Kubernetes: поиск и устранение проблем» В программе только важные аспекты: — troubleshooting Docker и образов — диагностика сетевых проблем — настройка readiness/liveness probes — отладка pod’ов, деплоев и ingress — анализ логов контейнеров и кластера — разбор ошибок CrashLoopBackOff, OOMKilled, ImagePullBackOff и других Собеседования на DevOps/SRE сейчас всё чаще строятся вокруг реальных инцидентов. Данный курс фокусируется именно на таких сценариях и помогает в подготовке к практическим вопросам 48 часов доступен со скидкой 25% ↗️ Пройти курс на Stepik

Бэкапы БД отдельным контейнером 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

💻А вы уже записались на бесплатный курс для начинающих системных администраторов? Начните работать с Linux на курсе от Академии Selectel. Вы научитесь: — работать с командной строкой Linux и основными утилитами, — управлять пакетами и обновлениями ПО, — настраивать сети, SSH-соединения и мониторинг системы, — управлять пользователями, файлами и правами доступа. Все уроки и практика уже доступны, проходите в комфортном для себя темпе. 👉Начните обучение: https://slc.tl/2e1tj Реклама. АО "Селектел". erid:2W5zFHHpqgM

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

Если при слове «облако» вы думаете не о небе, а об инфраструктуре и сетях — вам понравится канал «Кучевые АйТи». Здесь команда компании «Облакотека» пишет о развитии облачных технологий и о том, как превратить инфраструктурный хаос в удобные виртуальные решения для бизнеса. Читайте в канале: Вы же видели новость о том, как ИИ-агент в Cursor за 9 секунд удалил основную базу и все бэкапы стартапа PocketOS. Как держать ИИ на коротком поводке? Читать в канале Не NVIDIA единой. Разбираемся на практике, что находится за пределами привычного стека и почему иногда стоит туда заглянуть. Читать в канале Если в компании очередь к DWH-команде длиннее, чем в поликлинике, то Data Mesh придумали для вас. Рассказываем, в чем суть подхода и как он применяется на практике. Читать в канале Подписаться: t.me/oblakoteka

Полный курс по вайбкодингу с Claude Code (за 1.5 часа) 😁 По полочкам разложил весь багаж знаний по работе с Claude Code:

— Установка, оплата, настройка — MCP, субагенты, скиллы, команды — git/github, x100 к скорости работы через "Git Worktrees" — Деплой на выделенный сервер (как делают взрослые дяди): покупка домена, аренда сервера, настройка DNS, сборка через dokploy

Рассказываю, что сам использую в работе и почему. Ценю ваше время, поэтому сжал 7 часов лайва в 1.5 😊 Видео забирай бесплатно по ссылке

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

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

ОДНА eSIM — СВЯЗЬ БЕЗ ГРАНИЦ Когда обычный интернет падает — связь должна работать. У наших друзей в EsimWorld появились международные eSIM-карты — стабильный интернет там, где другие сети сдаются. 🌍 Интернет без VPN, блокировок и бесконечного «сайт недоступен» ⚡️ Быстрое подключение по QR-коду 📡 135+ стран в одном eSIM-профиле 💬 Связь для работы, общения, путешествий и повседневной жизни 🛰 Работает там, где нужен настоящий доступ к сети ✅ Все сервисы доступны без лишних приложений ✅ Подключение за пару минут ✅ Удобно в поездках и за границей ✅ Один профиль — весь мир на связи EsimWorld — экскаватор в мире связи. Прокладываем интернет там, где другие не могут. 🤖 @esimwrldbot 🛟 Поддержка: @esim_sup

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