🔄 Вышла OpenBSD 7.9

OpenBSD 7.9 — 60-й релиз проекта. В комплекте LibreSSL 4.3.0, OpenSSH 10.3, DRM от Linux 6.18.22.

Ядро

В планировщике появился механизм управления ядрами CPU с разной производительностью. Через sysctl hw.blockcpu задаются категории ядер (SMT, Performance, Efficient, Lethargic), медленные можно исключить. Работает на amd64 и arm64.

Спинлок в мьютексах ядра заменён на «parking» блокировку. Добавлена инфраструктура для до 52 разделов на диск. MAXCPUs на amd64 увеличен до 255.

Новый machdep.hibernatedelay будит систему из suspend через заданное время и уводит в гибернацию. Полезно для ноутбуков, чтобы не разряжать батарею во сне.

Безопасность

Root больше не обходит bpf(4) BIOCLOCK. Удалён pledge-промис tmppath, его заменяет unveil + pledge "rpath wpath cpath". Новый вызов __pledge_open(2) позволяет libc открывать внутренние файлы под pledge/unveil строго на чтение.

Сеть и pf

veb(4) стал VLAN-aware бриджем с PVID, trunk/hybrid портами и Private VLAN (RFC 5517). IPv6 SLAAC включён по умолчанию. В pf(4) добавлены source/state лимитеры с настраиваемым действием при достижении лимита.

VMM/VMD

Добавлен vmboot для sysupgrade(8) внутри vmd-виртуалок. OpenBSD работает на Apple Virtualization. Поддержка AMD SEV. Исправлены рейсы и дедлоки в vmd(8)/vmm(4).

Драйверы и Wi-Fi

Новые драйверы: USB4 (nhi(4)), Intel LPSS SPI (ispi(4)), SpacemiT K1 (riscv64), Rockchip RK3588/RK3576, Sophgo SG2042. Базовая поддержка 802.11ax. В iwx(4) — 160 МГц, WiFi 6e, PMF и powersave по умолчанию.

OpenSSH 10.3

Исправлены уязвимости: shell-инъекция через метасимволы в именах пользователей, некорректное сопоставление principals в сертификатах, обход PubkeyAcceptedAlgorithms для ECDSA. Добавлен штраф invaliduser в PerSourcePenalties.

LibreSSL 4.3.0

Поддержка MLKEM768_X25519 keyshare в TLS (пост-квантовая криптография). Исправлен off-by-one в X.509-верификаторе с перезаписью 4 байт в хипе. TLSv1.1 и ниже отключены на уровне метода.

➡️ Репозиторий

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии

sub /proglib/newsletter

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пятничный_деплой

🧐 Дашборд, чтобы не разбирать Crossplane через kubectl

Crossplane управляет инфраструктурой через Kubernetes-ресурсы, но наблюдать за ними из терминала неудобно. Провайдеры, композиции, XRD, клеймы — всё приходится доставать через kubectl get и разбирать вручную. Crossview — веб-дашборд, который показывает ресурсы Crossplane в одном интерфейсе с поиском, фильтрацией и отслеживанием статусов в реальном времени.

Что умеет

Crossview подключается к Kubernetes API через Informers и отслеживает изменения ресурсов без постоянных запросов. Обновления приходят по WebSocket. Поддерживается работа с несколькими кластерами — переключение между контекстами прямо из UI.

Для каждого ресурса доступны статус-условия, метаданные, события и связи с другими объектами. Есть тёмная тема и SSO через OIDC/SAML.

Стек

Фронтенд — React + Vite + Chakra UI. Бэкенд — Go (Gin) + client-go. БД — PostgreSQL (GORM).

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

Через Helm:

helm repo add crossview https://corpobit.github.io/crossview
helm repo update
helm install crossview crossview/crossview \
  --namespace crossview \
  --create-namespace \
  --set secrets.dbPassword=your-db-password

Через Docker Compose (в репозитории есть готовый файл с PostgreSQL):

docker-compose up

Для локальной разработки фронтенд и бэкенд запускаются отдельно:

npm install && npm run dev
cd crossview-go-server && go run main.go app:serve

Фронтенд на localhost:5173 проксирует API на бэкенд (localhost:3001).

API

Бэкенд предоставляет REST API на порту 3001:

GET /api/contexts — список Kubernetes-контекстов
GET /api/resources?apiVersion=&kind= — список ресурсов
GET /api/resource?apiVersion=&kind=&name= — детали ресурса
GET /api/events?kind=&name= — события ресурса
GET /api/watch — WebSocket для real-time обновлений

При запуске в кластере бэкенд автоматически использует service account без kubeconfig.

➡️ Репозиторий

📰 Наша подписка как дашборд, но приходит сама

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

😎 Найм по вайбу
 
86% команд работают по Agile. И именно в agile-культуре «совместимость по вайбу» превращается в главный критерий найма. Проблема в том, что исследования фиксируют прямую связь между vibe hiring и текучкой кадров.
 
Как это работает изнутри, что показывают данные по 70 000 кандидатам и почему AI-рекрутер в этом контексте нанимает объективнее человека — всё в статье 👈

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

🤔 HTTP-кэширование и CDN для API

GET-запросы к API кэшируются на уровне CDN — это снижает нагрузку и ускоряет ответы. Но одна ошибка в заголовках, и клиенты часами видят протухшие данные.

Попробуйте ответить: какие заголовки и механизмы нужны, чтобы кэш работал корректно, а инвалидация была точечной?

➡️ Проверить ответ можно в канале с ответами на собесы

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#задача_со_звёздочкой

🤩 Canonical выпустила Ubuntu Core 26

Canonical объявила о выходе Ubuntu Core 26 — минимальной неизменяемой ОС с поддержкой обновлений безопасности до 15 лет. Релиз ориентирован на IoT, edge-устройства и критическую инфраструктуру.

Что нового

OTA-обновления стали на 50–90% легче благодаря новому формату snap-delta. Обновление базовых snap-пакетов ядра теперь весит 1.5 МБ вместо прежних 16 МБ. Установка через initramfs убирает лишние перезагрузки, а значит устройства быстрее вводятся в строй.

Сборка образов теперь работает через Chisel. Каждый файл в файловой системе привязан к конкретному slice и исходному пакету. Это даёт точную трассировку зависимостей и упрощает проверку целостности. В сравнении с Yocto, где зависимости скрыты в слоях рецептов, подход Core 26 делает происхождение каждого компонента явным. Бонусом базовый образ похудел на 7%.

Для шифрования дисков (FDE) ключи TPM теперь хранятся прямо в заголовке LUKS2, что снижает риск повторного использования ключей между состояниями устройства. Появилась нативная интеграция с OP-TEE для ARM TrustZone — ключи шифрования запечатываются и распечатываются внутри Trusted Execution Environment.

Livepatch впервые работает на ARM64, обеспечивая патчинг ядра без перезагрузки. На AMD64 Livepatch официально поддерживается для всех версий, начиная с Ubuntu Core 20.

Из инструментария: Ubuntu Frame теперь поддерживает несколько графических приложений на одном дисплее с настраиваемой раскладкой. Появился интерфейс gpu-2604 для аппаратного ускорения графики.

В Snapcraft добавили компоненты — способ распространять крупные или опциональные ресурсы: драйверы, символы отладки, переводы; отдельно от основного snap-пакета.

Релиз важен для тех, кто готовится к EU Cyber Resilience Act. Canonical берёт на себя обязанности «производителя» по CRA в рамках жизненного цикла ОС и обеспечивает мониторинг CVE, координированное раскрытие уязвимостей и соответствие IEC 62443-4-1.

➡️ Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пятничный_деплой

😺 Kitty 0.47 — drag-and-drop из терминала, прогресс-бары и авто-перезагрузка конфига

Вышла версия 0.47 GPU-ускоренного эмулятора терминала kitty. Главное в этом релизе — новый kitten для drag-and-drop, который позволяет перетаскивать файлы прямо из шелла в GUI-приложения. Работает даже через SSH-сессии.

Drag-and-drop внутри kitty

Помимо нового kitten'а, переработали взаимодействие с окнами. Теперь окна можно перетаскивать мышью между табами и OS-окнами, а также отсоединять в отдельное окно. При перетаскивании можно временно показать заголовки окон через действие toggle_window_title_bars.

Авто-перезагрузка конфига

Появилась опция auto_reload_config. Больше не нужно вручную перезагружать kitty после правки конфигурации — изменения применяются сами.

Прогресс-бар

Kitty теперь отображает прогресс-бар в верхней части окна, когда программа сообщает о прогрессе через escape-последовательность OSC 9;4. Поведение управляется через опцию progress_bar.

Генерация палитры

Новая опция palette_generate автоматически строит 256-цветную палитру на основе первых 16 цветов. Полезно, если вы настраиваете тему и хотите согласованную палитру без ручной работы.

Скроллинг

Действия scroll_line_up и scroll_line_down теперь по умолчанию используют плавный скроллинг. Если нужно вернуть старое поведение, пересоздайте маппинг без аргумента smooth. На Wayland жест удержания (hold) теперь останавливает инерционный скроллинг при касании трекпада.

Фоновые изображения

Можно указать несколько записей background_image, и все они хранятся на GPU. Переключение между фонами стало быстрее.

Фокус

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

Платформенные изменения

На Linux kitty учитывает fontconfig matrix для fake slant шрифтов без курсива. Исправлена проблема с искажением цветов на Nvidia после выхода из suspend. На X11 устранён краш при отключении устройства ввода. На macOS — новая иконка в стиле Tahoe с отдельными фонами для светлой и тёмной темы, исправлены фантомные курсоры и работа аргументов через open --args.

Прочее

В выводе kitten @ ls появились поля session_name и last_focused_at. В diff kitten'е добавились sticky-заголовки. Улучшена производительность рендеринга таб-бара при использовании данных активных процессов. Добавлена поддержка отрисовки Unicode-символов из блока Symbols for Legacy Computing Supplement.

➡️ Полный список изменений

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии

📰 Предпоследняя неделя мая

Недельку поработать и уже лето. А мы пока собрали новостей.

— RHEL 10.2 и 9.8

Red Hat выпустила обновы для своего дистрибутива. В терминале появился AI-ассистент goose с поддержкой стриминга и MCP. Обновились тулсеты: Go 1.26, Python 3.14, Ruby 4.0, OpenJDK 25, PostgreSQL 18, MariaDB 11.8.

— Шумахер посчитал строки кода в KDE

— В Linux добавили правила для AI-репортов

— OpenBSD 7.9

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#дайджест_недели

👩‍💻 Bash-скрипт для мониторинга сервисов

Полноценный мониторинг вроде Zabbix или Prometheus не всегда оправдан, особенно на небольших проектах или dev-серверах. Иногда достаточно простого скрипта, который проверит список сервисов и скажет, что именно не работает.

Ниже готовый скрипт с проверкой через systemctl и отправкой уведомлений в Telegram.

Базовая версия

Создаём файл:

nano check_services.sh

Содержимое:

#!/bin/bash
SERVICES=("nginx" "postgresql" "redis" "ssh")

echo "===== СТАТУС СЕРВИСОВ ====="
echo ""

for SERVICE in "${SERVICES[@]}"; do
    STATUS=$(systemctl is-active "$SERVICE" 2>/dev/null)
    if [ "$STATUS" = "active" ]; then
        echo "[OK]     $SERVICE"
    else
        echo "[УПАЛ]   $SERVICE"
    fi
done

Даём права и запускаем:

chmod +x check_services.sh
./check_services.sh

Массив SERVICES правите под свой стек. Вывод будет примерно таким:

===== СТАТУС СЕРВИСОВ =====

[OK]     nginx
[OK]     postgresql
[УПАЛ]   redis
[OK]     ssh

Версия с уведомлением в Telegram

Базовая версия показывает результат в консоли. Но если скрипт работает по cron, вы его вывод не увидите. Добавим отправку сообщения в Telegram при обнаружении упавшего сервиса.

Для этого понадобится бот и chat_id. Бота создаёте через @BotFather, chat_id получаете через @userinfobot или из API бота после отправки ему любого сообщения.

#!/bin/bash
SERVICES=("nginx" "postgresql" "redis" "ssh")

BOT_TOKEN="123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11"
CHAT_ID="987654321"

FAILED=""

for SERVICE in "${SERVICES[@]}"; do
    STATUS=$(systemctl is-active "$SERVICE" 2>/dev/null)
    if [ "$STATUS" != "active" ]; then
        FAILED="${FAILED} ${SERVICE}\n"
    fi
done

if [ -n "$FAILED" ]; then
    HOSTNAME=$(hostname)
    MESSAGE=" Проблема на ${HOSTNAME}\n\nУпавшие сервисы:\n${FAILED}"
    curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
        -d chat_id="$CHAT_ID" \
        -d text="$(echo -e "$MESSAGE")" \
        -d parse_mode="HTML" > /dev/null
fi

Скрипт отправляет сообщение только когда что-то упало. Если все сервисы работают, он молчит и не спамит в чат.

Добавляем в cron

Открываем crontab:

crontab -e

Добавляем строку для проверки каждые 5 минут:

*/5 * * * * /path/to/check_services.sh

Что можно доработать

Скрипт намеренно простой, но его легко расширить. Например, добавить автоматический перезапуск упавшего сервиса через systemctl restart "$SERVICE" прямо в блоке проверки. Или писать результаты в лог-файл для истории. Если серверов несколько, можно запускать скрипт удалённо через ssh в цикле по списку хостов.

Для продакшена с десятками сервисов и серверов лучше смотреть в сторону полноценных решений. Но для пары серверов этот скрипт закрывает задачу за пять минут настройки.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#root_prompt

⚙️ AI-агенты как Terraform-ресурсы

В DevOps-сообществе набирает обороты идея: описывать AI-агентов в Terraform так же, как мы описываем инфраструктуру. Не просто поднимать под них compute и сеть, а определять самого агента как ресурс со всей его конфигурацией.

Зачем это вообще нужно

Агент сегодня это не «модель + промпт». Это набор компонентов: системный промпт, sandbox, MCP-серверы, навыки, хуки, секреты, параметры модели, сетевые доступы.

Ещё недавно у многих был один конфиг Claude Code в одном репозитории. Сейчас — research-агент, writing-агент, coding-агент, агент для ежедневных саммари. И это персональное использование. На уровне команды агентов десятки.

Вопрос логичный: как всё это конфигурировать, версионировать, воспроизводить между окружениями?

Аргументы против

Terraform хорош для стабильной инфраструктуры, а не для runtime-сущностей, которые меняют поведение. Разрешения, секреты, очереди, guardrails — это в Terraform. Сам агент, его конфиг и версионирование — ближе к слою приложения.

Ещё проще: агенты — это софт. Управляйте ими как софтом. Возможно, часть инфраструктуры под агента действительно описывается через Terraform, но сам агент — нет. Это обычный веб-сервис, который принимает запрос, обогащает его и отправляет LLM-провайдеру.

Есть и аргумент про саму природу Terraform. Его ценность — в drift management и reconciliation. Если стейт агента не может реально «дрифтовать» в том смысле, в котором дрифтует облачная инфраструктура, то Terraform здесь не нужен. Хватит обычного CI/CD и application image. Сетевой слой — да, через Terraform. Но весь «стек» агента — вряд ли.

Аргументы за

С точки зрения MLOps всё выглядит иначе. Вся инфра для AI-проектов описывается в TF сверху донизу, и это ничем не отличается от любого другого облачного проекта. Магии в MLOps нет — это DevOps в другой шляпе. AWS уже позволяет описывать Bedrock-агентов через aws_bedrockagent_agent, и это работает.

Где граница

Спор сводится к одному вопросу: где заканчивается инфраструктура и начинается приложение?

Terraform хорошо управляет тем, что декларативно, стабильно и должно быть одинаковым между окружениями. IAM-роли, сетевые политики, секреты, очереди — всё это ложится в .tf файлы без вопросов.

Но системный промпт, набор MCP-инструментов, логика планирования — это части, которые меняются часто и зависят от контекста. Класть их в Terraform значит получить медленный цикл обратной связи: plan → apply на каждое изменение промпта.

Единственного правильного ответа пока нет. Но сам факт, что DevOps-сообщество обсуждает управление агентами как инфраструктурную задачу, говорит о том, что количество агентов в продакшене растёт.

Агенты как ресурсы может и спорно, но наша рассылка точно только в плюс.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

☁️ Пора переходить на GraalVM Native Image

Spring Boot на JVM стартует 15–20 секунд и съедает ~300 МБ памяти в простое. В Kubernetes это означает полминуты бесполезного ожидания при каждом скейлинге, убитые liveness-пробы и initialDelaySeconds: 25 на каждом сервисе. А serverless с таким холодным стартом вообще не вариант.

GraalVM Native Image компилирует Java-приложение в нативный бинарник ещё на этапе сборки. Никакого JVM внутри, никакой интерпретации байткода. На выходе получаем старт за 60–90 мс и 55 МБ памяти в idle вместо 280.

Как это работает

GraalVM делает AOT-компиляцию (Ahead-of-Time). Статический анализатор проходит по всему коду и собирает в бинарник только то, что реально используется. Это называется closed-world assumption: всё, что не видно анализатору на этапе сборки, в бинарник не попадает. Мёртвый код, неиспользуемые библиотеки, весь JIT-компилятор — всё отсекается.

Отсюда же и главная проблема. Java активно использует рефлексию, динамическую загрузку классов и runtime-генерацию прокси. Статический анализатор этого не видит. Код соберётся, а в рантайме упадёт с ClassNotFoundException.

Spring Boot 3.x решает это через собственный AOT-движок: он заранее обрабатывает метаданные, подменяет динамические вызовы статическими и генерирует код регистрации бинов до компиляции.

Как собрать

В pom.xml добавляем плагин:

<build>
    <plugins>
        <plugin>
            <groupId>org.graalvm.buildtools</groupId>
            <artifactId>native-maven-plugin</artifactId>
        </plugin>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

Собираем нативный образ:

mvn -Pnative native:compile

Или через Docker (удобнее для CI/CD, не нужен локальный GraalVM):

mvn -Pnative spring-boot:build-image

Сборка занимает 3–8 минут даже для небольших сервисов. Это нормально — статический анализ и AOT-компиляция делают много работы. В пайплайне это отдельный шаг, не для быстрого фидбека.

Когда это нужно

JVM не устарела. Для сервисов с постоянной нагрузкой, где важен максимальный throughput после прогрева, обычный JVM с JIT по-прежнему лучший выбор.

GraalVM Native Image — для другого сценария: serverless-функции, сервисы, которые скейлятся до нуля ночью, event-driven обработчики с пиковой нагрузкой и долгими паузами, batch-задачи, которые запускаются раз в сутки.

➡️ Больше Java тут

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

✏️ Ещё один HTTP-клиент в терминале

Тестировать API через curl утомительно. Запросы длинные, плохо читаются, а сохранять их приходится в заметках или скриптах. Postman и Insomnia решают проблему, но тянут за собой тяжёлый GUI, аккаунты и облачную синхронизацию.

Slumber — это полноценный HTTP-клиент с интерфейсом в терминале, где вся конфигурация живёт в YAML-файле рядом с проектом.

Что делает Slumber

Slumber работает в двух режимах. TUI — интерактивный интерфейс в терминале, где можно выбирать запросы, отправлять их и просматривать ответы. CLI — для быстрых одноразовых вызовов и использования в скриптах. Оба режима читают одну и ту же конфигурацию, которая называется request collection.

Конфигурация хранится в файле slumber.yml. Это значит, что её можно коммитить в репозиторий и шарить между разработчиками. Не нужно экспортировать коллекции, пересылать JSON-файлы или синхронизировать через облако.

Проект написан на Rust, распространяется под лицензией MIT и останется бесплатным. На GitHub у него около 870 звёзд.

Как начать

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

brew install LucasPickering/tap/slumber

Или через Cargo:

cargo install slumber --locked

Для быстрого старта достаточно сгенерировать шаблон коллекции:

slumber new

После этого запускаем TUI одной командой:

slumber

Пример коллекции

Допустим, мы работаем с API на двух окружениях — локальном и продакшене. Файл slumber.yml будет выглядеть так:

profiles:
  local:
    data:
      host: http://localhost:5000
  production:
    data:
      host: https://myfishes.fish

requests:
  create_fish:
    method: POST
    url: "{{ host }}/fishes"
    body:
      type: json
      data: { "kind": "barracuda", "name": "Jimmy" }

  list_fish:
    method: GET
    url: "{{ host }}/fishes"
    query:
      big: true

Переменная {{ host }} подставляется из текущего профиля. Переключение между local и production делается прямо в TUI без правок файла.

Что ещё умеет

Slumber поддерживает шаблоны (templates), которые позволяют собирать запросы динамически — из результатов других запросов, файлов или вывода shell-команд. Ответы можно фильтровать через JSONPath прямо в интерфейсе. Если вы переезжаете с Insomnia, есть встроенный импорт коллекций. Также Slumber можно использовать как Python-пакет для интеграции в свои инструменты.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера