Лимиты CPU и памяти в cgroup v2 работают по-разному: cpu.max в cgroup v2 задаёт квоту, memory.high вызывает reclaim, а memory.max может привести к OOM. Результат зависит от ядра, дерева systemd, swap, OOM-политики и состава cgroup.

Чем cpu.max отличается от cpu.weight?

cpu.max задаёт квоту CPU на период, и после её исчерпания группа ждёт следующего периода. cpu.weight делит время между соседями, которые одновременно конкурируют за процессор. Без конкуренции высокий вес задачу не ускоряет, тогда как квота всё равно остаётся абсолютной границей для группы.

Где cgroup v2 действительно применяет контроллер

Одного файла cpu.max в cgroup v2 мало, путь процесса проверяют командами:

stat -fc %T /sys/fs/cgroup
 systemctl show -p ControlGroup app.service
 systemd-cgls --unit app.service

Контроллер должен входить в cgroup.controllers родителя и cgroup.subtree_control. Для доменных контроллеров действует no internal process: у родителя с дочерними cgroup не должно быть процессов.

cpu.max, cpu.weight и конкуренция за время процессора

cpu.max хранит квоту и период в микросекундах. cpu.weight (1–10000, по умолчанию 100) распределяет время между активными соседями одной ветви. Affinity и лимит родителя сужают доступный CPU. memory.max в cgroup v2 не ограничивает процессор.

Как увидеть исчерпание CPU-квоты в cpu.stat

Нагрузку создают через stress-ng в изолированном unit с неизменным cpuset, меняя между ступенями только cpu.max. Показатели usage_usec, nr_periods, nr_throttled и throttled_usec из cpu.stat сопоставляют с throughput и p99. memory.high против memory.max тестируют отдельно, чтобы reclaim не исказил результат.

Как memory.high и memory.max ведут себя под давлением?

memory.high замедляет процессы через reclaim, причём потребление может временно оставаться выше порога. memory.max задаёт жёсткую верхнюю границу, и если память освободить не удаётся, начинается cgroup OOM. Разницу видно по high, max, oom и oom_kill в memory.events.local, а также по memory PSI.

memory.low, memory.high и memory.max без смешения ролей

memory.low защищает рабочий набор в пределах бюджета родителя, memory.high усиливает reclaim, memory.max ставит жёсткую границу. При росте resident set пишут memory.current, anon, file и пределы родителя. В unit лимиты systemd cgroup v2 сверяют с эффективными значениями.

Замедление до OOM как отдельный режим

Память наращивают ступенями, записывая high в memory.events.local, pgscan, PSI memory и latency. Reclaim может нарушить SLO до OOM. CPU weight в cgroup при этом не трогают. anon и file разделяют анонимную и файловую память.

Что происходит при достижении memory.max

События max, oom и oom_kill сверяют с журналом ядра. memory.oom.group=1 убивает все задачи группы разом, кроме процессов с oom_score_adj=-1000. Проверять это можно только на изолированном стенде.

Как проверить, что лимиты cgroup v2 действительно работают?

1. systemd-cgls и ControlGroup подтверждают путь процесса.

2. Файлы содержат нужные значения, а счётчики растут под нагрузкой.

3. Throughput и latency меняются одновременно с throttling, PSI или OOM.

В отчёт идут дерево cgroup, лимиты, swap, ряды cpu.stat и memory.events, PSI, журнал OOM и версия ядра.

memory.swap.max, latency и ложное ощущение запаса

Для каждого прогона указывают swap, memory.swap.max, swap in/out и p99. Swap отодвигает OOM killer ценой задержки, поэтому прогоны со swap и без него не смешивают. Отсутствие OOM не означает выполнения SLO.

Как перенести измеренные границы в unit и мониторинг

В systemd slices CPUQuota, CPUWeight, MemoryHigh и MemoryMax задают параметры cgroup. Мониторинг берёт PSI, throttled_usec, high, oom и oom_kill. После изменения unit или ядра запускают canary-тест.

Лимиты CPU и памяти в cgroup v2 задают вместе с сигналами срабатывания: throttling в cpu.stat, pressure в PSI и события OOM. Проверяют их в той же systemd-иерархии, где работает служба. Настройка годится, когда приложение выполняет SLO при включённых лимитах.

Как объясняет в комментариях к твиту Шрёдер, зеркало как раз позволяет при отладке оценивать не скриншот, а изображение на физическом дисплее ноутбука. Что именно происходит на экране, разобрать тяжело из-за невысокого разрешения снимка и зеркального отражения. Если судить по его другому твиту, саму веб-камеру под Linux Шрёдер запускает с помощью T1Bridge — открытого проекта Standard Agents, добавляющего поддержку Apple T1 и iBridge, включая камеру FaceTime HD. Справа (слева на отражении в зеркале) открыт интерфейс приложения LocalSend: в папку /home/justin-schroeder/Downloads только что передали две фотографии в файловом формате HEIC. Слева, судя по характерным строкам Ran и Explored, работает Codex CLI компании OpenAI.

Сам Шрёдер — разработчик открытого программного обеспечения и создатель dmux, инструмента для параллельной работы с агентами программирования. Эта утилита запускает Codex, Claude Code и другие агенты в отдельных панелях tmux, создавая для каждой задачи отдельную ветку и рабочий каталог Git. Беглый поиск показывает, что к Omarchy Шрёдер имеет непосредственное отношение как контрибьютор: 9 сентября он отправил в проект патч, исправляющий работу адаптера Wi-Fi фирмы Broadcom на MacBookPro13,3. Судя по всему, сейчас он как раз занимается доводкой Omarchy на этой машине.

В большой инфраструктуре десятки тысяч машин, БД, контейнеров, платформ. И сценарии восстановления у всех свои: где-то нужно поднять всё с нуля, а где-то – вернуть один объект или несколько атрибутов. Российские вендоры последовательно движутся в сторону точности.

Свежий пример: в «Кибер Бэкапе Облачном» теперь можно выбирать отдельные объекты внутри Kubernetes. Резервируешь и восстанавливаешь только то, что действительно нужно, – не тащишь весь кластер ради одной ошибки.

Не просто «есть копия», а умение достать из неё именно то, что сломалось, и не трогать остальное.

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

Восстанавливать весь каталог из полной копии — как из пушки по воробьям.

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

Простая логика для каталога: перед миграцией сделал копию, потом сравнил состояния и точечно исправил последствия.

И здесь Kubernetes и каталог оказываются ближе, чем кажется: бэкап ценен не только фактом наличия, но и тем, насколько точно ты можешь им воспользоваться, когда что-то пошло не так.

Источники:

«Киберпротект» расширил возможности «Кибер Бэкапа Облачного» для крупных гетерогенных инфраструктур

Российские системы резервного копирования: из реестра

Пораскинув в хорошем смысле мозгами, сделал такую подборку:

• Основа — linux, linux-firmware, grub, runit, coreutils, util-linux, kmod, shadow, kbd

• Сеть — iproute2, dhcpcd, ca-certificates

• Окружение — kmscon/fbterm, tmux, nerd-fonts, mc

• Мастхэв: sudo, file, procps-ng, neovim, git, wget, openssh, openssl, gcc, make, glibc, tar, zstd, unzip, less, grep, sed, awk, findutils, man-db, man-pages

Если немножко додать жиру, то — yazi, neomutt, lynx/w3m, newsboat, alsa-lib, alsa-utils, mpv.

Наверняка чего-то упустил / чего-то захочется ещё. Но такова природа человека… Иначе до пятидесятого гнома мы бы не дошли.

Вот. На следующих выходных попробую себе устроить GUI-детокс и геморрой на свою соскучившуюся пятую точку (см. начало про безделье). Посмотрю, чего реально не хватает современному в меру упитанному человеку для жизни.

И распивая чаи со спиртом (опционально), буду читать здесь холивары о гноме и кедах 😁

Итак, дано. Стек: Linux, Wayland, Qt/GTK. Нужна программа для работы с цветом:

• Живой проект

• Linux/Wayland

• GUI

• Отдельная программа, а не GIMP/Figma/Krita/веееб-инструмееенты без регистрации и СМС

• Палитры

• Цветовые пространства

• Гармонические схемы

• Генерация вариаций

• Математическое смешивание

• Blend modes вроде Overlay

• Интерполяция/шаги

• Лёгкая и узкоспециализированная

• Кофе варить не обязана

Очень много?

Нужен богатый функционал, но при этом чётко очерченная область тупо работы с цветом. Безо всех этих «а ещё мы вам прямо здесь трактор в фигме нарисуем», лёгкие, быстрые, с минимумом зависимостей, чистая математика, удобный интерфейс.

Есть pastel. Консольная.
Есть Gpick. Дохлый.
Есть Rickrack. Дохлый. Да ещё и на PyQt5. С кучей некродрузей за ручку.

Я не понимаю. Правда. Сейчас всем хватает только пипеток и инстаграмчиков на телефончиках?

Недавно запилил свою мерялку экрана на C++/GTK4 со всякими координатами, шириной-высотой, углами, диагоналями, соотношениями сторон, направляющими и пр. плюшками. Для Wayland. И даже умудрился туда прикрутить те же колорпикер со скриншотами, мать их… Просто потому что самому нужно. Теперь пилить ещё и это? Я один такой дурак в этом мире, которому всё это нужно?… Простите. Крик души.

Сервис начал отвечать медленнее, пользователи жалуются на ошибки, а привычные дашборды показывают только рост задержек. Где искать причину, если приложение, сеть и инфраструктура выглядят «почти нормально»?

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

На открытом уроке курса «DevOps практики и инструменты» вместе с преподавателем разберём, как eBPF помогает исследовать сетевые взаимодействия, производительность и безопасность современных систем. Посмотрим, какие задачи он решает в реальной эксплуатации и где его применение действительно оправдано. Когда: 23 сентября в 20:00. Присоединяйтесь

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

1. Сравнить текущее состояние каталога с резервной копией.

2. Найти точечные расхождения.

3. Восстановить только изменённые объекты, не трогая остальное.

Защищать нужно не только доступность каталога, но и целостность данных. Потому что легитимный доступ ≠ безопасное изменение. И это справедливо не только для КИИ.

Информацию взял отсюда и отсюда.

Тест io_uring против epoll в KVM проводят на одной кодовой базе. Бенчмарк io_uring при множестве соединений корректен, если меняется только бэкенд событий. Итог зависит от ядра, цикла событий, протокола, режима io_uring и offload.

Когда io_uring обгоняет epoll на сетевом сервере?

io_uring обгоняет epoll, когда сервер пакетно отправляет операции и обрабатывает завершения, сокращая число переходов в ядро. Такой выигрыш обычно виден при множестве одновременных соединений и малом объёме работы на запрос. Простая замена epoll-уведомлений на io_uring poll может не окупить сложность.

Что обязано остаться неизменным между epoll и io_uring

Чтобы бенчмарк io_uring при множестве соединений был честным, обе ветки используют общий парсер, обработчик, TLS-режим, keep-alive и формат ответа. Сверяют чтения, записи и аллокации на запрос. Поэтому демонстрационный пример не сравнивают со зрелым сервером.

Готовность fd против очередей submission и completion

epoll сообщает о готовности fd, а приложение выполняет I/O. В io_uring приложение отправляет SQE в submission queue, а ядро записывает CQE. Пакетная отправка сокращает переходы в ядро, но неудачный цикл событий сводит выигрыш к нулю. Поэтому масштабирование epoll в KVM проверяют на том же профиле нагрузки.

Где KVM и virtio могут скрыть разницу бэкендов

Пакет идёт через сетевой стек гостя, очереди vhost-net и тракт хоста. До теста фиксируют число очередей, offload, привязку vCPU и IRQ. Иначе задержка сетевого сервера io_uring объясняется хостом, а не бэкендом.

Какой тест позволяет честно сравнить эти модели?

Используйте один код сервера, протокол, объём работы на запрос и правила соединений, меняя только бэкенд событий. После прогрева запускайте серии с одинаковым CPU-бюджетом на каждой ступени concurrency. Публикуйте пропускную способность, p99, число системных вызовов, ошибки и загрузку гостя и хоста отдельно.

Соединения, запросы и backpressure без скрытых различий

Задайте размеры запросов и ответов, долю новых соединений и keep-alive. Повышайте concurrency до насыщения, следя за ошибками, таймаутами и очередью. Накладные расходы цикла событий оценивайте по CPU на запрос и числу системных вызовов, сопоставляя их с p99 и пропускной способностью.

Syscalls, переключения контекста и CPU на запрос

Счётчики cycles, instructions и context-switches делят на число запросов. Отдельно измеряют расход CPU рабочими и vhost-потоками. Многократный accept в io_uring снижает число постановок accept, но каждый CQE нужно обработать. К отчёту прикладывают коммит, конфиги бэкендов, генератор и сырой CSV.

Где преимущество появляется и где исчезает

Сравните низкую нагрузку, рабочую точку и перегрузку. Проверьте мелкие и крупные сообщения. Сохраняйте p50, p99, пропускную способность, соединения в секунду и разброс повторов. Если разбросы перекрываются, не выбирайте победителя.

Какие накладные расходы добавляет KVM?

1. Часть ожидания vCPU отражается в %steal, остальные паузы видны только на хосте.

2. Очереди гостя, vhost и NIC хоста могут накапливать пакеты независимо от бэкенда.

3. IRQ, softirq и offload влияют на расход CPU, поэтому настройки фиксируют до теста.

Как найти источник p99 внутри ring или цикла событий

При росте p99 трассируют SQ/CQ, обработку CQE и паузы рабочих потоков. Проверяют переполнение ring, незавершённые операции и backpressure. Если хвостовая латентность растёт вместе с паузами vCPU, сначала проверяют хост.

Когда выигрыш оправдывает новый бэкенд

До перехода фиксируют версию ядра, поддержку отмены, наблюдаемость и fallback. Настройки virtio не меняют, иначе выигрыш не отнести к бэкенду. Порог связывают с целевой метрикой и ценой сопровождения. Новый бэкенд включают поэтапно, с откатом на epoll.

io_uring против epoll в KVM выбирают не по новизне API. Переход оправдан, если серии дают выигрыш по p99, пропускной способности или CPU на запрос, а поведение при перегрузке и fallback предсказуемо. Иначе epoll остаётся более простым бэкендом.

Я не просто создала программу и выложила на GitHub и всё, я настроила автоматическую сборку бинарного файла на сервере, поэтому вам не нужно компилировать. Бинарная сборка в одном файле AppImage доступна для всех. Работает как минимум на Debian 13 (я проверяла), так что программа будет работать и на Ubuntu, и на Fedora, и на ArchLinux

ФСТЭК готовит новые правила для ИИ в государственных информационных системах. 24 августа ведомство опубликовало проект изменений в приказ №117. В нем предлагается ограничить модели ИИ в доступе и правах. Проект должен вступить в силу 1 марта 2027 года.

Что меняется, когда ИИ получает доступ к LDAP

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

Например, если ИИ-агенту дать доступ к корпоративному LDAP-каталогу, он сможет:

• Добавить учетную запись в группу

• Изменить атрибут пользователя

• Изменить членство в группе

• Массово изменить данные

Поэтому, если злоумышленник получит доступ к агенту, то он сможет украсть или испортить данные каталога, передать их в третьи руки.

Что может оказаться под угрозой?

В каталоге лежат не только логины и учётные записи, но и ФИО, должности, отделы, телефоны, почта, фото – целая база персональных и служебных данных.

Если агенту разрешено читать эти данные, то злоумышленникам не обязательно взламывать LDAP. Достаточно дать агенту команду – и он сам отдаст данные наружу или испортит их.

Локальная или внешняя модель?

С точки зрения рисков не принципиально, используете вы внешнюю или локальную модель. Если локальная модель имеет широкие права, она сольёт данные не хуже внешнего сервиса. Так что ФСТЭК смотрит не на место проживания модели, а на то, что она видит, к чему имеет доступ и что может делать.

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

Причем источник проблемы может находиться далеко от каталога. Например, вредоносная инструкция может попасть в ИИ через внешний ресурс или заражённый документ. Эксперты называют prompt injection одной из главных дыр, которые надо закрывать в защите ИИ.

ИИ становится еще одним участником системы доступа

Выходит, ИИ-агент, подключенный к каталогу, становится еще одним участником системы управления доступом. Если дать ему слишком много прав, мы откроем путь:
внешняя команда → ИИ-агент → LDAP → данные пользователей или права доступа.

Поэтому принцип минимальных прав критичен. Если агенту нужен только один атрибут – не даём ему весь каталог. Если нужно сделать одну операцию – не разрешаем править все учётки. Чем меньше прав, тем меньше ущерб от возможной атаки.

Что делать, если изменения уже произошли

Просто иметь бэкап каталога – мало. Если агент испортил сотни записей, полный откат вернёт старую версию, но заодно откатит все правильные изменения, которые появились после бэкапа.

Поэтому нужны два уровня защиты:

1. Резервное копирование, чтобы сохранить состояние каталога;

2. Гранулярное восстановление, чтобы найти и вернуть неправильно изменённые объекты или атрибуты.

Получается простая цепочка:

ограничить права ИИ → контролировать его действия → не дать слить данные наружу → не дать править лишнее → иметь бэкап → уметь точечно восстановить данные.

Новые требования ФСТЭК интересны не только для ИИ. Они показывают: если ИИ подключается к инфраструктуре, его безопасность становится частью безопасности всей системы – включая службу каталога.

NUMA и топология CCD Ryzen 9 9950X не равнозначны: гость видит NUMA-схему, но не границы L3. Сравнивать нужно размещение vCPU на одной VM внутри CCD, между CCD и без pinning. Результат зависит от нагрузки, BIOS, ядра, QEMU и SMT.

Как определить, какие vCPU находятся на одном CCD?

Сопоставьте логические CPU с ядрами и SMT-сиблингами, затем найдите группы общего L3-кэша. Каждый CCD объединяет восемь ядер с общим L3, номера CPU зависят от хоста, поэтому проверяйте shared_cpu_list. Запишите BIOS, микрокод, ядро и governor.

lscpu -e=CPU,CORE,SOCKET,NODE,CACHE
grep -H . /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list

Границы CCD измеримы: в открытом наборе для 9950X с AGESA 1.2.0.2 средняя задержка CAS через общую строку кэша составила 22,4 нс внутри CCD и 79,5 нс между CCD, тогда как numactl границу не покажет.

От физических ядер к vCPU, emulatorpin и vNUMA

vcpupin связывает vCPU с CPU хоста, но не трогает остальные потоки VM: эмулятор QEMU и IOThread закрепляются отдельно. NUMA node гостя должен отражать домен памяти, а не границу L3, иначе межчиплетная задержка смешается с доступом к удалённой RAM.

virsh vcpupin vm-latency
virsh emulatorpin vm-latency
virsh numatune vm-latency

Компактный CCD, разнесённые CCD и свободное планирование

Сравните одну VM в трёх конфигурациях: внутри одного L3, между CCD и без vcpupin. Число vCPU и RAM не меняйте, пиннинг задавайте по физическим ядрам, SMT проверяйте отдельно.

Насколько размещение между CCD увеличивает задержку?

Универсальной прибавки нет: результат зависит от общих данных, синхронизации, памяти и миграций. Сравнивайте одну нагрузку на одном хосте, сохраняя p50, p95, p99 и разброс. Core-to-core тест измеряет обмен между CCD, а не p99 приложения.

Как не принять boost, нагрев или соседнюю VM за эффект CCD

Прогрейте VM, фиксируйте частоту, температуру и %st: performance не удерживает частоту на Ryzen. Чередуйте схемы A–B–C–C–B–A и записывайте фоновые задачи. vNUMA должна совпадать с доменами памяти хоста.

Связь задержки с миграциями, кэш-промахами и удалённой памятью

Возьмите приложение с общей памятью или синхронизацией и микротест обмена. Перед серией проверьте pinning в libvirt и память QEMU, затем снимайте context switches, миграции и NUMA faults. Для cache-misses нужен vPMU. Нормируйте счётчики: рост вместе с p99 причину не доказывает.

perf stat -e context-switches,cpu-migrations,cache-misses \
   -- ./test
numastat -p "$(pgrep -fo 'guest=vm-latency')"

Когда пиннинг vCPU улучшает p99?

1. Рабочие потоки часто обращаются к общим данным.

2. Без pinning они мигрируют между группами L3.

3. p99 снижается без потери throughput и роста %st.

Где компактность помогает, а где ограничивает параллелизм

Сведите три схемы в таблицу: медиана p99 по повторам и доверительный интервал разницы. Если интервал пересекает ноль, результат в пределах погрешности. Задачам с независимыми потоками компактность ничего не даёт: обмена между ядрами почти нет, а привязка сужает выбор планировщика.

Как превратить топологию 9950X в правило эксплуатации

До теста задайте порог, например снижение p99 на 10% без потери ops/s. В XML подставьте cpuset и узел.

<vcpu>2</vcpu>
<iothreads>1</iothreads>
<cputune>
 <vcpupin vcpu='0' cpuset='0'/>
 <vcpupin vcpu='1' cpuset='1'/>
 <emulatorpin cpuset='2'/>
 <iothreadpin iothread='1' cpuset='3'/>
</cputune>
<numatune><memory mode='strict' nodeset='0'/></numatune>

Закрепляйте vCPU внутри CCD только если улучшение p99 воспроизводится в повторных прогонах. Если throughput падает или p99 не меняется, оставьте свободное планирование. Топология задаёт гипотезу, решение зависит от VM.

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

26 августа в 19:00 на бесплатном демо-уроке будем разбираться, как работать с nftables на удалённом Linux-сервере так, чтобы изменения можно было вносить контролируемо и без неприятных сюрпризов. Заодно станет понятнее, чем nftables отличается от привычного iptables и что учитывать при постепенном переходе между ними.

Урок проведёт Николай Лавлинский — преподаватель-практик курса «Администратор Linux. Продвинутый уровень». Формат рассчитан на разбор реальной админской задачи, где цена ошибки вполне ощутима.

Больше бесплатных уроков на август собрали в дайджесте — там можно быстро посмотреть темы и выбрать нужную сейчас.

🤖 AI-агенты для Ansible: как делегировать рутину и не писать плейбуки руками — бесплатный стрим 12 августа

Я перестал писать Ansible-плейбуки руками. Вообще. Вместо этого у меня работает AI-агент, который знает лучшие паттерны, понимает мою инфраструктуру и сам пишет роли, модули, соединяет их и поднимает всё необходимое. Недавно он за вечер собрал связку Terraform + Ansible на новом сервере — и справился лучше, чем я ожидал.

На стриме покажу, как это устроено изнутри:

🔧 Архитектура AI-агента для Ansible: база знаний, инструментарий, что дёргать и как дёргать
📜 Как агент пишет роли и модули: промпты, валидация, итеративное исправление ошибок
🖥 Живой пример: поднимем инфраструктуру с нуля руками агента — в реальном времени
💡 Границы применимости: что агент делает хорошо, а что пока лучше делать самому

Андрей Чуян — основатель DebugSkills, автор AI-агента для работы с Ansible, спикер лабораторных по AI-оркестрации и Kubernetes.

📅 12.08.2026, 19:00 (МСК)
📡 ktalk
⏱️ 45 мин контент + 15 мин Q&A

> «Я ушёл из рутины, делегировал Ansible AI-агенту, который занимается этим.» — Андрей Чуян, из диалога с участником на лекции Jenkins

Это не вебинар и не лабораторная. Это живой разговор о том, как AI меняет работу DevOps-инженера уже сегодня. Без продаж, без подписок — просто приходите и смотрите.

Ссылка на регистрацию: https://debug-skills.timepad.ru/event/4127747/

Жду вас! 🤖

Проект делает ставку на обеспечение низких задержек, быстрого запуска и предсказуемого потребления ресурсов: состояние терминала обрабатывается на CPU, а отрисовка выполняется через бэкенды на базе Vulkan в Linux и Metal в macOS, без использования стороннего графического тулкита. При тестировании производительности вывод 100 МБ ASCII через терминал Shitty показывает ~118 МБ/с, обгоняя alacritty (0.81 с против 0.96 секунд), kitty и ghostty. На «случайных байтах» с некорректным UTF-8 отрыв от alacritty ещё заметнее (~51 МБ/с против ~31 МБ/с). Корректность работы Shitty обеспечивается более чем 5000 тестами, собранными из десятка с лишним внешних наборов — kitty, esctest, vttests из xterm, vttest, tack, libvterm, libtsm, alacritty, ghostty, contour, konsole, mosh. Тесты выполняются с проверкой работы на реальном PTY.

У новичка на сервере обычно два пути: открыть панель управления в браузере или подключиться по SSH и разбираться с командами. Панель дает готовые формы под типовые операции, консоль — прямой доступ к системе. Освоить панель получится быстрее, но Linux под ней никуда не денется.

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

Подробности — в блоге Рег.облака.

Вдохновившись вашими отзывами, вчера вечером я опубликовал проект на Hacker News. Результат превзошел все ожидания: прямо сейчас тред держит 204 поинта, а репозиторий набрал более 220 звезд на GitHub.

Проект попал в радар к хардкорным системщикам со всего мира. Среди тех, кто дал звезду, оказались инженеры из команд Cursor, Fly.io, Astro, создатель пакетного менеджера Pixi, разработчик Redox OS и в дискуссии на HN был легендарный автор утилиты Cydia @saurik.

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

Огромное вам спасибо! 

P.S. Хотел опубликовать в хаб «Я пиарюсь», но интерфейс не пропустил из-за нехватки кармы (нужно 30). Поэтому публикую в профильные хабы как апдейт к прошлой статье. Надеюсь на понимание!

Проект: https://github.com/wie-project/kakehashi

Статья на Хабре: https://habr.com/ru/articles/1065502/

Пост на Hacker News: https://news.ycombinator.com/item?id=49145937

Почему работа под root удобна и опасна? В Unix доступ к файлам и управление процессами зависят от пользователя и его групп. Root может изменять системные файлы, управлять службами, пакетами и сетью. При постоянной работе под root ошибка в команде способна затронуть системные файлы и службы. Опечатка в пути команды удаления или ошибка в скрипте, запущенном от root, может стереть системные файлы, изменить права на каталоги и остановить сервисы. При запуске от обычного пользователя ущерб чаще ограничен его правами. Украденный ключ, разрешающий вход под root, или пароль этой учётной записи сразу дают административные права. Ключ обычного пользователя даёт доступ только с его правами. Получение root-прав зависит от настроек sudo, пароля, уязвимостей и ошибок конфигурации.

Как правильно: отдельный пользователь и sudo.

В Ubuntu или Debian создайте пользователя и добавьте его в группу sudo:

adduser operator
 usermod -aG sudo operator

Добавьте публичный ключ в файл .ssh/authorized_keys в домашнем каталоге нового пользователя и проверьте вход по SSH. Затем задайте параметр в

/etc/ssh/sshd_config:
PermitRootLogin no

Проверьте конфигурацию и примените изменения без разрыва текущих подключений:

sshd -t && systemctl reload ssh

Мини-чек-лист безопасного старта на VPS

•        Отдельный пользователь создан, команды запускаются через sudo.

•        Публичный ключ добавлен, приватный защищён парольной фразой.

•        Вход по SSH под root отключён.

•        Обновления системы устанавливаются регулярно.

Проверьте настройки доступа к VPS: создайте отдельного пользователя с sudo, протестируйте вход по SSH и только после этого отключите вход под root.

🔥 Основы FastAPI: собираем сервис «прочитать позже»

У каждого есть свалка ссылок «прочитаю потом»: 40 вкладок, сохранёнки в Telegram, закладки с 2022 года. Проблема не в том, что нечего читать, — а в том, что всё это невозможно найти и разгрести.

Решим по-инженерному: напишем свой Read-Later сервис и с нуля освоим FastAPI.

6 августа, 19:00–20:30 МСК — бесплатный воркшоп с Ольгой Пичужкиной, Middle Python Developer (S-Cats).

За 1.5 часа:
⚡️ Поймёте, что такое FastAPI и почему он удобен
🧱 Опишете модель данных (SQLAlchemy + Pydantic)
🔁 Напишете полный CRUD
🔍 Научитесь фильтровать через query-параметры
📄 Получите Swagger UI бесплатно
🌐 Подключите простой фронтенд

Для кого: знаете Python, но ещё не писали API.

🛠 Куда дальше — дорожная карта: FastAPI — не просто фреймворк. На нём построен наш MCP Knowledge Server (Qdrant + семантический поиск) — ядро AI-ассистента сообщества, который «помнит» всё изученное.

Цепочка: 🐳 Docker (25.07) → 🐍 FastAPI (06.08) → 🧠 MCP Knowledge Server (сентябрь). В сентябре — отдельный воркшоп: поднимем такой сервер вместе.

📖 Pre-read: за 3 дня до воркшопа — инструкция по установке uv и Python.

🔗 Подробнее: https://debugskills.ru/content?article=labs-fastapi-workshop

#DebugSkills #FastAPI #Python #Backend

31 июля — День системного администратора, поздравляем с профессиональным праздником всех причастных! И это хороший повод ненадолго отложить чужие заявки и подумать о собственном развитии.

Профессия давно вышла за пределы настройки серверов и учетных записей. Современному админу приходится работать с контейнерами, автоматизацией, наблюдаемостью и безопасностью. Здесь собрали несколько бесплатных уроков для тех, кто хочет увереннее решать текущие задачи или двигаться в сторону DevOps, SRE и DevSecOps.

↓ Заглянуть под капот Linux
^{Когда проблема находится ниже уровня сервисов и конфигов, полезно понимать, что происходит внутри системы.}

«Что такое модуль ядра. Как его написать, собрать, запустить»
3 августа в 20:00
За один вечер можно пройти путь от исходного кода до загрузки собственного модуля и перестать воспринимать ядро Linux как полностью закрытый черный ящик. Записаться

↓ Быстрее находить причины сбоев
^{Обычный мониторинг сообщает, что сервису плохо. Наблюдаемость помогает понять, где именно все пошло не так.}

«OpenTelemetry — наблюдаемость на блюдечке»
4 августа в 20:00
Метрики, логи и трассировки пригодятся, когда один запрос проходит через несколько сервисов, а источник задержки или ошибки не лежит на поверхности. Записаться

↓ Сделать деплой предсказуемым
^{Если выпуск новой версии зависит от набора ручных команд и памяти конкретного сотрудника, процесс пора автоматизировать.}

«Kubernetes + CI/CD + GitOps — делаем стабильный деплой без выхода из кластера»
10 августа в 20:00
Полезно тем, кто хочет хранить состояние инфраструктуры в Git, контролировать изменения и откатываться без ночной археологии в терминале. Записаться

↓ Перестать искать логи по серверам вручную
^{Чем больше машин и контейнеров, тем меньше хочется подключаться к каждому из них ради одной строки.}

«Системы логирования: ELK, EFK или Graylog?»
17 августа в 20:00
Возможность сопоставить популярные стеки и понять, какой из них лучше подходит под конкретную инфраструктуру, объем данных и доступные ресурсы. Записаться

↓ Подготовиться к сбою до сбоя
^{Единственная точка отказа обычно не беспокоит ровно до того момента, пока не откажет.}

«Готовим инфраструктуру к сбоям: отказоустойчивый кластер на базе VRRP и HAProxy»
18 августа в 19:00

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

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

Метрика простая на вид и очень легко используется неправильно. Ниже — как она устроена, как снять её так, чтобы результат что-то значил, и почему высокий steal сам по себе ещё не диагноз.

Как steal вообще появляется Гипервизор раздаёт физические ядра между виртуальными машинами. Когда планировщик гостевого ядра ставит задачу на vCPU, а гипервизор в этот момент отдал физическое ядро другой машине, гостевое ядро видит, что время прошло, а работа не выполнялась. Эта разница и учитывается как steal.

Отсюда важное следствие: steal измеряется изнутри гостя и всегда является косвенной оценкой. Гость не знает, почему ему не дали ядро. Причин минимум четыре:

• конкуренция с соседними VM на ноде;

• ограничение по CPU на уровне тарифа (квота), которое гипервизор применяет к вам;

• накладные расходы самого планировщика гипервизора;

• кратковременные всплески — миграция VM, резервное копирование ноды, обслуживание.

Где steal не виден вообще? Если у вас контейнерная виртуализация (lxc, openvz), steal time не появится никогда — механизма для него нет, ядро общее с хостом. Проверить:

systemd-detect-virt

Аналог steal для контейнеров — троттлинг по cgroup:

grep -E 'nr_throttled|throttled_usec' /sys/fs/cgroup/cpu.stat
cat /sys/fs/cgroup/cpu.max

Растущий nr_throttled означает, что вы выбираете свою квоту. Это не соседи и не оверселлинг — это ваш лимит, и решается он либо оптимизацией, либо тарифом.

Какие значения считать нормой. Универсальной нормы нет — она зависит от платформы виртуализации, политики провайдера и тарифа. Практические ориентиры, которые у меня обычно работают:

• 0–1% — фон, встречается почти везде, игнорируем.

• 3–5% — повод посмотреть динамику и сопоставить с задержками приложения. Само по себе не проблема.

• выше 10% устойчиво — заметно влияет на латентно-чувствительные сервисы: API, realtime, базы под нагрузкой. Пакетную обработку может почти не задевать.

Ключевое слово — устойчиво. Смотрите значение за 10–15 минут, а не пиковый выброс. Разовый скачок до 30% на две секунды не значит ничего.

Как отличить соседей от собственной квоты. Единственный надёжный способ — сопоставить steal с вашей нагрузкой.

Постройте два ряда за сутки: steal и ваш собственный CPU usage (us + sy). Дальше:

• Steal растёт вместе с вашей нагрузкой и падает вместе с ней — почти наверняка вы упираетесь в квоту тарифа. Провайдер тут ни при чём.

• Steal приходит независимо от вашей активности, в том числе ночью при простое, — это внешняя конкуренция.

• Steal ровным фоном 2–3% круглосуточно — накладные расходы платформы, обычно нормально.

Без исторических данных этот анализ невозможен, поэтому sysstat стоит поставить заранее, а не в момент инцидента.

Что передавать в поддержку? Обращение вида «у меня высокий steal» почти всегда возвращается с просьбой уточнить. Работает такой набор:

• вывод sar -u 1 600 или график за несколько часов;

• mpstat -P ALL 1 за минуту — с разбивкой по ядрам;

• ваша собственная загрузка CPU за тот же период, чтобы показать отсутствие корреляции;

• конкретные временные метки, когда приложение деградировало;

• systemd-detect-virt и параметры тарифа.

Что не поможет

• Оптимизация кода. Если ядро вам не выдают, эффективность вашего кода на steal не влияет.

• Добавление vCPU. Иногда даже ухудшает: больше vCPU — больше конкуренции за планирование, особенно на переподписанной ноде.

• Перезагрузка. Помогает только если приводит к переезду на другую ноду, и это лотерея.

Чек-лист

systemd-detect-virt                          # есть ли steal в принципе
vmstat 1                                     # характер: плато или выбросы
mpstat -P ALL 1                              # распределение по ядрам
sar -u 1 600                                 # устойчивость за 10 минут
grep throttled /sys/fs/cgroup/cpu.stat       # для контейн

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

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

Сети, хранение данных и отказоустойчивость

• 30 июля в 20:00. «Восстанавливаем RAID5 в Linux». Записаться

• 3 августа в 20:00. «MPLS для корпоративных сетей: мифы, реальность и практика». Записаться

• 18 августа в 19:00. «Готовим инфраструктуру к сбоям: отказоустойчивый кластер на базе VRRP и HAProxy». Записаться

• 24 августа в 20:00. «Защита от петель L2: что выбрать, если STP уже не устраивает». Записаться

Linux и системное программирование

• 3 августа в 20:00. «Что такое модуль ядра. Как его написать, собрать, запустить». Записаться

• 10 августа в 20:00. «Вход в ядро: системные вызовы и граница между user space и kernel space». Записаться

• 20 августа в 20:00. «Средства защиты в ядре Linux». Записаться

Kubernetes и автоматизация инфраструктуры

• 10 августа в 20:00. «Kubernetes + CI/CD + GitOps — делаем стабильный деплой без выхода из кластера». Записаться

• 13 августа в 20:00. «Принцип DRY в GitLab CI: как избавиться от дублирования и навести порядок в пайплайнах». Записаться

Наблюдаемость и логирование

• 4 августа в 20:00. «OpenTelemetry — наблюдаемость на блюдечке». Записаться

• 17 августа в 20:00. «Системы логирования: ELK, EFK или Graylog?». Записаться

Безопасность инфраструктуры

• 3 августа в 20:00. «Какие результаты должен давать DevSecOps-проект бизнесу и команде». Записаться

• 18 августа в 20:00. «Безопасный релиз на практике: SAST, SCA, контейнеры и security gates». Записаться

Все занятия бесплатные. Можно задать вопросы преподавателю, сверить настройки и понять, какой инфраструктурный пробел стоит закрыть следующим.

ЧТО ПОЧИТАТЬ ПО ТЕМЕ

• «История о том, как мультикаст IGMP-запрос перестал быть запросом и стал broadcast-штормом»
  _{Разбор сбоя сетевых карт Intel X710: как найти причину по логам, проверить драйвер и прошивку и вернуть мультикаст в рабочее состояние.}

• «Ищем петли и шторма в L2-сети»
  _{Практический материал о поиске сетевых петель, MAC flapping, диагностике проблемного порта и защите сети от повторного коллапса.}

• «4 антипаттерна CI-автоматизации, из-за которых команда делает работу за ботов»
  _{О том, почему автоматические напоминания только создают новые ручные задачи и как перенести в конвейер само выполнение рутинных действий.}

• «От capabilities к AppArmor: что реально остановит атакующего в контейнере»
  _{Разбор многоуровневой защиты контейнера с помощью capabilities, seccomp и AppArmor: какие угрозы закрывает каждый механизм и где остаются пробелы.}

Больше открытых уроков, статей и материалов по Kubernetes, сетям, Linux, наблюдаемости и безопасности инфраструктуры — в полном дайджесте.

🏕️ Ваши друзья не понимают, зачем идти в лес с IT-шниками.

Саша планирует поехать на DebugCamp в сентябре. Это наш регулярный выезд на природу на 20 человек — проводим 2 раза в год. Саша написал нам честно: «Зову всех, но в кругу нет кто согласился».

Знакомо?

Когда вы говорите «пойду в лес с айтишниками на два дня», люди слышат «пойду спать в палатке с коллегами без связи». Картинка в голове - выживание, а не осмысленный выезд.

На самом деле DebugCamp - это два дня с понятной программой. За 48 часов вы:

- Формулируете личный запрос (карьерный, технический, продуктовый)

- Получаете идеи от 10+ коллег — не small-talk, а разбор рабочих задач: приносите свою — группа помогает найти решение

- Проходите квест-ориентирование «Тропа Выживания» с инструктором

- Участвуете в вечернем разборе карьерных вопросов в кругу коллег у костра

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

Сомневаться - нормально. Вы не один такой.

Если хоть раз думали «а почему бы и нет» - программа здесь

#DebugCamp #DebugSkills #ITмероприятия #поход #нетворкинг

Всё, что оно делает - показывает текст текущей песни в верхней панели. Тексты песен извлекаются с помощью lrclib.net.
Также есть небольшое меню настроечек, текст можно переместить в левый или правый угол панели.
Тестировал его на Fedora 44 Workstation, GNOME 50. Вроде работает.
Публиковать его я не хочу, мне лень этим заниматься. Но если кто-то хочет потестить - оно валяется на github

Навайбкодил небольшое веб-приложение для управления ИИ-сервером под Ubuntu. Управляем произвольными systemd-сервисами, добавляем новые + спец. диалог для добавления llama-server как сервиса. Возможно, кому-то пригодится: aiservermanager.

В начале проекта Uwoslab запланировал использовать 400 батареек: закупил четыре упаковки по сотне и 50 групп по восемь элементов. В процессе работы конструкция вышла проще. На всё ушло 192 батарейки. Энтузиаст распределил элементы по трём блокам, по 64 штуки в каждом. Ток от этой такой мегабатареи идёт напрямую в материнскую плату через переходник 12V DC-to-ATX.

По прикидкам Uwoslab, именно сборка из 400 таких батареек могла бы выдавать около 160 Вт на протяжении десяти часов. Характеристики ПК: система на сокете AM4 со встроенной графикой и без накопителя. ОС грузится прямо с флешки - Hannah Montana Linux на базе Debian.

На старте батарейный блок выдавал около 13 В, а под нагрузкой встроенного теста stress-ng, когда процессор загрузили на 98%, напряжение просело лишь до стабильных 11,95 вольта — ПК работал штатно. По остаточному заряду автор предположил, что она могла бы протянуть ещё пару часов, прежде чем напряжение упадёт слишком сильно. Также энтузиаст запустил на таком ПК FreeDoom.

Публикации про инцидент с xz на Хабре:

• «Можно ли было обнаружить бэкдор xz при более продуманной работе с пакетами в Git и Debian?»

• «Бэкдор в xz нашли из‑за замедления работы sshd в полсекунды».

🔥 Docker для начинающих: от «что это» до своего контейнера за 4 часа

Docker используется везде: от локальной разработки до production. Фокус лабы — не на запоминании команд, а на понимании. Вы пройдёте путь от первого контейнера до настройки сетей и данных — своими руками. После лабы сможете уверенно обсуждать контейнеризацию с разработчиками, DevOps и архитекторами.

25 июля, 10:00-14:00 МСК | Максим Тачков, Middle Developer (BIM), преподаватель Docker. По отзывам с прошлой лабы: экспертиза 9/10.

5 блоков за 4 часа: (1) Основы Docker → (2) Сборка (Dockerfile) → (3) Управление (Compose, логи, мониторинг) → (4) Данные (volumes, bind mounts) → (5) Сети (Docker Network, DNS)

За 4 часа вы:

- 🐳 Освоите словарь Docker: image, container, volume, network, Dockerfile

- 🔧 Соберёте и запустите свой первый контейнер из Dockerfile

- 🛠 Научитесь управлять контейнерами через Docker Compose

- 📦 Настроите хранение данных через volumes и bind mounts

- 🌐 Настроите сетевое взаимодействие между контейнерами

Для кого: Backend, frontend, fullstack разработчики, QA-инженеры, системные и бизнес-аналитики, архитекторы, технические менеджеры. Нужно: базовый CLI, понимание веб-приложений, VS Code.

🎬 Запись — 20%. Живая практика с ведущим, ответы на вопросы, разбор ошибок — только на лабораторной.

📖 Pre-read: за 3 дня до лабы высылаем шпаргалку по Docker-командам — подготовьтесь заранее и не теряйте темп.

🛠️ Makefile как «пульт управления» — одна команда = одно действие. Фокус на понимании, а не на синтаксисе CLI.

🚀 Дальнейший маршрут: Kubernetes → REST+OpenAPI → Keycloak → Kafka → Prometheus+Grafana.

🔗 Подробнее: https://debugskills.ru/content?article=labs-docker-basics

Вы пробовали ChatGPT и Cursor. Но система из нескольких AI-агентов — это другой уровень: агенты конфликтуют, теряют контекст, зацикливаются, а отладка напоминает расследование без улик.

🎻 Один AI = музыкант. Несколько AI = оркестр. А кто дирижёр?

19 июля, 10:00-14:00 МСК — лабораторная работа с Андреем Чуяном, создателем ROLES-экосистемы (3 экосистемы, 15+ ролей). За 4 часа: проектирование AI-ролей с YAML-контрактами, 5 хаос-сценариев, MCP-сервер на личной VM, самодиагностика экосистемы.

📐 Проверенная методология FPF + TDD в основе каждого блока.

🔗 Подробное описание: https://debugskills.ru/content?article=labs-ai-orchestration
Готовы спроектировать свою первую AI-экосистему? Приходите 19 июля! 🚀

Обновили ядро Linux на всех Ryzen-серверах в Москве

В копилку стабильности — и с конкретным обновлением под капотом.

Во время работы с высокопроизводительными серверами на Ryzen 7950X нашли причину редких зависаний нод. На старом ядре Ubuntu 22.04 эти процессоры могли работать нестабильно.

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

Чтобы устранить проблему, обновили ОС и ядро на всех Ryzen-серверах в московской локации.

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

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

Если вам нужны мощные серверы в Москве, есть еще одна новость — расширили парк Ryzen 7950X, чтобы было больше доступных конфигураций под ваши проекты.

Многодоменная архитектура: почему бэкап одного домена не восстанавливает сервис

В инфраструктурных проектах иногда возникает идея разделить окружение на несколько доменов:

• пользователи – в одном контуре;

• серверы и рабочие станции – в другом;

• тестовая среда – в третьем.

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

Но в эксплуатации важен не только вопрос «где лежит объект».

Важнее другое: какие зависимости связывают объекты между собой.

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

Сценарий

Пользователь – в домене A.
Рабочая станция – в домене B.
Группа доступа к приложению – в домене C.

Цепочка доступа:

учётная запись → группа → DNS → доверие между доменами (Kerberos) → права на сервере.

Каждый компонент по отдельности может выглядеть исправным:

KDC отвечает. LDAP-серверы доступны. DNS разрешает имена. Билеты выдаются. Группа существует. Пользователь в группе.

А доступ к приложению всё равно не работает.

Почему? Потому что сломался не отдельный объект, а связь между объектами.

Именно здесь обычная логика «объект изменился → нашли резервную копию → восстановили объект» перестаёт быть достаточной.

В многодоменной среде важно уметь восстановить не только объект, но и связность: группы, доверительные отношения между доменами, DNS SRV-записи, Kerberos-зависимости и порядок применения политик.

Что стоит проверить заранее

• Основной источник данных – где создаются пользователи, где живут группы, какие домены участвуют в кросс-аутентификации.

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

• Контур восстановления – какие домены можно восстанавливать отдельно, а какие требуют жёсткой последовательности: например, сначала восстановить домен A, проверить состояние доверия к B и только потом тестировать доступ.

• DNS и Kerberos – понимаем ли мы, как после восстановления домены находят друг друга? Не разъедутся ли ключи на сервисах и контроллерах, если восстановление идёт из старого снепшота? При откате может измениться KVNO в SPN-записях, и Kerberos-аутентификация для ресурсов сломается, хотя формально всё «зелёное».

• Сквозной тест доступа – проверяем не только доступность серверов, а весь путь: пользователь из одного домена должен получить доступ к ресурсу в другом.

Главный вывод

Многодоменная архитектура – это не просто «удобно разделили контуры». Это более сложная эксплуатационная модель.

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

Иначе гибкость на этапе проектирования превращается в непрозрачность при первой серьёзной аварии.

Коллеги, тестируете восстановление всей цепочки доступа или только каждый домен по отдельности?

#Linux #Инфраструктура #Backup

Если вы хотите лучше разобраться во внутреннем устройстве Linux и узнать, как его ядро взаимодействует с физическими устройствами, то приходите на бесплатный офлайн мастер-класс YADRO. Вместе пройдем полный цикл создания драйвера дисплея LCD1602 для VisionFive2: от теории до добавления новых функциональных элементов и запуске на одноплатнике.

Что будем делать:

• загрузим информацию о дисплее в ядро через Device Tree Overlay;

• выведем текст на дисплей через драйвер Linux для embedded-систем;

• считаем содержимое дисплея из ядра Linux и выведем в консоль;

• научимся управлять подсветкой и курсором через интерфейсы Linux Kernel Driver;

• займемся обработкой IRQ по нажатию кнопки;

• разберем типичные ошибки при разработке Linux-драйверов.

Мастер-класс проведет Никита Косырев, инженер-программист группы системного ПО в YADRO. Никита — энтузиаст embedded-систем и архитектуры RISC-V, несколько лет занимался разработкой драйверов периферийных устройств в ядре Linux. 

Приглашаем инженеров, которые хотят лучше разобраться в низкоуровневой разработке для Linux и особенно тех, кто работает с user space-приложениями. 

Мастер-класс пройдет офлайн 3 июля в московском офисе YADRO, количество мест ограничено. Участие бесплатное, но регистрация обязательна.

Российский Linux. Встреча с реальностью

Есть у нас один заказчик. Весь в Windows. Решил переезжать на российское.
На бумаге всё выглядит понятно: выбирает дистрибутив, разворачивает сервисы, переносит приложения, постепенно уходит от прежнего стека.
Упирается в версию Samba, которой в родных репах нет. Пакет конфликтует с системными библиотеками. Yum (dnf) не может разрешить зависимости и ломается.
Решили просто: подключили репы CentOS, перетерли половину системных пакетов.
На тесте взлетело. В продакшен – уже риск.

Вопрос, который сразу возникнет: «А почему просто не собрать Samba из исходников?»

Для тестовой лабы – ок. Для прода с сотнями пользователей – нет. И вот почему.

Почему это проблема, а не просто настройка

Когда для домена (Samba, Kerberos, DNS) вы собираете из исходников или лезете в чужие репозитории – вы теряете три вещи:

Поддержку вендора
В договоре чёрным по белому: только штатные репозитории. Подменили пакет или поставили самосбор – тикет закроют фразой «сами собрали, сами и поддерживайте».

Безопасные обновления
Выходит апдейт от вендора. При левых репах – dnf update падает с конфликтом зависимостей. При самосборе – вы вообще не получите апдейт, чинить каждую CVE придётся руками.

Сертификацию (ФСТЭК/Минцифра)
И левый репозиторий, и самосбор аннулируют сертификат моментально. На проверке это увидят.

Важное уточнение для тех, кто вспомнит EPEL
EPEL подключают к RHEL для установки дополнительного софта, которого нет в базе. Он не трогает системные пакеты. В нашем кейсе – родной репозиторий ОС не содержал нужной версии критического пакета (Samba). Пришлось лезть в чужой репозиторий и заменять базовые пакеты. Это совсем другая история.

Коротко про вендора

Вендор скажет ровно одно: «Ваша система — не наша сборка. Приходите, когда переустановите без левых реп и самосборов». Никто не приедет, не поправит, не подстрахует. Вы один на один с костылём.

Вывод

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

Плохие решения: подключать левые репозитории и подменять пакеты, собирать из исходников в продуктиве.

Правильные решения:
Взять другую российскую ОС, где эта роль работает из коробки.
Потребовать от вендора добавить нужные пакеты в свой репозиторий.
Отказаться от этой роли/стека, если ОС его не тянет.

Подмена пакетов в продуктиве – не выход, а вход в ад техподдержки.

Больше про российский ИТ без простоев – в телеграм-канале.

Это пошаговый маршрут изучения Linux с упором на практику. Каждый раздел содержит объяснение «почему это устроено именно так», разбор команд и обязательные задания, которые нужно выполнить руками в терминале. Чтение без повторения навыка не даёт — держите терминал открытым рядом с этим текстом.

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

https://github.com/justxor/linuxfullroadmap/

Кому нужно больше инфы пишите, буду отвечать!

Скоро будет доступен гитхаб проекта и сайт!

Реализация основана на коде проекта uutils (Rust Coreutils), развивающего вариант GNU Coreutils на языке Rust, а также реализациях утилит find и grep на Rust. Утилиты собраны в виде одного универсального исполняемого файла "C:\Program Files\coreutils\coreutils.exe", отдельные команды к которому привязаны при помощи жёстких ссылок в NTFS.

Из‑за конфликта с имеющимися штатными утилитами Windows или привязки к специфичным возможностям из поставки исключены утилиты dd, dir, dircolors, shred, sync, uname, expand, kill, more, paste, timeout и whoami. Из состава также исключены утилиты, завязанные на не поддерживаемые в Windows концепции POSIX: chcon, chgrp, chmod, chown, chroot, groups, hostid, id, install, logname, mkfifo, mknod, nice, nohup, pathchk, pinky, runcon, stdbuf, stty, tty, users, who.

Из ограничений и особенностей отмечается необходимость использовать NUL вместо /dev/null, отсутствие поддержки сигналов (SIGHUP, SIGPIPE, SIGUSR), возможность создания символических ссылок только после включения режима для разработчика, недоступность некоторых операций с правами доступа. При работе с каталогами принимаются как пути с символом "/", так и c "\".

На лицензию OpenMDW-1.1 переходят 4 семейства: Cosmos, Isaac GR00T, Ising и Nemotron.

Стандарт разработан Linux Foundation для ИИ-индустрии и одним документом покрывает все компоненты релиза: исходный код, датасеты, веса, метаданные и документацию. Лицензия позволяет делать дообученные модели и производные продукты проприетарными.

Разработчики получают права на коммерциализацию, модификацию и распространение моделей. Единственное требование - сохранение оригинальных копирайтов при дистрибуции.

https://openmdw.ai/

• Объём загружаемых пакетов вырос с обычных 2 Гб до 4 Гб! Вероятно у вас будет меньше, ведь это зависит от установленных вами пакетов, но если судить относительно прежнего объёма, то скачёк потребления трафика с учётом мобильного доступа не радует. Скаченные пакеты я сохранил, чтобы на других ноутбуках с Ubuntu не пришлось снова качать 4 Гб. Раньше я так не делал.

• Во время установки пакетов рабочий стол заблокировался с сообщением, что у меня нет прав root, чтобы что-то сделать, что именно не написано. Причём нажатие на Отмена блокировку не снимало, и окно сообщения оставалось открытым. Похоже на какой-то баг Gnome, Resolute или где-то глубже в системе. Дождался, когда индикатор диска и вентилятор успокоятся, в надежде, что обновление закончилось успешно, переключился на консоль и сделал reboot.

• После первой загрузки и входа в Gnome рабочий стол завис. Снова переключение в консоль и reboot. После второй перезагрузки Gnome заработал. Это ещё один явный баг.

• Теперь после каждого включения с нуля или после сна, не важно, запускается какой-то процесс localsearch, который интенсивно работает с диском и греет процессор. Причём процесс ветвится. Как отключить не понятно. Подождав полчаса сделал kill по номеру процесса localsearch. И вынужден делать это каждый раз.

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

В предыдущих выпусках был ещё баг с thumbnailer, который при открытии в Nautilus папки с большим количеством фото, выжирал остатки памяти, что приводило к торможению всей системы намертво и последующего принудительного жёсткого отключения питания (известный баг Linux, который за десять или более лет так и не исправлен). Как я понял, в 26.04 thumbnailer был заменён на что-то другое, и я пока ещё не поимел проблем с большими папками с фото. Но посмотрим…

UPD Посмотрел, что это за localsearch. Похоже, что это часть Gnome. Поэтому стандартными средствами управления сервисами его не отключить. Запускается при входе в Gnome. Как эту ненужную мне и вредную с точки зрения энергопотребления и шумозагряднения штуку выключить в Gnome? (В комментарии дали совет, но в первый раз нужно всё-таки сделать kill для процесса, одного его отключения не достаточно. После перезагрузки процесс localsearch уже не будет беспокоить.)

Резюме Ещё до обновления я начал искать альтернативы Ubuntu, понимая что запросы системы к процессору и памяти растут, Ubuntu всё больше походит на bloatware и corporate, а переходить на более новое железо я не собираюсь. Пока в качестве альтернатив рассматриваю: antiX, Devuan, Gentoo, Void, Guix, NetBSD, OpenBSD. Этот набор обусловлен тем, что мне нужно, чтобы система поддерживала 32-разрядность. И я хочу иметь на 32- и 64-разрядных системах одинаковый опыт и навыки работы с ними. А какие альтернативы Ubuntu используете вы? Что скажете про мой список альтернатив? Кстати, до полного перехода на Ubuntu я также работал в последние годы с ElementaryOS, Manjaro, Fedora. Пробовал antiX, Void, NixOS и Guix. По большому счёту они отвергнуты были в том числе по тем же причинам, что теперь и Ubuntu, Кроме antiX, Void и Guix. Это особый случай, и это отдельная тема для разговора.

(с) Симоненко Е.А., 2026