LFCS: Практика роботи з системами та мережами

Напрямок LFCS | Складність: [СКЛАДНИЙ] | Час: 45–60 хв | Цільова версія Kubernetes: 1.35+. Цей практичний модуль зосереджено на операціях із Linux-хостом, які водночас підтримують надійне адміністрування вузлів Kubernetes.

Час на читання: 45–60 хвилин, залежно від того, чи ви лише читаєте розділ, чи також виконуєте вправи в одноразовому лабораторному середовищі.

Передумови

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

Обов’язково: LFCS: Стратегія та робочий процес іспиту
Обов’язково: LFCS: Практика основних команд
Корисно: Модуль 1.2: Процеси та systemd
Корисно: Модуль 3.1: Основи TCP/IP
Корисно: Модуль 3.2: DNS у Linux
Корисно: Модуль 3.4: iptables та netfilter

Результати навчання

Після цього модуля ви зможете виконувати такі екзаменаційні завдання на основі доказів, а не здогадок:

діагностувати збої служб systemd за станом процесу, статусом юніта та свідченнями журналу
оцінювати цілі завантаження, режими відновлення та дії вимкнення, не ускладнюючи подальше відновлення
налаштовувати заплановані завдання cron і at із перевіркою, контролем доступу та прибиранням
порівнювати тимчасові виправлення маршрутизації з постійною конфігурацією Netplan чи NetworkManager
переглядати, завантажувати, вивантажувати, закріплювати та вносити до чорного списку модулі ядра з чіткими операційними свідченнями

Чому цей модуль важливий

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

Цей модуль тренує саме такий ланцюг доказів. Робота із системою, що вже працює, в LFCS — це не про запам’ятовування кожного можливого демона; це про використання того самого невеликого набору інструментів огляду Linux у дисциплінованому порядку. Ви потренуєтеся читати systemctl status, не сприймаючи перший червоний рядок як остаточну відповідь, використовувати journalctl, щоб відрізнити збій служби від збою залежності, планувати завдання так, щоб це можна було довести, і вирішувати, чи має зміна маршруту чи модуля пережити перезавантаження. Ті самі звички також безпосередньо переносяться на операції з Kubernetes, де зламана служба вузла, вимкнена залежність середовища виконання чи неправильний маршрут хоста можуть зробити симптоми кластера значно масштабнішими, ніж вони є насправді.

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

Цей розділ охоплює доступність клієнта SSH; посилення сервера через sshd_config (PermitRootLogin, ключі хоста) відпрацьовується в повному пробному іспиті (модуль 1.5) та в напрямку Linux.

Діагностика збоїв служб systemd на основі доказів

Діагностика системи, що працює, починається з простого розрізнення: процес — це програма, що виконується, тоді як юніт systemd — це запис менеджера про те, як цю програму слід запускати, зупиняти, перезапускати та поєднувати із залежностями. Завдання LFCS часто розмивають ці два рівні. Демон може працювати, навіть коли юніт вимкнено для завантаження; юніт може бути ввімкнено, навіть коли процес наразі мертвий; а процес може бути живим, але прив’язаним до неправильного порту. Якщо ви сприймаєте список процесів як істину, ви проґавите збереження. Якщо ви сприймаєте systemctl status як єдину істину, ви можете проґавити сторонній процес, який володіє сокетом.

Перший прохід навмисно невеликий. Знайдіть процес, визначте його командний рядок, вирішіть, чи достатньо він здоровий, щоб його лишити, і лише тоді дійте. kill -TERM просить процес завершитися коректно, що дає йому шанс скинути дані у файли та звільнити блокування. kill -KILL — це крайній засіб, бо ядро завершує процес негайно. nice і renice не виправляють збійну службу, але вони важливі в екзаменаційних сценаріях, де фонове завдання споживає CPU й створює враження, що машина зламана, тоді як основні служби технічно справні.

ps aux | grep nginx   # also matches the grep process itself; pgrep is cleaner
top
pgrep -a ssh
kill -TERM <pid>
kill -KILL <pid>
nice -n 10 long-job
renice 5 -p <pid>

Маючи докази про процес, переходьте до юніта. systemctl status корисний тим, що поєднує в одному поданні активний стан, нещодавні журнали, головний PID, завантажений файл юніта та підказки про ввімкнений стан. Не зупиняйтеся на слові failed; прочитайте рядок про те, чи коректно завантажився файл юніта, код виходу та останні записи журналу. Команди керування нижче навмисно звичайні, бо саме звичайні команди потрібні вам під тиском часу. Запуск і перезапуск перевіряють поточну поведінку, тоді як ввімкнення та вимкнення перевіряють поведінку під час завантаження.

systemctl status ssh
systemctl start nginx
systemctl stop nginx
systemctl enable nginx
systemctl disable nginx
systemctl restart nginx
systemctl list-units --type=service
systemctl get-default
systemctl set-default multi-user.target

Журнали — це докази, що тримають розслідування чесним. journalctl -u nginx звужує журнал до конкретного юніта, що зазвичай краще, ніж шукати знайоме слово по всьому завантаженню. journalctl -xe може виявити помилки залежностей, проблеми з правами та повідомлення політик поблизу поточного збою, але може також показати сторонній шум, якщо ви не прив’яжете його до юніта чи завантаження. journalctl -b -1 особливо цінний після перезавантаження, бо дає змогу оглянути попереднє завантаження замість того, щоб удавати, ніби поточний стан містить усю історію.

journalctl -u nginx
journalctl -xe
journalctl -b
journalctl -b -1
systemctl --failed
systemctl isolate rescue.target
shutdown -r +5 "LFCS practice reboot"
shutdown -c

Зупиніться й передбачте: якщо systemctl status nginx каже, що юніт зазнав збою, але ss -tlnp показує, що інший процес уже слухає на порту 80, чи варто спершу редагувати конфігурацію Nginx, чи спершу визначити того, хто слухає? Краща відповідь — визначити того, хто слухає, бо служба може бути налаштована правильно, але не здатна зайняти порт. Редагування конфігурації без доведення конфлікту сокета може перетворити одну несправність на дві, а дві несправності значно важче розплутати під час іспиту з обмеженим часом.

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

процес
юніт
журнал
конфігурація
мережа
збереження

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

Створення файлів юнітів з нуля ([Unit]/[Service]/ExecStart, daemon-reload) відпрацьовується в Linux: Процеси та systemd.

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

Та сама звичка захищає вас від надмірного припасування до знайомих служб. Можливо, ви тренувалися із SSH чи Nginx, але LFCS може запитати про будь-яку службу, встановлену в середовищі. Імена юнітів, шляхи до конфігурацій і порти можуть змінюватися, проте діагностична форма лишається стабільною. Визначте процес, прочитайте юніт, огляньте журнал юніта, перевірте задуману конфігурацію, доведіть мережевий шлях і перевіряйте збереження лише тоді, коли цього вимагає завдання. Такий підхід масштабується, бо спирається на інтерфейси Linux, а не на фольклор, специфічний для конкретної служби.

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

Практична вправа зі службами

Вправу 1, «Порятунок збійної служби», варто виконувати на одноразовій віртуальній машині чи лабораторному вузлі. Імітуйте зламану службу, зупинивши її, змінивши конфігурацію так, щоб запуск став неможливим, а потім використавши systemctl status разом із journalctl, щоб знайти збій, перш ніж редагувати знову. Навчальна мета — не конкретний демон. Мета — це звичка читати стан служби, використовувати журнали як докази та робити найменше виправлення, що відновлює очікуваний стан.

Повторюючи вправу, варіюйте несправність. Зробіть одну помилку синтаксичною, одну — відсутнім каталогом, одну — проблемою прав, а одну — конфліктом порту. Команди майже не змінюються, але змінюється ваша інтерпретація. У цьому й суть: LFCS перевіряє, чи можете ви міркувати на основі доказів, а не чи запам’ятали ви кожен можливий рядок помилки. Перш ніж виконувати перезапуск, запитайте себе, який вивід ви очікуєте від systemctl status і які докази порту чи процесу доведуть ремонт.

Оцінювання цілей завантаження, журналів і стану відновлення

Цілі завантаження описують режим роботи, якого намагається досягти systemd. Вони замінюють стару звичку мислити лише в категоріях рівнів виконання SysV, але відповідність усе ще має значення, бо екзаменаційні матеріали та старіша документація можуть згадувати обидва. Важливе розрізнення — поточний стан під час виконання проти значення за замовчуванням під час завантаження. systemctl isolate rescue.target змінює поточний стан системи зараз. systemctl set-default multi-user.target змінює те, що машина намагатиметься зробити під час майбутніх завантажень. Плутати ці речі — надійний спосіб перетворити тимчасовий крок відновлення на постійну проблему.

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

Ціль	Старий рівень виконання	Призначення
`poweroff.target`	0	Зупинка системи
`rescue.target`	1	Однокористувацький режим, мінімум служб
`multi-user.target`	3	Повний багатокористувацький режим, без GUI
`graphical.target`	5	Багатокористувацький режим із менеджером дисплея
`reboot.target`	6	Перезавантаження
`emergency.target`	—	Мінімальна root-оболонка, без служб

rescue.target і emergency.target достатньо схожі, щоб збивати людей з пантелику, і достатньо різні, щоб це мало значення. Режим порятунку монтує локальні файлові системи та запускає мінімальний набір служб, щоб ви могли ремонтувати користувачів, пакети, журнали та конфігурацію з певною підтримкою системи. Аварійний режим дає вам значно меншу root-оболонку, часто до того, як стане доступним звичайний граф залежностей, що робить його корисним, коли сам режим порятунку залежить від зламаного стану. Обирайте найменш суворий режим, який дає потрібний вам доступ, бо кожен крок донизу прибирає зручності, які можуть знадобитися для діагностики.

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

# Runtime — switch now without changing default
systemctl isolate rescue.target

# Persistent — change what boots next time
systemctl set-default multi-user.target
systemctl get-default

# GRUB override — append to kernel command line during boot:
# systemd.unit=rescue.target

Контроль над вимкненням — це частина дисципліни відновлення, а не запізніла думка. Планування перезавантаження з повідомленням дає під’єднаним користувачам і вам у майбутньому чіткий сигнал, тоді як shutdown -c дає змогу скасувати, коли ви усвідомлюєте, що перезавантаження непотрібне. В екзаменаційному середовищі це важливо, бо годинник цокає, а перезавантаження може приховати рядок журналу, який вам був потрібен. У виробничих середовищах та сама звичка запобігає уникненним перебоям, коли проблему можна було розв’язати перезапуском служби чи ізоляцією цілі.

Вправа 2, «Перебудова цілі завантаження», починається із запису поточної цілі за замовчуванням командою systemctl get-default. Потім встановіть multi-user.target як замовчування, підтвердьте це, ізолюйтеся в rescue.target лише на одноразовій ВМ, перемкніть замовчування назад до вихідного значення та огляньте журнали попереднього завантаження командою journalctl -b -1. Це тренує вільне володіння цілями завантаження й відновлення без сліпого перезавантаження. Це також змушує вас відрізняти перехід під час виконання від постійного замовчування, що є саме тим розрізненням, яке багато кандидатів втрачають під тиском.

Вправа 7, «Дисципліна вимкнення та відновлення», розвиває ту саму ідею. Огляньте ціль за замовчуванням, перемкніться на multi-user.target, ізолюйтеся в rescue.target в одноразовому практичному середовищі, заплануйте перезавантаження, скасуйте перезавантаження та огляньте як поточні, так і попередні журнали завантаження. Сприймайте кожну дію як перехід стану, що потребує перевірки. Якщо ви можете описати стан до, команду, стан після та відкат, ви працюєте як оператор, а не як збирач команд.

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

Реалізація запланованих завдань cron і at

Планування завдань оманливо просте, бо синтаксис команд короткий, але операційний ризик сидить навколо нього. Запис cron може виконатися від імені неправильного користувача, писати в шлях, який існує лише у вашій оболонці входу, залежати від змінних середовища, яких cron ніколи не отримує, або продовжувати працювати після завершення тесту, бо ви забули про прибирання. Завдання at може бути коректно поставлене в чергу й усе одно зазнати збою пізніше, бо команду неправильно взято в лапки або контроль доступу забороняє користувачеві. Тому перевірка — це частина завдання, а не необов’язковий крок прибирання.

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

П’ять полів cron легше запам’ятати, якщо читати їх від малих до великих одиниць часу. Першою йде хвилина, потім година, день місяця, місяць і день тижня. День тижня на багатьох системах приймає і 0, і 7 для неділі, але вам варто уникати хитромудрих виразів на іспиті, якщо завдання цього не вимагає. Простий розклад, який ви можете пояснити, кращий за компактний вираз, який ви не можете швидко перевірити.

┌───────────── minute (0-59)
│ ┌───────────── hour (0-23)
│ │ ┌───────────── day of month (1-31)
│ │ │ ┌───────────── month (1-12)
│ │ │ │ ┌───────────── day of week (0-7, 0 and 7 = Sunday)
│ │ │ │ │
* * * * *  command

Ці поширені шаблони покривають більшість практичних завдань. Зверніть увагу, що шлях до команди є абсолютним у кожному прикладі. Cron не виконується всередині вашої інтерактивної оболонки, тож припущення про власний PATH є поширеним джерелом тихих збоїв. Якщо скрипту потрібні змінні середовища, помістіть їх у crontab або в сам скрипт, де ви можете їх оглянути. Якщо завдання пише вивід, перенаправте його у файл, який ви можете перевірити; інакше у вас може не бути швидких доказів того, що воно запустилося.

# every 15 minutes
*/15 * * * * /usr/local/bin/healthcheck.sh

# daily at 2:30 AM
30 2 * * * /usr/local/bin/backup.sh

# every Monday at 6 AM
0 6 * * 1 /usr/local/bin/weekly-report.sh

# first of every month at midnight
0 0 1 * * /usr/local/bin/monthly-rotate.sh

Користувацькі crontab і загальносистемні каталоги cron розв’язують різні проблеми. crontab -e редагує заплановані завдання поточного користувача, тоді як sudo crontab -u alice -e редагує завдання іншого користувача. Файли в /etc/cron.d/ — це вставки зі своїм власним форматом, а скрипти в /etc/cron.daily/, /etc/cron.hourly/ та подібних каталогах керуються налаштуванням періодичного планування системи. Для LFCS знайте, як оглянути кожне місце, перш ніж припускати, що завдання відсутнє. Дубльоване завдання в неправильному місці може виглядати як помилка демона, хоча насправді це помилка планування.

crontab -e                  # edit current user's crontab
crontab -l                  # list current user's crontab
crontab -r                  # remove current user's crontab
sudo crontab -u alice -e    # edit another user's crontab
sudo crontab -u alice -l    # list another user's crontab

ls /etc/cron.d/             # drop-in cron files
ls /etc/cron.daily/         # scripts that run daily
ls /etc/cron.hourly/        # scripts that run hourly
ls /etc/cron.weekly/        # scripts that run weekly

at — це інструмент для одноразового планування. Він корисний для відкладеного прибирання, вікон обслуговування та екзаменаційних завдань, що вимагають виконати команду один раз, а не назавжди. Робочий процес — поставити в чергу, переглянути список, оглянути та за потреби вилучити. at -c особливо корисний, бо показує згенероване завдання, включно зі середовищем, захопленим у момент його подання. Цей крок огляду ловить помилки з лапками, перш ніж ви чекатимете на збій завдання.

echo "/usr/local/bin/cleanup.sh" | at now + 30 minutes
echo "/usr/local/bin/migrate.sh" | at 02:00 tomorrow
atq                         # list pending at jobs
atrm 3                      # remove job number 3
at -c 3                     # show job 3 contents

Файли контролю доступу можуть змінити відповідь, навіть коли ваш синтаксис бездоганний. Якщо /etc/at.allow існує, лише перелічені користувачі можуть використовувати at; якщо його не існує, /etc/at.deny блокує перелічених користувачів. Cron має схожі файли дозволу та заборони. Не запам’ятовуйте це як примітку. У завданні з усунення несправностей заблокований користувач може бачити збій планування, який виглядає не пов’язаним із командою, що планується.

cat /etc/at.allow           # if this exists, only listed users can use at
cat /etc/at.deny            # if allow doesn't exist, deny blocks listed users
cat /etc/cron.allow
cat /etc/cron.deny

Зупиніться й передбачте: якщо завдання cron працює, коли ви вставляєте команду у свою оболонку, але ніколи не пише свій вивід із cron, яка ваша перша гіпотеза? Найсильніша перша гіпотеза — середовище чи шлях, а не зламаний демон cron. Перевірте запис crontab, використовуйте абсолютні шляхи, перенаправте вивід і помилки та підтвердьте, який користувач володіє завданням, перш ніж перезапускати служби. Перезапуск cron може бути доречним пізніше, але рідко є першим корисним доказом.

Вправа 3, «Планування роботи», має використовувати і cron, і at із повною перевіркою. Для cron виконайте crontab -l, додайте завдання, що дописує heartbeat до /tmp/cron-test.log кожні п’ять хвилин, перевірте запис, дочекайтеся одного запуску, огляньте файл, вилучіть завдання та підтвердьте вилучення. Для at поставте в чергу одноразову команду, що пише /tmp/at-test.log, перегляньте її список командою atq, огляньте її командою at -c, перевірте файл після виконання та вилучіть його. Для контролю доступу огляньте файли дозволу та заборони, протестуйте з одноразовим користувачем, якщо ваша лабораторія це дозволяє, і відновіть файли точно.

Зверніть увагу, що перевірка навмисно зовнішня щодо планувальника. Перегляд списку crontab доводить, що запис існує, але не доводить, що команда запустилася. Бачення завдання at у черзі доводить подання, але не доводить, що майбутня команда створить задуманий файл. Перенаправлення виводу в /tmp у лабораторії дає вам конкретний артефакт для огляду, а вилучення цього артефакту згодом доводить прибирання. Це та сама модель доказів, що використовується для служб і маршрутів: конфігурація не є поведінкою, доки система не виконає поведінку, а ви її не спостерігаєте.

Порівняння тимчасової маршрутизації, постійної мережі та модулів ядра

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

Таблиця маршрутів — це план пересилання ядра, а не просто перелік намірів адміністратора. ip route show каже вам встановлені маршрути, тоді як ip route get запитує, який маршрут ядро обрало б для конкретного призначення. Ця різниця корисна, коли кілька маршрутів перекриваються. Може існувати широкий маршрут за замовчуванням, але конкретніший маршрут усе одно може спрямувати лабораторну мережу через інший шлюз. Якщо обраний маршрут неправильний, виправлення DNS не допоможе, бо пакети вже йдуть неправильним шляхом, перш ніж ім’я матиме значення.

ip addr
ip route
ip route add 10.20.30.0/24 via 192.168.1.1
ip route del 10.20.30.0/24 via 192.168.1.1
ss -tulpen
ping -c 3 8.8.8.8
getent hosts example.com
nmcli device status
systemctl is-enabled NetworkManager

Використовуйте вивід як послідовність запитань. Чи має інтерфейс адресу, на яку ви очікували? Чи обирає таблиця маршрутів шлюз, на який ви очікували? Чи може хост досягти IP-адреси без DNS? Чи розв’язує getent hosts ім’я через налаштований у системі шлях розв’язання імен? Файли розв’язання імен (/etc/resolv.conf) та resolvectl розглядаються в Модулі 3.2: DNS у Linux; цей модуль лишається на рівні перевірок імен через getent hosts. Чи справді служба слухає на порту, який ви очікуєте, і чи ввімкнена вона для завантаження, якщо завдання вимагає збереження? Ці запитання не дають збоям маршруту, DNS, брандмауера та служби злитися в нечітке твердження на кшталт «мережа зламана».

Досяжність служби має і локальний, і віддалений бік. Локально ss може довести, що демон слухає на адресі та порту, але не може довести, що віддалений клієнт зможе пройти шлях. Віддалено збій з’єднання може відображати маршрутизацію, політику брандмауера, прив’язку служби чи автентифікацію. Тримайте ці рівні окремо. Якщо служба слухає лише на 127.0.0.1, віддалений клієнт не може її досягти, навіть якщо локальний сокет виглядає здоровим. Якщо служба слухає на очікуваній адресі, але віддалений трафік не проходить, наступне запитання — шлях між клієнтом і сервером.

Тимчасові маршрути потрібні для доведення шляху. Постійні маршрути потрібні, щоб доведений шлях пережив перезавантаження. Це розрізнення — одна з найцінніших екзаменаційних звичок у цьому модулі. Додайте тимчасовий маршрут командою ip route, перевірте вибір маршруту командою ip route get і чисто вилучіть його після завершення тесту. Лише після того, як маршрут доведе задуману поведінку, варто перекласти його в конфігурацію Netplan чи NetworkManager. Крок перекладу — це не діагностика; це збереження.

# Add a route
sudo ip route add 10.20.30.0/24 via 192.168.1.1

# Add a default gateway
sudo ip route add default via 192.168.1.1

# Verify
ip route show
ip route get 10.20.30.5

# Remove
sudo ip route del 10.20.30.0/24 via 192.168.1.1

Netplan поширений у системах Ubuntu 22.04, а NetworkManager поширений у настільних чи універсальних інсталяціях. Навичка LFCS — це не вірність одному інструменту; це розпізнавання того, що керує поточним інтерфейсом, і внесення постійної зміни в правильному місці. Якщо інтерфейсом володіє Netplan, напишіть коректний YAML і застосуйте його. Якщо профілем володіє NetworkManager, змініть активний профіль з’єднання та підніміть його. У будь-якому разі перевірте таблицю маршрутів згодом, замість того щоб довіряти файлу конфігурації.

Будьте обережні з іменами інтерфейсів у прикладах збереження. Зразок на кшталт ens33 вчить форми YAML, а не універсального імені інтерфейсу. Ваша лабораторія може використовувати ens160, enp0s3, eth0 чи інше передбачуване ім’я. Завжди читайте фактичний інтерфейс із ip addr або з активного профілю з’єднання, перш ніж писати збереження. Коректний файл YAML із неправильним іменем інтерфейсу може застосуватися чисто й усе одно не змінити маршрут, який вас цікавить. Це одна з причин, чому доведення під час виконання передує збереженню.

network:
  version: 2
  ethernets:
    ens33:
      routes:
        - to: 10.20.30.0/24
          via: 192.168.1.1

sudo netplan apply
ip route show | grep 10.20.30

sudo nmcli connection modify "Wired connection 1" +ipv4.routes "10.20.30.0/24 192.168.1.1"
sudo nmcli connection up "Wired connection 1"

Мережеві служби додають друге запитання про збереження. Служба може слухати зараз, але бути вимкненою для наступного завантаження, або ввімкненою для завантаження, але наразі збійною. Перевірте обидва. Наприклад, для SSH systemctl is-enabled ssh відповідає на запитання про завантаження, тоді як ss -tlnp | grep :22 відповідає на запитання про сокет під час виконання. Правильна відповідь на екзаменаційне завдання зазвичай потребує обох доказів, коли формулювання каже, що служба має бути доступною після перезавантаження.

# Check what manages networking
systemctl is-active NetworkManager
systemctl is-active systemd-networkd

# Ensure the right service is enabled at boot
systemctl is-enabled NetworkManager
sudo systemctl enable NetworkManager

# Check a specific network-facing service
systemctl is-enabled ssh
sudo systemctl enable --now ssh
ss -tlnp | grep :22

# After enabling, confirm the symlink exists
ls -l /etc/systemd/system/multi-user.target.wants/ | grep ssh

# Or use:
systemctl list-unit-files --type=service --state=enabled | grep ssh

Модулі ядра — це ще одне місце, де виконання та збереження розходяться. lsmod показує те, що завантажено зараз, modinfo пояснює, що таке модуль і які параметри він приймає, а modprobe завантажує чи вивантажує за іменем, розв’язуючи залежності. Для екзаменаційної роботи віддавайте перевагу modprobe над insmod, бо insmod завантажує шлях до файлу безпосередньо й не розв’язує залежностей. Безпечний робочий процес — оглянути, завантажити, перевірити, використати, вивантажити за потреби й лише тоді вирішити, чи є збереження або внесення до чорного списку частиною завдання.

Модулі також змушують вас думати про докази з точки зору ядра. Файл конфігурації може запитати завантаження, але lsmod показує, чи модуль справді резидентний зараз. Файл чорного списку може запобігти автоматичному завантаженню, але вручну завантажений модуль усе одно може фігурувати, доки його не вилучать. Параметр у командному рядку може виглядати правильним, але /sys/module — сильніше місце, щоб підтвердити активне значення, коли модуль його розкриває. Сприймайте кожне завдання про модуль як два запитання: що налаштовано і що ядро робить наразі?

lsmod                           # list all loaded modules
lsmod | grep '^dummy'           # check if a specific module is loaded
modinfo dummy                   # show module description, parameters, dependencies
sudo modprobe dummy             # load module (resolves dependencies automatically)
sudo modprobe -r dummy          # unload module

Постійне завантаження модулів використовує /etc/modules-load.d/, тоді як внесення до чорного списку використовує /etc/modprobe.d/. Вони розв’язують протилежні проблеми, тож не плутайте їх. Завантаження під час кожного завантаження корисне для потрібного драйвера чи модуля віртуального інтерфейсу. Внесення до чорного списку запобігає автоматичному завантаженню, коли модуль спричиняє небажану поведінку чи конфліктує із задуманим драйвером. В обох випадках файл — це лише частина відповіді; вам усе одно потрібні докази під час виконання з lsmod, modinfo чи /sys/module.

# Load at every boot — add a file in /etc/modules-load.d/
echo "dummy" | sudo tee /etc/modules-load.d/dummy.conf

# Verify the file is in place
cat /etc/modules-load.d/dummy.conf

# Prevent a module from loading automatically
echo "blacklist pcspkr" | sudo tee /etc/modprobe.d/blacklist-pcspkr.conf

# Verify
grep pcspkr /etc/modprobe.d/*.conf

Параметри модуля варто перевірити, перш ніж вгадувати. modinfo -p показує доступні параметри, коли модуль їх розкриває, а /sys/module/<name>/parameters/ може показати активне значення після завантаження. Не кожен модуль розкриває параметри, і не кожен параметр можна змінити після завантаження. Операційна відповідь — оглянути, що модуль справді підтримує, завантажувати з потрібним параметром лише тоді, коли це доречно, і перевірити підсумковий стан з точки зору ядра.

# Show available parameters
modinfo -p dummy

# Load with a parameter
sudo modprobe dummy numdummies=2

# Check current parameter value (if module exposes it)
cat /sys/module/dummy/parameters/numdummies 2>/dev/null

Вправу 4, «Сортування мережі», варто виконувати як драбину: перевірте стан з’єднання, перевірте призначення IP-адреси, огляньте таблицю маршрутів, протестуйте розв’язання DNS і перевірте досяжність служби на очікуваному порту. Вправа 5, «Статичні маршрути та мережеві служби під час завантаження», додає маршрут до 10.99.0.0/16 через шлюз за замовчуванням, перевіряє вибір маршруту, вилучає його, а потім повторює ту саму ідею постійно через Netplan чи NetworkManager. Вправа 6, «Практика з модулями ядра», використовує безпечний модуль на кшталт dummy, коли він доступний, оглядає його за допомогою modinfo, завантажує його за допомогою modprobe, підтверджує його за допомогою lsmod, вилучає його та пояснює, як працювало б збереження, якби воно було потрібне.

SSH та віддалений доступ

SSH — це міст між локальним відновленням і віддаленим адмініструванням. LFCS може включати завдання, де ви під’єднуєтеся до іншого хоста, копіюєте файл чи доводите, що віддалена служба досяжна. Базові команди невеликі, але докази важливі: ssh -v може показати поступ автентифікації та ключів хоста, scp доводить передавання файлу, а серверні перевірки через systemctl плюс ss доводять, що служба доступна. Сприймайте віддалений доступ як ще одну службу з вимірами виконання, мережі та збереження.

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

ssh user@server
scp file.txt user@server:/tmp/
ssh -v user@server

Патерни та антипатерни

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

Ці патерни навмисно повторювані, бо відновлення Linux винагороджує нудну послідовність. Виправлення служби, виправлення маршруту, виправлення cron і виправлення модуля мають різні поверхні команд, але операційна граматика та сама. Прочитайте поточний стан, зробіть найменшу корисну зміну, спостерігайте за зміненою поведінкою та залежно від завдання або закріпіть, або приберіть. Якщо ви практикуєте цю граматику в непов’язаних підсистемах, ви витрачаєте менше екзаменаційного часу на рішення про те, з чого почати. Хороший початок — велика перевага, бо більшість провалів через час починається з нефокусованої першої хвилини.

Патерн	Коли його застосовувати	Чому він працює	Міркування щодо масштабування
Драбина доказів	Будь-який нечіткий симптом служби чи мережі	Вона звужує несправність, не створюючи зайвих змін	Навчіть тій самій драбині колег, щоб нотатки про інциденти лишалися порівнянними
Виконання перед збереженням	Маршрути, служби, модулі та цілі завантаження	Вона доводить поведінку, перш ніж кодувати її для перезавантаження	Автоматизація має фіксувати і тест, і сталу конфігурацію
Перевір і прибери	Cron, at, тимчасові маршрути, тестові користувачі, модулі	Вона запобігає перетворенню практичних артефактів на майбутні несправності	Спільним лабораторіям потрібні контрольні списки прибирання, бо залишковий стан вводить в оману наступного учня

Антипатерни зазвичай походять із нетерплячості, а не з незнання. Повторний перезапуск служби без читання журналів здається активним, але він руйнує час і може приховати першу корисну помилку. Редагування Netplan до доведення тимчасового маршруту здається ретельним, але ризикує зламати ваш сеанс постійною помилкою. Завантаження модуля ядра до читання modinfo здається нешкідливим, доки в модуля немає параметрів, залежностей чи побічних ефектів, про які вам слід було знати першими.

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

Антипатерн	Що йде не так	Краща альтернатива
Цикл перезапусків	Той самий збій повторюється, тоді як корисні докази ігноруються	Прочитайте статус юніта та вивід журналу, потім перезапустіть один раз після цільового виправлення
Мережа «спершу постійне»	Поганий маршрут чи помилка YAML переживає перезавантаження	Спершу доведіть командою `ip route`, потім закріпіть через активний менеджер
Прибирання по пам’яті	Тестові завдання, маршрути, користувачі чи файли модулів лишаються позаду	Впишіть прибирання в план вправи та перевірте підсумковий стан

Каркас прийняття рішень

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

Симптом або вимога	Перші докази	Наступна дія	Перевірка збереження
Служба не працює	`systemctl status`, `journalctl -u`, `pgrep -a`	Виправте причину з журналу, потім перезапустіть один раз	`systemctl is-enabled`, ввімкнений файл юніта, сокет, що слухає
Неправильний режим завантаження	`systemctl get-default`, поточна ціль	Ізолюйте лише за потреби, встановлюйте замовчування лише за вимогою	Перевірте знову замовчування та журнали попереднього завантаження
Запланована команда відсутня	`crontab -l`, `/etc/cron.*`, `atq`	Додайте чи відремонтуйте завдання з абсолютними шляхами	Підтвердьте вивід, вміст черги та прибирання
Хост не досягає мережі	`ip addr`, `ip route`, `getent hosts`, `ss`	Протестуйте стан маршруту чи служби перед редагуванням конфігурації	Netplan, NetworkManager чи ввімкнений стан служби
Потрібна здатність модуля	`modinfo`, `lsmod`, `/sys/module`	Завантажте через `modprobe`, перевірте, потім вивантажте, якщо тимчасово	`/etc/modules-load.d/` чи `/etc/modprobe.d/`

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

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

Використовуйте ту саму звичку прийняття рішень для роботи з хостом, суміжної з Kubernetes. Проблему kubelet можуть повідомити як проблему готовності вузла, але корінною причиною все одно може бути вимкнена служба, відсутній маршрут, підказка з переповненого журналу чи стан модуля ядра. Іспит LFCS — це не іспит з усунення несправностей Kubernetes, проте навички роботи з Linux-хостом безпосередньо повторно використовуються, коли компоненти кластера залежать від мережі хоста, нагляду за процесами та збереження завантаження. Саме тому модуль постійно повертається до доказів. Kubernetes додає оркестрацію, але вузол усе одно підкоряється Linux.

Чи знали ви?

systemd став системою ініціалізації за замовчуванням у кількох великих дистрибутивах Linux протягом 2010-х років, ось чому LFCS очікує вільного володіння цілями та юнітами, а не лише запам’ятовування рівнів виконання SysV.
Cron використовує п’ять полів часу перед командою в користувацьких crontab, а значення дня тижня зазвичай приймають і 0, і 7 як неділю, що може здивувати учнів, які очікують єдиного значення.
modprobe читає інформацію про залежності модуля та конфігурацію, тоді як insmod завантажує конкретний файл модуля безпосередньо, тож modprobe є практичним замовчуванням для операцій з урахуванням залежностей.
ip route get <destination> не надсилає трафік до призначення; він запитує ядро, який маршрут воно обрало б, що робить його швидкою та малоризиковою перевіркою вибору маршруту.

Типові помилки

Помилка	Чому вона виникає	Як її виправити
Повторний перезапуск збійної служби	Червоний стан `failed` відчувається як проблема замість симптому	Спершу прочитайте `systemctl status` і `journalctl -u`, виправте причину з журналу, потім перезапустіть один раз
Сприйняття «ввімкнено» як «працює»	Збереження завантаження та поточний стан процесу — це різні рівні	Перевіряйте і `systemctl is-enabled`, і `systemctl status`, потім за потреби перевірте сокет, що слухає
Редагування постійних файлів мережі перед тестом під час виконання	Постійні інструменти відчуваються офіційнішими за тимчасові команди маршруту	Доведіть маршрут командами `ip route add` та `ip route get`, потім закодуйте сталу версію
Забуття про відмінності середовища cron	Команда спрацювала в інтерактивній оболонці, тож звинувачують розклад	Використовуйте абсолютні шляхи, перенаправте вивід і огляньте завдання під правильним користувачем
Плутанина `rescue.target` та `emergency.target`	Обидва відчуваються як однокористувацькі режими відновлення	Використовуйте rescue для мінімуму служб, а emergency для найменшого шляху відновлення через root-оболонку
Завантаження модулів без читання метаданих	Ім’я модуля виглядає знайомим, тож параметри та залежності ігнорують	Виконайте `modinfo`, завантажте через `modprobe` та перевірте через `lsmod` чи `/sys/module`
Залишання практичних артефактів	Ремонт удався, тож прибирання відчувається необов’язковим	Вилучіть тестові маршрути, заплановані завдання, файли модулів і тимчасові журнали, потім перевірте чистий стан

Тест

Питання 1: Вебслужба ввімкнена, але після завантаження вона не слухає на порту 80. Які докази ви збираєте перед редагуванням конфігурації?

Почніть із systemctl status для юніта, потім огляньте journalctl -u для того самого юніта та використайте ss -tlnp, щоб побачити, чи інший процес володіє портом. Стан «ввімкнено» доводить лише спробу завантаження, а не здоровий процес чи сокет. Якщо журнал показує помилку прив’язки, а ss показує іншого слухача, правильний ремонт — розв’язати конфлікт слухача, а не переписувати непов’язану конфігурацію служби. Це питання оцінює результат — діагностувати збої служб systemd за станом процесу, статусом юніта та свідченнями журналу.

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

Використайте systemctl isolate rescue.target в одноразовому середовищі відновлення й уникайте зміни цілі за замовчуванням, якщо завдання явно не вимагає постійної зміни режиму завантаження. isolate змінює поточну транзакцію, тоді як set-default змінює майбутні завантаження. Якщо ви встановите замовчування під час тимчасового завдання відновлення, ви створите другу проблему, що з’явиться після перезавантаження. Це перевіряє, чи можете ви оцінювати цілі завантаження, режими відновлення та дії вимкнення, не ускладнюючи відновлення.

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

Огляньте точний запис crontab, користувача, який ним володіє, абсолютні шляхи до команд і перенаправлення виводу, перш ніж перезапускати cron. Cron не успадковує вашого інтерактивного середовища оболонки, тож PATH, робочий каталог і змінні — поширені відмінності. Корисне виправлення — використовувати повні шляхи та перенаправляти і стандартний вивід, і помилки у файл, який ви можете перевірити. Це перевіряє вміння налаштовувати заплановані завдання cron і at із перевіркою та прибиранням.

Питання 4: Ви додаєте тимчасовий маршрут, і зв'язок починає працювати. Завдання каже, що маршрут має пережити перезавантаження. Який наступний правильний крок?

Визначте активний менеджер мережі, потім закодуйте доведений маршрут через Netplan чи NetworkManager за потреби та перевірте таблицю маршрутів після застосування зміни. Тимчасовий маршрут доводить гіпотезу, але зникає під час перезавантаження. Постійна конфігурація — це сталий результат, проте вона має ґрунтуватися на маршруті, що вже працював під час виконання. Це перевіряє результат — порівнювати тимчасові виправлення маршрутизації з постійною конфігурацією Netplan чи NetworkManager.

Питання 5: `modprobe dummy` спрацьовує, але перезавантаження має завантажувати той самий модуль автоматично. Які докази та розташування файлу мають значення?

Перевірте, що модуль завантажено зараз, командою lsmod чи через /sys/module, огляньте його командою modinfo, потім додайте ім’я модуля у файл під /etc/modules-load.d/. Завантаження під час виконання та завантаження під час старту — окремі стани, тож самого modprobe недостатньо для вимоги збереження. Після запису файлу огляньте його та будьте готові вилучити його під час прибирання, якщо це було лише практичним завданням. Це оцінює вміння переглядати, завантажувати, вивантажувати, закріплювати та вносити до чорного списку модулі ядра на основі доказів.

Питання 6: Пошук DNS не вдається для хоста, але `ping` до зовнішнього IP теж не вдається. Чому DNS не є вашою першою ціллю ремонту?

Якщо досяжність IP теж не вдається, маршрут, інтерфейс, брандмауер чи канальний рівень можуть бути зламані ще до того, як DNS узагалі задіяно. Перевірте ip addr, ip route та ip route get, перш ніж змінювати конфігурацію розв’язання імен. DNS усе ще може бути зламаним пізніше, але вам потрібен робочий шлях до мережі, перш ніж розв’язання імен зможе допомогти. Це підкріплює мережеву драбину та різницю між збоями шляху та збоями розв’язання імен.

Питання 7: Ви запланували завдання прибирання `at`, а потім усвідомили, що крок обслуговування скасовано. Що вам слід зробити?

Перегляньте список завдань у черзі командою atq, огляньте відповідне завдання командою at -c, якщо є будь-який сумнів, і вилучіть його командою atrm, використавши правильний номер завдання. Залишення одноразового прибирання в черзі після скасування завдання обслуговування створює відкладену зміну стану, яку важко пояснити пізніше. Той самий принцип діє на іспиті: планування не завершене, доки ви не можете перевірити чи вилучити поставлену в чергу роботу. Це також перевіряє дисципліну перевірки та прибирання планування.

Практична вправа

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

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

Діагностуйте збої служб systemd за станом процесу, статусом юніта та свідченнями журналу. Зупиніть нешкідливу службу, огляньте стан процесу, прочитайте статус юніта, перевірте журнал юніта, запустіть її знову та перевірте, чи ввімкнена вона для завантаження.
Оцініть цілі завантаження та дії вимкнення. Запишіть поточну ціль за замовчуванням, визначте, чи був би доречним режим rescue або emergency для гіпотетичної зламаної конфігурації, заплануйте перезавантаження, скасуйте його та огляньте поточні плюс попередні журнали завантаження.
Реалізуйте заплановані завдання cron і at із прибиранням. Додайте серцебиття cron, що пише в /tmp/cron-test.log, перевірте, що воно запускається, вилучіть його, потім поставте в чергу завдання at, що пише /tmp/at-test.log, огляньте чергу та приберіть файл.
Порівняйте тимчасову маршрутизацію з постійною конфігурацією мережі. Додайте тимчасовий маршрут до призначення лише для лабораторії через ваш шлюз, перевірте вибір маршруту, вилучіть його, потім поясніть, чи володів би Netplan або NetworkManager постійною версією у вашій системі.
Огляньте та керуйте безпечним модулем ядра. Використайте modinfo на dummy чи іншому нешкідливому модулі, завантажте його через modprobe, перевірте його через lsmod, вивантажте його та опишіть, як /etc/modules-load.d/ чи /etc/modprobe.d/ змінили б поведінку завантаження.
Перевірте SSH чи іншу мережеву службу. Перевірте, чи служба активна, ввімкнена та слухає; якщо ви використовуєте віддалений хост, скопіюйте нешкідливий файл і використайте докладний вивід SSH лише настільки довго, щоб довести поступ з’єднання.

Підказка до розв'язання завдання 1

Використовуйте драбину доказів служби замість того, щоб одразу стрибати до перезапуску. Зафіксуйте докази процесу через pgrep -a чи ps, прочитайте systemctl status та огляньте journalctl -u для юніта. Після запуску чи перезапуску служби перевірте як активний стан, так і будь-який сокет, що слухає, який служба має розкривати. Якщо завдання вимагає збереження завантаження, завершіть командою systemctl is-enabled.

Підказка до розв'язання завдання 2

Тримайте стан виконання та стан завантаження за замовчуванням окремо. systemctl get-default записує сталу ціль, тоді як операція isolate змінює поточний стан. Використовуйте планування та скасування вимкнення, щоб практикувати кероване перезавантаження без фактичної втрати сеансу. Журнали попереднього завантаження доступні через journalctl -b -1 після перезавантаження, а поточні журнали завантаження доступні через journalctl -b.

Підказка до розв'язання завдання 3

Для cron використовуйте абсолютні шляхи та перенаправте вивід, щоб ви могли довести запуск. Для at перегляньте чергу командою atq та огляньте згенероване завдання командою at -c, перш ніж воно запуститься. Прибирання — частина успіху: вилучіть тестові записи crontab, вилучіть поставлені в чергу завдання, коли це доречно, і видаліть тимчасові файли виводу лише після того, як ви перевірили, що вони були створені.

Підказка до розв'язання завдання 4

Використайте спершу тимчасовий маршрут, бо його легко вилучити, і він доводить, чи правильний шлюз. ip route get — найшвидша перевірка вибору маршруту. Для збереження огляньте, чи володіє інтерфейсом Netplan, NetworkManager чи інший менеджер, перш ніж редагувати файли. Застосовуйте постійну зміну лише після того, як тимчасовий маршрут доведе задуманий шлях.

Підказка до розв'язання завдання 5

Почніть із modinfo, щоб знати, що таке модуль і чи має він параметри. Використайте modprobe, щоб завантажити за іменем, бо він обробляє залежності, потім підтвердьте командою lsmod чи через /sys/module. Для збереження помістіть ім’я модуля під /etc/modules-load.d/; для запобігання використайте файл чорного списку під /etc/modprobe.d/. Вилучіть будь-які практичні файли, які ви створили, та перевірте підсумковий стан.

Підказка до розв'язання завдання 6

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

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

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

Джерела

Наступний модуль

Продовжуйте до LFCS: Практика сховища, служб і користувачів.