AlmaLinux 10 вернул полноценную поддержку Btrfs, включая возможность загрузки системы с Btrfs volume.
Это опять показывает текущую философию проекта:
совместимость с RHEL
≠
запрет на полезные дополненияЕсли изменение не разрушает целевую совместимость, AlmaLinux может добавлять возможности, которых нет в соответствующей конфигурации RHEL.
Для определённых сценариев Btrfs даёт:
- — snapshots;
- — checksums;
- — subvolumes;
- — compression;
- — дополнительные варианты управления storage.
Но само наличие Btrfs не означает, что его автоматически следует использовать в любой production-системе.
Это просто ещё один доступный инструмент.
Поддержка старого оборудования
В AlmaLinux 10 проект также вернул поддержку ряда PCI ID и драйверов для оборудования, отключённого upstream.
Среди них встречаются старшие поколения:
- — RAID-контроллеров;
- — Fibre Channel HBA;
- — сетевых адаптеров;
- — storage controllers.
Практическое следствие:
AlmaLinux 10 может оказаться пригоден для части оборудования, на котором стандартная Enterprise Linux 10-система уже не является очевидным вариантом.
Но здесь особенно важно тестирование.
Факт наличия драйвера:
≠ гарантия нормальной эксплуатации конкретного сервера десять лет
SELinux
В AlmaLinux SELinux является полноценной частью системы безопасности.
Типовая production-конфигурация:
SELinux → Enforcing
Очень распространённая ошибка администратора:
приложение не работает
↓
setenforce 0
↓
заработало
↓
отключаем SELinuxНо правильный вывод:
ограничение действительно связано с SELinux.
Следующий шаг:
почему policy запрещает действие?
а не:
SELinux мешает — выключаем
Для Enterprise Linux умение работать с SELinux — часть нормальной эксплуатации.
firewalld
Аналогично с сетью.
Типовая система использует:
firewalld
↓
zones
↓
services / ports / sourcesТо есть вместо:
открыть всё
можно описывать доступ на уровне роли сервиса.
Например:
firewall-cmd --add-service=https
При этом реальную применённую конфигурацию всё равно нужно проверять, а не просто наличие команды в истории shell.
Secure Boot
AlmaLinux поддерживает UEFI Secure Boot.
Проект использует подписанный shim, позволяющий загружать доверенные компоненты в Secure Boot environment.
Для современных физических серверов и рабочих станций это важно, если требования включают:
UEFI Secure Boot + trusted boot chain
Причём в актуальных AlmaLinux 8/9/10 уже учитывается переход на новые сертификаты Microsoft Secure Boot.
Cloud
AlmaLinux существует не только как ISO для физического сервера.
Проект предоставляет официальные cloud images.
Например для:
- — AWS;
- — Google Cloud;
- — Oracle Cloud;
- — generic cloud / cloud-init сценариев.
Типовая модель:
cloud VM ↓ официальный AlmaLinux image ↓ cloud-init ↓ configuration management
Для автоматизированного развёртывания это удобнее, чем устанавливать ОС с ISO.
Контейнерные образы
Есть и официальные container images.
Причём доступны разные варианты:
Default Minimal Base Init Micro
Это позволяет использовать AlmaLinux не только как container host, но и как базу контейнера.
Например:
FROM almalinux:10
может быть удобен, если application environment должен оставаться близким к Enterprise Linux.
Особенно когда production-хосты или целевая vendor-среда также ориентированы на RHEL-compatible stack.
Что означает длинный жизненный цикл
Для AlmaLinux 10:
active support → до 31 мая 2030 security support → до 31 мая 2035
То есть major-ветка рассчитана примерно на десятилетний жизненный цикл.
Для инфраструктуры это принципиально.
Можно строить систему:
2025 ↓ 2026 ↓ ... ↓ 2035
без обязательной смены major OS каждые несколько лет.
Но здесь есть нюанс.
Minor release — не отдельная десятилетняя версия
Например:
10.1 10.2 10.3
не поддерживаются параллельно до 2035.
После выхода следующего minor release предыдущий перестаёт быть текущей поддерживаемой точкой ветки.
То есть эксплуатационная модель:
AlmaLinux 10
↓
10.1 → 10.2 → 10.3 → ...
↓
регулярные обновленияа не:
поставил 10.0 и держу именно 10.0 десять лет
Это важное различие.