Встановлення AlmaLinux 10: корпоративний Linux із чітким шляхом оновлення

Чому AlmaLinux 10 (і що ви насправді обираєте)

AlmaLinux — це дистрибутив Enterprise Linux, орієнтований на сумісність із екосистемою RHEL. Простими словами для операційної роботи: ви отримуєте конвенції пакування, поведінку systemd, стандартні налаштування SELinux та адміністративні шаблони, на яких підприємства стандартизуються. Це важить більше, ніж логотип.

Справжня цінність AlmaLinux 10 — не «безкоштовність». Це передбачуваність. Передбачуваний процес завантаження (UEFI), передбачувана безпекова позиція (SELinux увімкнено), передбачувані інструменти оновлення (DNF), передбачувані шаблони життєвого циклу (мажорні оновлення — події, мінорні — технічне обслуговування).

Але сумісність працює в обидва боки. Якщо ви встановлюєте його як хобі-дистрибутив — один гігантський розділ, без думки про /var, без плану щодо UEFI, без базової конфігурації — тоді кожен «мінорний» інцидент перетвориться на контактний спорт.

Ось моя принципова позиція: встановлюйте AlmaLinux 10 так, як плануєте експлуатувати його 5–10 років. Якщо ви не можете на це погодитися, запустіть його в контейнері або оберіть те, що готові часто перебудовувати.

Цікаві факти та історичний контекст (щоб не повторювати історію)

• Колись клонів Enterprise Linux вистачало встановити і забути. Потім зсуви в політиці upstream зробили «стратегію клонування» питанням на рівні ради директорів, а не хобі адміна.
• UEFI став типовою історією завантаження, бо BIOS-завантаження — це фактично експонат музею, що ще живить вашу платіжну систему.
• SELinux зі статусу «вимкніть» перейшов у «він нас врятував». Сучасні інструменти політик і кращі дефолти зробили режим enforce розумною базою знову.
• DNF замінив YUM, щоб виправити проблеми з розв’язанням залежностей і продуктивністю; команда «yum» здебільшого суміснісний шар зараз.
• systemd переміг, бо консистентне управління сервісами краще тисячі авторських init-скриптів, особливо під час збоїв.
• За замовчуванням OpenSSH посилив налаштування (алгоритми, заборона root-логінів). Старі «дозволити все» конфіги стають блокерами при оновленнях.
• XFS став типовою файловою системою для великих обсягів через продуктивність і консистентність; ext4 усе ще прийнятний, але дефолти мають значення.
• Kickstart і PXE інсталяції стали зрілим способом будувати флот, бо «клік-опс» не масштабується і не проходить аудит.

Одна перефразована ідея зі світу надійності, яку варто приклеїти на монітор: paraphrased idea — «Сподівання — не стратегія», приписують Gen. Gordon R. Sullivan. В опсах «ми пригадуємо кроки інсталяції» — це сподівання з додатковими кроками.

Жарт #1: Якщо ваша єдина резервна копія — «ми можемо перевстановити», вітаю — ви винайшли аварійне відновлення методом інтуїції.

Рішення, що важливі перед натисканням «Begin Installation»

1) UEFI + Secure Boot: вирішуйте свідомо

UEFI має бути вашим дефолтом, хіба що ви застрягли на застарілому апаратному забезпеченні. Щодо Secure Boot — будьте чесні: чи потрібен він вам через відповідність політикам, чи тому, що ви дійсно керуєте цілісністю ланцюга завантаження? Якщо увімкнете його, доведеться тримати історію kernel/module нудною — без випадкових неподписаних драйверів потім.

Оперативна порада: обирайте Secure Boot, якщо ваша платформа може стабільно його підтримувати. Змішані флоти, де деякі вузли з Secure Boot, а деякі — без, схильні породжувати «працює на моїй машині» відмови.

2) Розкладка сховища: ви насправді проєктуєте домени відмов

Ваш вибір розділів під час інсталяції визначає, що заповниться першим, що можна зробити знімком, і що блокує оновлення. Класична продукційна відмова — це / або /var, що доходить до 100% опівночі через логи, шари контейнерів або якийсь runaway spool.

Позиція: розділяйте /var, якщо система буде запускати бази даних, контейнери, CI-ранери або будь-що говірке. Викладайте /var/log окремо лише коли маєте реальну причину й відповідний моніторинг. Інакше ви створите другий режим відмов: «/var/log повний і тому нічого не логиться».

3) Вибір файлової системи: оберіть нудного переможця

XFS — відмінний дефолт для серверних томів. Ext4 також підходить, особливо для невеликих boot/root розділів. Якщо ви хочете ZFS, ви обираєте іншу модель життєвого циклу і інструментарій; це може бути чудово, але не прикидайте, що це «просто як XFS».

4) Синхронізація часу та DNS: не імпровізуйте

Час і DNS — це дві служби, які всі вважають налаштованими — аж до моменту, коли Kerberos падає, TLS сертифікати виглядають «ще не дійсні», або ваш пакетний менеджер не може вирішити репозиторії. Забезпечте, щоб NTP/chrony та налаштування резолвера були частиною пост-інсталяційної бази.

5) Ідентифікація та доступ: локальні користувачі смердять

В підприємствах локальні адміністратори накопичуються як пил. Використовуйте централізовану автентифікацію (SSSD/LDAP/Kerberos) там, де це доречно, і зберігайте break-glass локальний акаунт з контрольованим доступом. Якщо у вас менше середовище — робіть простіше: принаймні вимагаючи SSH-ключі, вимикайте парольну авторизацію та логайте все.

6) Шлях оновлення: плануйте зараз, не пізніше

«Чіткий шлях оновлення» — це наполовину політика, наполовину архітектура:

• Політика: поступові розгортання, зафіксовані репозиторії та вікна змін, що включають час на відкат.
• Архітектура: управління конфігурацією, ідемпотентні скрипти bootstrap та відокремлення даних від ОС там, де можливо.

Якщо стан вашого додатку живе всередині /usr/local з ручними правками та загадковими бінарниками, жоден дистрибутив вам не допоможе. AlmaLinux не виправить ваше ставлення до ентропії.

Шляхи інсталяції: ISO, Kickstart та golden images

Інтерактивна інсталяція з ISO (добре для першого вузла, погано для флоту)

Використовуйте інтерактивний інсталятор, щоб перевірити сумісність апаратури, припущення щодо сховища і іменування NIC. Потім зупиніться. Не будуйте десять серверів, натискаючи ті самі екрани десять разів і покладаючись на пам’ять.

Kickstart (дорослий варіант)

Kickstart дає вам версіонований і підлягаючий ревізії процес інсталяції. Це означає:

• Аудитоване розбивання на розділи та вибір пакетів.
• Передбачуване іменування мережі та базові служби.
• Шлях до PXE provisioning і zero-touch відновлень.

Коли настане неминуче «потрібно терміново перебудувати вузол 14», Kickstart перетворює паніку на рутину.

Golden images (використовуйте обережно)

Golden images хороші для хмар і гіпервізорів, але вони можуть закласти проблеми: застарілі machine IDs, дубльовані SSH host keys і дивні артефакти udev/мережі. Якщо йдете цим шляхом, потрібен перший-boot ініціалізаційний крок, що скидає ідентичність і правильно перев’язує секрети.

Макети сховища, що витримують аудити та збої

Базовий макет для серверів загального призначення (рекомендовано)

Для типової VM або bare-metal сервера, що запускає кілька сервісів:

• /boot (ext4): малий, стабільний.
• /boot/efi (vfat): UEFI system partition.
• / (XFS): ОС та бінарники.
• /var (XFS): логи, кеші, spool-и, контейнери.
• /home опційно (XFS): якщо люди справді заходять у систему (намагайтеся не давати).

LVM поверх RAID (апаратного або mdadm) дає вам гнучкість: розширювати файлові системи, додавати LV для /var/lib/containers або виділяти місце під дані додатків без перевстановлення.

Хости для контейнерів (не прикидайте, що це «просто сервери»)

Якщо хост запускає Podman/Docker або компоненти Kubernetes, плануйте ампліфікацію записів у сховище. Дайте /var додатковий запас або винесіть /var/lib/containers в окремий LV. Якщо цього не зробите, runtime контейнерів рано чи пізно з’їсть вашу ОС.

Хости баз даних (відокремлюйте ОС від даних)

Для баз даних розділяйте ОС і дані агресивно. Розміщуйте дані БД на окремих томах із чіткими mount-опціями, окремими чергами вводу/виводу по можливості, і моніторингом. Тримайте / та /var чистими, щоб оновлення ОС та логи не конкурували з основним навантаженням.

Шифрування: LUKS — це політичне рішення

Шифрування диска — чудово, поки вам не треба перезавантажити віддалений сервер о 2:00 ночі. Обирайте LUKS лише коли маєте план для віддаленого розблокування, консолі та операційних рукописів. «Ми введемо пароль при перезавантаженні» — не план, якщо сервер за 800 миль.

Практичні завдання: команди, виводи та рішення, які вони підказують

Ось перевірки, які я виконую після інсталяції AlmaLinux 10. Кожна відповідає на питання, що важливі під час оновлення або інциденту.

Завдання 1: Перевірити реліз ОС і рядок ядра

cr0x@server:~$ cat /etc/os-release
NAME="AlmaLinux"
VERSION="10.0 (Purple Lion)"
ID="almalinux"
ID_LIKE="rhel fedora"
VERSION_ID="10.0"
PLATFORM_ID="platform:el10"
PRETTY_NAME="AlmaLinux 10.0 (Purple Lion)"

Що це означає: Підтверджує, що ви на очікуваній мажорній версії та платформному ID.

Рішення: Якщо тут не вказано el10, зупиніться та виправте образ/вибір репо. Не «оновлюйте пізніше».

Завдання 2: Підтвердити режим завантаження UEFI (або BIOS)

cr0x@server:~$ test -d /sys/firmware/efi && echo UEFI || echo BIOS
UEFI

Що це означає: UEFI активний, якщо цей каталог існує.

Рішення: Якщо чекали UEFI, а отримали BIOS, виправляйте зараз. Змішані режими завантаження ускладнюють стандартизацію, Secure Boot і процедури відновлення.

Завдання 3: Перевірити стан Secure Boot

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Що це означає: Secure Boot увімкнено.

Рішення: Якщо увімкнено, вважайте сторонні модулі ядра та out-of-tree драйвери контрольованими змінами. Якщо вимкнено, але потрібно політикою — виправляйте до введення в продакшен.

Завдання 4: Інспектувати диски та макет файлових систем

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
sda       476G disk
├─sda1    600M part vfat   /boot/efi
├─sda2      1G part ext4   /boot
└─sda3  474.4G part LVM2_member
  ├─almalv-root  60G lvm   xfs    /
  ├─almalv-var  120G lvm   xfs    /var
  └─almalv-home  20G lvm   xfs    /home

Що це означає: Підтверджує наявність UEFI розділу, окремого /boot і LVM-розкладку.

Рішення: Якщо /var малий на хості сервісу, виправте зараз (змінити розміри LV) до того, як логи/контейнери його заповнять і перетворять наступне оновлення на заручництво.

Завдання 5: Перевірити, що fstab адекватний (без несподіваних мережевих монтів)

cr0x@server:~$ cat /etc/fstab
UUID=3E2A-1C0B  /boot/efi  vfat  umask=0077,shortname=winnt  0  2
UUID=7b3e6dd4-0f3e-4a4c-9b0d-5a5f0a8a5f17  /boot  ext4  defaults  1  2
/dev/mapper/almalv-root  /     xfs   defaults  0  0
/dev/mapper/almalv-var   /var  xfs   defaults  0  0

Що це означає: Критичні для завантаження точки монтування локальні і прості.

Рішення: Якщо бачите NFS/CIFS монтування без nofail і правильних timeout-ів, ви запрошуєте зависання при завантаженні після першої мережевої хиби.

Завдання 6: Перевірити іменування NIC та стан лінку (важлива передбачуваність)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
ens192           UP             00:50:56:aa:bb:cc

Що це означає: Ім’я інтерфейсу та стан. UP означає, що лінк активний.

Рішення: Якщо імена відрізняються на ідентичному апаратному забезпеченні/VM-шаблонах, виправте provisioning або udev правила. «Який NIC — продакшен?» — не весела гра під час інциденту.

Завдання 7: Підтвердити IP, маршрут і DNS через NetworkManager

cr0x@server:~$ nmcli -g GENERAL.DEVICE,GENERAL.STATE,IP4.ADDRESS,IP4.GATEWAY,IP4.DNS device show ens192
ens192:100 (connected)
10.20.30.40/24
10.20.30.1
10.20.30.10

Що це означає: Пристрій підключений, має IP, gateway і DNS.

Рішення: Якщо DNS неправильний, виправте його до того, як почнете дебажити «dnf ламається». Зазвичай проблеми через DNS.

Завдання 8: Перевірити синхронізацію часу (TLS та auth залежать від неї)

cr0x@server:~$ timedatectl
               Local time: Tue 2026-02-05 13:18:19 UTC
           Universal time: Tue 2026-02-05 13:18:19 UTC
                 RTC time: Tue 2026-02-05 13:18:19
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Що це означає: Годинник синхронізований і NTP активний.

Рішення: Якщо System clock synchronized — no, виправте chrony до того, як торкнетесь сертифікатів, Kerberos або розподілених систем.

Завдання 9: Перевірити режим SELinux та недавні відмови

cr0x@server:~$ getenforce
Enforcing

cr0x@server:~$ ausearch -m avc -ts recent | tail -n 5
----
time->Tue Feb  5 13:10:41 2026
type=AVC msg=audit(1738761041.223:412): avc:  denied  { name_connect } for  pid=1240 comm="nginx" dest=5432 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:postgresql_port_t:s0 tclass=tcp_socket permissive=0

Що це означає: SELinux у режимі enforcing; AVC denial показує, що nginx намагався підключитися до порту Postgres.

Рішення: Не вимикайте SELinux. Визначте, чи має сервіс мати доступ до того порту, і застосуйте правильний boolean/маркування. Якщо підключення легітимне — виправляйте політику; якщо ні — виправляйте архітектуру.

Завдання 10: Підтвердити стан firewall та відкриті сервіси

cr0x@server:~$ systemctl is-active firewalld
active

cr0x@server:~$ firewall-cmd --list-all
public (active)
  target: default
  interfaces: ens192
  services: ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Що це означає: Firewall увімкнено; у публічній зоні відкритий лише сервіс SSH.

Рішення: Якщо хост експозить випадкові порти — закрийте їх зараз. Якщо додатку потрібні порти, відкривайте їх явно і документуйте як код.

Завдання 11: Перевірити конфігурацію репозиторіїв і метадані оновлень

cr0x@server:~$ dnf repolist
repo id                              repo name
almalinux-baseos                     AlmaLinux 10 - BaseOS
almalinux-appstream                  AlmaLinux 10 - AppStream
almalinux-crb                        AlmaLinux 10 - CRB

cr0x@server:~$ dnf -q check-update || true
kernel.x86_64  6.11.0-12.el10  almalinux-baseos
openssl.x86_64 3.2.2-4.el10    almalinux-baseos

Що це означає: Репозиторії увімкнені; доступні оновлення.

Рішення: Якщо репо відсутні або з’явились небажані сторонні репозиторії — зупиніться. Безпека оновлень починається з гігієни репозиторіїв.

Завдання 12: Інспектувати увімкнені сервіси (щоб не здивуватись при боті)

cr0x@server:~$ systemctl list-unit-files --type=service --state=enabled | head -n 15
UNIT FILE                          STATE   PRESET
chronyd.service                     enabled enabled
firewalld.service                   enabled enabled
sshd.service                        enabled enabled
tuned.service                       enabled enabled
NetworkManager.service              enabled enabled

Що це означає: Базові сервіси увімкнені; ви бачите, що стартуватиме при завантаженні.

Рішення: Вимикайте те, що не потрібно. Кожен увімкнений демон — це і вектор атаки, і майбутня взаємодія при оновленні.

Завдання 13: Підтвердити політику жорсткості SSH

cr0x@server:~$ sshd -T | egrep 'passwordauthentication|permitrootlogin|pubkeyauthentication'
passwordauthentication no
permitrootlogin no
pubkeyauthentication yes

Що це означає: Парольна автентифікація та root-логін вимкнені; ключі ввімкнені.

Рішення: Якщо парольна автентифікація дозволена на хостах, що доступні з інтернету, виправте це до того, як станете частиною ботнету.

Завдання 14: Перевірити індикатори здоров’я диска (NVMe/SATA)

cr0x@server:~$ smartctl -H /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.11.0-12.el10] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Що це означає: Пристрій повідомляє про стан PASSED (не ідеально, але початок є).

Рішення: Якщо SMART падає або недоступний, вирішіть, чи потрібні вендорні інструменти, перевірки RAID-контролера або проактивна заміна. Не чекайте на театральний «read-only filesystem».

Завдання 15: Підтвердити persistent journald і очікування обсягу логів

cr0x@server:~$ grep -E '^(Storage|SystemMaxUse|RuntimeMaxUse)=' /etc/systemd/journald.conf
Storage=persistent
SystemMaxUse=1G
RuntimeMaxUse=200M

Що це означає: Логи зберігаються після перезавантаження з лімітами.

Рішення: Якщо journald без обмежень на малих дисках — обмежте його. Якщо потрібне тривале зберігання — відправляйте логи за межі хоста; не збирайте їх локально як сувеніри.

Завдання 16: Виміряти продуктивність завантаження і знайти повільні юніти

cr0x@server:~$ systemd-analyze
Startup finished in 3.212s (kernel) + 9.844s (userspace) = 13.056s
graphical.target reached after 9.801s in userspace

cr0x@server:~$ systemd-analyze blame | head
4.812s NetworkManager-wait-online.service
1.905s firewalld.service
1.102s chronyd.service

Що це означає: Вказує сервіси, що уповільнюють завантаження, часто «wait-online».

Рішення: Якщо NetworkManager-wait-online домінує і вам він не потрібен — вимкніть. Швидше завантаження = швидше відновлення та патчинг.

Завдання 17: Перевірити CPU/пам’ять та навантаження (базова лінія для порівнянь)

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\):|Thread|Core|Socket'
CPU(s):                               4
Model name:                           Intel(R) Xeon(R) CPU
Thread(s) per core:                   2
Core(s) per socket:                   2
Socket(s):                            1

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       0.9Gi       5.9Gi       0.0Gi       0.9Gi       6.6Gi
Swap:          4.0Gi         0B       4.0Gi

Що це означає: Встановлює, яким є «нормально» на свіжій інсталяції.

Рішення: Якщо пам’ять уже напружена на новому хості, не розгортайте пам’ятенависні навантаження і не дивуйтеся потім.

Завдання 18: Перевірити планувальник I/O та опції монтування файлових систем (продуктивність і затримки)

cr0x@server:~$ cat /sys/block/sda/queue/scheduler
[mq-deadline] kyber bfq none

cr0x@server:~$ findmnt -no TARGET,FSTYPE,OPTIONS / /var
/ xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota
/var xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota

Що це означає: Показує планувальник і опції монтування, що впливають на затримки і пропускну здатність.

Рішення: Не «тюніть» опції монтування випадково. Спочатку зафіксуйте базову лінію; змінюйте одне; вимірюйте; відкатуйте, якщо стало гірше.

План швидкої діагностики (знайти вузьке місце за хвилини)

Це послідовність «я на виклику і щось повільно працює». Мета — визначити, чи ви залежите від CPU, пам’яті, I/O, мережі, або заблоковані через залежність (DNS, auth, бекенд сховища).

Перший крок: підтвердити, що симптом реальний і локальний

• Чи повільний додаток для всіх або лише з одного сегмента мережі?
• Чи повільний хост для всіх команд або лише для додатка?
• Чи щось змінилося (деплой, патч, конфіг) за останню годину?

Другий крок: перевірити насичення ресурсів простими інструментами

cr0x@server:~$ uptime
 13:22:11 up 10 days,  3:41,  1 user,  load average: 6.12, 5.98, 5.44

Інтерпретація: Load average вище кількості CPU вказує на конкуренцію за CPU або ріст черги готовності (може також спричиняти блокований I/O).

Рішення: Якщо load високий, негайно перевірте використання CPU проти iowait та чергу виконання.

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 5  1      0 412112  90124 982112    0    0   120   450  580  900 25 10 45 20  0
 6  2      0 401980  90124 982400    0    0   110   980  600  950 22 11 42 25  0

Інтерпретація: r — процеси в черзі, b — заблоковані, wa — iowait. Тут iowait значущий і є заблоковані процеси.

Рішення: Розглядайте як ймовірний вузол у сховищі. Перейдіть до перевірки затримок диска перед тим, як тюнити потоки додатка.

Третій крок: відрізнити затримку диска від повної файлової системи чи тиску пам’яті

cr0x@server:~$ df -hT / /var
Filesystem            Type  Size  Used Avail Use% Mounted on
/dev/mapper/almalv-root xfs    60G   18G   42G  31% /
/dev/mapper/almalv-var  xfs   120G  118G  2.0G  99% /var

Інтерпретація: /var фактично повний. Це може спричиняти повільні записи, падіння сервісів і дивну поведінку пакетного менеджера.

Рішення: Зупиніть кровотечу: прокрутіть логи, почистіть кеші або розширте LV. Не «перезапускайте все» і не сподівайтесь на диво.

cr0x@server:~$ dmesg -T | tail -n 8
[Tue Feb  5 13:18:02 2026] XFS (dm-1): log I/O error -5
[Tue Feb  5 13:18:02 2026] XFS (dm-1): Filesystem has been shut down due to log error (0x2).

Інтерпретація: Якщо бачите відключення файлової системи — проблема не в додатку. Це сховище або низькорівневі помилки пристрою.

Рішення: Ескалюйте до служби сховища/апаратури негайно. Захистіть дані. Перемонтуйте у режим read-only за потреби і плануйте контрольоване відновлення.

Четвертий крок: перевірити мережу та DNS (бо це завжди підозрюваний)

cr0x@server:~$ resolvectl status | sed -n '1,25p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.30.10
       DNS Servers: 10.20.30.10 10.20.30.11

Інтерпретація: Підтверджує конфігурацію резолвера і активний DNS-сервер.

Рішення: Якщо DNS-сервери неправильні або недоступні — виправте DNS до того, як звинувачувати DNF, SSSD або додаток.

П’ятий крок: перевірити здоров’я сервісів і логи з наміром

cr0x@server:~$ systemctl --failed
  UNIT          LOAD   ACTIVE SUB    DESCRIPTION
● app.service    loaded failed failed Example Application

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state.
SUB    = The low-level unit activation state.

Інтерпретація: Failed unit — явний сигнал; не гадуйте.

Рішення: Перейдіть до journalctl -u app.service -b, знайдіть корінь, виправте і перезапустіть. Не перезавантажуйте як діагностику, якщо любите зникати докази.

Три міні-історії з корпоративного світу (бо хтось уже зробив вашу помилку)

Міні-історія 1: Інцидент через неправильне припущення

Одна фінансова компанія перемістила флот внутрішніх сервісів на «RHEL-совісний Linux», щоб уніфікувати патчинг. Новий образ на базі AlmaLinux швидко збудували, швидко затвердили і швидко відправили. Критичне припущення: «Дефолтні налаштування інсталятора підходять; це enterprise-дистрибутив».

Він підходив для тихої VM. Він не підходив для навантаженого API-вузла, що пише логи, тримає кеш пакетів і запускає runtime контейнерів. За кілька тижнів /var заповнився під час пікового трафіку. Додаток почав видавати таймаути, а саппорт ганявся за фантомними проблемами з мережею, бо CPU і мережа виглядали нормально. Тим часом journald почав скидати повідомлення через нестачу місця, і найкорисніші логи зникли саме тоді, коли всі їх хотіли бачити.

Постмортем був незручним, бо ніхто не «зробив щось неправильно» у звичному розумінні. ОС встановлено. Сервіс стартував. Моніторинг був. Справжня помилка — припущення, що дефолтна розкладка відповідає навантаженню.

Виправлення не було героїчним: перебудувати вузли з окремим, більшим /var, застосувати обмеження journald і відправляти логи з хоста. Також додали pre-production soak-тест, що навмисно генерує обсяг логів і churn шарів контейнерів. Коли /var пережив тиждень синтетичного навантаження, образу знову довіряли.

Міні-історія 2: Оптимізація, що обернулась проти

Інша організація мала latency-sensitive сервіс і інженера, який боявся контекстних перемикань. Він «оптимізував», вимкнувши кілька дефолтних сервісів і підсиливши kernel/sysctl за порадою з блогу. Він також вимкнув tuned, бо «він змінює речі», і зафіксував CPU governor у конфіг-сніпеті.

У синтетичних тестах це дало кращий результат. Потім прийшло справжнє вікно технічного обслуговування. Після оновлення і перезавантаження час завантаження різко виріс і сервіс відкривався непослідовно по вузлах. Деякі вузли чекали мережу; інші стартували рано, отримували timeout DNS і падали. Один вузол був в нормі. Флот — ні. Налаштування відрізнились, бо golden image оновлювали на місці, а різні команди «чиннили» вузли вручну.

Страшне було не в тому, що оптимізація дала приріст. Страшне в тому, що вона зробила систему непроспокійно відтворюваною. Під час відновлення вони не могли сказати, які зміни є на якому вузлі. Реакція на інцидент перетворилась на археологію.

Заміна була прозаїчною: відкотити невідомі sysctl, знову увімкнути базові сервіси і впровадити тюнінг через версіоновані профілі з вимірюваннями як воротами. Вони досі тюнінгували, але лише з планом roll-forward/roll-back і з конфіг-менеджментом, що забезпечує ідентичність.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Рітейл-організація запускала AlmaLinux на edge-системах, які інколи втрачали мережеве з’єднання. Нічого особливого: кілька локальних сервісів, черга і періодичний синх. Їхня платформа наполягала на двох речах, які ніхто не любив: строгий базовий чек-лист і рутинні вправи з перебудови через Kickstart.

Одного дня прошивка контролера сховища почала давати інтермітентні I/O помилки. Кілька вузлів перейшли в read-only. Команда додатку хотіла «просто перезапустити» і продовжити продавати. Але платформа мала відпрацьований рутини: зібрати логи, вивести вузол з ротації, перебудувати на перевіреному обладнанні і відновити сервіс з черги.

Оскільки інсталяція ОС була відтворювана, вони не витрачали час на роздуми про стан коробки. Оскільки розділи були консистентні, їхні скрипти збору логів працювали. Оскільки SELinux був enforcing скрізь, не було «на вузлі A працює, а на вузлі B — ні» через відмінності в безпекових настройках. Аутедж було локалізовано, а не святковано.

Того дня ніхто не отримав кредиту за геніальність. Компанія отримала кредит за те, що залишилась відкритою. Оце і є вся робота.

Жарт #2: Єдина річ більш постійна за тимчасове виправлення — це тикет з написом «remove later».

Типові помилки: симптом → корінь проблеми → виправлення

1) DNF повільний або падає з таймаутами

Симптом: dnf makecache зависає або завантаження метаданих репо таймаутиться.

Корінь проблеми: Неправильний DNS, проксі або проблеми з MTU/шляхом. Рідше: поламаний вибір дзеркала.

Виправлення: Підтвердьте резолвер і маршрутизацію (nmcli, resolvectl), протестуйте розв’язування імен, перевірте налаштування проксі в /etc/dnf/dnf.conf та в оточенні. Якщо у VLAN дивний MTU — тестуйте ping -M do і підлаштуйте.

2) Система не завантажується після увімкнення Secure Boot

Симптом: Завантаження падає після встановлення сторонніх драйверів або кастомних модулів ядра.

Корінь проблеми: Непідписані модулі блокуються політикою Secure Boot.

Виправлення: Використовуйте підписані, підтримувані вендором драйвери; зареєструйте ключі, якщо дійсно керуєте власним підписуванням; або відключіть Secure Boot, лише якщо політика дозволяє. Не поєднуйте «жорсткий ланцюг завантаження» з «випадковими DKMS модулями».

3) Сервіси загадково падають після інсталяції

Симптом: Сервіс стартує на одному вузлі, на іншому падає з «permission denied», навіть для root.

Корінь проблеми: SELinux denials, неправильні контексти файлів або некоректні контексти після ручного копіювання файлів.

Виправлення: Інспектуйте AVC denials, відновіть контексти (restorecon), встановіть правильні мітки файлів і використовуйте booleans де потрібно. Вимикання SELinux — не виправлення; це капітуляція.

4) Завантаження триває вічно, особливо на мережевих хостах

Симптом: Довге завантаження; systemd-analyze blame показує wait-online.

Корінь проблеми: NetworkManager-wait-online чекає на мережу в середовищах, де це не потрібно або де DHCP ненадійний.

Виправлення: Вимкніть wait-online, якщо робоче навантаження не потребує його на старті, або виправте залежність мережі. Не маскуйте мережеві проблеми нескінченними очікуваннями.

5) Диск заповнюється під час нормальної роботи

Симптом: /var доходить до 100%, сервіси крашаться, логи припиняються, DNF ламається.

Корінь проблеми: Недостатній розмір /var, необмежені логи, ріст шарів контейнерів, runaway spool-папки.

Виправлення: Змініть розміри LV, обмежте journald, налаштуйте logrotate, відокремте сховище контейнерів і ставте алерти на використання простору та inode.

6) Після оновлення додаток не може забіндитись на порт або встановити з’єднання зовні

Симптом: Permission denied при bind/connect хоча конфіг додатку правильний.

Корінь проблеми: SELinux маркування портів або firewall правила не відповідають додатку.

Виправлення: Перевірте зони/порти/сервіси у firewalld, підтвердіть SELinux port types і застосуйте прицільні виправлення. Уникайте широких «відкрийте все» правил, що стають постійними ризиками.

7) Ключі хостів або ідентичність машини дублюються в клонованих VM

Симптом: Попередження SSH про зміну хост-ключа; моніторинг показує кілька вузлів з тим самим ID.

Корінь проблеми: Golden image клонували без регенерації machine-id і SSH host keys.

Виправлення: Використовуйте cloud-init або first-boot скрипти для скидання ідентичності, регенерації ключів і забезпечте унікальні hostnames та DHCP-резерви за потреби.

Чек-листи / покроковий план

Покроково: корпоративна інсталяція AlmaLinux 10 (один сервер)

1. Вирішіть режим завантаження: використовуйте UEFI, хіба що є задокументована причина інакше. Виріште політику Secure Boot наперед.
2. Вирішіть розкладку сховища: плануйте окремий /var для хостів сервісів. Використовуйте LVM для гнучкості. Обирайте XFS для більшості навантажень.
3. Встановіть hostname і мережу: налаштуйте статичний IP де потрібно; переконайтесь у правильності DNS і NTP.
4. Мінімальні пакети: встановлюйте лише необхідне. Менше пакетів — менше CVE і менше конфліктів при оновленнях.
5. Створіть доступ адміністратора: використовуйте SSH-ключі. Вимкніть root-login по SSH. Створіть audit-ований break-glass шлях.
6. Залишайте SELinux у режимі enforcing: вирішуйте проблеми політик правильно, а не вимикайте його.
7. Увімкніть firewall: відкривайте лише потрібні порти явно.
8. Оновіть одразу: пропатчуйте до поточного мінорного стану перед введенням у продакшен.
9. Зафіксуйте базову лінію: збережіть виводи ключових команд (repolist, розкладка монтувань, увімкнені сервіси, синхронізація часу).
10. Підключіть моніторинг: мінімум — простір/іноди, CPU, пам’ять, load і стан сервісів.
11. Документуйте план оновлення: який у вас відкат? Snapshot? Rebuild? Де зберігаються дані?
12. Протестуйте перезавантаження: перевірте boot, мережу, сервіси і готовність додатку після рестарту.

Чек-лист: що означає «чіткий шлях оновлення» на практиці

• Відтворювана збірка: Kickstart або pipeline образів. Ніяких ручних сніжинок.
• Управління конфігом: Ansible/Salt/Puppet/тощо. Навіть для малого — щось має бути.
• Контроль репо: лише відомі репозиторії; сторонні переглянуті й зафіксовані.
• Відокремлення даних: дані додатку не змішані з файлами ОС. Резервне копіювання і відновлення протестовані.
• Репетиції оновлень: тестуйте на представницькому staging-вузлі з реальними патернами трафіку, де можливо.
• Історія відкату: VM snapshot, LVM snapshot (обережно) або rebuild + restore. Оберіть і практикуйте.
• Обсервабельність: логи відсилаються зовні, метрики зберігаються, дашборди відомі людям, яких будуть пейджити.

Чек-лист: післяінсталяційне зміцнення, що не зламає ваше майбутнє «я»

• Вимкнути парольний доступ по SSH; вимагати ключі.
• Вимкнути прямий root SSH-доступ; використовувати sudo.
• Встановити ліміти journald; перевірити logrotate де потрібно.
• Увімкнути і налаштувати firewalld з правильними зонами.
• Підтвердити роботу chrony/NTP; використовувати UTC, якщо немає сильної причини інакше.
• Тримати SELinux в режимі enforcing; трактувати відмови як сигнали, не як прикру неприємність.
• Видалити невживані пакети/сервіси; чим менше — тим краще.

FAQ

1) Чи варто обирати AlmaLinux 10 для нових production-систем?

Якщо ви хочете конвенції Enterprise Linux і стабільну екосистему — так. Операційний виграш приходить від сумісності та передбачуваності, а не від нововведень.

2) Чи справді «minimal install» кращий?

Зазвичай так. Менше пакетів зменшує поверхню атак і потенційні конфлікти при оновленнях. Встановлюйте мінімум, а решту додавайте через конфіг-менеджмент.

3) Яка найкраща файлова система для серверів AlmaLinux 10?

XFS — безпечний дефолт для більшості серверних файлових систем. Ext4 підходить для /boot і невеликих root-розділів. Обирайте ZFS тільки якщо готові до її операційної моделі.

4) Чи потрібен LVM?

Якщо ви експлуатуєте реальні системи: так, здебільшого. LVM дозволяє змінювати розміри і виправляти розкладку без перевстановлення. Без нього ви ставите на карту, що ніколи не помилитесь з дисковим плануванням.

5) Чи потрібно відокремлювати /var?

Для хостів сервісів — так. Особливо при роботі з контейнерами, CI, інтенсивним логуванням або кешуванням пакетів. Ізольований /var запобігає тому, щоб один шумний процес вбив ОС.

6) Чи варто включати Secure Boot?

Варто, коли ви можете послідовно його підтримувати і середовище дбає про цілісність завантаження. Якщо ви регулярно використовуєте out-of-tree модулі, Secure Boot може стати вашим регулярним податком на обслуговування.

7) Як забезпечити чистий шлях мажорного оновлення?

Полегшіть перебудови. Контролюйте репо. Тримайте конфіг декларативним. Відокремлюйте дані. Тоді оновлення стануть плановими подіями, а не ритуалом відчаю.

8) SELinux блокує мій додаток. Яке правильне рішення?

Знайдіть відмову, вирішіть, чи доступ легітимний, і застосуйте прицільні зміни (booleans, коректні контексти, дозволені порти). Вимикання SELinux лікує симптом шляхом видалення огорожі.

9) Що перевіряти спочатку, коли «сервер повільний»?

uptime і vmstat. Ви повинні знати, чи ви CPU-bound, I/O-bound або під тиском пам’яті до того, як торкатися додатку.

10) Чи можна покладатися на golden images замість Kickstart?

Можна, але тільки якщо маєте first-boot процес, що скидає ідентичність, і дисципліну у pipeline образів. Інакше тиражуватимете в масштабі вчорашні помилки.

Висновок: практичні подальші кроки

Якщо хочете, щоб AlmaLinux 10 відчувався «корпоративним», встановлюйте його так, ніби збираєтесь із ним жити. Більшість болю приходить від непланованого росту: логи, контейнери, кеші і людські правки, що ніколи не потрапляють в автоматизацію.

Зробіть наступне:

1. Оберіть розкладку сховища з реальною стратегією для /var і запишіть її.
2. Вирішіть політику UEFI + Secure Boot на рівні флоту, а не хосту.
3. Перетворіть ваш найкращий інтерактивний інсталяційний сценарій у Kickstart і перебудуйте один вузол з нуля, щоб довести працездатність.
4. Зафіксуйте базову лінію командами вище і зберігайте її з конфігом системи.
5. Проведіть одну імітацію відмови: заповніть /var у staging, подивіться, що ламається, і виправте до продакшену.

Коли прийдуть оновлення, вам все одно доведеться працювати. Але це буде робота, яка завершується вчасно, а не та, що закінчується постмортемом і новою повагою до місця для дискового простору.