Встановлення Oracle Linux 9: Ksplice, UEK та чистий базовий сервер

February 27, 2026 • February 27, 2026 • Читання: 7 хв • Views: 0

Було корисно?

Продуктивні сервери не ламаються через те, що ви забули якийсь хитрий трюк. Вони ламаються через те, що ви зробили щось «дрібне» під час інсталяції — вибрали неправильне ядро, пропустили один репозиторій, залишили оновлення на волю випадку — і через пів року ви дебагуєте о 2-й ночі зі «шоловним ліхтариком» із повідомлень у Slack.

Це нудний, але правильний базовий образ Oracle Linux 9: UEK там, де він доречний, Ksplice там, де він виправданий, і набір перевірок, що тримають ваш парк уніфікованим. Ви отримаєте сервер, який можна патчити, аудитуати і діагностувати без потреби знову вивчати власні рішення.

Ментальна модель: OL9, UEK, RHCK і Ksplice

Oracle Linux 9 — це дистрибутив, сумісний з RHEL, з двома треками ядра, які ви можете використовувати:

RHCK (Red Hat Compatible Kernel): тісно відповідає очікуванням ABI ядра RHEL.
UEK (Unbreakable Enterprise Kernel): ядро Oracle, зазвичай новіше, з фічами та роботою над продуктивністю, орієнтованими на корпоративні навантаження.

Жоден з них не є «завжди правильним». UEK часто є хорошим вибором за замовчуванням для розгортань OL, особливо де Oracle його очікує (бази даних, інтенсивні I/O по диску/мережі, певні драйвери). RHCK може бути консервативним вибором, коли вам потрібна максимальна сумісність зі сторонніми модулем ядра, протестованими для лінії RHEL, або коли інструменти відповідності вашої організації очікують версії ядра RHEL.

Ksplice — це живе патчування: застосування певних оновлень ядра без перезавантаження. У реальному світі воно не скасовує потребу в перезавантаженнях назавжди. Воно змінює графік перезавантажень з «кожен раз при CVE ядра» на «коли ви це заплануєте». Це величезна різниця, якщо ви коли-небудь пробували узгодити перезавантаження в stateful-кластерах, з примхливим middleware або з терпінням керівництва.

Цитата, яку варто прикріпити над стійкою: «Сподівання — не стратегія.» — генерал Гордон Р. Салліван. Не цитата SRE, але вона потрапляє в суть планування опсів.

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

Жарт №1: Якщо ви не стандартизуєте базовий образ, кожен сервер стає унікальною «сніжинкою». А сніжинки тануть під тиском.

Цікаві факти та контекст (бо історія просочується в інцидент)

Oracle Linux починався як перебіл RHEL із джерел; ДНК «сумісний, але з опціями» — це причина, чому RHCK існує поряд із UEK.
Ksplice спочатку був стартапом (кінець 2000-х), що фокусувався на безперервних оновленнях ядра; Oracle придбала його й інтегрувала в корпоративний набір.
UEK часто розвивався швидше за потік ядра RHEL, що може бути важливим для підтримки нового апаратного забезпечення.
Стабільність ABI ядра в стилі RHEL — це ціль проектування; сторонні вендори часто тестують проти цього очікування, тому RHCK залишається актуальним.
Живе патчування не охоплює «всі патчі»: деякі зміни ядра надто інвазивні; для певних класів оновлень все одно потрібні вікна технічного обслуговування.
Реалії Secure Boot: його можна увімкнути і воно все одно не захистить, якщо ваші процеси дозволяють неподписані модулі або слабкі контролі ланцюга завантаження.
Модульність DNF і розростання репозиторіїв стали практичною операційною проблемою в епоху RHEL 8+; гігієна репозиторіїв тепер частина «інсталяції».
Домінування systemd (з середини 2010-х у більшості дистрибутивів) означає, що поведінка сервісів, журнали завантаження й проблеми залежностей здебільшого — питання systemd, а не «ініт-скриптів».

Чистий базовий образ сервера, що переживе реальні операції

Цілі базового образу (те, що важить о 3-й ранку)

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

Компоненти базового образу

Для більшості середовищ я хочу встановити це на ранньому етапі:

Усвідомлений вибір UEK або RHCK, інша сімейство ядра має бути видалене або принаймні не за замовчуванням.
Ksplice увімкнений і моніториться, якщо у вас є підписка/право та операційна необхідність.
Політика репозиторіїв: лише потрібні репозиторії увімкнені; жодних «тестових» репозиторіїв у production.
Автоматичні оновлення безпеки (або щонайменше автоматичні сповіщення), з людським власником вікна для перезавантажень.
Синхронізація часу через chrony; зсув часу руйнує хронології інцидентів і аутентифікацію.
Політика брандмауера, яка відповідає реальному експонуванню сервісів, а не «відкрито й пощастить».
SELinux у режимі Enforcing, якщо ви не можете обґрунтувати виняток доказами.
Crash kernel (kdump) увімкнений для систем, де падіння ядра буде дорогим для розслідування.
Перевірки цілісності сховища: правильний планувальник, правильні опції монтування, жодних «здається швидше» налаштувань без вимірювань.

Думка: якщо ви не готові запускати SELinux у режимі Enforcing, ви не готові запускати сервіси, відкриті в інтернет. «Лише внутрішній доступ» — не силове поле; це чутка.

Практичні завдання: команди, очікувані сигнали та рішення

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

Завдання 1: Підтвердіть реліз ОС та ідентичність бази

cr0x@server:~$ cat /etc/os-release
NAME="Oracle Linux Server"
VERSION="9.4"
ID="ol"
ID_LIKE="fedora"
VERSION_ID="9.4"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Oracle Linux Server 9.4"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:9:4:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://github.com/oracle/oracle-linux"
ORACLE_BUGZILLA_PRODUCT="Oracle Linux 9"
ORACLE_BUGZILLA_PRODUCT_VERSION=9.4

Значення: Підтверджує, що ви справді на Oracle Linux 9.x, а не на подібному шаблоні. PLATFORM_ID і CPE_NAME показують родину EL9.

Рішення: Зафіксуйте версію в CMDB/інвентарі активів; узгодьте цільові репозиторії і політику патчів з тією ж мінорною гілкою по всьому парку, де це можливо.

Завдання 2: Перевірте, яке ядро запущене зараз

cr0x@server:~$ uname -r
5.15.0-201.135.6.el9uek.x86_64

Значення: el9uek у рядку випуску вказує на UEK. Якщо бачите .el9.x86_64 без uek, то це RHCK.

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

Завдання 3: Підтвердіть, яке ядро встановлено за замовчуванням для наступного завантаження

cr0x@server:~$ sudo grubby --default-kernel
/boot/vmlinuz-5.15.0-201.135.6.el9uek.x86_64

Значення: Це те, що GRUB завантажить за замовчуванням, а не те, що у вас запущено сьогодні.

Рішення: Якщо ядро за замовчуванням відрізняється від uname -r, ви на відстані одного перезавантаження від сюрпризу. Узгодьте їх.

Завдання 4: Перелічіть встановлені ядра (виявлення подвійних треків)

cr0x@server:~$ rpm -qa | egrep '^kernel|^kernel-uek' | sort
kernel-5.14.0-427.13.1.el9_4.x86_64
kernel-core-5.14.0-427.13.1.el9_4.x86_64
kernel-modules-5.14.0-427.13.1.el9_4.x86_64
kernel-uek-5.15.0-201.135.6.el9uek.x86_64
kernel-uek-core-5.15.0-201.135.6.el9uek.x86_64
kernel-uek-modules-5.15.0-201.135.6.el9uek.x86_64

Значення: У вас встановлені і RHCK, і UEK. Це часто після міграцій або «на всяк випадок» інсталяцій.

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

Завдання 5: Перевірте увімкнені репозиторії (гігієна репозиторіїв)

cr0x@server:~$ sudo dnf repolist --enabled
repo id                                   repo name
ol9_baseos_latest                         Oracle Linux 9 BaseOS Latest (x86_64)
ol9_appstream                             Oracle Linux 9 Application Stream (x86_64)
ol9_uek_latest                            Latest Unbreakable Enterprise Kernel Release 7 for Oracle Linux 9 (x86_64)
ol9_ksplice                               Ksplice for Oracle Linux 9 (x86_64)

Значення: Це джерела істини для пакетів і ядер. Додаткові репозиторії — це шлях випадково імпортувати дивні версії.

Рішення: Вимкніть все, що не можете пояснити. Якщо у вас немає прав на Ksplice, не залишайте репозиторій напівналаштованим.

Завдання 6: Перевірте стан очікуваних оновлень пакетів

cr0x@server:~$ sudo dnf -q check-update
kernel-uek.x86_64                  5.15.0-201.138.1.el9uek        ol9_uek_latest
openssl-libs.x86_64                1:3.0.7-29.el9_4               ol9_baseos_latest

Значення: Очікувані оновлення включають ядро й бібліотеки користувацького простору. Це нормально.

Рішення: Вирішіть, чи застосовувати одразу (новий билд), чи стадіювати. Якщо Ksplice увімкнений, оновлення ядра стає рішенням «спершу живі патчі, потім перезавантаження».

Завдання 7: Підтвердіть стан Secure Boot (не гадати)

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

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

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

Завдання 8: Перевірте режим SELinux (реальність базової безпеки)

cr0x@server:~$ getenforce
Enforcing

Значення: SELinux активний і застосовує політику. Permissive — це «режим аудиту»; Disabled — «я люблю жити ризиковано».

Рішення: Тримайте Enforcing, якщо немає відомої несумісності. Якщо щось ламається, напишіть локальну політику або налаштуйте контексти; не вимикайте просто так.

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

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

Значення: Годинник синхронізований, NTP активний і ви використовуєте UTC (добре). Якщо synchronized: no, ваші журнали будуть обманювати вас.

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

Завдання 10: Підтвердіть мережеву ідентичність і DNS (базове, але ламає все)

cr0x@server:~$ hostnamectl
 Static hostname: ol9-db-01
       Icon name: computer-server
         Chassis: server
      Machine ID: 2f9b2c9d0d6a4d4a8c1d3b0d3b2c4a11
         Boot ID: 8a42f5d7e7f747a0a5f01d72bbf05d61
Operating System: Oracle Linux Server 9.4
          Kernel: Linux 5.15.0-201.135.6.el9uek.x86_64
    Architecture: x86-64

Значення: Ім’я хоста встановлене; показане ядро відповідає очікуванню. Невідповідні імена хостів спричиняють колізії моніторингу й проблеми з сертифікатами.

Рішення: Стандартизуйте шаблони імен хостів; переконайтеся, що DNS прямий/зворотний коректний для всього, що працюватиме з TLS або Kerberos-подібними системами.

Завдання 11: Подивіться, що слухає порти (виявлення випадкової експозиції)

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

Значення: Лише SSH відкрито назовні; chrony слухає локально. Якщо бачите випадкові сервіси на 0.0.0.0, ваша «мінімальна інсталяція» не мінімальна.

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

Завдання 12: Стан брандмауера та реальні правила

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

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

Значення: Брандмауер працює і лише SSH дозволено в публічній зоні.

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

Завдання 13: Перевірте макет сховища та опції монтування (уникнути випадкових помилок)

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
NAME        TYPE   SIZE FSTYPE MOUNTPOINTS
sda         disk   200G
├─sda1      part   600M vfat   /boot/efi
├─sda2      part     1G xfs    /boot
└─sda3      part 198.4G LVM2_member
  ├─ol-root lvm     80G xfs    /
  ├─ol-var  lvm     60G xfs    /var
  └─ol-home lvm   58.4G xfs    /home

Значення: Окремий /var зазвичай корисний для логів, кешів пакетів і баз даних, що «проливаються». LVM дає можливості для зміни розмірів, коли реальність настає.

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

Завдання 14: Перевірте планувальник вводу-виводу і налаштування черг (не налаштовуйте в сліпу)

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

Значення: Поточний планувальник — mq-deadline. На сучасних SSD-накопичувачах у віртуальному середовищі це часто підходить; на певних масивах none також може бути доречним.

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

Завдання 15: Підтвердіть swap і поведінку при навантаженні пам’яті

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi       2.1Gi        26Gi       128Mi       3.0Gi        28Gi
Swap:          4.0Gi          0B       4.0Gi

Значення: Swap існує і не використовується; добре. Відсутність swap — це не «налаштування продуктивності», це гра з OOM killer.

Рішення: Тримайте swap для більшості загальних серверів; розміруйте його розумно. Для спеціалізованих СУБД вирішуйте свідомо і тестуйте режими відмов.

Завдання 16: Швидко перегляньте помилки при завантаженні (не чекайте тікета)

cr0x@server:~$ sudo journalctl -b -p warning --no-pager | tail -n 20
Feb 05 10:01:18 ol9-db-01 kernel: ACPI: \_SB_.PLTF.C000: Failed to evaluate _DSM (0x1001)
Feb 05 10:01:20 ol9-db-01 systemd[1]: Failed to start Crash recovery kernel arming.
Feb 05 10:01:20 ol9-db-01 systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE

Значення: Завантаження має попередження; kdump не запустився. Це не обов’язково фатально, але відхилення від базового образу.

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

Ksplice на OL9: що вам реально потрібно

Ksplice — це операційна перевага. Але тільки якщо ви ставитеся до нього як до системи, а не галочки в списку.

Для чого Ksplice корисний

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

Чого від Ksplice чекати не слід

Гарантії, що ви ніколи більше не перезавантажуватиметесь.
Заміни оновлень користувацького простору (OpenSSL, glibc тощо).
Чарівної палички для зламаних ядер, поганих драйверів або проблем з прошивкою.

Основні перевірки готовності до Ksplice

Завдання 17: Перевірте наявність інструментів ksplice

cr0x@server:~$ rpm -q ksplice-uptrack
ksplice-uptrack-1.0.2-14.el9.x86_64

Значення: Пакет присутній. Якщо не встановлено, ви нічого не патчите в режимі live.

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

Завдання 18: Перевірте статус сервісу ksplice

cr0x@server:~$ sudo systemctl status uptrack.service --no-pager
● uptrack.service - Ksplice Uptrack service
     Loaded: loaded (/usr/lib/systemd/system/uptrack.service; enabled; preset: disabled)
     Active: active (running) since Tue 2026-02-05 10:05:12 UTC; 6min ago
   Main PID: 1523 (uptrack)
     Tasks: 3
     Memory: 12.4M
        CPU: 0.220s
     CGroup: /system.slice/uptrack.service
             └─1523 /usr/sbin/uptrack -d

Значення: Сервіс працює. Зверніть увагу на стан «enabled»; ви хочете, щоб він був постійним після перезавантаження.

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

Завдання 19: Перелічіть застосовані та доступні оновлення Ksplice

cr0x@server:~$ sudo uptrack-show --available
Effective kernel version is 5.15.0-201.135.6.el9uek.x86_64
Updates available:
[0t9s] CVE-2025-12345: Fix for kernel issue in netfilter
[1a2b] CVE-2025-23456: Fix for kernel issue in io_uring

Значення: Ksplice бачить ваше ефективне ядро і має доступні живі патчі.

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

Завдання 20: Застосуйте Ksplice-оновлення (коли політика дозволяє)

cr0x@server:~$ sudo uptrack-upgrade -y
Installing [0t9s]... ok
Installing [1a2b]... ok
Your kernel is fully up to date.

Значення: Живі патчі успішно застосовано.

Рішення: Занотуйте подію патчування (тикет/CMDB). Якщо патчі не вдається застосувати — не продовжуйте бездумно повторювати спроби; зберіть логи й розгляньте звичайне оновлення ядра + перезавантаження.

Завдання 21: Підтвердіть стан вимоги перезавантаження (Ksplice не скасовує фізику)

cr0x@server:~$ sudo dnf -q needs-restarting -r || true
No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

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

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

Вибір UEK і гігієна завантаження

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

Виберіть стандарт: UEK за замовчуванням, якщо немає причини сумісності

Мій дефолт в середовищах Oracle Linux — UEK для загальних серверних навантажень, якщо лише:

Ви покладаєтесь на сторонній модуль ядра, сертифікований лише для лінії RHEL.
У вас є регуляторна або вендорна вимога, яка явно посилається на сумісний стрім ядра.
Ви намагаєтеся мінімізувати відмінності між OL і RHEL парками.

Завдання 22: Встановіть пакети ядра UEK (якщо ще не встановлені)

cr0x@server:~$ sudo dnf install -y kernel-uek
Last metadata expiration check: 0:18:10 ago on Tue 05 Feb 2026 09:54:21 AM UTC.
Dependencies resolved.
====================================================================
 Package                Arch       Version                         Repo            Size
====================================================================
Installing:
 kernel-uek              x86_64     5.15.0-201.138.1.el9uek         ol9_uek_latest  17 M

Transaction Summary
====================================================================
Install  1 Package

Complete!

Значення: Ядро UEK встановлено. Вам усе ще треба переконатися, що воно встановлене за замовчуванням для завантаження.

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

Завдання 23: Явно встановіть ядро за замовчуванням

cr0x@server:~$ sudo grubby --set-default /boot/vmlinuz-5.15.0-201.138.1.el9uek.x86_64

cr0x@server:~$ sudo grubby --default-kernel
/boot/vmlinuz-5.15.0-201.138.1.el9uek.x86_64

Значення: Наступне завантаження піде до призначеного образу UEK.

Рішення: Зафіксуйте це. Не покладайтеся на поведінку GRUB «остання версія перемагає», коли встановлено кілька сімейств ядер.

Завдання 24: Видаліть невикористовувану сім’ю ядер (необов’язково, але зменшує плутанину)

cr0x@server:~$ sudo dnf remove -y 'kernel*5.14.0*' 'kernel-core*5.14.0*' 'kernel-modules*5.14.0*'
Dependencies resolved.
====================================================================
 Package                Arch   Version                    Repository    Size
====================================================================
Removing:
 kernel                  x86_64 5.14.0-427.13.1.el9_4      @System      0
 kernel-core             x86_64 5.14.0-427.13.1.el9_4      @System     25 M
 kernel-modules          x86_64 5.14.0-427.13.1.el9_4      @System     34 M

Transaction Summary
====================================================================
Remove  3 Packages

Complete!

Значення: Пакети RHCK видалено (в цьому прикладі). У вас все ще встановлений UEK.

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

Стратегія оновлень: безпека, стабільність і контроль змін

Оновлення — це не команда. Це політика з прикріпленими інструментами.

Оновлення безпеки: робіть їх рутиною

Якщо ви не можете автоматизувати оновлення безпеки, принаймні автоматизуйте видимість. Люди ненадійні як планувальники.

Завдання 25: Подивіться порадники безпеки для очікуваних оновлень

cr0x@server:~$ sudo dnf updateinfo list --security
OLSA-2026-0001 Important/Sec.  openssl-libs-1:3.0.7-29.el9_4.x86_64
OLSA-2026-0002 Moderate/Sec.   curl-7.76.1-29.el9_4.x86_64

Значення: Існують порадники безпеки для конкретних пакетів.

Рішення: Якщо ці пакети використовуються у вашому виконуваному шляху (а зазвичай так), плануйте патчі. Для систем, відкритих в інтернет, «Important» не опціонально.

Завдання 26: Застосуйте оновлення з консервативною позицією

cr0x@server:~$ sudo dnf upgrade -y
Dependencies resolved.
====================================================================
 Package             Arch   Version                      Repo               Size
====================================================================
Upgrading:
 openssl-libs         x86_64 1:3.0.7-29.el9_4             ol9_baseos_latest  1.5 M

Transaction Summary
====================================================================
Upgrade  1 Package

Complete!

Значення: Пакет користувацького простору оновлено. Ядро може залишатися в очікуванні залежно від вашого підходу.

Рішення: Після оновлень запустіть needs-restarting, щоб вирішити, чи потрібні перезапуски сервісів або перезавантаження.

Завдання 27: Визначте сервіси, які потребують перезапуску через оновлені бібліотеки

cr0x@server:~$ sudo dnf needs-restarting || true
sshd : 1032
chronyd : 980

Значення: Ці процеси працюють зі старими бібліотеками в пам’яті; їх слід перезапустити, щоб оновлення вступили в силу.

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

Завдання 28: Заблокуйте джерела пакетів і запобігайте випадковому увімкненню репозиторіїв

cr0x@server:~$ sudo dnf config-manager --set-disabled ol9_developer_EPEL
Error: No matching repo to modify: ol9_developer_EPEL.

Значення: Репозиторій відсутній; добре. Якби він був присутній і увімкнений, його слід вимкнути в продакшні.

Рішення: Явно керуйте увімкненими репозиторіями в автоматизації. «Він не був увімкнений на моїй машині» — це не контроль.

Три корпоративні міні-історії з поля бою

Інцидент через неправильне припущення: «UEK встановлено, отже ми ним користуємось»

У середньому підприємстві команда стандартизувала Oracle Linux для парку серверів додатків. У базовому документі було «встановити UEK», і пайплайн білду зробив саме це. Однак десь у ланцюгу перезавантажень ядро за замовчуванням лишилося RHCK, бо образ спочатку походив із шаблону, де RHCK був першим у порядку GRUB.

Місяцями нічого не ламалось. Моніторинг був у зеленому. Продуктивність нормальна. Потім під час планового перезавантаження підмножини вузлів раптом відразу стала поводитися по-іншому функція мережевого адаптера третьої сторони. Симптом був неприємний: періодичні втрати пакетів під навантаженням і ретрансляції, що виглядали як «мережа», але пахли як «ядро». Команда ганялася за портами комутаторів, звинувачувала кабелі й відкривала тікети до вендора. Час зник.

Виправлення було соромно просте: підтвердити запущене ядро, підтвердити ядро за замовчуванням, потім узгодити їх. Урок не був «UEK поганий» чи «RHCK поганий». Він полягав у тому, що встановлення пакета ≠ завантаження пакета. Будь-який базовий образ, що не перевіряє стан завантаження, — казка перед сном.

Після цього вони додали дві перевірки в приймання білду: uname -r має відповідати призначеному треку, і grubby --default-kernel має збігатися з uname -r. Це зайняло хвилини. Це заощадило дні пізніше.

Оптимізація, що дала зворотний ефект: «Відключимо swap заради зниження латентності»

Інша організація запускала низьколатентні сервіси й вирішила, що swap ворог. Хтось прочитав тему про продуктивність і сприйняв висновок надто буквально. Swap було видалено з базового образу. Сервери в певних вузьких бенчмарках стали «швидшими», тож зміна виглядала виправданою.

Потім почався повільний витік: Java-сервіс з багом зростання пам’яті, який зазвичай під тиском виштовхував холодні сторінки в swap. Без swap пам’ять переходила від «трохи деградовано» до «миттєвий OOM». Ядро почало вбивати процеси. І не завжди великий очевидний процес — інколи першим падав сайдкар або агент логування, що ускладнювало інтерпретацію інциденту.

Найгірше було у відмовному режимі. Це не було граціозне деградування. Це була хаотична петля краху, що виглядала як баг додатку (це був), але поводилася як нестабільність інфраструктури (вона такою й стала). Вони повернули swap з розумним розміром, налаштували memory limits і використали cgroups, щоб обмежити найгірші порушники. «Оптимізація» зменшила один тип латентності й значно підвищила середній час до повернення до нормального стану.

Жарт №2: Відключити запасне колесо, щоб «зменшити вагу» — технічно правда, доки дорога не стане цікавою.

Нудна, але правильна практика, що врятувала день: «Тримайте /var окремо і моніторьте його»

У регульованому середовищі команда безпеки вимагала детального аудит-логування. Оперативна команда зробила глибоко негарну річ: відокремила /var в окремий логічний том, додала алерти за вільним простором і тримала жорсткий обіг логів. Ніхто не аплодував. Ніхто не писав блог-пост про це.

Одного ранку у стороннього провайдера аутентифікації були періодичні невдачі. Додатки почали повторні запити, і шторм повторів підвищив об’єм логів. На багатьох системах така подія заповнює кореневу файлову систему й ви отримуєте каскадні відмови: пакетний менеджер ламається, сервіси не можуть писати стан, SSH-входи відмовляють, і відновлення стає завданням для фізичної присутності на місці.

Тут root залишився здоровим. Лише /var постраждав, спрацювали алерти ранньо, і команда мала простір для маневру: вони загальмували повтори, тимчасово посилили ротацію і почистили зростання. Інцидент все ще був болючим, але не перетворився на повний відмову системи. Найкраща операційна робота виглядає так, ніби нічого не сталося.

Швидкий план діагностики

Це послідовність «входу в горячу кімнату». Вона передбачає OL9, але більшість кроків універсальні. Мета — швидко знайти вузьке місце: CPU, пам’ять, диск, мережа або «ядро не те, що ви думаєте».

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

cr0x@server:~$ uname -r
5.15.0-201.135.6.el9uek.x86_64

cr0x@server:~$ sudo grubby --default-kernel
/boot/vmlinuz-5.15.0-201.135.6.el9uek.x86_64

Сигнал: Невідповідність означає, що ви на відстані одного перезавантаження від нового режиму відмови. Деякі аномалії продуктивності корелюють з відмінностями треків ядра.

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

Друге: визначте ресурсний тиск за 60 секунд

cr0x@server:~$ uptime
 10:19:52 up  2:31,  2 users,  load average: 7.22, 6.91, 6.80

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
 3  0      0 26800000 120000 2100000  0    0     2     7  120  240  3  1 95  1  0
 8  2      0  900000 110000 2200000  0    0  8000 12000 1400 2200  5  3 55 37  0

Сигнал: Високий wa (iowait) вказує на латентність або насичення сховища. Високий r при низькому idle вказує на конкуренцію за CPU. Обміни в swap — на тиск пам’яті.

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

Третє: якщо iowait високий, доведіть це статистикою по пристрою

cr0x@server:~$ iostat -xz 1 3
Linux 5.15.0-201.135.6.el9uek.x86_64 (ol9-db-01)  02/05/2026  _x86_64_  (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.20    0.00    3.10   34.50    0.00   56.20

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz  aqu-sz  %util
sda              65.0   5200.0     0.0    0.0   18.5     80.0    110.0  14500.0     2.0    1.8   35.2    131.8    5.3   92.0

Сигнал: Високий await, велике %util і зростаючий aqu-sz = сховище є вузьким місцем.

Рішення: Перевірте бекенд сховища, глибину черги, шумних сусідів, файлову систему і шаблони I/O додатку перш ніж чіпати тюнінг CPU.

Четверте: якщо CPU високий, знайдіть основні процеси і їхні системні виклики

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
  PID COMMAND         %CPU %MEM
 2412 java            380  22.1
 1530 node             95   3.2
  980 chronyd           2   0.1

Сигнал: Один процес, що домінує, дозволяє зосередитись. Багато процесів з невеликим навантаженням кожен — натяк на конкуренцію або «thundering herd».

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

П’яте: якщо «схоже на мережу», перевірте пропуски й помилки

cr0x@server:~$ ip -s link show dev ens192
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:50:56:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
      987654321  1234567      0      12       0       0
    TX:  bytes packets errors dropped carrier collsns
      876543210  1122334      0       0       0       0

Сигнал: Пропуски або помилки є; це не доказ причини, але підказка. У віртуалізованих середовищах пропуски можуть бути наслідком заторів на хості.

Рішення: Якщо пропуски ненульові і зростають, корелюйте з навантаженням і перевіряйте метрики vSwitch/хоста; не переписуйте налаштування TCP відразу.

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

1) «Ksplice встановлено, але нічого не патчується»

Симптоми: uptrack-show показує помилки, сервіс не працює або оновлення ніколи не з’являються.

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

Виправлення: Переконайтеся, що dnf repolist --enabled містить репозиторій Ksplice, увімкніть systemctl enable --now uptrack.service і підтвердіть, що uname -r відповідає очікуваному UEK/RHCK-потоку для підтримки Ksplice.

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

Симптоми: Система перезавантажилась і тепер драйвери/продуктивність відрізняються; uname -r показує інше сімейство.

Корінь проблеми: Запис GRUB за замовчуванням не встановлено; встановлені обидва сімейства ядер; оновлення встановило новіше ядро іншої сім’ї.

Виправлення: Використайте grubby --default-kernel і grubby --set-default, щоб зафіксувати; видаліть невикористовувані пакети ядер або явне керуйте GRUB у CM.

3) «DNF тягне несподівані версії»

Симптоми: Рутинне оновлення приносить пакети, яких ви не очікували; ланцюжки залежностей дивні.

Корінь проблеми: Додаткові репозиторії увімкнені (часто developer/testing), або modular streams неузгоджені між хостами.

Виправлення: Застосуйте allow-list репозиторіїв, аудитуйте dnf repolist --enabled і стандартизуйте модульні стріми, якщо ви їх використовуєте.

4) «Перезапуск SSH відключив мене»

Симптоми: Перезапустили sshd під час патчів і втратили з’єднання.

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

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

5) «Високий iowait після «налаштування сховища»»

Симптоми: Спади латентності; додатки повільні; iostat показує високий await.

Корінь проблеми: Змінено планувальник I/O або налаштування черг без урахування бекенда сховища або віртуалізації; невідповідні опції файлової системи/монтажу.

Виправлення: Поверніть тюнінг; поверніть дефолтний планувальник; вимірюйте з репрезентативним навантаженням; координуйтеся зі storage-командою щодо глибини черги й поведінки масиву.

6) «Логи зникли або система зависла через повний диск»

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

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

Виправлення: Розділіть /var (і іноді /var/log), увімкніть агресивну ротацію логів, налаштуйте алерти на використання файлової системи і обмежуйте runaway-логи.

7) «Secure Boot увімкнено, але модулі ядра не завантажуються»

Симптоми: Драйвери/модулі не завантажуються після увімкнення Secure Boot; dmesg показує проблеми з підписом.

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

Виправлення: Або підписуйте модулі коректно і керуйте ключами MOK, або держіть Secure Boot вимкненим за політикою — не лишайте проміжний невизначений стан.

Контрольні списки / покроковий план

Базовий золотий образ (зробіть це один раз, автоматизуйте назавжди)

Встановіть OL9 minimal там, де доречно; уникайте зайвих груп пакетів, якщо вони не потрібні.
Встановіть hostname, DNS і часовий пояс (використовуйте UTC, якщо немає юридичної причини інакше).
Виберіть трек ядра:
- UEK для типової Oracle Linux інфраструктури.
- RHCK якщо вендор вимагає або потрібно суворе вирівнювання з RHEL-ядром.
Зафіксуйте ядро за замовчуванням за допомогою grubby; видаліть іншу сім’ю ядер, якщо вона не потрібна.
Увімкніть лише потрібні репозиторії; перевірте за допомогою dnf repolist --enabled.
Увімкніть SELinux в режимі Enforcing; виправляйте політику замість вимикання.
Налаштуйте chrony і перевірте синхронізацію часу.
Налаштуйте брандмауер: дозволяйте лише те, що потрібно; перевіряйте за допомогою ss і firewall-cmd.
Розділіть диски розумно: окремий /var для більшості серверних ролей; забезпечте план росту.
Вирішіть питання Ksplice:
- Якщо використовуєте — встановіть агент, увімкніть сервіс, перевірте застосування патчів.
- Якщо не використовуєте — не вдавайте; видаліть пакети й вимкніть репозиторії.
Застосуйте оновлення, потім вирішіть: перезапуск сервісів чи перезавантаження. Використовуйте needs-restarting.
Перезавантажте один раз під час валідації образу, щоб переконатися, що він коректно повертається на призначеному ядрі.
Збережіть «відомо гарний» стан: ядро, увімкнені репозиторії, завантажені модулі, слухаючі порти, макет файлової системи.

Повторювані операції (щотижневий ритм)

Перегортайте видимість оновлень безпеки (dnf updateinfo list --security).
Регулярно застосовуйте оновлення користувацького простору; перезапускайте постраждалі сервіси свідомо.
Застосовуйте Ksplice-оновлення, коли доступні (за політикою).
Плануйте періодичні перезавантаження (щомісяця/щокварталу) навіть з live-patching.
Аудитуйте дрейф: сімейство ядра, список репозиторіїв, сервіси брандмауера, режим SELinux.

Перевірки перед вікном обслуговування (на хост)

uname -r і grubby --default-kernel збігаються.
dnf check-update переглянуто; ядро і критичні бібліотеки зафіксовано.
dnf needs-restarting переглянуто після оновлень.
Перевірено консольний доступ для віддалених сайтів.
Перевірено бекапи/снепшоти для систем зі станом.

ЧаПи

1) Чи варто використовувати UEK або RHCK на Oracle Linux 9?

Використовуйте UEK за замовчуванням для більшості парків Oracle Linux, особливо якщо ви запускаєте Oracle-навантаження або хочете нові функції ядра. Використовуйте RHCK, коли сторонній вендор сертифікує лише для сумісної з RHEL лінії ядра або ваша організація вимагає суворого вирівнювання з RHEL.

2) Чи можна встановити обидва UEK і RHCK «на всяк випадок»?

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

3) Чи усуває Ksplice всі перезавантаження?

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

4) Чому `grubby --default-kernel` важливий, якщо `uname -r` виглядає правильно?

Бо uname -r — це «що ви завантажили», тоді як grubby — це «що ви завантажите наступного разу». Аутсайди люблять розрив між цими двома реченнями.

5) Чи потрібно вмикати автоматичні оновлення на OL9 серверах?

Вмикайте автоматичні оновлення безпеки лише якщо у вас є протестована історія відкату і ви розумієте вимоги контролю змін. Щонайменше — автоматизуйте звітність по порадниках безпеки і робіть вікна обслуговування частими.

6) Який мінімальний набір репозиторіїв варто тримати увімкненими?

Зазвичай BaseOS і AppStream, плюс UEK якщо ви його використовуєте, плюс Ksplice якщо маєте право і використовуєте. Усе інше має бути виправдане конкретною потребою пакета й періодично переглянуте.

7) Чи реалістично тримати SELinux у режимі Enforcing в продакшні?

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

8) Який макет файлової системи ви рекомендуєте для загального сервера?

UEFI + окремий /boot, LVM для гнучкості, окремий /var для росту і ізоляції логів. Для інтенсивного логування або баз даних розгляньте виділення /var/log або розміщення даних на окремих томах.

9) Як зрозуміти, чи варто турбуватись про Secure Boot?

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

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

Визначте стандарт ядра (UEK або RHCK) і зафіксуйте це в одному місці, що має значення: пайплайн білду + політика.
Додайте дві перевірки приймання для кожного хоста при побудові: uname -r відповідає стандарту, і grubby --default-kernel відповідає uname -r.
Свідомо вирішіть питання Ksplice. Якщо використовуєте — моніторьте й доведіть, що він патчить. Якщо не використовуєте — видаліть його й перестаньте вдавати.
Зробіть оновлення передбачуваними: обмежте репозиторії, стандартизуйте каденс патчів і використовуйте needs-restarting, щоб уникати випадкових перезавантажень.
Прогіньте швидкий план діагностики на одному здоровому хості і зафіксуйте «норму». Цей базовий профіль робить майбутні аномалії очевидними.

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