K0Shik

23 апреля 2026 года Canonical выпустила Ubuntu 26.04 LTS Resolute Raccoon. Для меня это старт большого проекта. Работа Linux-администратора в крупной компании подразумевает создание «золотого образа», который потом годами будет крутиться на сотнях машин.

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

Срок поддержки заявлен до 2031 года. Для корпоративной среды это главный аргумент: если сейчас нормально подготовить дистрибутив, на нём можно спокойно жить ещё 5 лет.

Первое знакомство.

Canonical в документации указывает для Ubuntu Desktop 26.04 минимум 6 ГБ RAM, 2 GHz dual-core CPU и 25 ГБ.

В чистом виде, без swap-файла, система заняла у меня около 6.6 ГБ на диске. Потребление оперативки на старте чуть меньше 2 ГБ. На фоне этого официальная рекомендация в 6 ГБ RAM выглядит как оценка для комфортной работы.

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

После тестовой установки нескольких тяжеловесных приложений, система ощущается плавной и отзывчивой. Дальше предстоит выяснить что поменялось в системе, где могут сломаться сценарии Puppet, не поедут ли настройки dconf/gsettings и ещё тысячи других мелочей.

Что нового в «Решительном еноте»?

Если сравнивать с 22.04 (которая до сих пор остается основной рабочей лошадкой во многих конторах), то это довольно крупный технологический скачок.

- Ядро Linux 7.0. Ubuntu 26.04 базируется на новой мажорной версии ядра. Это поддержка самого свежего железа, оптимизации в работе планировщика, а также свежие фичи в сетевом стеке.

- GNOME 50 принёс улучшения в адаптации интерфейса под небольшие экраны, аппаратное ускорение записи экрана, прокачанный remote desktop и более плавную работу. GNOME-сессия теперь работает только на Wayland. Старый добрый X11 не бросили (он работает через XWayland), но стандартная сессия как X.org больше не запускается. Здесь есть риск что все настройки связанные с графикой и удалённым доступом могут сломаться.

- Также Canonical удалила PreLogin и PostSession скрипты. Это может задеть корпоративные сценарии, например синхронизацию домашней директории при входе/выходе или очистку временных данных.

- Расширилось использования Rust в системе. Это помогает бороться с целым классом ошибок памяти, что всё равно не делает утилиты полностью безопасными.

- APT 3.1. Наконец то история операций и команды для отката: apt history-info, apt history-undo, apt history-redo, apt history-rollback. Вещь полезная, особенно когда случайно удалил лишнее.

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

- Dracut — новый механизм сборки initramfs по умолчанию. Он отвечает за ранний этап загрузки системы: подготовку драйверов, модулей, шифрования дисков и всего, что нужно до старта основной ОС.

- TPM-backed full-disk encryption — полнодисковое шифрование с привязкой ключей к TPM-чипу. Система может разблокироваться автоматически, если проверка целостности прошла успешно. Это удобно, но требует аккуратности при обновлениях BIOS или замене платы.

- CUDA и ROCm в репозиториях Ubuntu — упрощённая установка инструментов для вычислений на GPU, что полезно для ML.

Итог

Первое впечатление у меня положительное. Система установилась без сюрпризов, занимает умеренно места, по памяти выглядит адекватно, интерфейс работает плавно. В системе заявлено довольно много новых технологий, что обещает начало долгого марафона по настройке и тестированию. Будем смотреть, как Енот покажет себя в «боевых» условиях.

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

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

Но экскаватор внёс свои коррективы и просто перерубил оптику, отрезав один из ЦОДов от остального мира. Казалось бы, чего переживать: компоненты распределены, запас прочности есть, значит переживём.

Только реальность, как обычно, интереснее, чем схемы на бумаге.

В сервисе были указаны локальные DNS-серверы, и находились они как раз в том самом отрубленном ЦОДе. Формально сервис продолжал жить, но тихо начал деградировать.

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

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

Postmortem составили, причины выяснили, выводы сделали. Дальше уже обычная инженерная работа — не просто обсудить проблему, а закрыть дыру в архитектуре. Так появилась задача добавить собственный кэширующий DNS, который позволил бы сервису продержаться без удалённых резолверов.

Я взял эту задачу на себя. Перебрал несколько вариантов и в итоге поднял в Kubernetes связку из двух pod’ов Unbound для отказоустойчивости и Redis для хранения кэша. Redis сохраняет данные в файл в хранилище Ceph, чтобы кэш не исчезал после перезапуска и система не начинала каждый раз с чистого листа.

Получился ещё один слой устойчивости.

Самое полезное в таких историях не конкретный стек, а понимание простой вещи: отказоустойчивость проверяется не только количеством узлов, но и надёжностью зависимостей.

Как говорил великий классик:

«Опыт, сын ошибок трудных».

Официально: репозиторий github.com/minio/minio отправлен в архив. Поддержка Community Edition прекращена, а пользователям настойчиво предлагают переходить на платный продукт AIStor.

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

- Сначала «вырезали» удобный UI из бесплатной версии.

- Затем перестали выкладывать готовые Docker-образы и бинарники.

- Позже документация стала привилегией Enterprise-клиентов.

- Проект перешел в режим «только фиксы», а теперь и вовсе заархивирован.

В ноябре прошлого года я как раз готовили проект с использованием minio: мне выделили мощности, подготовили десятки терабайт под данные, я настроил кластер с хранением в cold tier.

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

После совещания рисковать инфраструктурой не стали и начали искать альтернативное S3-хранилище. Глядя на текущий статус репозитория — решение было на 100% верным.

У кого есть необходимость в S3, какое хранилище сейчас рассматриваете вы в качестве альтернативы?

Меня особенно привлекают два момента:

⚙️ Производительность десктопа и накопителей

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

не только для серверов, но и для тысяч десктопных машин. Любое улучшение планировщика или подсистемы ввода-вывода напрямую влияет на пользовательский опыт и стабильность всей инфраструктуры. Чем меньше тормозов - тем меньше обращений в поддержку 😉

🦀 Rust официально в ядре

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

Думаю следующий язык, который я буду осваивать будет Rust. Пора расширять инструментарий и заглядывать в будущее инфраструктурных решений.

Вы будете тестировать новую версию ядра сразу или будете ждать, пока оно не войдёт в стабильный релиз или LTS-ветку?