Встановлення RHEL 10: корпоративний чекліст налаштування, який пригодився б раніше

Короткі факти та контекст (чому інсталяції RHEL виглядають саме так)

• Anaconda — інсталятор RHEL, існує з кінця 1990-х. Його завдання нудне, але важливе: бути передбачуваним на поганому залізі.
• Kickstart — автоматизація не розкіш; це те, як підприємства перетворили «унікальні сервери» на однотипні машини задовго до того, як хмара стала модною.
• systemd став дефолтом у RHEL 7. Саме тому сервіси, логи й діагностика завантаження тепер живуть в єдиному скриптовному середовищі.
• XFS став файловою системою за замовчуванням у RHEL 7 з вагомих причин: масштабування, зрілість і адекватна продуктивність при великих деревах директорій.
• SELinux присутній у RHEL десятиліттями. Багато зломів не відбувається тому, що SELinux — магія, а через те, що його складно тихо обійти.
• UEFI витіснив BIOS як сучасний стандарт завантаження; помилки завантаження дедалі частіше виглядають як «змінні EFI» і «стан Secure Boot», а не як чаклунство MBR.
• chrony замінив старі демони NTP, бо сучасним мережам потрібна швидша збіжність і краща робота з ноутбуками/VM, які підвішуються або дрейфують.
• LUKS2 — сучасний формат шифрування дисків у Linux. Це не лише для ноутбуків; це для дата-центрів, де втрачені диски — кошмар відповідності.
• cgroups v2 (сучасна модель контролю ресурсів Linux) змінює поведінку лімітів CPU/пам’яті; це важливо, якщо ви запускаєте контейнери або суворі квоти.

Жоден із цих фактів не є дрібницею. Вони пояснюють, чому «просто пройти інсталятор» — пастка. RHEL розраховано на повторювані операції в масштабі.
Якщо ви не встановлюєте систему так, як збираєтеся експлуатувати її, ви підписуєтеся на майбутній інцидентний звіт.

Рішення, які потрібно прийняти до запуску інсталятора

1) Що ви будуєте: «пет»-сервер, вузол флоту чи регульована система?

Якщо це вузол флоту, вам потрібна автоматизація (Kickstart), стандартизоване сховище й передбачувана мережа. Якщо це регульована система, потрібне шифрування, налаштування аудиту й паперова слідовість.
Якщо це одноразовий «утилітарний ящик», — гаразд, але не прикидайтеся, що він ніколи не стане продакшном.

2) Прошивка й режим завантаження: UEFI чи legacy?

Вибирайте UEFI, якщо немає суворих обмежень сумісності. Legacy BIOS все ще можливо, але підтримка постачальника й майбутні оновлення дедалі частіше припускають UEFI. Також: політика Secure Boot має бути усвідомленим рішенням, а не сюрпризом.

3) Розкладка диска: LVM, звичайні розділи чи особлива схема?

Для корпоративних інсталяцій RHEL здоровий вибір за замовчуванням — GPT + UEFI + LVM на XFS, з опціональним LUKS.
LVM дає операційну гнучкість: змінювати розміри, додавати томи, відокремлювати шляхи з великим навантаженням запису.

Уникайте героїчних схем розділення, що «оптимізують продуктивність» вручну, якщо ви не можете захистити їх під час аварії.
Той, хто буде підтримувати систему пізніше, не пригадає, навіщо /var отримав 12.7 GiB.

4) Шифрування: чи потрібне воно й чи зможете ви розблоковувати масово?

Шифрування диска — просто. Шифрування диска з безнаглядним завантаженням, віддаленим персоналом і зламаним ескрою ключів — ні.
Якщо ви вмикаєте LUKS, вирішіть механізм розблокування: локальна фраза-пароль (ручна), мережеве прив’язане шифрування або метод, сумісний з вашою оркестрацією.

5) Ідентичність у мережі: імена хостів, DNS, NTP і план IP

Обирайте імена хостів, що відображають функцію й середовище. Вирішіть, чи будете використовувати DHCP, статичні IP чи резервації DHCP. Визначте DNS-сервери й пошукові домени.
Вирішіть джерела часу NTP і чи потрібні внутрішні сервери часу.

6) Стратегія оновлень: «останнє», зафіксовано чи поетапно?

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

7) Аутентифікація: локальні користувачі, LDAP/IdM чи SSO?

Якщо плануєте централізовану ідентифікацію (це часто), заплануйте її зараз. Це змінює sudo-політики, доступ по SSH, очікування по аудиту й процес реагування на інциденти.

Жарт №1: Встановлювати RHEL, не вирішивши наперед питання зі сховищем і ідентичністю — як купити сейф, а ключ сховати під килимком.

Чеклісти / покроковий план (перед, під час, після)

Чекліст перед інсталяцією (зробіть це до запуску Anaconda)

• Підтвердіть характеристики апаратури/VM: CPU, RAM, модель диска, тип контролера та мережеві картки. Отримайте фактичні імена пристроїв, які будете бачити в Linux.
• Підтвердіть налаштування прошивки: увімкнений UEFI, режим RAID проти HBA/JBOD, політика Secure Boot, розширення віртуалізації за потреби.
• Виберіть розкладку сховища: розділи, LVM, точки монтування, типи файлових систем і план шифрування.
• Визначте мережеві налаштування: VLAN, MTU, bonding/teaming, статичні маршрути, DNS і джерела часу.
• Вирішіть пост-інсталяційні репозиторії й метод оновлення (і чи зможе машина дістатися до них під час інсталяції).
• Підготуйте автоматизацію: Kickstart-файл або принаймні письмовий аркуш збірки, якого ви точно дотримуєтеся.
• Задокументуйте базові дані: передбачуване ім’я хоста, IP, серійний/інвентарний тег, власник, середовище й призначення.

Чекліст інсталятора (вибори, які вдарять пізніше)

• Переконайтеся, що інсталюєте в потрібному режимі завантаження (UEFI проти legacy) до розмітки диска.
• Встановіть правильний часовий пояс і увімкніть синхронізацію часу (або принаймні заплануйте це після інсталяції).
• Обирайте мінімальні набори пакетів; додавайте потрібне свідомо.
• Не вимикайте SELinux, щоб «запустити». Виправте політику або мітки.
• Встановіть політику паролів для root і створіть адміністративного користувача з sudo. Віддавайте перевагу доступу по ключах SSH.
• Переконайтеся, що вибрані правильні цільові диски. Потроїно перевіряйте на серверах з кількома дисками.

Чекліст після інсталяції (перший запуск — де починається справжня інсталяція)

• Оновіть до вашого базового рівня патчів (поетапно, контрольовано).
• Захистіть SSH: ключі, дозволені користувачі/групи, відключіть аутентифікацію паролем там, де можливо.
• Підтвердіть, що SELinux в режимі enforcing; виправте неправильні мітки від образу/скриптів.
• Налаштуйте зони firewall і явні дозволи сервісів.
• Налаштуйте персистентне логування і відправку логів на віддалені системи, якщо потрібно.
• Перевірте сховище: опції файлової системи, правильність fstab, стан LVM і очікування планувальника вводу-виводу.
• Перевірте синхронізацію часу і розв’язування імен. Несправний DNS буде маскуватися під «випадкове уповільнення».
• Зніміть базові показники продуктивності: CPU steal (VM), затримки вводу-виводу та пропускну здатність мережі. Зафіксуйте початкові метрики.
• Зареєструйте в управлінській площині (Satellite, внутрішні репи, конфіг-менеджмент) і позначте збірку як відтворювану.

Практичні завдання (команди, виводи, що означають, що вирішити)

Це перевірки «walk the box», які я очікую виконати на новій системі RHEL 10 перед тим, як довірити їй щось з пейджем.
Кожне завдання включає: команду, приклад виводу, що це означає та яке рішення прийняти.

Завдання 1: Підтвердити версію ОС і походження інсталяції

cr0x@server:~$ cat /etc/redhat-release
Red Hat Enterprise Linux release 10.0 (Plow)

Що це означає: Ви на очікуваному мажорному/мінорному релізі (не на старому «золотому» образі, який хтось «перевикористав»).

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

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

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

Що це означає: Система завантажилася в режимі UEFI. Це впливає на розмітку, конфігурацію GRUB і деякі процедури відновлення.

Рішення: Якщо очікували UEFI, а отримали Legacy — перевстановіть зараз. Змішані парки ускладнюють операції.

Завдання 3: Оглянути блокові пристрої й визначити реальний диск завантаження

cr0x@server:~$ lsblk -o NAME,MODEL,SIZE,TYPE,FSTYPE,MOUNTPOINTS
NAME        MODEL          SIZE TYPE FSTYPE      MOUNTPOINTS
sda         PERC H755      1.8T  disk
├─sda1                    600M  part vfat        /boot/efi
├─sda2                      1G  part xfs         /boot
└─sda3                    1.8T  part LVM2_member
  ├─rhel-root               80G lvm  xfs         /
  ├─rhel-var                50G lvm  xfs         /var
  ├─rhel-tmp                 8G lvm  xfs         /tmp
  └─rhel-home               10G lvm  xfs         /home

Що це означає: Ви бачите EFI System Partition, окремий /boot і LVM PV із логічними томами.

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

Завдання 4: Перевірити типи файлових систем і опції (налаштування продуктивності й безпеки)

cr0x@server:~$ findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS / /var /tmp /home
/ /dev/mapper/rhel-root xfs rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k
/var /dev/mapper/rhel-var xfs rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k
/tmp /dev/mapper/rhel-tmp xfs rw,nosuid,nodev,noexec,relatime,seclabel
/home /dev/mapper/rhel-home xfs rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k

Що це означає: /tmp загартований (nosuid,nodev,noexec). Вжито XFS. Доступні SELinux-мітки.

Рішення: Тримайте /tmp загартованим, якщо лише ваш інструментарій збірки дійсно не потребує виконуваних файлів у /tmp — тоді виправляйте інструментарій, а не послаблюйте ОС.

Завдання 5: Підтвердити стан LVM і вільне місце для зростання

cr0x@server:~$ vgs
  VG   #PV #LV #SN Attr   VSize  VFree
  rhel   1   4   0 wz--n-  1.79t  1.64t

Що це означає: У VG багато вільного місця. Добре: ви можете розширити /var або додати томи для додатків без звернення до «театру» Команди Сховищ.

Рішення: Якщо VFree мізерний, ви або занадто велико розподілили томи, або забули про майбутній ріст. Виправте це зараз, до появи даних.

Завдання 6: Підтвердити стан шифрування (LUKS) там, де потрібно

cr0x@server:~$ lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINTS
sda      disk
├─sda1   part vfat        /boot/efi
├─sda2   part xfs         /boot
└─sda3   part crypto_LUKS
  └─luks-2b3c...  crypt LVM2_member
    └─rhel-root   lvm   xfs         /

Що це означає: Кореневий PV знаходиться в контейнері LUKS. Це реальне шифрування «at-rest», а не «ми замкнули двері дата-центру».

Рішення: Перевірте, що у вас є працездатний процес розблокування (локальна консоль, віддалений KVM або метод, затверджений підприємством). Якщо ні — ви створили майбутній простій.

Завдання 7: Перевірити ядро, параметри завантаження й стан microcode

cr0x@server:~$ uname -r
6.12.0-xx.el10.x86_64

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.12.0-xx.el10.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto rhgb quiet

Що це означає: Ви на відомій гілці ядра; cmdline показує, що crashkernel увімкнено (корисно для kdump).

Рішення: Якщо у вас затримкочутливі навантаження, подумайте, чи варто тримати «quiet/rhgb» на серверах (я зазвичай їх прибираю, щоб зробити логи завантаження видимими).

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

cr0x@server:~$ getenforce
Enforcing

Що це означає: SELinux виконує свою роботу: в режимі enforcing, а не лише логування.

Рішення: Якщо в режимі Permissive/Disabled — виправте це до розміщення додатків. Інакше ваша «політика безпеки» залишається на папері, а не в контролі.

Завдання 9: Перевірити стан файрволу та що реально відкрито

cr0x@server:~$ sudo firewall-cmd --state
running

cr0x@server:~$ sudo firewall-cmd --get-active-zones
public
  interfaces: ens192

cr0x@server:~$ sudo firewall-cmd --zone=public --list-services
ssh

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

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

Завдання 10: Перевірити DNS і поведінку резолвера (швидкі помилки краще за повільні загадки)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
 resolv.conf mode: stub
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53 10.20.0.54
        DNS Domain: corp.example

Що це означає: systemd-resolved керує DNS; у вас два резолвери; вказано пошуковий домен.

Рішення: Якщо потрібен DNSSEC або split DNS, заплануйте це зараз. Якщо резолвери недоступні, виправляйте до того, як звинуватите «мережу».

Завдання 11: Підтвердити синхронізацію часу (на неї залежать аутентифікація та розподілені системи)

cr0x@server:~$ chronyc tracking
Reference ID    : 0A140035 (10.20.0.53)
Stratum         : 3
Ref time (UTC)  : Mon Feb 05 12:10:28 2026
System time     : 0.000123456 seconds fast of NTP time
Last offset     : -0.000045678 seconds
RMS offset      : 0.000210000 seconds
Frequency       : 12.345 ppm fast
Leap status     : Normal

Що це означає: Chrony синхронізовано, невелике зміщення, стабільний стратум. Це запобігає помилкам TLS, дивній поведінці Kerberos і проблемам кореляції логів.

Рішення: Якщо Leap status не Normal або зміщення великі — виправте доступність NTP або правила файрволу. Не ігноруйте дрейф часу.

Завдання 12: Підтвердити персистентність journald (логи, що переживають перезавантаження)

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

cr0x@server:~$ journalctl --disk-usage
Archived and active journals take up 312.0M in the file system.

Що це означає: Логи зберігаються після перезавантаження й мають ліміт. Ви зберігаєте докази без ризику, що логи з’їдять кореневу файлову систему.

Рішення: Якщо Storage встановлено як volatile — змініть це. Якщо SystemMaxUse не обмежений — встановіть ліміт і відправляйте логи поза хост, якщо потрібне зберігання.

Завдання 13: Перевірити базові ресурси системи (тиск пам’яті, адекватність swap)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi       1.2Gi        28Gi       120Mi       1.8Gi        29Gi
Swap:          8.0Gi          0B       8.0Gi

Що це означає: Достатньо вільних ресурсів; swap є й наразі не використовується.

Рішення: Для багатьох серверних навантажень дещо swap все ще корисне як підстраховка. Уникайте політик «swapoff скрізь», якщо ви не розумієте режим відмови.

Завдання 14: Перевірити IO-стек і виявити очевидні затримки до приходу додатків

cr0x@server:~$ iostat -xz 1 3
Linux 6.12.0-xx.el10.x86_64 (server)  02/05/2026  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          1.20    0.00    0.55    0.10    0.00   98.15

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
dm-0             0.20    1.50     8.0    64.0      64.0     0.01    2.10    1.90    2.13   0.25   0.04

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

Рішення: Якщо await різко зростає до десятків/сотень мс під невеликим навантаженням — зупиніться і дослідіть контролер сховища, multipath або продуктивність підлеглого SAN.

Завдання 15: Підтвердити канали оновлень і те, що справді буде патчитися

cr0x@server:~$ sudo dnf repolist
repo id                              repo name
rhel-10-baseos                       RHEL 10 BaseOS (Staged)
rhel-10-appstream                    RHEL 10 AppStream (Staged)
rhel-10-extras                       RHEL 10 Extras (Staged)

Що це означає: Репозиторії налаштовані й ймовірно вказують на ваші поетапні mirror/знімки.

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

Завдання 16: Підтвердити, що kdump налаштовано (ви не цінуватимете це, доки не знадобиться)

cr0x@server:~$ systemctl is-enabled kdump
enabled

cr0x@server:~$ sudo kdumpctl status
Kdump is operational

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

Рішення: На критичних системах зберігайте kdump. На маленьких VMs можете його відключити, щоб повернути RAM — задокументуйте це рішення.

Сховище й файлові системи: розкладки, що витримують реальне життя

Розкладка за замовчуванням, якій я довіряю (і чому)

На серверах загального призначення я рекомендую:
/ (root) достатньо для ОС і інструментів, /var окремо для логів і змінного стану,
/tmp окремо і загартоване, а також опціональні виділені томи для баз даних або черг.
Використовуйте XFS, якщо немає конкретно валідації іншого вибору.

Операційна мета — не елегантність, а контроль радіусу ураження. Коли додаток починає безконтрольно писати логи, /var заповнюється — а не /.
Коли процес збірки зловживає /tmp, він не зможе випадково створити виконувану зону.

Розмітка й LVM: обирайте гнучкість, а не пророцтво

Люди роблять забагато розділів, бо хочуть уникнути заповнення диска. Це благородно, але часто призводить до інцидентів із заповненням.
Правильний підхід — відокремлені ризикові точки монтування плюс вільне місце в LVM для контрольованого зростання.

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

UEFI-розділи завантаження: тримайте їх простими

Для UEFI потрібен EFI System Partition (vfat), змонтований в /boot/efi. Тримайте стандартний розмір (декілька сотень МБ).
Тримайте /boot окремим (XFS підходить), якщо використовуєте LUKS для кореня — бо бутстреп шифрованого кореня потребує ясності.

Шифрування: зробіть його реальним і керованим

Шифрування даних «at-rest» часто є політичною вимогою. Пастка — побудувати систему, яка не зможе завантажитися без нагляду після технічного обслуговування,
бо хтось поклав фразу-пароль у таблицю і потім її поміняв.

Якщо ви використовуєте LUKS, вирішіть:

• Де зберігаються ключі й хто може їх отримати під час інциденту.
• Що станеться, коли хост перемістять, замінять або відновлять з бекапу.
• Чи існує віддалений консольний доступ під час завантаження (для ручного розблокування).

Swap: нудно, немодно, але корисно

Swap — це не функція продуктивності. Це форма керування режимом відмови. Невеликий swap може утримати систему в робочому стані достатньо довго, щоб повідомити вас, відправити логи і коректно відновитися, замість того, щоб випадково вбивати процеси.

Опції монтування: безпека й поведінка, а не фольклор

Використовуйте nodev,nosuid,noexec там, де має сенс (наприклад, /tmp). Використовуйте noatime тільки якщо розумієте побічні ефекти; relatime зазвичай підходить і є стандартом.
Уникайте налаштувань заради інтернетного «культу» оптимізацій.

Базовий рівень безпеки: SELinux, firewall, крипто і реалії SSH

SELinux: enforcing — це база, а не прагнення

SELinux звинувачують у проблемах, які він лише виявляє. Коли додаток намагається писати не в ту директорію або прив’язати неправильний порт, SELinux каже «ні», і ви дізнаєтеся про проблему раніше. Це — фіча.

Якщо потрібно налагодити — використовуйте цільові інструменти: перевіряйте логи аудиту, підтверджуйте контексти й застосовуйте мінімальні політики.
«Вимкнути SELinux» — це адміністративний аналог «зняти пожежну сигналізацію, бо гуде».

Firewall: за замовчуванням відмовляти, відкривати навмисно

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

SSH: ключі, суворий доступ і без таємничих користувачів

Використовуйте авторизацію по ключах для адміністративного доступу, де можливо. Забороніть вхід root по SSH. Обмежте, хто може підключатися (AllowUsers або AllowGroups).
Для «break-glass» використовуйте аудитуємий шлях і задокументуйте його.

Криптополітики: не воюйте з платформою

RHEL має системне управління криптополітиками. Це добре: воно робить налаштування TLS консистентними в усіх клієнтах OpenSSL.
Не дозволяйте випадковим скриптам ослаблювати політику, щоб «старий клієнт підключився».
Виправте клієнта або ізолюйте застарілу систему до її заміни.

Парафраз ідеї Вернера Фогельса: «Ти побудував — ти експлуатуєш» — надійність зростає, коли творці несуть відповідальність за експлуатаційні наслідки.

Логування та спостережуваність: зберігайте докази

Персистентний journald — обов’язковий для продакшн-дебагу

Якщо journald volatile, логи зникають після перезавантаження — саме після оновлень ядра, відключень живлення або «ми поміняли одну дрібницю».
Підтримуйте журнал персистентним, встановіть ліміт дискового використання й відправляйте важливі логи поза хоста, якщо політика або інцидент-репорт вимагають збереження.

Ізоляція обсягу логів: /var як бар’єр безладу

Відокремлення /var — класична нудна практика, бо вона працює. Там містяться кеші пакетів, логи, черги й стан.
Коли /var заповнюється, ОС часто залишається працювати достатньо довго, щоб ви могли виправити ситуацію. Коли / заповнений — всі події стають цікавими.

Базові метрики: робіть знімок у здоровому стані

Найкращий час зібрати базові показники продуктивності — одразу після інсталяції, до зміни навантаження.
Зафіксуйте: CPU idle/steal, затримки IO, пропускну здатність мережі і тиск пам’яті. Коли коли-небудь скажуть «повільно», у вас буде еталон.

Жарт №2: Логи як резервні копії — всі полюблять їх, коли усвідомлять, що в них їх немає.

Мережа: DNS, час, MTU, bonding і «чому повільно»

DNS: корінь половини ваших «періодичних» інцидентів

Неправильно налаштовані резолвери викликають повільний запуск додатків, випадкові таймаути API і заплутані фейловери.
Перевірте пряме і зворотне розв’язування там, де потрібно. Знайте, чи використовується systemd-resolved і як він інтегрується з вашими інструментами.

Синхронізація часу: невидима залежність

Дрейф часу ламає TLS, аутентифікацію, розподілену трасування і кореляцію логів між системами.
Chrony має бути налаштований і перевірений. Не задовольняйтеся «мабуть, усе гаразд».

MTU і VLAN: класична пастка для продуктивності

Jumbo-кадри можуть допомогти в деяких середовищах, але також створюють «чорні дири» втрати пакетів, якщо шлях не підтримує їх end-to-end.
Якщо встановлюєте MTU 9000 — перевірте це по всьому шляху: комутатори, гіпервізори і NIC. Інакше отримаєте дивні часткові збої.

Bonding/teaming: відмовостійкість потребує тестування

Не святкуйте перемогу, бо обидва лінки «UP». Протестуйте failover. Відключіть кабель (або віртуальну NIC) і перевірте, чи зберігається зв’язок.
Також підтвердіть, що конфігурація на боці комутатора відповідає режиму bonding.

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

Коли щойно встановлений хост RHEL 10 «повільний», не починайте з перевстановлення. Почніть із ізоляції домену вузького місця:
CPU, пам’ять, диск, мережа або конфіг/ідентичність. Ця послідовність швидко знаходить 80% проблем.

Перший крок: чи система фундаментально здорова?

• Перевірте помилки завантаження: journalctl -b -p err
• Перевірте базове навантаження: uptime, top або htop
• Перевірте заповнення диска: df -h, df -i

Другий крок: чи це CPU/планування VM?

• Шукайте CPU steal (VM): mpstat -P ALL 1 5 (steal %)
• Перевірте тротлінг: systemd-cgtop для тиску cgroup

Третій крок: чи це затримка IO?

• Виміряйте: iostat -xz 1 5 (await, %util)
• Знайдіть винуватців: pidstat -d 1, iotop якщо доступний
• Перевірте multipath/SAN: multipath -ll (якщо використовується)

Четвертий крок: чи це мережа (або DNS, що маскується під мережу)?

• Затримка DNS: resolvectl query your-service і перевірте час
• Втрата пакетів: ping -c 20 gateway
• Пропускна здатність: ss -s (стан сокетів), ip -s link (drop/error)

П’ятий крок: чи це політика/конфігурація?

• SELinux denials: ausearch -m avc -ts recent
• Блокування файрволом: firewall-cmd --list-all плюс логи сервісів
• Дрейф часу/TLS: chronyc tracking, помилки сертифікатів у логах додатків

Фішка — дисципліна. Не гоняйтеся за п’ятьма гіпотезами одночасно. Оберіть домен, доведіть його винуватим або невинним, потім переходьте далі.

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

1) Симптом: випадкові таймаути до внутрішніх сервісів

Корінь проблеми: Неправильна конфігурація DNS-резолвера, відсутність пошукового домену або плутанина зі stub режимом systemd-resolved.

Виправлення: Перевірте resolvectl status, переконайтеся, що резолвери доступні, встановіть правильний домен/пошук і протестуйте запити явно.

2) Симптом: перезавантаження після оновлень і система більше не завантажується

Корінь проблеми: Неправильний режим завантаження (встановлено Legacy замість очікуваного UEFI) або EFI-розділ не створено/не змонтовано правильно.

Виправлення: Підтвердьте UEFI через /sys/firmware/efi. Якщо режим не той — перевстановіть у потрібному режимі. Якщо відсутній EFI-розділ — відновіть завантажувач з rescue media.

3) Симптом: логи зникають після перезавантаження

Корінь проблеми: journald налаштовано як volatile (за замовчуванням у деяких мінімальних збірках) або /var/log не персистентний в конвеєрі образів.

Виправлення: Встановіть Storage=persistent у journald.conf, створіть /var/log/journal і обмежте використання через SystemMaxUse.

4) Симптом: «Диск заповнений» і це виводить весь хост із ладу

Корінь проблеми: Єдиний кореневий файловий простір; /var і / однакові; злива логів заповнює /. Іноді закінчуються іноди.

Виправлення: Відокремте /var; моніторьте df -i; налаштуйте logrotate; відправляйте логи поза хост.

5) Симптом: додаток не може прив’язатися до порту або записати в директорію

Корінь проблеми: SELinux забороняє через неправильний контекст або відсутню boolean-налаштування; або файрвол блокує вхідні з’єднання.

Виправлення: Перевірте AVC-відмови через ausearch, виправте контексти за допомогою restorecon, встановіть потрібні boolean і відкрийте порти файрвола цілеспрямовано.

6) Симптом: мережа «up», але великі передачі гальмують або нестабільні

Корінь проблеми: MTU не співпадає (jumbo кадри не підтримуються повністю) або неправильна конфігурація bonding.

Виправлення: Перевірте MTU по шляху; тестуйте ping з DF-бітом; переконайтеся, що конфігурація switch відповідає режиму bonding; перевірте failover.

7) Симптом: продуктивність жахлива тільки на VM

Корінь проблеми: CPU steal через overcommit, конкуренція за сховище на спільних datastore або відсутність оптимізацій virtio.

Виправлення: Виміряйте steal через mpstat, перевірте затримки IO через iostat, координуйтеся з командою віртуалізації щодо розміщення ресурсів і рівнів зберігання.

8) Симптом: хост не може аутентифікуватися до корпоративних сервісів

Корінь проблеми: Дрейф часу, неправильне ім’я хоста або відсутність зворотного DNS, очікувана в Kerberos-подібних середовищах.

Виправлення: Спочатку виправте синхронізацію часу; переконайтеся, що ім’я хоста/FQDN правильні; перевірте пряме/зворотне DNS; потім повторіть спробу приєднання.

Три корпоративні міні-історії (що реально йде не так)

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

Команда розгорнула пул нових jump-хостів на RHEL 10 для доступу в продакшн. Вони зробили «звичні речі»: пропатчили, загартували SSH, увімкнули firewalld.
Доступ начебто працював під час легкого тестування. Але коли on-call почали використовувати хости під час реального інциденту, почалися проблеми.

Сесії зависали на 20–40 секунд, коли інженери запускали команди, які звертаються до внутрішніх імен хостів. Потім усе «наздоганяло».
Першою думкою була мережа. Другою — поламаний bastion-інструмент. Третьою — «DNS у RHEL 10 дивний».

Корінь був болісно простий: інсталяція припускала, що корпоративний пошуковий домен забеспечується DHCP усюди. В тому середовищі — ні.
Більшість імен не були кваліфіковані в скриптах і шель-практиках. Тому кожен запит пробував неправильні суфікси, потрапляв у таймаут, а потім нарешті знаходився.

Виправлення було так само просте: явно налаштували пошуковий домен і список резолверів, перевірили через resolvectl і додали базову перевірку затримки DNS у пайплайн збірки.
Урок не в «DHCP поганий». Урок у тому, що припущення — це конфігурація, яку ви забули задокументувати.

Міні-історія 2: Оптимізація, яка вдарила у відповідь

Інфраструктурна група хотіла прискорити збірки для CI-runner-ів на RHEL 10. Хтось запропонував вимкнути персистентний journald, бо «записи на диск повільні» і «нам не потрібні логи на епемерних раннерах». Це подали як оптимізацію продуктивності і економію місця. Пропозицію прийняли.

Через два тижні підмножина раннерів почала періодично падати. Збої були непостійні — інколи падали інсталяції пакетів, інколи проваливався мережевий fetch, інколи тести тайм-аутували. Єдина постійна річ — перезавантаження раннера іноді «фіксило» все на деякий час.

Виявилося справжнє підґрунтя: взаємодія драйвера NIC з прошивкою на певній партії заліза викликала періодичні link-flap-і.
Journald показав би хронологію подій: down/up лінка, оновлення DHCP і перезапуски сервісів. Але journald був volatile і машини перезавантажувалися під час автоматичної ремедіації. Отже докази випарувалися.

Вони повернули персистентний journald з жорстким дисковим лімітом, додали відправку критичних подій на віддалений накопичувач, і час на відладку скоротився з днів до годин.
«Оптимізація» не дала значної економії IO. Вона дала ілюзію економії в обмін на втрачену спостережуваність — зазвичай найдорожчу річ.

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

Кластер додатку поруч з фінансами працював на RHEL з суворими вимогами аудиту. Стандарт збірки був майже смішно консервативний:
окремий /var, наявний swap, kdump увімкнено, SELinux в enforcing, мінімальний firewall, journald персистентний з лімітами і стандартизована LVM-розкладка з великим вільним VG.
Ніхто цього не полюбляв. Всі це терпіли.

Під час напруженого кварталу сторонній компонент відійшов від норми і почав писати детальні дебаг-логи до /var/log у високому темпі після невеликої зміни конфігурації.
Через кілька годин /var досяг 100% використання. На багатьох системах це означає повний вихід хоста з ладу і довгу ніч.

Тут хост залишився в роботі. Кореневий файловий простір мав місце. SSH працював. systemd працював. Моніторинг працював.
Інженер on-call увійшов, підтвердив, що /var заповнений, провів ротацію і усік частини логів, перезапустив компонент з виправленою конфігурацією.

Постмортем не був гучним. Стандарт збірки не отримав оплесків. Але він запобіг збою, який міг би спричинити каскад пропущених пакетних завдань і затриманих звітів.
Нудна практика — відокремлення /var і лімітування логів — зробила саме те, що має робити нудна практика: зменшила масштаб катастроф.

Питання та відповіді

1) Чи варто використовувати GUI-інсталяцію або мінімальну інсталяцію для серверів RHEL 10?

Мінімальну, якщо немає вагомої причини. Менше пакетів — менше CVE, менше руху патчів і менше дивних залежностей.
Завжди можна додати інструменти пізніше; видалення GUI-стеку рідко варто зусиль.

2) Чи завжди XFS — правильна файлова система?

Для більшості корпоративних серверних випадків — так. XFS добре масштабується і передбачувано поводиться під навантаженням. Якщо вам потрібна конкретна функція (наприклад, патерни з малими файлами або певні снапшоти),
обґрунтуйте вибір тестами і планом підтримки, а не суб’єктивними міркуваннями.

3) Чи справді потрібен окремий /var?

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

4) Чи шифрувати кореневі диски на серверах?

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

5) Чи можна вимкнути SELinux заради швидшого розгортання?

Можна, але не варто. Вимкнення SELinux зазвичай ховає помилки конфігурації до кращого моменту, коли їх наслідки будуть більшими.
Використовуйте permissive режим коротко для діагностики при потребі, а потім поверніть enforcing з правильними мітками/політикою.

6) Який базовий рівень захисту SSH без руйнування автоматизації?

Використовуйте авторизацію по ключах, забороніть вхід root, обмежте дозволених користувачів/групи. Залиште «break-glass» шлях, але зробіть його аудитуємим.
Якщо автоматизація потребує доступу — використовуйте виділені сервісні акаунти з обмеженими sudo-правами, а не спільні ключі.

7) Як поводитися з оновленнями на щойно встановлених системах?

Узгодьте їх із вашими поетапними репозиторіями й вікнами патчів. Не дозволяйте свіжим інсталяціям тягнути випадкові найновіші пакети звідусіль.
Стандартизуйтесь на відомому базовому образі, а потім рухайтеся вперед контрольованими хвилями.

8) Що перш за все перевірити, коли «мережа повільна»?

DNS і MTU. Перевірте затримки резолверів і конфігурацію, потім перевірте помилки/дропи на інтерфейсах.
Далі — перевірка path MTU, якщо великі передачі падають. Багато скарг на «повільну мережу» — це затримки розв’язування імен.

9) Чи потрібен kdump на всіх серверах?

На критичних системах — так. На маленьких VM з обмеженою пам’яттю — можливо ні.
Зробіть це усвідомленим рішенням: або зберігайте kdump для діагностики, або вимкніть його і прийміть меншу видимість падінь.

Наступні кроки, які можна зробити сьогодні

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

1. Запишіть ваш базовий стандарт: режим завантаження, розкладку сховища, позицію щодо шифрування, DNS/NTP, політику SELinux/firewall і стратегію оновлень.
2. Перетворіть це в автоматизацію: Kickstart плюс пост-інсталяційний конфіг-менеджмент. Якщо ви не можете його відтворити, ви ним не володієте.
3. Запустіть розділ завдань як gating чекліст: розглядайте невдачі як провал тесту, а не як «поправимо після go-live».
4. Додайте швидкий план діагностики до документації on-call: найкращий час навчити дебагу — до інциденту, а не під час нього.

Продакшн — це не місце, де ви доводите, що вмієте клікати інсталятор. Це місце, де ви доводите ваші дефолти. Зробіть їх хорошими.