Библиотека девопса | DevOps, SRE, Sysadmin
10.4K subscribers
1.95K photos
76 videos
5 files
3.39K links
Все самое полезное для девопсера в одном канале.

По рекламе: @proglib_adv

Учиться у нас: https://proglib.io/w/25874ec4

Для обратной связи: @proglibrary_feeedback_bot

РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787
Download Telegram
👨‍💻 Terraform 1.15 — динамические источники модулей, deprecation переменных и другие обновления

Вышел Terraform 1.15. В этом релизе появились переменные в источниках модулей, механизм deprecation для переменных и output, функция convert для явного приведения типов и нативная поддержка Windows ARM64. Разберём основные изменения.

Динамические источники модулей

Раньше source в блоке module принимал только статическую строку. Теперь можно использовать переменные. Для этого добавлен новый атрибут const у переменных. Он принимает true или false и указывает, что значение доступно уже на этапе terraform init:
variable "folder" {
type = string
const = true
}


После этого переменную можно подставлять в source:
module "zoo" {
source = "./${var.folder}"
}


Важный момент — const нельзя сочетать с sensitive или ephemeral. Если вы сошлётесь на что-то кроме const-переменной, Terraform выдаст ошибку при init.

Deprecation переменных и output

Авторы модулей теперь могут помечать переменные и output как устаревшие через атрибут deprecated. При обращении к такому элементу Terraform покажет предупреждение на этапе валидации.

variable "bad" {
deprecated = "Please use 'good' instead, this variable will be removed"
}

output "old" {
value = "some_value"
deprecated = "Please use 'new' instead, this output will be removed"
}


Логика работает на нескольких уровнях. Если кто-то передаёт значение в deprecated-переменную через CLI или переменные окружения, будет warning. Если модуль ссылается на deprecated output дочернего модуля внутри своего deprecated output, предупреждение не сработает. Но если deprecated output стоит на корневом уровне, это уже ошибка.

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

Inline-приведение типов через convert

Новая функция convert решает давнюю проблему с неявным приведением типов. Terraform обычно сам определяет типы, но в ряде случаев это работает некорректно. Например, {} интерпретируется как пустой object без атрибутов, а не как пустой map. Аналогично [] — это пустой tuple, а не list.

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

Прочие изменения

Terraform 1.15 теперь собирается под Windows ARM64. Это актуально для владельцев Surface Pro, Windows Dev Kit 2023, а также для тех, кто запускает Windows-виртуалки на Mac M1/M2 через Parallels.

S3-бэкенд получил поддержку аутентификации через aws login (AWS CLI v2.32.0+). Это значит, что можно использовать credentials из консоли AWS без долгоживущих access-ключей.

У output-блоков появились type constraints — явные ограничения типа, аналогичные тем, что давно есть у input-переменных:
output "string" {
type = string
value = var.some_string
}


В Terraform Test теперь разрешены функции внутри mock-блоков. Можно генерировать тестовые данные через uuid() или format(), что упрощает мокирование ресурсов с конкретными форматами ID.

Для Stacks добавлены validation-блоки в переменных с атрибутами condition и error_message. Это помогает ловить ошибки конфигурации на раннем этапе.

Обнова за обновой выходит каждый день. Мы отбираем только самое важное для вас в нашей рассылке. 👉 Подпишитесь

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

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

#пульс_индустрии
Please open Telegram to view this post
VIEW IN TELEGRAM
2
📰 Топ 5 новостей недели

Debian 13.5

Обновлено больше сотни пакетов: закрыты CVE в apache2, openssh, systemd, sudo, glibc, nginx, curl, python3.13

NWinfo v1.6.3

Leaf 1.21.0

Что будет в Podman 6

nginx 1.31.0

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

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

#дайджест_недели
Please open Telegram to view this post
VIEW IN TELEGRAM
📎 Ловим drift в Terraform автоматически

Кто-то поправил инфраструктуру руками через консоль. Terraform об этом ничего не знает. При следующем terraform apply начинаются конфликты, откаты и разбор полётов. Это называется drift. Состояние инфраструктуры разошлось с тем, что описано в коде.

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

Как обнаружить drift

У terraform plan есть флаг -detailed-exitcode. Он возвращает разные коды выхода в зависимости от результата.
terraform plan -detailed-exitcode


Код 0 означает, что изменений нет. Код 1 говорит об ошибке. А вот код 2 сигнализирует, что план нашёл расхождения между стейтом и реальной инфраструктурой. Именно код 2 и есть индикатор drift.

Проверять это вручную каждый раз неудобно. Гораздо надёжнее встроить проверку в CI. Например, в GitHub Actions это можно сделать так:
name: Drift Detection
on:
schedule:
- cron: '0 9 * * 1'

jobs:
detect-drift:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: hashicorp/setup-terraform@v3
- run: terraform init
- run: terraform plan -detailed-exitcode
continue-on-error: true
id: plan
- run: echo "Drift detected!"
if: steps.plan.outcome == 'failure' && steps.plan.outputs.exitcode == '2'


Этот воркфлоу запускается раз в неделю по понедельникам. Если plan вернул код 2, значит, кто-то менял инфру в обход Terraform. Аналогичную логику можно настроить и в Jenkins через проверку $? после выполнения команды.

Drift неизбежен в командах, где инфраструктурой занимается больше одного человека. Регулярная автоматическая проверка через CI помогает поймать расхождения до того, как они превратятся в проблему на проде.

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

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

#root_prompt
Please open Telegram to view this post
VIEW IN TELEGRAM
👍31
🔒 Блокировка неиспользуемых модулей ядра Linux одним скриптом

ModuleJail — это shell-скрипт без зависимостей, демонов и initramfs-изменений. Он читает список загруженных модулей из /proc/modules, сравнивает его с полным деревом модулей в /lib/modules/, и для всего, что не используется, генерирует файл /etc/modprobe.d/modulejail-blacklist.conf с директивами install <mod> /bin/true.

Есть встроенный базовый набор модулей, которые никогда не попадут в блокировку: файловые системы, контроллеры хранилищ, сетевые драйверы. Плюс можно задать свой whitelist.

Зачем это нужно именно сейчас

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

Если модуль заблокирован и не загружается, очередная уязвимость в нём вас просто не касается.

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

Безопасный способ — скачать, проверить, запустить:
curl -fsSL https://raw.githubusercontent.com/jnuyens/modulejail/v1.1.4/modulejail -o /tmp/modulejail
less /tmp/modulejail
sudo sh /tmp/modulejail


Для Debian/Ubuntu и RHEL/Fedora/Rocky есть готовые пакеты:
# Debian / Ubuntu
curl -fsSLO https://github.com/jnuyens/modulejail/releases/download/v1.1.4/modulejail_1.1.4_all.deb
sudo dpkg -i modulejail_1.1.4_all.deb

# RHEL / Fedora / Rocky
curl -fsSLO https://github.com/jnuyens/modulejail/releases/download/v1.1.4/modulejail-1.1.4-1.noarch.rpm
sudo rpm -i modulejail-1.1.4-1.noarch.rpm


Профили

Скрипт поддерживает три профиля через флаг -p:
sudo sh modulejail -p conservative
sudo sh modulejail -p minimal
sudo sh modulejail -p desktop


conservative (по умолчанию) подходит для серверов и виртуалок. desktop сохраняет WiFi, Bluetooth, аудио и видео. minimal оставляет только ядро файловых систем и самое необходимое.

Модель безопасности

Принцип простой. Всё, что загружено в момент запуска скрипта, считается нужным и сохраняется. Всё остальное блокируется. Поэтому запускать ModuleJail нужно на стабильной системе, когда все сервисы подняты, все драйверы загружены, все файловые системы смонтированы.

Откат тоже простой:
sudo rm /etc/modprobe.d/modulejail-blacklist.conf
sudo reboot


Или, если нужно вернуть конкретный модуль без ребута:
sudo modprobe <имя_модуля>


Что ещё полезно знать

Скрипт идемпотентен. Два запуска подряд на неизменённой системе дают побайтово идентичный результат. В заголовке файла генерируется sha256-отпечаток, рассчитанный по входным данным, а не по времени запуска. Это удобно для флотового управления через Ansible или другие CM-инструменты.

Работает на Ubuntu, Debian, Rocky, Arch, Alpine и openSUSE. Из зависимостей нужны только awk, comm, find и sha256sum, которые есть в любом базовом Linux, включая busybox.

➡️ GitHub-репозиторий

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

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

#арсенал_инженера
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
😎 Знакомьтесь с экспертом Proglib.academy: AI-архитектор Андрей Носов

Андрей — один из ключевых спикеров нашего курса AgentOps. Он выстраивает архитектуру, которая выживает в суровом проде и активно делится своим опытом.

За что его ценит IT-комьюнити:

🟣 Топ-спикер AI Conf 2026
Его доклад про мифы семантического поиска и провалы Naive RAG стал одним из самых рейтинговых на конференции.


🟣 Эксперт по GraphRAG и Knowledge Graphs
Андрей внедряет инженерный подход в сложные системы, заменяя «слепую веру» в эмбеддинги строгой логикой графов.


🟣 Автор «14 кругов ада для RAG»
Разработал уникальный набор из 14 unit-тестов, на которых ломается стандартный векторный поиск (от слепоты к отрицаниям до конфликта версий).


🟣 Спикер Saint HighLoad
Регулярно выступает на крупнейших хайлоад-площадках, разбирая архитектуру отказоустойчивых ИИ-сервисов.


Андрей упаковал свои наработки в Google Colab, где можно пощупать 14 сценариев ошибок RAG и их решения:

🔗 Забрать Colab-ноутбук

На курсе Андрей отвечает за самые «мясные» блоки: RAG, оркестрацию агентов и их промышленную эксплуатацию.

Узнать больше о программе и обучении у Андрея:
👉 Курс о том, как внедрять AI-логику в бэкенд и сохранять стабильность сервиса

Так, продолжаем знакомить вас с командой?
👍 — Да, ждем новых лиц
🔥 — Пойду тестить Colab Носова
Please open Telegram to view this post
VIEW IN TELEGRAM
🧑‍💻 su и sudo — в чём разница и когда что использовать

su и sudo дают доступ к привилегиям суперпользователя, но работают по-разному.

Что делает su

su (substitute user) переключает текущую сессию на другого пользователя. По умолчанию — на root. При вызове команда запрашивает пароль того пользователя, на которого вы переключаетесь.

После ввода пароля root вы получаете полноценную root-сессию. Все последующие команды выполняются от имени суперпользователя до тех пор, пока вы не выйдете через exit.

Если нужно переключиться с загрузкой окружения целевого пользователя, используйте форму с дефисом:
su -

Это загрузит переменные окружения, $HOME, $PATH и профиль root так, как если бы вы залогинились напрямую.

Что делает sudo

sudo (superuser do) выполняет одну конкретную команду с повышенными привилегиями. Пароль запрашивается ваш собственный, а не пароль root.

sudo apt update


Команда отработает от имени root, после чего вы вернётесь в свою обычную сессию. Никакого переключения пользователя не происходит.

Список пользователей, которым разрешено использовать sudo, и допустимые для них команды задаются в файле /etc/sudoers. Редактировать его нужно только через visudo, чтобы избежать синтаксических ошибок, которые могут заблокировать доступ.

Ключевые отличия

su требует знать пароль root. sudo требует только ваш пароль и запись в sudoers. Это принципиальная разница с точки зрения безопасности.

Раздавать пароль root нескольким администраторам — плохая практика. С sudo каждый работает под своей учёткой, а все действия логируются с привязкой к конкретному пользователю.

su открывает постоянную root-сессию. Забыли выйти — любая случайная команда выполнится с максимальными правами. sudo работает точечно, на одну команду, что снижает риск случайного повреждения системы.

Когда что использовать

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

su оправдан, когда нужно выполнить серию команд от root подряд, и переключение в полноценную root-сессию экономит время. Но даже в этом случае можно заменить его на:
sudo -i


Эта команда открывает интерактивную root-сессию через механизм sudo, без необходимости знать пароль root.

В современных дистрибутивах sudo стал стандартом. Ubuntu, например, по умолчанию вообще отключает вход под root и предлагает использовать только sudo.

Это безопаснее, прозрачнее для аудита и не требует распространения root-пароля. Используйте su только если точно понимаете, зачем вам полная root-сессия.

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

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

#root_prompt
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤‍🔥22
🛠 Переключение namespace в kubectl одной командой

Если вы работаете с Kubernetes, то наверняка устали дописывать -n my-namespace к каждой команде. Это раздражает, отнимает время и рано или поздно приводит к ошибке — забыли флаг, команда ушла в default, получили не тот результат.

Проблема решается одной строкой:
kubectl config set-context --current --namespace=<namespace>


Эта команда меняет namespace по умолчанию в текущем контексте вашего kubeconfig. После выполнения все последующие вызовы kubectl будут работать с указанным namespace без дополнительных флагов.

Допустим, вы работаете с namespace staging:
kubectl config set-context --current --namespace=staging


Теперь kubectl get pods покажет поды именно из staging. Не нужно писать kubectl get pods -n staging каждый раз.

Как проверить текущий namespace

Убедиться, какой namespace сейчас выставлен, можно так:
kubectl config view --minify --output 'jsonpath={..namespace}'


Если команда ничего не вернула, значит, используется default.

Что важно понимать

Настройка сохраняется в файле ~/.kube/config и действует не только на текущую сессию терминала. Она будет активна до тех пор, пока вы не переключитесь на другой namespace или не смените контекст.

Для тех, кто переключает namespace часто, есть утилита kubens из пакета kubectx. Она делает то же самое, но короче:
kubens staging


Мелочь, но экономит десятки лишних символов в день.

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

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

#root_prompt
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
👨‍💻 55 миллионов строк кода KDE

Корнелиус Шумахер, один из давних контрибьюторов KDE, проанализировал кодовую базу проекта. Почти 30 лет публичной истории в git дают много материала для анализа.

Шумахер посчитал код ядра KDE. Это библиотеки, рабочий стол и стандартные приложения из регулярных релизов. Сейчас в репозиториях находится 8 173 148 строк кода, если не считать графику, переводы и прочие нетекстовые файлы.

Но самое интересное в другой цифре. Если учесть всю историю изменений, добавлений и удалений, то через репозитории KDE прошло 55 041 902 строки кода. То есть на каждую строку, которая есть в проекте сегодня, приходится примерно 7 строк, которые когда-то были написаны, изменены или удалены.

Сам автор отмечает, что главное тут не цифры. За этим кодом стоят тысячи людей, которые десятилетиями совместно работали над улучшением KDE. И это, пожалуй, самый важный вывод из всей этой статистики.

Подпишитесь на нашу рассылку и мы дадим вам столько же строк полезной информации.

➡️ Источник

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

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

#пульс_индустрии
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍2
Стартуем с Kubernetes без боли в Managed Kubernetes от MWS Cloud Platform.

27 мая в 16:00 Александр Курасов, технический владелец продукта в MWS Cloud Platform, покажет, как развернуть кластер за минуты, на вебинаре «Быстрый старт с Managed Kubernetes в облаке MWS».

Разберём архитектуру сервиса, его интеграцию с IAM, сетями и балансировщиками. Увидите, как управляемый сервис берёт на себя администрирование master-узлов и упрощает жизнь.

Будет интересно:

♦️DevOps-инженерам, которые хотят упростить работу с Kubernetes
♦️Backend-разработчикам, которым нужно быстро задеплоить сервис
♦️Platform-инженерам, строящим cloud-native инфраструктуру
♦️Техлидам и архитекторам, выбирающим Kubernetes в облаке

➡️ Зарегистрироваться
Please open Telegram to view this post
VIEW IN TELEGRAM
👩‍💻 Смотрим нагрузку на CPU правильно

Когда сервер тормозит, первый инстинкт — открыть top или htop. Но они показывают общую картину. Если нужно понять, как нагрузка распределяется по ядрам, какой процент времени CPU тратит в режиме ожидания ввода-вывода и где именно зарыта проблема — нужен mpstat.

Что такое mpstat

mpstat входит в пакет sysstat и выводит статистику использования процессора: по каждому ядру отдельно или суммарно. В отличие от top, он не интерактивный — удобно логировать вывод или использовать в скриптах.

Основные флаги

Запуск без аргументов покажет среднюю статистику с момента старта системы — не очень полезно. Обычно используют так:
mpstat -P ALL 2 5


-P ALL — показать все ядра
2 — интервал в секундах
5 — количество итераций

Пример вывода:
Linux 5.15.0 (srv01)   05/18/2026   _x86_64_   (4 CPU)

14:32:01 CPU %usr %nice %sys %iowait %irq %soft %steal %idle
14:32:03 all 12.3 0.0 3.1 8.4 0.0 0.1 0.0 76.1
14:32:03 0 45.2 0.0 5.3 2.1 0.0 0.2 0.0 47.2
14:32:03 1 3.1 0.0 1.2 18.3 0.0 0.0 0.0 77.4
14:32:03 2 2.4 0.0 2.8 9.2 0.0 0.1 0.0 85.5
14:32:03 3 0.8 0.0 3.2 4.1 0.0 0.0 0.0 91.9


На что смотреть

%usr — время в пространстве пользователя. Высокое значение говорит о нагруженном приложении.

%sys — время в режиме ядра. Если оно неожиданно высокое, стоит проверить системные вызовы.

%iowait — CPU ждёт завершения операций ввода-вывода. Значение выше 10–15% — сигнал проблем с диском или сетью.

%steal — время, украденное гипервизором на виртуалках. Если стабильно выше 5% — ресурсов на хосте не хватает.

%idle — простой. Чем меньше, тем выше нагрузка.

В примере выше видно, что нулевое ядро загружено на 45%, а %iowait на первом ядре — 18%. Это повод разобраться, какой процесс привязан к этим ядрам и почему он так активно работает с диском.

Смотрим только iowait

Если нужно быстро отследить проблемы с вводом-выводом:
mpstat -P ALL 1 | awk '/[0-9]/ {print $1, $2, $6}'


Выведет только время, номер ядра и %iowait.

Логирование

sysstat умеет собирать статистику в фоне через sar. Но если нужно просто сохранить данные в файл на время инцидента:
mpstat -P ALL 2 30 > /tmp/cpu_$(date +%F_%T).log


Запустит 30 итераций с интервалом 2 секунды и сохранит в файл с меткой времени.

mpstat полезен, когда нужно быстро понять распределение нагрузки по ядрам или найти аномалии — высокий %iowait, перекос нагрузки на одно ядро, активность гипервизора.

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

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

#арсенал_инженера
Please open Telegram to view this post
VIEW IN TELEGRAM
👨‍💻 В ядро Linux добавили модель угроз и правила для AI-репортов

Линус Торвальдс принял в ядро документ, который формализует обработку багов безопасности. Он определяет модель угроз, объясняет, какие баги считаются уязвимостями, и вводит правила для AI-отчётов.

Почему сейчас

На приватную рассылку безопасности хлынул поток AI-отчётов. Два года назад приходило 2–3 в неделю, сейчас 5–10 в день. Большинство — обычные баги, ошибочно поданные как уязвимости. Авторы просто не знакомы с моделью угроз ядра.

Правила для AI-репортов

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

• Plain text, без Markdown
• Проверяемые факты («баг даёт CAP_NET_ADMIN»), а не спекуляции
• Рабочий reproducer, протестированный вручную
• Патч с тегом Fixes: на проблемный коммит

Модель угроз

Новый threat-model.rst фиксирует границы. Уязвимость — нарушение изоляции пользователей, обход capabilities (CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_PTRACE), выход из user namespaces в глобальное пространство, доступ к отладочным интерфейсам (/proc/kmsg, perf, debugfs) без прав.

Не уязвимость: баги в устаревших ветках, небезопасные конфигурации сборки, LOCKDEP/KASAN/FAULT_INJECTION, модули STAGING, проблемы, требующие root, утечки по побочным каналам, обход ASLR, повреждения от аппаратных сбоев.

Документ не запрещает AI. Но требует от репортеров тот же уровень подготовки, что и от всех. Торвальдс сказал прямо: читайте документацию, пишите патч, берите ответственность.

➡️ Полный текст в коммите ядра Linux

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

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

#пульс_индустрии
Please open Telegram to view this post
VIEW IN TELEGRAM
🐧 ИИ нашёл серию критических уязвимостей в ядре Linux

За последние недели в ядре Linux закрыли несколько уязвимостей локального повышения привилегий, и все они объединены одной темой: их нашёл автоматизированный инструмент на базе ИИ.

Что за уязвимости

Все три относятся к одному классу: локальный пользователь без прав может получить root. Рабочие эксплойты опубликованы.

Copy Fail — уязвимость в подсистеме algif_aead ядра Linux. Эксплуатируется через splice() в связке с io_uring. Позволяет перезаписать страницы памяти suid-бинарников вроде /usr/bin/su, passwd, mount, pkexec.

Dirty Frag (CVE-2026-43284, CVE-2026-43500) — два варианта той же техники, но через xfrm-ESP (IPsec) и RxRPC. Уязвимость в xfrm-ESP присутствует в ядре с 2017 года, в RxRPC — с 2023-го. Проверена на Ubuntu 24.04, RHEL 10.1, openSUSE Tumbleweed, Fedora 44.

PinTheft — свежая эксплуатация через RDS (Reliable Datagram Sockets) и io_uring. Использует double-free в функции rds_message_zcopy_from_user(). CVE ещё не присвоен.

Роль ИИ

Все три уязвимости нашёл автоматизированный инструмент анализа кода. Это не значит, что раньше их не было — они сидели в ядре годами. Инструмент нашёл паттерн: использование splice() и io_uring для записи в страницы page cache без учёта флагов защиты. Один паттерн — несколько точек входа в разных подсистемах.

Затронутые конфигурации

Уязвимости эксплуатируются при наличии загруженных модулей:
- Copy Fail — нужен io_uring (включён по умолчанию) и поддержка algif_aead
- Dirty Frag — нужны модули esp4/esp6 или rxrpc
- PinTheft — нужны модули rds и rds_tcp, а также io_uring

В большинстве дистрибутивов эти модули загружаются автоматически при первом обращении. Arch Linux загружает rds по умолчанию.

Что делать прямо сейчас

Для Dirty Frag — отключить уязвимые модули:
sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"


Для PinTheft — отключить rds и rds_tcp:
rmmod rds_tcp rds
printf 'install rds /bin/false\ninstall rds_tcp /bin/false\n' > /etc/modprobe.d/pintheft.conf


Для Copy Fail — обновить ядро. Патч есть в ветке netdev.

Исправления для Dirty Frag включены в ядра 7.0.5, 6.18.28, 6.12.87, 6.6.138, 6.1.172, 5.15.206, 5.10.255. Все основные дистрибутивы уже выпустили или выпускают обновления.

Почему это важно

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

Если вы администрируете Linux-серверы или рабочие станции — обновите ядро и проверьте, какие модули загружены в вашей конфигурации. Также подпишитесь на нашу рассылку, там нет уязвимостей.

➡️ Источник

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

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

#разбор_полётов
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍2🥱1
🔥 База по экономике токенов и кэшированию от AI Platform Lead из Bitrix24

Знакомьтесь, Сергей Нотевский. AI Platform Lead в Bitrix24.

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

Мы попросили Сергея поделиться материалами для тех, кто хочет оптимизировать косты на LLM в проде. Сохраняйте методичку по prefix cache метрике, которая напрямую влияет на ваши деньги.

Как говорят создатели Manus:
“KV-cache hit rate is the single most important metric for a production-stage AI agent.”


🛠 Что внутри методички (комбо из 3 статей + код):
Экономика кэширования — особенности провайдеров и как правильно считать затраты.

Частые анти-паттерны — почему ваш кэш постоянно сбрасывается и вы платите больше.

Кэш в AI-агентах — специфика работы с памятью в автономных системах.


🍒 Вишенка на торте: готовый SKILL для агента, который делает ревью вашего проекта, находит анти-паттерны и предотвращает низкое попадание в кэш.

Забрать комбо-материалы на GitHub

P.S. Если хотите послушать Сергея вживую — ловите его на конференциях Kode Waves (май), Conversations AI и Highload Spb (июнь).

🎁 Акция в честь старта продаж!

Прямо сейчас при покупке Инженерного трека вы получаете полный доступ к материалам курса «Разработка ИИ-агентов» в подарок.

👉 Забрать 2 курса по цене 1 и начать обучение
🫠 Топ-вакансий для девопсов за неделю

DevOps Архитектор — офис в Москве

Senior DevOps Engineer —‍ до 5,500 $, удалёнка.

DevOps-инженер — до 2 800 €, удалёнка.

➡️ Еще больше топовых вакансий — в нашем канале Devops Jobs

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

#вакансия_недели
Please open Telegram to view this post
VIEW IN TELEGRAM
🔄 Вышла 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

#пульс_индустрии
Please open Telegram to view this post
VIEW IN TELEGRAM
🧐 Дашборд, чтобы не разбирать 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

#арсенал_инженера
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1