Встановлення Rocky Linux 10: сумісний з RHEL без клопоту з підпискою

Що ви фактично будуєте (і що ні)

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

Але давайте про умову честі:

• Ви отримуєте сумісний з RHEL userland і поведінку ядра, знайомий стек пакетування (dnf/rpm) та корпоративні значення за замовчуванням.
• Ви не отримуєте контрактів підтримки від вендора за замовчуванням, пропрієтарних інтеграцій управління або репозиторіїв за підпискою.
• Вам обов’язково потрібно виконати власну базову валідацію: режим завантаження, схема дисків, оновлення, синхронізація часу, журнали та безпековий стан.

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

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

Цікаві факти та історичний контекст

Це не факти для вікторини. Вони допомагають пояснити, чому Rocky існує і чому він поводиться так, як поводиться.

1. Реклами RHEL повторюються. Екосистема давно мала відтворення корпоративного Linux, щоб отримати сумісність з RHEL без ліцензійних перешкод.
2. CentOS колись був дефолтним «безкоштовним RHEL-подібним». Протягом років багато організацій стандартизувалися на CentOS для серверних флотів, бо він близько відтворював RHEL.
3. CentOS Stream змінив очікування. Коли Stream став фокусом, він змістився з «downstream rebuild» до оновлюваного попереднього перегляду того, що може потрапити в RHEL.
4. Rocky Linux виник як відповідь на ту зміну. Велика частина галузі знову потребувала стабільної платформи, сумісної downstream.
5. «Контракт корпоративного Linux» — стільки ж соціальний, скільки технічний. Стабільність означає мало сюрпризів: ABI-очікування, ритм ядра та консервативні значення за замовчуванням.
6. dnf замінив yum не випадково. Розв’язування залежностей, модульність та підвищення продуктивності — не косметичні зміни; вони вирішували багаторічні проблеми у патчінгу флотів.
7. SELinux не є опцією в серйозних середовищах. Одна з головних причин, чому «RHEL-подібні» системи можна розгортати в масштабі, не перетворюючи кожен сервіс на унікальний випадок.
8. systemd стандартизував поведінку сервісів між дистрибутивами. Хтось любить, хтось ні, але воно зробило нагляд за сервісами, логування та управління залежностями більш послідовними.
9. UEFI + GPT тепер — стандартна реальність. Якщо ви досі проєктуєте під BIOS+MBR повсюдно, ви будуєте часові бомби для сучасних серверних платформ.

Передінсталяційні рішення, що запобігають простоям

1) Вирішіть: UEFI чи старий BIOS (і не змішуйте підходи)

Якщо обладнання хоч трохи сучасне — використовуйте UEFI. Це не про моду; це про узгоджене керування завантаженням,
кращу підтримку GPT і менше загадок «чому завантажувач зник після оновлення прошивки».

Змішування режимів завантаження інсталяційних носіїв (інсталяція в legacy BIOS на одному хості, UEFI на іншому) створює операційну дрейфність.
Дрейф породжує плутанину, а плутанина народжує тікети о 03:00.

2) Вирішіть: схема зберігання за доменом відмов, а не за звичкою

Ваш план зберігання повинен відповідати двом питанням:

• Що виходить з ладу? Диск, контролер, вузол, стійка, том у хмарі, людина.
• Що ламається при відмові? Завантаження, кореневий файловий простір, журнали, база даних, образи контейнерів.

Прості поради, що працюють у production:

• Надійність завантаження: Тримайте /boot просто. Якщо ви робите RAID, переконайтеся, що ваш завантажувач це підтримує чисто.
• Операційний контроль: Виносьте /var на окремий логічний том, якщо сервер інтенсивно логуватиме або запускатиме контейнери. Шторм журналів не має заповнювати root.
• Запобіжні засоби: Якщо ви не можете дозволити простою, використовуйте відмовостійкість (апаратний RAID або mdraid) для системних дисків; не вдавайте, що знімки в хмарі — це RAID.
• Продуктивність: Відокремлюйте «гарячі» шляхи запису (бази даних, додатки з інтенсивним журналюванням) від усього іншого. Якщо не можете — хоча б моніторте I/O і плануйте потужність.

3) Вирішіть: LVM чи «звичайні розділи»

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

4) Вирішіть: вибір файлової системи (XFS vs ext4) з наміром

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

5) Вирішіть: план мережі (статична, DHCP reservation чи динаміка)

Сервери, що надають production сервіси, повинні мати передбачувані адреси. Це може бути статична конфігурація або DHCP reservation,
але «він отримає якусь IP» — це не план.

6) Вирішіть: як будете патчити (і як відкатитесь)

Патчінг — це не одна подія; це пайплайн. Вирішіть зараз:

• Чи оновлюєте ви автоматично (dnf-automatic), чи батчами з погодженням?
• Яка ваша політика оновлень ядра?
• Чи знімаєте знімки VM дисків перед патчем? Чи є у вас протестований метод відкату?

Жарт №1 (короткий, в тему): Ставтеся до патчування як до чищення зубів — усі погоджуються, що треба, але більшість інцидентів трапляються через «почну завтра».

Покрокова інструкція: UEFI, сховище та розумні налаштування

Крок 0: перевірте інсталяційний носій і режим завантаження

Перед тим як натискати «Install», підтвердьте, що ви завантажилися так, як плануєте (UEFI чи legacy). На багатьох серверах у меню завантаження
будуть дві записи для одного й того ж USB ISO — оберіть UEFI, якщо немає причин інакше.

Крок 1: оберіть мінімальний набір пакетів, якщо не потрібен GUI

Для серверів обирайте мінімальну інсталяцію. Кожен зайвий пакет — це:
ще одне оновлення,
ще одна потенційна вразливість,
ще один «чому цей сервіс слухає на порту, про який ми не знали» момент.

Крок 2: час, локаль і клавіатура (тихі шкідливі моменти)

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

Крок 3: розмітка диска, яка вас не переслідуватиме

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

• UEFI System Partition (ESP), невеликий
• /boot, невеликий
• LVM PV для решти
• Логічні томи для /, /var і swap (розмір swap залежить від навантаження; не робіть «за звичкою»)

Якщо інсталюєте на фізичних серверах з двома системними дисками, є два звичні підходи:

• Апаратний RAID1 для системних дисків: найпростіше в експлуатації; контролер стає залежністю.
• Програмний RAID1 (mdraid): прозорий і переносний між контролерами; треба бути уважним з розташуванням завантажувача/UEFI.

Крок 4: мережа і hostname

Встановіть реальний hostname. Якщо ваша політика найменування — путанина, виправляйте політику, а не імена вузлів після розгортання.
Імена хостів з’являються в логах, моніторингу, сертифікатах і в головах людей.

Крок 5: користувачі та SSH

Створіть не-root адміністратора. Дозвольте SSH за ключами. Вимкніть SSH з паролем, якщо немає конкретної потреби, і навіть тоді обмежте його мережею та MFA, якщо можливо.

Крок 6: SELinux має бути Enforcing

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

Крок 7: валідація після першого завантаження

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

Після встановлення: оновлення, репозиторії, базова безпека та гігієна сервісів

Репозиторії: тримайте все нудним і свідомим

Корпоративний Linux живе і помирає дисципліною репозиторіїв. Потрібно:
відомий набір репозиторіїв,
консистентні пакети по хостах,
і передбачувана поведінка оновлень.

Не вмикайте випадкові сторонні репозиторії на production-серверах лише тому, що блог про це сказав. Якщо потрібні додаткові пакети, прийміть свідоме
рішення: дзеркальте їх, фіксуйте версії і тестуйте оновлення в staging-середовищі, що нагадує production.

Оновлення: патчуйте рано, потім регулярно

Першою реальною дією після інсталяції має бути оновлення, а потім перезавантаження, якщо змінився ядро або критичні бібліотеки.
Це встановлює базову лінію і уникає міфу «воно працювало з дня інсталяції».

Базова безпека: SSH, firewalld і політика SELinux

Налаштуйте SSH на ключі, забороніть вхід root, тримайте firewalld увімкненим і використовуйте SELinux як шар безпеки,
що обмежує радіус ураження.

Логування: зберігайте логи, але не тонуйте в них

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

Цитата (перефразована ідея)

Перефразована ідея: все коли-небудь ламається; стійкість приходить від проєктування під відмову, а не від надії, що її не буде.
— Вернер Вогельс (лідерство, орієнтоване на надійність, перефразовано)

Практичні завдання: команди, сенс виводу та рішення (12+)

Це перевірки, які я фактично виконую після інсталяції системи, сумісної з RHEL. Кожна закінчується рішенням,
бо команди без рішень — це просто перформанс-арт.

Завдання 1: Підтвердити версію ОС і ідентифікацію платформи

cr0x@server:~$ cat /etc/os-release
NAME="Rocky Linux"
VERSION="10.0 (Green Obsidian)"
ID="rocky"
ID_LIKE="rhel fedora"
VERSION_ID="10.0"
PLATFORM_ID="platform:el10"
PRETTY_NAME="Rocky Linux 10.0 (Green Obsidian)"
ANSI_COLOR="0;32"
LOGO="rocky"

Що це означає: Ви на Rocky 10, і система оголошує сумісність з сімейством RHEL.

Рішення: Якщо PLATFORM_ID не EL10 — зупиніться і підтвердьте, що ви не інсталювали невірний ISO або небажаний дериват.

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

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

Що це означає: Наявність директорії EFI вказує на UEFI-завантаження.

Рішення: Якщо ви чекали UEFI, а отримали BIOS — перевстановіть правильно зараз. «Виправлю пізніше» дорого обходиться.

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

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
sda        200G disk
├─sda1     600M part vfat   /boot/efi
├─sda2       1G part xfs    /boot
└─sda3   198.4G part LVM2_member
  ├─rl-root   40G lvm  xfs  /
  ├─rl-var    80G lvm  xfs  /var
  └─rl-swap    8G lvm  swap [SWAP]

Що це означає: У вас чиста схема UEFI + /boot + LVM, і /var ізольовано.

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

Завдання 4: Перевірити використання файлових систем і пастку «/var, що заповнив root»

cr0x@server:~$ df -hT
Filesystem           Type   Size  Used Avail Use% Mounted on
/dev/mapper/rl-root  xfs     40G  2.3G   38G   6% /
/dev/mapper/rl-var   xfs     80G  5.1G   75G   7% /var
/dev/sda2            xfs    960M  220M  740M  23% /boot
/dev/sda1            vfat   599M  6.2M  593M   2% /boot/efi

Що це означає: Достатньо вільного місця на важливих точках монтування.

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

Завдання 5: Підтвердити коректність fstab (завантаження важливіше за естетику)

cr0x@server:~$ cat /etc/fstab
UUID=2f6c4d9b-4c1e-4ed6-a57b-3e1e6e2a9b0a /                       xfs     defaults        0 0
UUID=fa1b70d8-5b0c-4b98-8e12-7c0d8f8195a2 /var                    xfs     defaults        0 0
UUID=8d8a7d9f-9b02-4d5e-9f21-3d65d7f6e4bc /boot                   xfs     defaults        0 0
UUID=0A1B-2C3D                            /boot/efi               vfat    umask=0077,shortname=winnt 0 2
/dev/mapper/rl-swap                       none                    swap    defaults        0 0

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

Рішення: Якщо ви бачите шляхи пристроїв на кшталт /dev/sda3 для критичних точок монтування на фізичних серверах — перейдіть на UUID негайно.

Завдання 6: Перевірити стан репозиторіїв і уникнути «таємничих пакетів»

cr0x@server:~$ dnf repolist
repo id                         repo name
appstream                       Rocky Linux 10 - AppStream
baseos                          Rocky Linux 10 - BaseOS
extras                          Rocky Linux 10 - Extras

Що це означає: У вас увімкнені основні репозиторії. Зазвичай це те, що потрібно в перший день.

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

Завдання 7: Перевірити наявність оновлень і зрозуміти радіус ураження

cr0x@server:~$ dnf check-update
Last metadata expiration check: 0:12:31 ago on Tue 06 Feb 2026 10:14:20 AM UTC.
kernel.x86_64                     6.12.0-1.el10_0                 baseos
openssl-libs.x86_64               3.2.2-4.el10_0                  baseos
systemd.x86_64                    256.7-2.el10_0                  baseos

Що це означає: Очікують оновлення ядра, OpenSSL і systemd — це не категорія «можна пізніше».

Рішення: Патчіть у вікні обслуговування; плануйте перезавантаження, якщо оновляться ядро або systemd. Якщо хост частина кластера — робіть roll.

Завдання 8: Застосувати оновлення і зафіксувати зміни

cr0x@server:~$ sudo dnf -y update
Dependencies resolved.
================================================================================
 Package           Arch   Version                 Repository               Size
================================================================================
Upgrading:
 kernel            x86_64 6.12.0-1.el10_0         baseos                  12 M
 openssl-libs      x86_64 3.2.2-4.el10_0          baseos                 2.4 M
 systemd           x86_64 256.7-2.el10_0          baseos                 4.1 M

Transaction Summary
================================================================================
Upgrade  3 Packages

Complete!

Що це означає: Ви оновили ключові компоненти.

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

Завдання 9: Перевірити стан SELinux (і не домовлятися з ним)

cr0x@server:~$ getenforce
Enforcing

Що це означає: SELinux виконує свою роботу.

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

Завдання 10: Підтвердити статус брандмауера і відкриті порти за наміром

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

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

Що це означає: firewalld запущено і за сервісами дозволено лише SSH.

Рішення: Якщо ви бачите широко відкриті сервіси, яких не впізнаєте — приберіть їх. «Обміркуємо обмеження пізніше» — так тестові порти стають продакшн-фічами.

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

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

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

Рішення: Якщо синхронізація «ні» — виправте це перед приєднанням до доменів, випуском сертифікатів або налагодженням розподілених систем.

Завдання 12: Перевірити мережеву конфігурацію і розв’язування DNS

cr0x@server:~$ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens192           UP             10.40.12.34/24 fe80::250:56ff:feaa:bbcc/64

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

Що це означає: У вас є адреса, і DNS вказує на мережеві ресурси свідомо.

Рішення: Якщо DNS вказує на випадковий резолвер або не розв’язує внутрішні зони — виправте це зараз; встановлення пакетів і виявлення сервісів будуть помирати в креативний спосіб.

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

cr0x@server:~$ systemctl --failed
0 loaded units listed.

cr0x@server:~$ ss -lntp
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      128    0.0.0.0:22          0.0.0.0:*     users:(("sshd",pid=991,fd=3))
LISTEN 0      4096   127.0.0.1:323       0.0.0.0:*     users:(("chronyd",pid=812,fd=5))

Що це означає: Нічого не впало; відкриті лише очікувані порти.

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

Завдання 14: Перевірити стан сховища (рівень апаратного впливу варіюється)

cr0x@server:~$ sudo dmesg -T | grep -E "I/O error|blk_update_request|reset|nvme|ata" | tail -n 8
[Tue Feb  6 10:21:22 2026] nvme nvme0: pci function 0000:5e:00.0
[Tue Feb  6 10:21:22 2026] nvme nvme0: 4/0/0 default/read/poll queues
[Tue Feb  6 10:21:22 2026] nvme0n1: p1 p2 p3

Що це означає: Немає явних помилок сховища; пристрій перелічився коректно.

Рішення: Якщо ви бачите ресети або I/O помилки під час дня інсталяції — замініть апарат або виправте прошивку перед тим, як довіряти цьому хосту важливі дані.

Завдання 15: Гігієна ядра та перезавантажень (уникайте «запатчено, але не перезавантажено»)

cr0x@server:~$ uname -r
6.12.0-1.el10_0.x86_64

cr0x@server:~$ sudo dnf -q repoquery --installed --latest-limit=1 kernel
kernel-6.12.0-1.el10_0.x86_64

Що це означає: Запущене ядро відповідає останньому встановленому ядру.

Рішення: Якщо після оновлення вони не співпадають — заплануйте перезавантаження і зафіксуйте його. «Ми оновили» не рахується, доки ви не працюєте на ньому.

Три короткі корпоративні історії з передової

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

Середня компанія мігрувала флот внутрішніх сервісів з застарілого CentOS до RHEL-сумісного відтворення.
Вони сприйняли інсталяцію ОС як формальність і зосередилися на розгортанні застосунків.
Припущення було просте: «місця на диску вистачить — настройки за замовчуванням підходять».

Стек застосунків був контейнерний. Журнали були гучними, але керованими — поки в одному сервісі не лишили ввімкнений режим налагодження.
За кілька годин /var роздувся. На їхній «дефолтній» інсталяції /var жив на root-файловій системі.
Root досяг 100%, і система почала падати у вигляди, що виглядали не пов’язаними: SSH-з’єднання зависали, unit-и systemd тайм-аутувалися,
і вузол перестав приймати нові образи контейнерів.

On-call спочатку ганявся за CPU і мережею. Графіки шуміли; диск тихо кричав.
Зрештою хтось запустив df, побачив повний root і видалив логи. Хост відновився — частково.
Далі була сиквел: пошкоджені часткові завантаження і runtime контейнерів, який довелося перезапустити.

Виправлення не полягало в «скажемо розробникам менше логувати» (хоча й це теж зробили). Справжнє виправлення — схема зберігання, що передбачає відмову:
окремий /var, обмеження зберігання journald і відправка логів зовні. Інцидент став уроком інсталяції,
а не виключно додатка — особливий вид неприємності.

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

Інша організація мала вимогу продуктивності: швидші CI збірки, швидші завантаження артефактів, все швидше.
Хтось запропонував «оптимізацію»: монтувати робочу директорію збірки на один великий файловий простір, без окремих томів,
і налаштувати під пропускну здатність. Також вимкнули SELinux, бо «воно уповільнює файлові операції».

CI трохи прискорився. Потім почалося дивне. Появилися періодичні аномалії прав доступу, але тільки під навантаженням.
Декілька збірок провалилися з помилками файлової системи; при повторі вони вдавалося. Команди звинувачували CI-інструменти, мережу,
і навіть коротко — місяць.

Корінь проблеми — коктейль: агресивне налаштування плюс робоча директорія з величезним churn метаданих,
у поєднанні з лог-пайплайном, що час від часу спричиняв різкі записи. Без ізоляції між /, /var
і робочою директорією однієї найгіршої доби робочого навантаження вистачило, щоб зламати все.
Вимкнення SELinux не «вирішило продуктивність», воно лише зняло запобіжник, і остаточний аудит безпеки змусив їх
знову ввімкнути його під тиском — у період релізу кварталу. Це був… вибір.

Вони відкочували «оптимізацію»: виділили окремі логічні томи, повернули розумні I/O налаштування, SELinux — Enforcing,
і підходили до тюнінгу зі зрозумілими бенчмарками, що відображали реальні навантаження.
Час збірки став трохи довшим ніж «найшвидша» конфігурація, але кількість збоїв різко впала.
У production найшвидше рідко означає найкраще.

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

Команда, близька до фінансів, експлуатувала системи на Rocky-подібних ОС для внутрішніх сервісів.
Їхня практика була болісно нудною: кожна інсталяція проходила за чеклістом, кожен хост мав однакове розбиття,
репозиторії були закріплені, оновлення проходили через канаркове коло.
Це не було гламурно. Це працювало.

Одного ранку пакет хостів почав не завантажуватися після оновлення прошивки, яке виконала інша команда.
Моделі поведінки відрізнялися по апаратних моделях. Деякі системи впали у boot prompt; інші не знаходили EFI-запис.
Тут зазвичай паніка і люди «ліплять» виправлення вручну на консолі.

Вони швидко відновили роботу, бо їхня дисципліна інсталяцій давала передбачуваний стан:
UEFI скрізь, однакові розміри ESP, уніфікована конфігурація завантажувача і стандартний спосіб перевірки та відновлення EFI-записів.
Вони могли порівняти зламаний хост з робочим і застосувати ті самі кроки відновлення без здогадок.

Результат не був героїчною нічною битвою. Це був спокійний інцидент з чистим постмортемом.
Найкращий комплімент, який може отримати операція: «Було нудно». Жарт №2 (короткий, в тему): Нудна інфраструктура — як ремінь безпеки: ви помічаєте її тільки коли її немає.

План швидкої діагностики

Коли свіжа інсталяція Rocky Linux 10 «повільна», «не оновлюється» або «не може дістатися до ресурсів», не блукайте.
Тріаж — це послідовність. Ваша мета — ідентифікувати клас вузького місця за хвилини.

Перший крок: визначте домен відмови (завантаження, мережа, сховище, CPU/пам’ять, репозиторії)

• Проблеми завантаження: зависання на завантажувачі, emergency mode, відсутній root, помилки fsck.
• Проблеми мережі: DNS-помилки, недоступність репозиторіїв, відсутній маршрут за замовчуванням, періодична втрата пакетів.
• Проблеми сховища: високий iowait, помилки журналу, заповнені файлові системи, ресети пристроїв.
• Вирахувальні проблеми: високий load average, OOM-kill, процес, що вийшов з-під контролю.
• Проблеми з репозиторіями/пакетами: конфлікти залежностей, тайм-аути метаданих, GPG-помилки.

Другий крок: виконайте три найшвидші дискримінатори

1) Простір на диску та санітарія інодів

cr0x@server:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/mapper/rl-root   40G  2.3G   38G   6% /
/dev/mapper/rl-var    80G  5.1G   75G   7% /var

Інтерпретація: Якщо будь-яка критична файловa система > ~90% — вважайте її причиною інциденту поки не доведено зворотнє.

Рішення: Звільніть простір, розширте LV або обмежте логи перш ніж робити що-небудь інше.

2) DNS і маршрут за замовчуванням

cr0x@server:~$ ip route
default via 10.40.12.1 dev ens192 proto static metric 100
10.40.12.0/24 dev ens192 proto kernel scope link src 10.40.12.34 metric 100

cr0x@server:~$ getent hosts mirrors.rockylinux.org
203.0.113.20   mirrors.rockylinux.org

Інтерпретація: Якщо DNS-запит не працює — операції з репозиторіями і багато «випадкових» речей зламаються.

Рішення: Виправте DNS/маршрути перед тим, як звинувачувати dnf або ОС.

3) 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
 1  0      0 312544  42152 812344    0    0   120   220  310  640  6  3 89  2  0
 0  1      0 309812  42152 812512    0    0   320  5400  290  610  4  2 65 29  0
 0  1      0 310120  42160 812600    0    0   280  5100  300  620  5  2 63 30  0
 0  0      0 311004  42160 812900    0    0   140   260  305  635  5  2 90  3  0
 1  0      0 310888  42168 812930    0    0   150   240  320  650  6  3 88  3  0

Інтерпретація: Сплески wa (iowait) свідчать про конкуренцію за сховище або проблеми з пристроєм.

Рішення: Якщо iowait високий — припиніть тюнінг CPU. Дослідіть диски, черги і сервіси з інтенсивними записами.

Третій крок: заглибтеся по знайденій проблемі

• Якщо не завантажується: перевірте журнал попереднього завантаження, /etc/fstab, перевірте EFI-записи.
• Якщо dnf падає: перевірте репозиторії, DNS, час і GPG-ключі; читайте текст помилки dnf як дорослий.
• Якщо продуктивність погана: визначте, чи це CPU, брак пам’яті чи латентність сховища; не здогадуйтеся.

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

1) «dnf update таймаутиться»

Симптоми: Cannot download repomd.xml, повільні метадані, періодичні відмови.

Причина: Неправильна конфігурація DNS, проблеми з проксі або зламаний маршрут за замовчуванням.

Виправлення: Перевірте маршрутизацію і DNS; підтвердьте синхронізацію часу; повторіть спробу.

cr0x@server:~$ curl -I -m 5 https://mirrors.rockylinux.org
HTTP/2 200
date: Tue, 06 Feb 2026 10:45:12 GMT
content-type: text/html

Рішення: Якщо curl не може дістатися — dnf теж не зможе. Виправляйте мережевий шлях перш за все.

2) «Після перезавантаження входить в emergency mode»

Симптоми: systemd emergency shell, повідомлення про неможливість примонтувати файлову систему.

Причина: Неправильний запис у /etc/fstab, невірний UUID, відсутній диск або гонка з мережевими монтами.

Виправлення: Використайте systemctl status і журнали для ідентифікації юніта монтування, потім поправте fstab.

cr0x@server:~$ systemctl --failed
  UNIT           LOAD   ACTIVE SUB    DESCRIPTION
  var.mount      loaded failed failed /var

Рішення: Якщо це локальне монтування — виправте UUID. Якщо мережеве — додайте залежності або nofail з розумними таймаутами.

3) «SSH працює, але все інше не може з’єднатися»

Симптоми: SSH доступ є, але зовнішній HTTPS не працює або внутрішні сервіси недоступні.

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

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

cr0x@server:~$ ping -c 2 10.40.12.1
PING 10.40.12.1 (10.40.12.1) 56(84) bytes of data.
64 bytes from 10.40.12.1: icmp_seq=1 ttl=64 time=0.388 ms
64 bytes from 10.40.12.1: icmp_seq=2 ttl=64 time=0.402 ms

--- 10.40.12.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss

Рішення: Якщо ви не можете дістатися до шлюзу — не звинувачуйте DNS, вирішуйте L2/L3.

4) «SELinux блокує мій сервіс; я його відключив»

Симптоми: Сервіс не стартує, AVC denials в логах, хтось ставить SELinux в permissive/disabled.

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

Виправлення: Читайте відмову, правильно промаркуйте, дозвольте потрібний тип порту за потреби і тримайте SELinux у Enforcing.

cr0x@server:~$ sudo ausearch -m avc -ts recent | tail -n 3
----
type=AVC msg=audit(1738839012.412:911): avc:  denied  { name_connect } for  pid=1420 comm="nginx" dest=8080 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket

Рішення: Якщо це легітимне з’єднання — налаштуйте порти/мітки; якщо ні — розглядайте як знахідку безпеки.

5) «Система повільна під навантаженням; CPU здається нормальним»

Симптоми: Спайки латентності, високий load average, CPU стоїть у режимі idle, користувачі скаржаться.

Причина: Латентність сховища і iowait, часто через сплески логів, swap-thrashing або перевантажені диски.

Виправлення: Знайдіть процеси з найбільшим I/O, перевірте стан пристроїв, відокремте навантаження і відрегулюйте логування.

cr0x@server:~$ iostat -x 1 3
Device            r/s   w/s  rkB/s  wkB/s  await  svctm  %util
sda              5.0  90.0   80.0  7200.0  28.50   1.10  99.0

Рішення: Якщо %util близько 100% і await росте — ви зв’язані зі сховищем. Додайте IOPS, зменшіть записи або переробіть розкладку.

6) «Ми закінчили простір, але df каже, що він є»

Симптоми: Записи не вдаються, але df -h показує вільне місце.

Причина: Вичерпання інодів (рідко на XFS, більш імовірно на ext4) або файли, що були видалені, але ще відкриті.

Виправлення: Перевірте використання інодів і відкриті видалені файли; перезапустіть проблемні сервіси у контрольованому вікні, щоб звільнити місце.

cr0x@server:~$ df -i
Filesystem            Inodes  IUsed   IFree IUse% Mounted on
/dev/mapper/rl-var    524288  81234  443054   16% /var

cr0x@server:~$ sudo lsof +L1 | head
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NLINK NODE NAME
rsyslogd 901 root    5w   REG  253,1  1048576     0  123 /var/log/messages (deleted)

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

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

Чекліст A: «Мені потрібен надійний сервер Rocky Linux 10»

1. Підтвердьте налаштування прошивки обладнання: увімкнений UEFI, політика secure boot відповідна політиці організації.
2. Завантажте інсталятор у потрібному режимі (запис UEFI, не legacy).
3. Оберіть мінімальний набір пакетів, якщо GUI не потрібен.
4. Встановіть hostname, часовий пояс і план адресації мережі.
5. Схема зберігання:
   • ESP + /boot + LVM
   • Окремий /var для систем з інтенсивними логами/контейнерами
   • Відмовостійкість для системних дисків (RAID1 апаратний або mdraid), якщо час простою важливий
6. Створіть не-root адміністратора; налаштуйте SSH-ключі.
7. Тримайте SELinux у Enforcing.
8. Після першого завантаження: перевірте реліз ОС, режим завантаження, схему дисків і точки монтування.
9. Увімкніть і перевірте синхронізацію часу.
10. Перевірте репозиторії; відключіть усе, що не затверджено.
11. Повністю пропатчіть; перезавантажте; підтвердьте, що запущене ядро відповідає встановленому.
12. Переконайтеся, що брандмауер запущено; відкрийте лише необхідні сервіси/порти.

Чекліст B: «Стандартизація інсталяцій по флоту»

1. Напишіть золотий шаблон розмітки сховища (імена LVM, точки монтування, розміри, типи ФС).
2. Визначте політику репозиторіїв: які репозиторії, чи дзеркалити, і як проходить потік оновлень (dev → staging → prod).
3. Визначте базові сервіси: chronyd увімкнено, firewalld увімкнено, sshd загартовано, непотрібні демони відключені.
4. Кодифікуйте конфігурацію автоматизацією (Kickstart + конфіг-менеджмент). Ручні інсталяції не масштабуються; вони лише множаться.
5. Створіть перевірки валідації: режим завантаження, SELinux, синхронізація часу, відкриті порти, пороги використання диска.
6. Визначте процедуру «break-glass»: доступ до консолі, процедура рятування при завантаженні та відновлення EFI-записів.

Чекліст C: «Перед тим як ставити на нього додаток»

1. Місце: перевірте запас в / і /var; встановіть політики зберігання.
2. Ідентичність: підтвердьте hostname, DNS і синхронізацію часу.
3. Безпека: SELinux Enforcing; SSH-ключі; наявність політики брандмауеру.
4. Оновлення: пропатчено, перезавантажено і стабільно.
5. Спостережуваність: підтвердіть збереження журналів при потребі та роботу форвардингу логів.

Поширені запитання

1) Чи є Rocky Linux 10 «те саме, що RHEL»?

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

2) Чи ставити GUI на сервери?

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

3) XFS чи ext4 для Rocky Linux 10?

XFS — сильний дефолт для загального серверного використання і добре масштабується. ext4 також надійна.
Стандартизуйтесь на одній, якщо немає специфічних вимог. Більший виграш — дисципліна розмітки, а не війна файлових систем.

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

Зазвичай так, але розмір визначайте за навантаженням. Swap — не про продуктивність; це запобіжник.
На системах з малою пам’яттю він може запобігти аварії під час діагностики. На затримкахчутливих навантаженнях можете обмежити swap і покладатися на коректне планування пам’яті.
Не виділяйте «2× RAM» автоматично у 2026 році.

5) Чи вимикати SELinux, якщо він заважає?

Ні. Виправте політику або мітки файлів. Вимкнення SELinux міняє короткострокове зручність на довгострокову крихкість і ризик.
Якщо потрібно тимчасово встановити permissive для налагодження — документуйте це і заведить завдання з контролем.

6) Як тримати інсталяції консистентними між середовищами?

Використовуйте Kickstart для інсталяції ОС і конфігураційні інструменти для стану (користувачі, SSH, sysctl, сервіси, конфіг додатка).
Потім перевіряйте автоматичними тестами. Люди хороші в прийнятті рішень, але погані в повторюваній точності.

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

Відокремте /var (а іноді й /var/lib залежно від runtime), щоб образи, шари і логи не заповнили root.
Плануйте ампліфікацію записів. Моніторте IOPS, а не лише обсяг. Якщо можете винести контейнерне сховище на окремі диски — робіть це.

8) Як зрозуміти, чи я CPU-bound чи storage-bound?

Перевірте vmstat на iowait і чергу, потім iostat -x на насичення пристроїв.
Високе завантаження CPU з низьким iowait — CPU-bound; високе iowait і високий %util диска — bound за сховищем.

9) Чи можна приєднати Rocky Linux 10 до корпоративного каталогу?

Так. Звичні передумови: коректний DNS, синхронізація часу і правильний hostname.
Підключення до каталогу частіше зриваються через годинники і DNS, ніж через ОС.

10) Що автоматизувати в першу чергу після інсталяції?

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

Висновок: практичні наступні кроки

Rocky Linux 10 дає вам ту операційну форму, сумісну з RHEL, на яку покладаються багато організацій, не прив’язуючи вашу базову
здатність патчити флот до підпискових процесів. Ось його цінність. Ризик — думати, що інсталяція «закінчена», коли інсталятор так сказав.

Наступні кроки, що дають швидкий ефект:

1. Стандартизуйте режим завантаження і розмітку диска (UEFI + GPT, відокремлений /var для шумних хостів, LVM майже всюди).
2. Заблокуйте репозиторії і зробіть оновлення передбачуваними (канареї → поетапні релізи).
3. Тримайте SELinux у Enforcing і вчіться читати відмови замість того, щоб розгнівано відключати.
4. Перевіряйте після кожної інсталяції за допомогою практичних завдань вище; перетворіть їх на автоматичні перевірки.
5. Прийміть план швидкої діагностики, щоб команда перестала гадати і почала швидко локалізувати вузькі місця.

Якщо ви зробите ці п’ять речей, Rocky Linux 10 стане саме тим, що ви хотіли: стабільною, корпоративно-орієнтованою ОС, яка зникає на фоні
і дає вам можливість хвилюватися про ті частини production, які справді цікаві. Наприклад — користувачів.