Встановлення openSUSE Leap 15.6: стабільна Linux‑система, яку збережете на роки

Чому Leap 15.6 — дистрибутив «зберегти на роки»

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

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

Те, що робить Leap особливо придатним для «встановив і забув», це поєднання:

• YaST для конфігурації системи, яка залишається читабельною через роки, включно зі сховищем і мережею.
• Btrfs + Snapper інтеграції, яка перетворює багато випадків «мабуть перевстановимо» на «відкатнулися і продовжуємо роботу».
• zypper робочих процесів патчування, що добре вписуються в контрольоване управління змінами.
• AppArmor як прагматичний шар жорсткості, який реально використовується і підтримується.

Одна думка наперед: якщо ви хочете «все найновіше», це не ваш дистрибутив. Якщо ви хочете «я можу пояснити кожну зміну аудитору», ви вдома.

Цікаві факти та контекст (те, що пояснює культуру)

1. openSUSE має дві особистості за задумом: Tumbleweed (ролінг) і Leap (стабільний). Цей поділ навмисний, а не компроміс.
2. YaST з’явився раніше за більшість сучасних інсталяторів: це визначальна риса SUSE десятиліттями, і модуль сховища залишається одним із найкращих інструментів «бачити все в одному місці».
3. Основа Leap прив’язана до корпоративної роботи SUSE: консерватизм успадкований. Ось чому він здається повільнішим — і чому він ламається рідше.
4. Btrfs став дефолтом в openSUSE раніше за більшість дистрибутивів: не тому, що це було модно, а тому, що снапшоти й відкат зменшують навантаження підтримки.
5. Модель «pre/post» у Snapper — це керування змінами, закодоване в інструменті: вона перетворює пакетні операції на аудиторські стани системи.
6. Концепція патчу в zypper — це першокласний робочий процес: це не просто «оновити все», це «застосувати набір перевірених виправлень».
7. AppArmor історично — сильна сторона SUSE: інша філософія від SELinux, орієнтована на профілі, зазвичай легша для експлуатації у змішаних командах.
8. Wicked існує тому, що корпоративні мережі — складні: NetworkManager чудовий для ноутбуків; сервери часто хочуть декларативної, нудної поведінки.
9. openSUSE давно вважає пакування та конвеєри збірки за ключову компетенцію: культура очікує відтворюваності, а не імпровізації.

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

Виберіть ціль встановлення: робоча станція, сервер або «одна машина для всього»

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

• Сервер: мінімальна система, SSH, firewalld, NTP, ваші сервіси.
• Робоча станція: KDE Plasma — міцний дефолт на Leap. GNOME також підходить. Оберіть один.
• Одна машина в лабораторії: все ж встановіть мінімум + один легкий UI за потреби. Уникайте встановлення «всіх десктопів». Так ви зрештою налагоджуватимете два аудіо‑стеки на сервері.

Вибір файлової системи: Btrfs там, де допомагає; XFS там, де треба нудність

Дефолтний корінь на Btrfs у Leap — це функція, а не трюк. Снапшоти і відкати рятують, коли оновлення йдуть не так. Але не кладіть усе на Btrfs тільки тому, що він є.

Мій дефолт:

• / на Btrfs зі включеним Snapper.
• /home на XFS для робочої станції (просто, швидко, без драми) або на Btrfs, якщо вам важливі снапшоти даних користувача і ви приймаєте операційну складність.
• /var/lib для баз даних на XFS (або ext4), якщо немає чіткої причини використовувати Btrfs і ви розумієте поведінку copy‑on‑write та налаштування.

Жарт #1: Btrfs‑снапшоти як ремені безпеки — ви помічаєте їх тільки тоді, коли щось намагається зіпсувати ваш день.

Розділення та завантаження: UEFI, GPT і «не вигадуйте»

Використовуйте UEFI, якщо ваше обладнання його підтримує. Використовуйте GPT. Створіть EFI System Partition (ESP) принаймні 512 МиБ. Не діліть ESP між забагато ОС, якщо вам не до вподоби археологія.

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

Мережева підсистема: Wicked для серверів, NetworkManager для ноутбуків

Wicked чудовий, коли ви хочете «інтерфейс піднімається однаково щоразу». NetworkManager підходить, коли ви перемикаєтесь між Wi‑Fi мережами. Не змішуйте їх без причини.

Дисципліна репозиторіїв: менше репозиторіїв — менше загадок

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

Покрокова інсталяція з рекомендованими налаштуваннями

1) Носій завантаження та налаштування прошивки

Використовуйте офіційний ISO інсталятора (офлайн‑інсталятор підходить для серверів; мережевий інсталятор підходить, якщо ваша мережа надійна). У налаштуваннях прошивки:

• Увімкніть режим UEFI.
• Вимкніть режим «RAID», якщо це фальшивий RAID і ви хочете Linux mdadm.
• Залиште Secure Boot увімкненим, якщо немає конкретної причини його вимикати (кастомні модулі ядра, нишеві драйвери).

2) Вибір патерну інсталяції: тримайте мінімум

На серверах: починайте з мінімальної інсталяції і додавайте пакети навмисно. На робочих станціях: KDE Plasma — практичний дефолт на Leap. Він звично поводиться і добре інтегрований.

3) Пропозиція сховища: приймайте дух, редагуйте деталі

YaST запропонує макет. Він часто пристойний, але не натискайте «все за замовчуванням». Ваше завдання — зробити майбутні операції простими:

• ESP: 512 МиБ–1 ГіБ (FAT32, змонтовано в /boot/efi).
• Root: Btrfs, зі включеними снапшотами.
• Swap: розмір залежить від потреб гібернації і ОЗП. Для серверів невеликий swap підходить; для ноутбуків з гібернацією — співпадає з ОЗП.
• Дані: окремий розділ/LV для /var/lib (контейнери, бази даних), якщо ви їх запускатимете.

4) Користувачі та SSH: встановіть політику зараз

Створіть звичайного користувача. Якщо це сервер, уникайте ввімкнення SSH з паролями. Плануйте аутентифікацію за ключами. Якщо доводиться тимчасово використовувати паролі, встановіть дату для їх видалення.

5) Синхронізація часу та ім’я хоста: нудні деталі, що кусають пізніше

Встановіть правильний часовий пояс. Увімкніть NTP. Оберіть ім’я хоста, яке не зганьбить вас у логах. «server2-final» — не план.

6) Перший перезавантаження: перевірте завантаження та інструменти снапшотів

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

План зберігання: Btrfs, XFS, LVM, RAID і що я б розгорнув

Btrfs на /: розглядайте його як систему безпеки ОС

Btrfs‑корінь у Leap з Snapper побудований навколо однієї ідеї: більшість відмов відбуваються під час змін. Якщо ви можете швидко відкотити стан ОС, ви зменшуєте час простою та паніку.

Чим Btrfs‑корінь добрий:

• Снапшоти до/після пакетних операцій.
• Швидкий відкат після невдалого оновлення або неправильної конфігурації.
• Розумна продуктивність для файлів ОС.

Чим Btrfs‑корінь не є автоматично кращим:

• Високо‑записні бази даних без налаштування та розуміння copy‑on‑write.
• «Налаштував і забув», коли ви ніколи не перевіряєте політику збереження снапшотів і вільне місце.

XFS для інтенсивних записів

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

LVM: опціонально, але корисно для людей

LVM не є обов’язковим, але часто вартий зусиль на серверах, бо дає гнучке розширення і чітке розділення між ОС і даними. YaST робить його керованим, і це інструмент, який розпізнає ваше майбутнє «я».

Програмний RAID: mdadm для рідного RAID у Linux

Якщо вам потрібен RAID1/10 для доступності, Linux mdadm стабільний і прозорий. Уникайте «фальшивого RAID», якщо немає сильної причини, бо він ускладнює відновлення.

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

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

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

Перші завдання після першого завантаження, щоб уникнути жалю (команди включено)

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

Завдання 1: Підтвердити версію ОС і ядро

cr0x@server:~$ cat /etc/os-release
NAME="openSUSE Leap"
VERSION="15.6"
ID="opensuse-leap"
PRETTY_NAME="openSUSE Leap 15.6"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.6"

Що це означає: Ви дійсно на Leap 15.6, а не на неправильному ISO або частково оновленій системі.

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

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

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

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

Рішення: Якщо ви очікували UEFI, а бачите BIOS, перегляньте налаштування прошивки перед продовженням.

Завдання 3: Перевірити файлові системи та параметри монтування

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /
/dev/nvme0n1p3 btrfs rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/@/.snapshots/1/snapshot

Що це означає: Root на Btrfs, і ви на підтомі снапшота (звично з інтеграцією Snapper).

Рішення: Якщо root не Btrfs, а ви хотіли Snapper‑відкат, виправте це зараз, а не після встановлення півсвіту пакетів.

Завдання 4: Підтвердити, що Snapper працює і має базовий снапшот

cr0x@server:~$ sudo snapper list
 # | Type   | Pre # | Date                     | User | Cleanup | Description | Userdata
---+--------+-------+--------------------------+------+---------+-------------+---------
0  | single |       |                          | root |         | current     | 
1  | single |       | 2026-02-05 09:18:24      | root |         | first root filesystem | 

Що це означає: Snapper бачить принаймні один снапшот. Система може відкотити стан ОС за потреби.

Рішення: Якщо Snapper не налаштований, вирішіть, чи хочете ви його. На Leap я зазвичай використовую його для /.

Завдання 5: Оглянути блокові пристрої і підтвердити, що ви на тому диску, який планували

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
NAME        SIZE TYPE FSTYPE MOUNTPOINTS
nvme0n1   953.9G disk        
├─nvme0n1p1   1G part vfat   /boot/efi
├─nvme0n1p2  32G part swap   [SWAP]
└─nvme0n1p3 920G part btrfs  / /.snapshots

Що це означає: Розділення відповідає очікуванням: ESP, swap і Btrfs‑root.

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

Завдання 6: Перевірити вільне місце так, як його бачить Btrfs

cr0x@server:~$ sudo btrfs filesystem usage /
Overall:
    Device size:                 920.00GiB
    Device allocated:             60.00GiB
    Device unallocated:          860.00GiB
    Used:                         18.50GiB
    Free (estimated):            900.00GiB      (min: 900.00GiB)
    Data ratio:                       1.00
    Metadata ratio:                   1.00

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

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

Завдання 7: Підтвердити репозиторії (і вчасно помітити «випадковий репо‑дріфт»)

cr0x@server:~$ sudo zypper lr -u
#  | Alias                       | Name                        | Enabled | GPG Check | Refresh | URI
---+-----------------------------+-----------------------------+---------+-----------+---------+---------------------------
1  | repo-oss                    | Main Repository (OSS)       | Yes     | (r ) Yes  | Yes     | https://download...
2  | repo-non-oss                | Main Repository (NON-OSS)   | Yes     | (r ) Yes  | Yes     | https://download...
3  | repo-update                 | Update Repository (OSS)     | Yes     | (r ) Yes  | Yes     | https://download...

Що це означає: У вас чиста база: основні репозиторії плюс оновлення.

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

Завдання 8: Застосувати патчі безпеки (фокус на патчах, а не «все одно оновлю»)

cr0x@server:~$ sudo zypper patch
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 3 patches are going to be installed:
  openSUSE-SLE-15.6-2026-1234 security  openssl security update
  openSUSE-SLE-15.6-2026-2345 security  openssh security update
  openSUSE-SLE-15.6-2026-3456 recommended  systemd bugfix update

3 patches to install.
Overall download size: 4.2 MiB. Already cached: 0 B. After the operation, additional 12.0 MiB will be used.
Continue? [y/n/v/...? shows all options] (y): y

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

Рішення: На серверах віддавайте перевагу zypper patch регулярно; плануйте повні оновлення пакетів, коли можете тестувати і перезавантажуватися.

Завдання 9: Підтвердити стан сервісів і здоров’я завантаження

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

Що це означає: Наразі немає несправних юнітів systemd.

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

Завдання 10: Переглянути логи останнього завантаження на предмет важливих попереджень

cr0x@server:~$ sudo journalctl -b -p warning --no-pager | tail -n 8
Feb 05 09:22:11 server kernel: ACPI: \_SB.PCI0... AE_NOT_FOUND
Feb 05 09:22:12 server systemd[1]: Found device /dev/disk/by-uuid/...
Feb 05 09:22:14 server wicked[915]: eth0: link detected
Feb 05 09:22:15 server chronyd[1022]: System clock was stepped by 0.423 seconds

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

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

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

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

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

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

Завдання 12: Підтвердити стек мережевого управління (Wicked проти NetworkManager)

cr0x@server:~$ systemctl is-active wicked NetworkManager
active
inactive

Що це означає: Wicked керує мережею, NetworkManager неактивний. Це розумна серверна позиція.

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

Завдання 13: Підтвердити статус фаєрволу і зону за замовчуванням

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

cr0x@server:~$ sudo firewall-cmd --get-default-zone
public

Що це означає: firewalld активний; зона за замовчуванням — public (зазвичай обмежувальна).

Рішення: Тримайте його увімкненим. Відкривайте лише необхідне. «Вимкну фаєрвол для тестування» має довге резюме жалю.

Завдання 14: Перевірити завантаження CPU, тиск пам’яті та політику swap

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

Що це означає: Достатньо вільної оперативної пам’яті; swap не використовується (нормально на простій системі).

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

Завдання 15: Швидко перевірити стан дисків (приклад NVMe)

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | sed -n '1,18p'
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.14.21-lp156.12-default] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       ACME NVMe 1TB
Serial Number:                      ABCD123456
Firmware Version:                   1.0.3
PCI Vendor/Subsystem ID:            0x1234
IEEE OUI Identifier:                0xdeadbe
Total NVM Capacity:                 1,000,204,886,016 [1.00 TB]
Unallocated NVM Capacity:           0
Controller ID:                      0
NVMe Version:                       1.4
Number of Namespaces:               1
Namespace 1 Size/Capacity:          1,000,204,886,016 [1.00 TB]
Namespace 1 Utilization:            54,321,098,752 [54.3 GB]

Що це означає: SMART‑дані читаються; модель і прошивка ідентифіковані.

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

Завдання 16: Підтвердити, що AppArmor увімкнений

cr0x@server:~$ sudo aa-status | sed -n '1,10p'
apparmor module is loaded.
30 profiles are loaded.
28 profiles are in enforce mode.
2 profiles are in complain mode.
0 profiles are in kill mode.

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

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

Завдання 17: Перевірити базову політику SSH

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

Що це означає: Логін root заблоковано; парольний SSH вимкнено; ключі увімкнені.

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

Стратегія оновлень: zypper, патчі та коли бути обережним

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

• Рутинний ритм: застосовуйте безпекові та рекомендовані патчі за допомогою zypper patch.
• Контрольовані оновлення: плануйте zypper update або zypper dup лише тоді, коли маєте намір робити ширші зміни (і коли можна перезавантажитись).
• Робочий процес з урахуванням снапшотів: переконайтеся, що Snapper створює pre/post‑снапшоти для пакетних операцій. Якщо щось зламається, відкат — це план, а не молитва.

Відкат після невдалих змін

Коли оновлення ламає завантаження або сервіс, шлях відновлення має бути процедурним. На Btrfs+Snapper‑корені ви часто можете відкотитися.

cr0x@server:~$ sudo snapper list | tail -n 5
98  | pre    |       | 2026-02-05 10:12:01 | root | number | zypp(zypper patch) | 
99  | post   | 98    | 2026-02-05 10:13:12 | root | number | zypp(zypper patch) | 
100 | single |       | 2026-02-05 10:20:44 | root | number | before-nginx-config | 

Що це означає: У вас є пара pre/post навколо патчування і ручний снапшот «before‑nginx‑config».

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

Одне керівне правило з надійності: «Сподівання — не стратегія.» — Gene Kranz

Базова безпека: фаєрвол, SSH, AppArmor та логування

Фаєрвол: відкривайте порти тільки коли сервіс готовий

На серверах тримайте зону за замовчуванням обмежувальною. Додавайте сервіси явно. Приклад: дозволити SSH і (тільки за потреби) HTTP/HTTPS.

cr0x@server:~$ sudo firewall-cmd --permanent --add-service=ssh
success

cr0x@server:~$ sudo firewall-cmd --reload
success

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

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

Рішення: Не відкривайте порти «для майбутніх сервісів». Відкривайте, коли сервіс встановлено, налаштовано і моніториться.

SSH: ключі, без root, мінімальна поверхня атаки

Встановіть PasswordAuthentication no, PermitRootLogin no. Тримайте аварійний шлях: доступ до консолі або OOB‑управління, якщо це реальний продакшен.

Логування: не можна налагоджувати те, чого не записано

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

AppArmor: примус, не відключення

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

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

Інцидент: неправильне припущення («снапшоти — це резервні копії»)

Середня компанія запускала кілька внутрішніх сервісів на VM‑хості на базі Leap. Вони любили Btrfs‑снапшоти. Мали щотижневі снапшоти і відчували себе в безпеці. Команда адміністраторів навіть практикувала відкат після невдалого оновлення пакетів раз. Впевненість зросла.

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

Перший інстинкт команди був «відкатнути снапшоти». Це працювало для однієї VM… нетривало. Потім підвищення проблем з апаратурою повторювалося. Снапшоти ж живуть на тому ж сховищі. Вони захищають від поганих змін, але не від поганого обладнання або поганого дня в SAN.

Довга ніч пішла на відновлення з реальної системи бекапів, яка у них була — просто не так недавно протестована, як слід. Післямова була прямолінійною: припущення не було злочинним, воно було лінивим семантично. Снапшот — не резервна копія. Такий самий диск — та сама зона відмови.

Що змінилося: нудно і правильно — щомісячні тести відновлення та віджет‑дашборд, що показує свіжість бекапів поряд із кількістю снапшотів. Команда перестала сперечатися словами і почала вимірювати відновлення.

Оптимізація, що відгукнулася боком: «настроїмо під швидкість»

Інша організація мала флоту Leap 15.x з контейнеризованими сервісами. Хтось помітив піки використання диска й I/O під час пік‑годин і вирішив, що система «витрачає час» на поведінку copy‑on‑write для шарів контейнерів.

Вони зробили швидку зміну: перемістили сховище контейнерів на Btrfs‑root і почали експериментувати з опціями монтування та агресивною політикою прибирання. Система на синтетичних тестах стала відчуватися швидшою. Всім сподобалося. Тикет закрили з маркуванням «оптимізовано».

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

Вони відкотилися до простішого дизайну: Btrfs для ОС, контейнерні й базові шляхи запису — на XFS, і розумна ретенція снапшотів. Продуктивність повернулася до «трохи менш захоплюючої», а доступність — до «нудно стабільної». Команда також запам’ятала урок: оптимізація без плану виходу — це експеримент у продакшені.

Нудна практика, що врятувала день: вікна змін + попередні перевірки

Маленька фінансова конторка використовувала Leap‑сервери для внутрішніх додатків. Вони не були показні. Мали щомісячне вікно патчів, чеклист і звичку робити ручний снапшот з читабельною міткою перед будь‑якою значущою зміною.

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

Оскільки у них був чеклист, on‑call не почав дебагати додаток постачальника сканерів. Вони слідували скрипту: підтвердити, що регресія корелює з патчем, порівняти логи між pre/post снапшотом і відкотити OS‑снапшот на одному канарі.

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

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

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

Перше: це системний збій чи один сервіс?

cr0x@server:~$ uptime
 09:41:03 up  1:12,  2 users,  load average: 6.21, 5.98, 5.10

Інтерпретація: Високе навантаження може означати насичення CPU, накопичення черги runnable або блокований I/O (load включає uninterruptible sleep).

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

Друге: CPU проти пам’яті проти I/O (оберіть правильну проблему)

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
 2  0      0 2780000  42000 820000    0    0    12    25  220  410  8  2 89  1  0
 7  3      0  120000  43000 790000    0    0  8800  9200 1200 3500 10  5 40 45  0

Інтерпретація: Стовпець b (заблоковані процеси) і високий wa (I/O wait) вказують на вузьке місце в зберіганні.

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

Третє: знайдіть найгарячіший процес, потім перевірте, чи він — причина

cr0x@server:~$ top -b -n 1 | head -n 15
top - 09:42:55 up  1:14,  2 users,  load average: 6.80, 6.05, 5.20
Tasks: 214 total,   3 running, 211 sleeping,   0 stopped,   0 zombie
%Cpu(s): 11.0 us,  4.0 sy,  0.0 ni, 40.0 id, 45.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  32000.0 total,   118.0 free,  1250.0 used,  30632.0 buff/cache
MiB Swap:  32768.0 total, 32768.0 free,     0.0 used.  30100.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 3221 postgres  20   0 3248000 220000  12000 D  12.0   0.7   0:34.11 postgres

Інтерпретація: Процес у стані D (uninterruptible sleep) плюс високий I/O wait сильно вказує на зависання зберігання.

Рішення: Перейдіть до перевірок сховища. Не перезапускайте сервіси навмання; ви просто додасте навантаження на диск, що страждає.

Четверте: затримки та помилки сховища (тихі вбивці)

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
         10.70    0.00    4.10   44.90    0.00   40.30

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  r_await  w_await
nvme0n1          85.0   120.0  9800.0 11000.0     0.0     5.0   98.0    12.4    35.8

Інтерпретація: %util близько до 100 і високий await вказують, що диск насичений або нечемний, або ви влучили в проблему чергування.

Рішення: Якщо затримки високі, перевірте SMART, dmesg/journal на помилки I/O і шаблони навантаження. Розгляньте перенесення шляхів з інтенсивними записами з Btrfs‑root.

П’яте: мережа, але лише після виправдання диска і CPU

cr0x@server:~$ ss -s
Total: 278
TCP:   41 (estab 25, closed 8, orphaned 0, timewait 6)

Transport Total     IP        IPv6
RAW       0         0         0
UDP       7         5         2
TCP       33        22        11
INET      40        27        13
FRAG      0         0         0

Інтерпретація: Дає швидке уявлення про навантаження сокетів; не глибокий аналіз, але корисно для «чи потопаємо в з’єднаннях?»

Рішення: Якщо кількість з’єднань аномальна, дослідіть сервіс і upstream‑балансувальники, потім перевірте помилки NIC і DNS.

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

1) «Після оновлень система не завантажується»

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

Корінна причина: Невідповідність kernel/initramfs, погане оновлення драйвера або помилкова конфігурація монтування, введена під час зміни.

Виправлення: Використайте Snapper rollback (якщо root на Btrfs) для повернення до pre‑update снапшоту; потім повторно застосуйте патчі з підходом канарки.

2) «Диск заповнений, але df показує місце» (випадок Btrfs)

Симптоми: Записи не проходять; сервіси падають; df -h виглядає нормально.

Корінна причина: Виснаження метаданих Btrfs або утримання снапшотів, що споживає алоковане місце.

Виправлення: Перевірте btrfs filesystem usage /, почистіть Snapper‑снапшоти і розгляньте ребаланс. Також встановіть здорові політики очищення снапшотів.

3) «Мережа працює до перезавантаження»

Симптоми: Ручний ip addr add працює; після перезавантаження зникає; інколи Wi‑Fi пропадає.

Корінна причина: Конфліктуючі мережеві менеджери (Wicked і NetworkManager) або конфіг змінено в одному інструменті, але управляється іншим.

Виправлення: Оберіть одного менеджера. На серверах: вимкніть NetworkManager. На ноутбуках: вимкніть Wicked. Тримайте конфіг у відповідному місці.

4) «SSH раптово відмовляє в логіні»

Симптоми: Ключі, що раніше працювали, перестають працювати після харднінгу або оновлень.

Корінна причина: Права/власник на ~/.ssh або authorized_keys занадто відкриті; або домашній каталог користувача на файловій системі з несподіваними опціями монтування.

Виправлення: Виправте права і підтвердіть конфіг sshd. Перевірте за допомогою sshd -T і журналів journal.

5) «AppArmor зламав мій сервіс»

Симптоми: Сервіс стартує, потім падає, з записами про відмови в логах.

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

Виправлення: Переведіть профіль у complain для конкретного сервісу тимчасово, підкорегуйте профіль і потім поверніть enforce. Не відключайте AppArmor глобально.

6) «zypper конфлікти та залежності пекла»

Симптоми: zypper хоче змінити вендора пакетів або видалити півсистеми.

Корінна причина: Занадто багато репозиторіїв, невідповідні пріоритети або змішування Leap з несумісними сторонніми репозиторіями.

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

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

Чеклист інсталяції (30 хвилин, без геройств)

1. Прошивка: UEFI увімкнено, правильний режим диску вибрано, політика Secure Boot вирішена.
2. Ціль інсталяції: свідомо обрано server minimal або workstation desktop.
3. Сховище: ESP ≥ 512 МиБ, root на Btrfs, вирішено розміщення /home і /var/lib.
4. Мережевий менеджер: Wicked для сервера, NetworkManager для ноутбука.
5. Користувачі: створити не‑root адміністратора; план для SSH‑ключів.
6. Час: увімкнути NTP, встановити часовий пояс.
7. Перезавантаження і перевірка: чисте завантаження, репозиторії в порядку, Snapper працює.

Чеклист жорсткості після інсталяції (перший день)

1. Патчі: виконати zypper patch; перезапустити, якщо оновилися ядро/ systemd.
2. SSH: відключити парольну авторизацію; заборонити root; перевірити за допомогою sshd -T.
3. Фаєрвол: дозволити тільки необхідні сервіси; підтвердити зону та активні правила.
4. Моніторинг: принаймні збирати journalctl, SMART‑здоров’я дисків і використання файлової системи.
5. Снапшоти: підтвердити політику ретенції і забезпечити запас вільного місця.
6. Бекапи: впровадити реальні резервні копії; протестувати відновлення.

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

1. Підтвердити, де житимуть дані з інтенсивними записами (надавати перевагу XFS для шляхів з великою змінністю).
2. Переконатися, що є окремі файлові системи/томи для контролю blast‑radius.
3. Перевірити стан дисків за допомогою SMART і переглянути журнали ядра на помилки I/O.
4. Визначити рівень RAID і зону відмови; по можливості протестувати сценарій у деградованому режимі.

Жарт #2: Якщо ви не тестуєте відновлення, ваша система бекапів — це просто дуже дороге місце для зберігання оптимізму.

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

Вибрати Leap 15.6 чи Tumbleweed?

Якщо машина має бути передбачуваною і малообслуговуваною — обирайте Leap. Якщо вам потрібні найновіші ядра, драйвери й developer stack і ви можете терпіти чардж — обирайте Tumbleweed.

Чи безпечно використовувати Btrfs як корінь?

Так, особливо на Leap, де це дефолт і інтегровано зі Snapper. Використовуйте його як сітку безпеки ОС. Для даних з інтенсивними записами розгляньте XFS на окремих томах.

Чи одне й те саме — снапшоти і бекапи?

Ні. Снапшоти — це точка в часі на тому самому диску. Резервні копії мають бути на окремому сховищі (і бажано в іншій домені відмови) і повинні бути протестовані при відновленні.

Кого обрати: Wicked чи NetworkManager?

Сервери: Wicked. Ноутбуки/десктопи з роумінгом Wi‑Fi: NetworkManager. Оберіть один, щоб уникнути конфліктної поведінки.

Яка найнадійніша команда оновлення на Leap?

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

Як відкотитися після поганого оновлення?

Якщо root на Btrfs з Snapper, використайте снапшоти: знайдіть pre‑change снапшот і відкотіться. Якщо Snapper не використовується, ваш відкат — «відновлення з бекапу або перебудова», що повільніше і ризикованіше.

Чи треба відключати AppArmor для контейнерів або веб‑сервісів?

Зазвичай ні. Якщо профіль блокує сервіс, відкоригуйте його або тимчасово переведіть у complain під час діагностики. Глобальне відключення AppArmor — грубий інструмент.

Яка найкраща файлова система для бази даних на Leap?

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

Як утримувати стабільну налаштування репозиторіїв?

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

Який найшвидший спосіб діагностики «сервер повільний»?

Перевірте load і I/O wait, потім затримки диска і SMART, потім тиск пам’яті, і тільки після цього мережу. Більшість «таємничих повільностей» — через зберігання або один неправильно працюючий сервіс.

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

Якщо хочете інсталяцію Linux, яку можна зберігати роками, будуйте її так, ніби вам доведеться пояснити це пізніше — бо так і буде. Використовуйте сильні сторони Leap 15.6: YaST для читабельності, Btrfs‑снапшоти для відкатів, zypper‑патчі для контрольованих змін і AppArmor для прагматичного загартування.

Наступні кроки, що негайно окупляться:

1. Пройдіть перелік пост‑інсталяційних завдань вище і виправте сюрпризи, поки система ще «нова».
2. Визначте, де житимуть шляхи з інтенсивними записами, і при потребі перемістіть їх з файлової системи ОС.
3. Встановіть ритм патчування і виконайте перший перезавантаження за вашим графіком, а не під час інциденту.
4. Реалізуйте реальні бекапи і проведіть тест відновлення цього тижня. Не пізніше.
5. Запишіть список репозиторіїв, схему зберігання і вибір мережевого менеджера в одній операційній нотатці, яку ви зможете знайти за рік.

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