Повний пробний іспит LFCS

Напрямок LFCS | Складність: [СКЛАДНИЙ] | Час: 90-120 хв

Час на читання: 25-35 хвилин на ознайомлення, потім один повний прохід із таймером і один структурований розбір.

Передумови

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Операційна модель пробного іспиту

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

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

+------------------+      +------------------+      +------------------+      +------------------+
|  Read all tasks  | ---> | Rank by payoff   | ---> | Execute + verify | ---> | Debrief evidence |
|  before typing   |      | effort, and risk |      | one task at time |      | not impressions  |
+------------------+      +------------------+      +------------------+      +------------------+

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

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

[ ] users: create operator1, add supplementary group, verify with id and file write
[ ] service: inspect failed unit, fix cause, verify active and journal has no new failure
[ ] storage: mount device or loop image, persist in fstab, verify with findmnt and df
[ ] network: prove route, DNS, listening socket, or firewall state depending on symptom

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

Зупиніться та подумайте, перш ніж продовжити: якщо завдання каже “зробити так, щоб це пережило перезавантаження”, яка команда доводить поточний стан, а яка команда доводить персистентну конфігурацію? Команда поточного стану на кшталт mount або systemctl status корисна, але персистентність часто потребує читання /etc/fstab, перевірки увімкнених юнітів або використання інструмента, який володіє конфігурацією. Ця відмінність неодноразово з’являється в пробному іспиті.

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

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

Підготовка практичного середовища

Запускайте пробний іспит в одноразовому середовищі Linux, де доступний sudo і де зміни на рівні системи прийнятні. Локальна віртуальна машина ідеальна, тому що ви можете зробити знімок, зламати машину та відновити її без вагань. Хмарний інстанс також підходить, але переконайтеся, що пристрої зберігання, поведінка фаєрвола та керування службами нагадують дистрибутив, на якому ви маєте намір практикуватися.

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

mkdir -p ~/lfcs-mock/{docs,logs,archives,restore,scripts,service-data}
printf 'alpha\nbravo\ncharlie\nerror: disk warning\n' > ~/lfcs-mock/logs/app.log
printf 'operator=maya\nteam=platform\nrole=oncall\n' > ~/lfcs-mock/docs/operator.conf
printf 'daily backup completed\nweekly backup pending\n' > ~/lfcs-mock/docs/backup-notes.txt

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

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

printf 'LFCS mock started: %s\n' "$(date -Is)" > ~/lfcs-mock/mock-notes.txt
printf '[ ] essential commands\n[ ] users and permissions\n[ ] service\n' >> ~/lfcs-mock/mock-notes.txt
printf '[ ] networking\n[ ] storage\n[ ] scheduled task\n' >> ~/lfcs-mock/mock-notes.txt

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

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

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

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

cat /etc/os-release
uname -r
systemctl --version | head -n 1
lsblk
ip -br address

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

Читання та ранжування списку завдань

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

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

Тип завдання	Типовий зиск	Типовий ризик	Швидка перевірка
Основні команди	Високий, якщо синтаксис знайомий	Низький, бо файли локальні	find, grep, tar -tf, порівняння відновленого файлу
Користувачі та права доступу	Високий, якщо імена точні	Середній, бо помилки володіння блокують доступ	id, namei -l, sudo -u, реальний тест запису
Запущені служби	Від середнього до високого	Середній, бо цикли перезапуску приховують першопричину	systemctl is-active, journalctl, перевірка, специфічна для служби
Мережі	Змінний, бо симптоми відрізняються	Середній, бо фаєрвол і DNS плутають один одного	ip, ss, getent hosts, curl або nc
Зберігання	Високий, але ризикований	Високий, бо помилки персистентності можуть вплинути на завантаження	findmnt, df, mount -a, контрольований тестовий файл
Заплановані завдання	Середній і швидкий	Від низького до середнього залежно від контексту користувача	crontab -l, перевірка спулу, файл журналу або виводу

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

Корисна позначка рангу має три частини: оцінені зусилля, впевненість та команду перевірки. Наприклад, “E/high/tar -tf” означає, що завдання з основними командами виглядає легким і його можна довести переліком архіву. “M/medium/findmnt + mount -a” означає, що завдання зі зберіганням може бути керованим, але воно потребує перевірок як поточного стану, так і персистентності.

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

Сильний кандидат починає із завдань, які створюють імпульс та докази. Імпульс важливий, тому що ранні перемоги зменшують стрес. Докази важливі, тому що саме кінцевий стан системи приносить залік. Завдання, яке здається завершеним, але не має виводу перевірки, є лише здогадкою.

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

Опрацьований приклад: основні команди під тиском іспиту

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

Припустімо, завдання каже: знайти конфігураційний файл, який містить слово platform, зберегти відповідний рядок у ~/lfcs-mock/result.txt, створити стиснений архів каталогу docs і довести, що архів відновлюється. Завдання поєднує пошук, перенаправлення, архівування та перевірку. Жодна з цих частин не є складною окремо, але іспит перевіряє, чи можете ви поєднати їх, не відхиляючись.

Почніть пошук, маючи на увазі як назву файлу, так і вміст. find відповідає на запитання про шляхи, тоді як grep відповідає на запитання про вміст файлів. Коли завдання дає слово всередині файлу, grep -R є природним першим інструментом, тому що він повідомляє файл, який містить цей вміст.

grep -R "platform" ~/lfcs-mock/docs
grep -R "platform" ~/lfcs-mock/docs > ~/lfcs-mock/result.txt
cat ~/lfcs-mock/result.txt

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

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

tar -czf ~/lfcs-mock/archives/docs.tgz -C ~/lfcs-mock docs
tar -tzf ~/lfcs-mock/archives/docs.tgz

Операція переліку доводить, що містить архів, перш ніж ви його відновите. Якщо архів містить docs/operator.conf, це легко відновити в окремий каталог. Якщо він містить довгий шлях домашнього каталогу, архів усе ще може працювати, але він менш чистий і може не відповідати запитуваному виводу.

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

rm -rf ~/lfcs-mock/restore/docs
mkdir -p ~/lfcs-mock/restore
tar -xzf ~/lfcs-mock/archives/docs.tgz -C ~/lfcs-mock/restore
diff -u ~/lfcs-mock/docs/operator.conf ~/lfcs-mock/restore/docs/operator.conf

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

Шаблон узагальнюється на багато завдань із файлами. Знайдіть об’єкт, перетворіть або збережіть об’єкт, перевірте вивід і протестуйте вивід у чистому місці. Коли завдання включає обробку тексту, віддавайте перевагу командам, чий вивід ви можете одразу прочитати, порахувати або порівняти.

Опрацьований приклад: користувачі та права доступу

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

Припустімо, завдання каже: створити групу з назвою platformops, створити користувача з назвою lfcsop1, зробити користувача додатковим членом групи, створити /srv/platform-reports і дозволити членам групи створювати там файли. Це завдання включає створення облікового запису, членство в групі, володіння, біти режиму та реальний тест доступу.

sudo groupadd platformops
sudo useradd -m -s /bin/bash -G platformops lfcsop1
sudo mkdir -p /srv/platform-reports
sudo chown root:platformops /srv/platform-reports
sudo chmod 2770 /srv/platform-reports

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

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

id lfcsop1
namei -l /srv/platform-reports
sudo -u lfcsop1 bash -c 'printf "ok\n" > /srv/platform-reports/access-test.txt'
ls -l /srv/platform-reports/access-test.txt

Команда sudo -u є ключовим доказом, тому що вона виконує запитувану дію від імені запитуваного користувача. Рядок режиму може виглядати правильним, тоді як батьківський каталог усе ще блокує проходження. Членство в групі може виглядати правильним, тоді як наявний сеанс входу ще не підхопив нову групу. Реальний запис файлу зменшує ці невизначеності.

Якщо тест запису провалюється, утримайтеся від сліпої зміни прав доступу на 777. Діагностуйте шлях по одному рівню за раз. namei -l показує кожен компонент у шляху, а id показує дієві групи. Найменше виправлення, яке пояснює збій, майже завжди безпечніше, ніж відкриття каталогу для всіх.

namei -l /srv/platform-reports
sudo -u lfcsop1 id
sudo -u lfcsop1 test -w /srv/platform-reports && echo writable

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

Опрацьований приклад: запущені системи та systemd

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

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

sudo tee /etc/systemd/system/lfcs-mock.service >/dev/null <<'EOF'
[Unit]
Description=LFCS mock failing service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/lfcs-mock-start

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl start lfcs-mock.service || true

Служба зазнає збою, тому що /usr/local/bin/lfcs-mock-start не існує. Версія на іспиті може бути тоншою, наприклад неправильний шлях, відсутнє право доступу, поганий файл середовища або недійсна конфігурація. Робочий процес той самий: перевірити стан, прочитати журнали, внести найменше виправлення, перезавантажити, якщо файли юнітів змінилися, перезапустити та перевірити.

systemctl status lfcs-mock.service --no-pager
journalctl -u lfcs-mock.service -n 20 --no-pager
systemctl cat lfcs-mock.service

systemctl status дає високорівневий стан, journalctl дає останні деталі збою, а systemctl cat показує дієвий вміст юніта. Ці команди відповідають на різні запитання. Якщо ви запустите лише одну з них, ви можете побачити симптом, але пропустити причину.

Тепер створіть відсутній скрипт із правами на виконання. Вміст може бути мінімальним, тому що завдання стосується шляху служби та стану виконуваності. Після зміни виконуваного скрипта вам не потрібен daemon-reload; після зміни самого файлу юніта — потрібен.

sudo tee /usr/local/bin/lfcs-mock-start >/dev/null <<'EOF'
#!/usr/bin/env bash
printf 'lfcs mock service ran at %s\n' "$(date -Is)" >> /var/log/lfcs-mock-service.log
EOF
sudo chmod 755 /usr/local/bin/lfcs-mock-start
sudo systemctl start lfcs-mock.service
systemctl is-active lfcs-mock.service || true
tail -n 5 /var/log/lfcs-mock-service.log

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

Коли служба має залишатися активною, використовуйте довготривалий процес або перевіряйте головний процес за допомогою systemctl status і systemctl show. Коли служба призначена для виконання одноразової дії, успіхом може бути inactive з успішним результатом. Іспит винагороджує відповідність перевірки наміру.

systemctl show lfcs-mock.service -p ActiveState -p SubState -p Result
journalctl -u lfcs-mock.service -n 10 --no-pager

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

sudo systemctl disable --now lfcs-mock.service 2>/dev/null || true
sudo rm -f /etc/systemd/system/lfcs-mock.service /usr/local/bin/lfcs-mock-start
sudo systemctl daemon-reload
sudo rm -f /var/log/lfcs-mock-service.log

Опрацьований приклад: діагностика мережі

Завдання з мережами складні, тому що схожі симптоми можуть походити з різних шарів. Невдалий curl може означати відсутність адреси, неправильний маршрут, збій DNS, заблокований порт, зупинену службу, політику фаєрвола або помилку застосунку. Розв’язання — не запам’ятати одну команду; розв’язання — перевіряти шари в порядку, який звужує проблему.

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

+-------------+     +-------------+     +-------------+     +-------------+     +-------------+
| IP address  | --> | Route table | --> | Name lookup | --> | Local ports | --> | App request |
| ip -br addr |     | ip route    |     | getent      |     | ss -ltnp    |     | curl / nc   |
+-------------+     +-------------+     +-------------+     +-------------+     +-------------+

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

ip -br address
ip route

Потім перевірте розв’язання імен окремо від тестування з’єднання. getent hosts використовує налаштований системний шлях служби імен, який може включати /etc/hosts, DNS та інші джерела. Це часто більш репрезентативно, ніж інструмент лише для DNS, коли завдання запитує, як хост розв’язує імена.

getent hosts localhost
getent hosts example.com

Для локальних служб підтвердьте, що щось слухає, перш ніж тестувати з іншого хоста. ss -ltnp показує слухачів TCP і, коли права доступу дозволяють, процес-власник. Фаєрвол не може переслати трафік до служби, яка не слухає, тому ця перевірка передує вгадуванню фаєрвола.

ss -ltnp

Якщо завдання включає службу HTTP, локальний запит дає швидкий зворотний зв’язок. Використовуйте curl -I для заголовків, коли вміст не має значення, і використовуйте повний запит, коли вам потрібно перевірити тіло. Якщо curl не встановлено, можуть бути доступні nc або інструменти, специфічні для дистрибутива, але не витрачайте пробний іспит на встановлення утиліт, якщо завдання цього не вимагає.

curl -I http://127.0.0.1/ 2>/dev/null || true

Команди фаєрвола відрізняються залежно від дистрибутива, і завдання LFCS можуть очікувати firewalld, nftables, iptables або обгортку дистрибутива. Звичка досвідченого фахівця — визначити активний механізм фаєрвола, перш ніж змінювати правила. Запуск команд із неправильної родини фаєрвола може дати вам хибне відчуття завершення.

systemctl is-active firewalld 2>/dev/null || true
sudo nft list ruleset 2>/dev/null | head -n 40 || true
sudo iptables -S 2>/dev/null | head -n 20 || true

Зупиніться та подумайте: якщо розв’язання імен провалюється, але curl http://93.184.216.34/ успішний, який шар ви перевірили б наступним? Імовірна проблема — у шляху резолвера, а не в маршруті. Ви перевірили б /etc/resolv.conf, getent hosts та будь-які локальні записи хостів, перш ніж змінювати конфігурацію інтерфейсу чи фаєрвола.

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

Опрацьований приклад: зберігання та персистентність

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

Приклад loopback створює файл, форматує його, монтує, записує тестовий файл і додає запис /etc/fstab, використовуючи UUID. Використання UUID зазвичай стабільніше, ніж використання назви loop-пристрою, тому що номери loop-пристроїв можуть змінюватися. На реальних дисках UUID також безпечніші, ніж назви пристроїв, які можуть зміщуватися між завантаженнями.

mkdir -p ~/lfcs-mock/storage
dd if=/dev/zero of=~/lfcs-mock/storage/data.img bs=1M count=64
mkfs.ext4 -F ~/lfcs-mock/storage/data.img
sudo mkdir -p /mnt/lfcs-data
sudo mount -o loop ~/lfcs-mock/storage/data.img /mnt/lfcs-data

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

findmnt /mnt/lfcs-data
df -h /mnt/lfcs-data
printf 'storage ok\n' | sudo tee /mnt/lfcs-data/proof.txt >/dev/null
cat /mnt/lfcs-data/proof.txt

Персистентність — це окрема вимога. Для реальних блокових пристроїв blkid може повернути UUID напряму. Для практики з loopback ви все одно можете перевірити UUID файлової системи та записати рядок /etc/fstab, але пам’ятайте, що монтування loopback у /etc/fstab може поводитися по-різному в різних дистрибутивах, якщо файл, що лежить в основі, недоступний достатньо рано.

sudo blkid ~/lfcs-mock/storage/data.img

Реалістичний рядок fstab використовує UUID, точку монтування, тип файлової системи, опції, поле dump та порядок fsck. Ви повинні розуміти кожне поле, тому що відсутнє поле чи погана опція можуть зламати перевірку. Наступна команда друкує кандидатний рядок; перегляньте його, перш ніж дописувати на вашій практичній машині.

UUID_VALUE="$(sudo blkid -s UUID -o value ~/lfcs-mock/storage/data.img)"
printf 'UUID=%s /mnt/lfcs-data ext4 loop,defaults 0 0\n' "$UUID_VALUE"

Якщо ви вирішите дописати рядок під час практики, спершу зробіть резервну копію. Потім запустіть mount -a, щоб протестувати синтаксис fstab без перезавантаження. Це одна з найважливіших звичок зі зберіганням LFCS, тому що вона виловлює помилки, поки ви ще маєте робочу оболонку.

sudo cp /etc/fstab /etc/fstab.lfcs-mock.bak
UUID_VALUE="$(sudo blkid -s UUID -o value ~/lfcs-mock/storage/data.img)"
printf 'UUID=%s /mnt/lfcs-data ext4 loop,defaults 0 0\n' "$UUID_VALUE" | sudo tee -a /etc/fstab
sudo mount -a
findmnt /mnt/lfcs-data

Якщо mount -a провалюється, не перезавантажуйтеся, щоб “подивитися, що буде”. Прочитайте помилку, перевірте рядок і відновіть резервну копію за потреби. Кандидат, який може безпечно відновитися після поганого рядка fstab, практикується як адміністратор, а не лише як набирач команд.

sudo cp /etc/fstab.lfcs-mock.bak /etc/fstab
sudo umount /mnt/lfcs-data 2>/dev/null || true
sudo mount -a

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

Опрацьований приклад: заплановані завдання

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

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

mkdir -p ~/lfcs-mock/cron-output
CRON_FILE="$(mktemp)"
crontab -l 2>/dev/null > "$CRON_FILE" || true
printf '* * * * * /usr/bin/date -Is >> %s/cron-output/timestamps.log\n' "$HOME/lfcs-mock" >> "$CRON_FILE"
crontab "$CRON_FILE"
rm -f "$CRON_FILE"

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

crontab -l
sleep 70
tail -n 5 ~/lfcs-mock/cron-output/timestamps.log

Якщо файл виводу не з’являється, перевірте, чи активна служба cron і чи існує шлях команди. Назви служб у дистрибутивах можуть відрізнятися, тому використовуйте systemctl list-units, якщо пряма назва служби не спрацьовує. Не припускайте, що планувальник зламаний, перш ніж перевірити саму команду.

command -v date
systemctl list-units '*cron*' '*crond*' --no-pager

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

crontab -l | grep -v 'lfcs-mock/cron-output/timestamps.log' | crontab -
crontab -l

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

Структура пробного іспиту

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

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

+-------------------+-------------------+-------------------+
| First pass        | Main execution    | Final review      |
| read and rank     | solve + verify    | inspect evidence  |
| 5-8 minutes       | 70-78 minutes     | 7-12 minutes      |
+-------------------+-------------------+-------------------+

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

Завдання 1: основні команди та архіви

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

Перш ніж розв’язувати, визначте, чи запитує завдання назву файлу, вміст файлу, метадані файлу або перетворений вивід. Це різні запитання. find сильний для назв і метаданих, grep сильний для вмісту, tar сильний для архівів, а diff сильний для доказу відновленого вмісту.

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

Зупиніться та подумайте: якщо архів перелічує home/student/lfcs-mock/docs/operator.conf замість docs/operator.conf, чи буде завдання все одно прийнятним? Відповідь залежить від формулювання, але безпечніша екзаменаційна звичка — архівувати з контрольованого батьківського каталогу, щоб відновлення створювало очікувану структуру.

Завдання 2: користувачі, групи та доступ до спільного каталогу

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

Завдання не завершене, коли useradd завершується успішно. Стан облікового запису, стан групи, володіння каталогом, проходження через батьківські каталоги, поведінка setgid і доступ на запис — усе має значення. Чиста перевірка використовує id, namei -l, ls -ld та sudo -u USER для реального тесту.

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

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

Завдання 3: запущені системи та збій служби

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

Не починайте з редагування першого файлу, який виглядає пов’язаним. Почніть із systemctl status, journalctl -u та systemctl cat, щоб ви знали, що systemd насправді намагається запустити. Якщо юніт посилається на файл середовища, скрипт, сокет, монтування чи користувача, перевірте цю залежність, перш ніж змінювати сам юніт.

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

Перевірка має відповідати типу служби. Довготривалий демон має стати активним і залишатися активним. Юніт типу oneshot може успішно завершитися і стати неактивним. Завдання, пов’язане з таймером, може вимагати перевірки як таймера, так і служби, яку він запускає.

Завдання 4: мережі та розв’язання імен

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

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

Спершу використовуйте компактні команди, щоб не потонути у виводі. ip -br address, ip route, getent hosts та ss -ltnp зазвичай дають достатньо напрямку для наступного кроку. Залиште глибоку перевірку пакетів і великі дампи фаєрвола для випадків, коли перші команди вказують туди.

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

Завдання 5: зберігання, монтування та виживання після перезавантаження

Шлях до даних має бути персистентним. Визначте запитуваний пристрій або файлову систему, змонтуйте її в правильний шлях, налаштуйте персистентність і перевірте за допомогою findmnt, df, тесту запису та безпечної перевірки персистентності на кшталт mount -a.

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

Використовуйте /etc/fstab обережно. Створіть резервну копію перед редагуванням під час практики, віддавайте перевагу UUID, коли доречно, і протестуйте файл за допомогою mount -a, перш ніж вважати завдання завершеним. Рядок, який працює лише до перезавантаження, не задовольняє вимогу персистентності.

Повна відповідь доводить і змонтований стан, і шлях до даних. findmnt /path показує джерело та опції, df -h /path показує придатний для використання простір, а тест запису-читання доводить, що шлях придатний для запису, як задумано. Якщо права доступу мають значення, тестуйте з правильною особою користувача.

Завдання 6: запланована адміністративна дія

Повторювана чи одноразова адміністративна дія має виконуватися автоматично. Додайте запис cron або роботу at у правильному контексті користувача, перевірте, що вона існує, доведіть, що команда може виконатися, і видаліть чи збережіть її відповідно до формулювання завдання.

Ключове рішення — контекст користувача. Кореневий crontab, користувацький crontab та файл у /etc/cron.d мають різний синтаксис і різні привілеї виконання. Уважно прочитайте завдання, перш ніж обирати розташування планувальника.

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

Перевірка має включати і наявність розкладу, і ефект команди, коли дозволяє час. crontab -l доводить встановлення, тоді як файл журналу, файл виводу або стан служби доводить виконання. Якщо інтервал розкладу надто довгий для очікування, доведіть команду вручну і доведіть, що розклад існує.

Стратегія темпу для проходу з таймером

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

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

ready: users task, next command is sudo -u lfcsop1 write test
blocked: service task, journal says permission denied but target file ownership unclear
verify: storage task, mounted now but fstab still needs mount -a test

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

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

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

Оцінювання пробного іспиту

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

Категорія	Сильне виконання	Слабке виконання	Докази для огляду
Правильність	Запитувані користувачі, файли, служби, маршрути, монтування та розклади існують у задуманому стані	Команди було набрано, але кінцевий стан неповний чи неправильний	Фінальні команди перевірки та стан завдання за завданням
Перевірка	Кожне завдання має незалежну перевірку, яка відповідає вимозі	Завершення ґрунтується на пам’яті, успіху команди чи візуальному вгадуванні	Нотатки, історія оболонки, файли виводу, стан служби
Темп	Легкі завдання завершено рано, а час фінального огляду збережено	Одне складне завдання поглинуло прохід, поки легша робота залишилася незайманою	Позначки часу, порядок завдань, нотатки заблокованих завдань
Відновлення	Помилки діагностовано, звужено та виправлено з мінімальними змінами	Виправлення ставали ширшими, ризикованішими чи непов’язаними із симптомом	Невдалі команди, кроки відкату, відновлені файли

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

Сильний розбір називає командні родини, а не риси характеру. “Я погано знаю Linux” непридатне для використання. “Я втратив дванадцять хвилин, бо сплутав поточні монтування з персистентністю fstab” — це дієве. Друге твердження точно говорить вам, що саме потрібно відпрацювати.

Перегляньте історію оболонки після проходу, але не плутайте історію з доказом. Історія оболонки показує, що ви намагалися зробити. Стан системи показує, що збереглося. Обидва корисні, і вони відповідають на різні запитання.

history | tail -n 80
findmnt
systemctl --failed --no-pager
crontab -l 2>/dev/null || true

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

Запитання для розбору, які дають кращу практику

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

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

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

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

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

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

Як виглядає сильне виконання

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

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

Сильний прохід перевіряє з правильною особою. Завдання з правами доступу тестуються від імені цільового користувача, а не лише від імені root. Завдання зі службами перевіряються через systemd та журнали, а не лише редагуванням файлів. Завдання зі зберіганням перевіряються через стан монтування та поведінку fstab, а не лише створенням каталогу.

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

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

Чи знали ви?

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

2. Файл /etc/fstab був джерелом реальних виробничих збоїв, тому що один поганий запис персистентності може вплинути на поведінку завантаження ще довго після того, як початковий адміністратор покине термінал.

3. Зміни додаткової групи можуть не з’явитися всередині вже запущеного сеансу входу, і саме тому тестування зі свіжим контекстом команди на кшталт sudo -u USER може виявити іншу поведінку.

4. Служба systemd типу oneshot може успішно завершитися, не залишаючись активною, тому правильна перевірка залежить від типу юніта та формулювання завдання, а не від універсального очікування “active”.

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

Помилка	Що йде не так	Краща екзаменаційна поведінка
Починати із завдання, яке здається найтерміновішим	Один складний пункт поглинає прохід, поки легші перевірені бали залишаються незайманими	Прочитайте всі завдання, проранжуйте за зусиллями та вартістю доказу, потім спершу здобудьте швидкі перемоги
Довіряти успіху команди без перевірки стану	Команда завершується успішно, але створює неправильний шлях, контекст користувача, форму архіву чи поведінку монтування	Поєднуйте кожну зміну з незалежною командою перевірки, яка відповідає вимозі
Використовувати root для тесту завдання, що не стосується root	Root може писати майже будь-де, тому тест не доводить доступ запитуваного користувача	Використовуйте sudo -u USER або свіжий контекст користувача для виконання реальної операції
Редагувати файли служб перед читанням журналів	Перше редагування може пропустити справжній збій і ускладнити інтерпретацію доказів	Перевірте systemctl status, journalctl -u та systemctl cat, перш ніж щось змінювати
Плутати поточний стан із персистентним станом	Монтування, служба чи маршрут працюють зараз, але зникають після перезапуску чи перезавантаження	Перевіряйте стан виконання та персистентного власника на кшталт fstab, увімкнених юнітів чи файлів конфігурації
Відкривати права доступу занадто широко, щоб тест пройшов	Завдання видається розв’язаним, але система менш безпечна і може порушувати вимогу	Застосовуйте найвужчу зміну володіння, групи, режиму чи ACL, яка пояснює потрібний доступ
Забувати про очищення в практичному середовищі	Користувачі, записи cron, монтування та служби пробного іспиту залишаються позаду і плутають пізніші проходи	Відстежуйте практичні артефакти та видаляйте їх після розбору, якщо завдання не каже їх зберегти
Повторювати ту саму невдалу команду без нової гіпотези	Час минає, стрес зростає, а збій не дає нової інформації	Змініть кут перевірки, занотуйте блокувальник або перейдіть до іншого завдання, доки не зможете повернутися продуктивно

Тест

1. Ваш пробний іспит починається з шести завдань, і завдання зі зберіганням виглядає знайомим, але потребує редагування /etc/fstab. Завдання з користувачем і завдання з архівом обидва виглядають простими і мають очевидні команди перевірки. Який порядок ви маєте обрати і чому?

   Відповідь

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

2. Ви створюєте спільний каталог, правильно встановлюєте його групу і підтверджуєте за допомогою ls -ld, що режим — 2770. Цільовий користувач усе одно не може створити там файл під час вашого тесту. Що ви маєте перевірити, перш ніж змінювати режим на щось ширше?

   Відповідь

   Перевірте дієві групи користувача за допомогою id USER або sudo -u USER id, потім перевірте кожен компонент шляху за допомогою namei -l /path/to/shared-directory. Збій може походити від відсутнього членства в додатковій групі, застарілого сеансу чи батьківського каталогу без права на виконання. Розширення кінцевого режиму каталогу може приховати симптом, не виправивши справжній шлях доступу. Правильний тест — реальний запис від імені цільового користувача після того, як перевірки особи та шляху пояснять, чому доступ має працювати.

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

   Відповідь

   Ви, ймовірно, забули systemctl daemon-reload, який каже systemd перезавантажити змінені файли юнітів. Після його запуску використовуйте systemctl cat UNIT, щоб підтвердити, що дієвий вміст юніта включає скоригований ExecStart. Потім перезапустіть службу та перевірте systemctl status плюс journalctl -u UNIT -n 20. Ключ — перевіряти завантажений вигляд менеджера, а не лише файл, який ви відредагували.

4. Завдання з мережами каже, що користувачі не можуть досягти app.internal на порту 8080. getent hosts app.internal повертає адресу, але curl http://app.internal:8080 провалюється. Яка хороша наступна діагностична послідовність?

   Відповідь

   Оскільки розв’язання імен працює, переходьте до перевірок транспорту та служби. Перевірте маршрут за допомогою ip route get ADDRESS, якщо доступно, перевірте стан локального чи цільового слухача за допомогою ss -ltnp, коли ви на хості, який має обслуговувати порт, і перевіряйте правила фаєрвола лише після підтвердження, що служба насправді слухає. Якщо служба віддалена, використовуйте тест з’єднання на кшталт nc -vz app.internal 8080, якщо доступно. Послідовність уникає зміни DNS, тому що DNS уже дав адресу.

5. Ви монтуєте файлову систему в /data, записуєте файл-доказ, і df -h /data виглядає правильно. Завдання явно каже, що монтування має пережити перезавантаження. Яку додаткову перевірку ви маєте виконати, перш ніж позначити завдання завершеним?

   Відповідь

   Перевірте конфігурацію персистентності, зазвичай /etc/fstab, і протестуйте її безпечно за допомогою mount -a після резервного копіювання файлу під час практики. Також використовуйте findmnt /data, щоб підтвердити джерело та опції. Поточне монтування плюс тест запису доводить поведінку виконання, але не доводить виживання після перезавантаження. Персистентність потребує перевірки конфігурації, яка буде використана пізніше.

6. Завдання cron працює, коли ви запускаєте команду вручну, але запланований файл виводу так і не з’являється. Які відмінності між вашою оболонкою та cron ви маєте оцінити?

   Відповідь

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

7. Під час фінального огляду ви виявляєте, що завдання зі службою все ще провалюється, але три інші завдання завершені та перевірені. У вас залишилося лише кілька хвилин. Що ви маєте зробити з рештою часу?

   Відповідь

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

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

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

Крок 1: побудуйте практичний робочий простір

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

mkdir -p ~/lfcs-mock/{docs,logs,archives,restore,cron-output,storage}
printf 'platform team owns this file\n' > ~/lfcs-mock/docs/ownership.txt
printf 'service warning: missing executable\n' > ~/lfcs-mock/logs/service.log
printf 'network target: localhost\n' > ~/lfcs-mock/docs/network.txt
printf '[ ] essential commands\n[ ] users and permissions\n[ ] service\n[ ] networking\n[ ] storage\n[ ] scheduled task\n' > ~/lfcs-mock/mock-notes.txt

Критерії успіху:

• Каталог ~/lfcs-mock існує з окремими підкаталогами для docs, logs, archives, тестів відновлення, виводу cron та практики зі зберіганням.
• Файл ~/lfcs-mock/mock-notes.txt містить по одному відстежуваному рядку для кожної з шести галузей завдань пробного іспиту.
• Ви можете пояснити, які практичні артефакти є локальними файлами, а які пізніші кроки можуть змінити глобальний стан системи.

Крок 2: виконайте ранжування першого проходу

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

{
  printf '\nRanked order:\n'
  printf '1. essential commands - verify with grep output, tar listing, restore diff\n'
  printf '2. users and permissions - verify with id, namei, sudo -u write test\n'
  printf '3. scheduled task - verify with crontab -l and output file\n'
  printf '4. service - verify with systemctl, journalctl, service-specific output\n'
  printf '5. networking - verify with ip, getent, ss, curl or nc\n'
  printf '6. storage - verify with findmnt, df, mount -a, proof file\n'
} >> ~/lfcs-mock/mock-notes.txt

Критерії успіху:

• Ваш проранжований порядок з’являється в ~/lfcs-mock/mock-notes.txt, перш ніж ви виконаєте роботу, що змінює систему.
• Кожен рядок завдання називає щонайменше одну команду перевірки, яка довела б завершення.
• Ваше ранжування визначає щонайменше одне завдання як вищого ризику, тому що воно впливає на персистентність, стан служби чи глобальний доступ.

Крок 3: завершіть і перевірте завдання з основними командами

Знайдіть файл, що містить фразу platform team, збережіть відповідний рядок, створіть стиснений архів каталогу docs, перелічіть архів, відновіть його в чистий каталог і порівняйте один відновлений файл з оригіналом.

grep -R "platform team" ~/lfcs-mock/docs > ~/lfcs-mock/result-essential.txt
tar -czf ~/lfcs-mock/archives/docs.tgz -C ~/lfcs-mock docs
tar -tzf ~/lfcs-mock/archives/docs.tgz
rm -rf ~/lfcs-mock/restore/docs
tar -xzf ~/lfcs-mock/archives/docs.tgz -C ~/lfcs-mock/restore
diff -u ~/lfcs-mock/docs/ownership.txt ~/lfcs-mock/restore/docs/ownership.txt

Критерії успіху:

• Файл ~/lfcs-mock/result-essential.txt містить відповідний рядок і вихідний шлях, який його породив.
• Архів ~/lfcs-mock/archives/docs.tgz перелічує передбачуваний шлях docs/..., а не випадковий абсолютний шлях.
• Порівняння відновленого файлу проходить без виводу від diff, доводячи, що архів може відтворити вміст.

Крок 4: завершіть і перевірте завдання з користувачами та правами доступу

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

sudo groupadd lfcsops 2>/dev/null || true
id lfcsop1 2>/dev/null || sudo useradd -m -s /bin/bash -G lfcsops lfcsop1
sudo usermod -aG lfcsops lfcsop1
sudo mkdir -p /srv/lfcsops
sudo chown root:lfcsops /srv/lfcsops
sudo chmod 2770 /srv/lfcsops
id lfcsop1
namei -l /srv/lfcsops
sudo -u lfcsop1 bash -c 'printf "user access ok\n" > /srv/lfcsops/proof.txt'
ls -l /srv/lfcsops/proof.txt

Критерії успіху:

• Команда id lfcsop1 показує користувача як члена групи lfcsops.
• Каталог /srv/lfcsops належить групі lfcsops і має права доступу, що підтримують контрольовану групову співпрацю.
• Запис файлу, виконаний від імені lfcsop1, а не root, успішний усередині /srv/lfcsops.

Крок 5: завершіть і перевірте завдання зі службою

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

sudo tee /etc/systemd/system/lfcs-mock.service >/dev/null <<'EOF'
[Unit]
Description=LFCS mock service for hands-on practice

[Service]
Type=oneshot
ExecStart=/usr/local/bin/lfcs-mock-start

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl start lfcs-mock.service || true
systemctl status lfcs-mock.service --no-pager || true
journalctl -u lfcs-mock.service -n 20 --no-pager || true

sudo tee /usr/local/bin/lfcs-mock-start >/dev/null <<'EOF'
#!/usr/bin/env bash
printf 'service proof %s\n' "$(date -Is)" >> /tmp/lfcs-mock-service-proof.log
EOF
sudo chmod 755 /usr/local/bin/lfcs-mock-start
sudo systemctl start lfcs-mock.service
systemctl show lfcs-mock.service -p ActiveState -p SubState -p Result
tail -n 5 /tmp/lfcs-mock-service-proof.log

Критерії успіху:

• Ви зафіксували початковий збій за допомогою systemctl status або journalctl, перш ніж застосувати виправлення.
• Виправлена служба повідомляє успішний результат, який відповідає її типу oneshot.
• Специфічний для служби файл-доказ показує, що задумана команда насправді виконалася.

Крок 6: завершіть і перевірте завдання з мережами

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

ip -br address
ip route
getent hosts localhost
ss -ltnp 2>/dev/null | head -n 20
curl -I http://127.0.0.1/ 2>/dev/null || true

Критерії успіху:

• Ви записали інформацію про локальну адресу та маршрут, перш ніж вносити будь-яку зміну, пов’язану з мережею.
• Ви протестували розв’язання імен окремо від з’єднання застосунку.
• Ваша фінальна команда доказу задіює той самий шлях, який описано у вашому обраному завданні з мережами.

Крок 7: завершіть і перевірте завдання зі зберіганням

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

dd if=/dev/zero of=~/lfcs-mock/storage/data.img bs=1M count=64
mkfs.ext4 -F ~/lfcs-mock/storage/data.img
sudo mkdir -p /mnt/lfcs-data
sudo mount -o loop ~/lfcs-mock/storage/data.img /mnt/lfcs-data
findmnt /mnt/lfcs-data
df -h /mnt/lfcs-data
printf 'storage proof\n' | sudo tee /mnt/lfcs-data/proof.txt >/dev/null
cat /mnt/lfcs-data/proof.txt

sudo cp /etc/fstab /etc/fstab.lfcs-mock.bak
UUID_VALUE="$(sudo blkid -s UUID -o value ~/lfcs-mock/storage/data.img)"
printf 'UUID=%s /mnt/lfcs-data ext4 loop,defaults 0 0\n' "$UUID_VALUE" | sudo tee -a /etc/fstab
sudo mount -a
findmnt /mnt/lfcs-data

Критерії успіху:

• Точка монтування /mnt/lfcs-data підкріплена файловою системою loopback, як показує findmnt.
• Файл-доказ можна записати та прочитати через змонтований шлях.
• Конфігурацію fstab протестовано за допомогою mount -a, і ви можете відновити резервну копію під час очищення.

Крок 8: завершіть і перевірте пункт із запланованим завданням

Створіть запис cron, який записує позначки часу у ваш робочий простір пробного іспиту, перевірте, що запис існує, зачекайте достатньо довго для одного запуску та перевірте вивід. Потім видаліть лише рядок пробного іспиту, щоб непов’язаний вміст crontab був збережений.

CRON_FILE="$(mktemp)"
crontab -l 2>/dev/null > "$CRON_FILE" || true
printf '* * * * * /usr/bin/date -Is >> %s/lfcs-mock/cron-output/timestamps.log\n' "$HOME" >> "$CRON_FILE"
crontab "$CRON_FILE"
rm -f "$CRON_FILE"
crontab -l
sleep 70
tail -n 5 ~/lfcs-mock/cron-output/timestamps.log

crontab -l | grep -v 'lfcs-mock/cron-output/timestamps.log' | crontab -
crontab -l 2>/dev/null || true

Критерії успіху:

• Crontab містить заплановану команду пробного іспиту, перш ніж ви чекаєте на виконання.
• Файл виводу в ~/lfcs-mock/cron-output містить щонайменше одну позначку часу, створену запланованою командою.
• Очищення видаляє рядок cron пробного іспиту, не знищуючи навмисно непов’язані заплановані записи.

Крок 9: розберіть і створіть план перездачі

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

{
  printf '\nDebrief:\n'
  printf 'Longest task:\n'
  printf 'Weakest command family:\n'
  printf 'Skipped or late verification:\n'
  printf 'Task to drill before retake:\n'
} >> ~/lfcs-mock/mock-notes.txt
tail -n 30 ~/lfcs-mock/mock-notes.txt

Критерії успіху:

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

Крок 10: очистіть практичні артефакти, де доречно

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

sudo systemctl disable --now lfcs-mock.service 2>/dev/null || true
sudo rm -f /etc/systemd/system/lfcs-mock.service /usr/local/bin/lfcs-mock-start
sudo systemctl daemon-reload
sudo cp /etc/fstab.lfcs-mock.bak /etc/fstab 2>/dev/null || true
sudo umount /mnt/lfcs-data 2>/dev/null || true
sudo rm -f /tmp/lfcs-mock-service-proof.log

Критерії успіху:

• Юніт systemd пробного іспиту та допоміжний скрипт видалено, і systemd перезавантажено після видалення.
• Будь-яке практичне редагування fstab було або навмисно збережено для лабораторії, або відновлено з резервної копії.
• Ви можете перезапустити пробний іспит пізніше без застарілих служб, монтувань чи записів cron, які заплутують наступну спробу.

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

Це останній модуль у послідовності LFCS; продовжуйте, повернувшись до огляду напрямку LFCS та запланувавши перездачу з таймером на основі вашого розбору.

Джерела

• Важливі інструкції Linux Foundation LFCS — авторитетне джерело щодо формату іспиту LFCS, часових рамок та практичної структури.
• Довідник конфігурації юнітів systemd.service — основний довідник щодо Type=oneshot, RemainAfterExit та деталей перевірки стану служби.
• Довідник util-linux mount(8) — основний довідник щодо порад UUID-проти-назви-пристрою та поведінки mount -a при перевірці персистентності.