LFCS: практика зі сховищем, службами та користувачами

Напрямок LFCS | Складність: [СКЛАДНО] | Час: 50-70 хв на інтегрований модуль практики з адміністрування Linux, що охоплює ідентифікацію, сховище, служби, обмеження та перевірку.

Час на читання: 50-70 хвилин, з достатньою практичною глибиною, щоб робити паузи між розділами, виконувати команди в одноразовій лабораторії та порівнювати докази після кожної зміни.

Передумови

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

Обов’язково: LFCS: стратегія та робочий процес на іспиті
Обов’язково: LFCS: практика з основними командами
Обов’язково: LFCS: практика з робочими системами та мережею
Корисно: Модуль 1.4: користувачі та права доступу
Корисно: Модуль 8.1: керування сховищем

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

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

Впроваджувати зміни користувачів, груп, sudo, власності та прав доступу, які є свідомими, оборотними й легко перевіряються.
Діагностувати поведінку обмежень ресурсів та сеансів PAM, розрізняючи обмеження оболонки, постійну політику та застосування під час входу.
Проєктувати постійні зміни сховища за допомогою файлової системи, UUID, /etc/fstab та робочих процесів LVM, які залишаються чинними після перезавантаження.
Оцінювати стан життєвого циклу служби через встановлення пакета, увімкнення в systemd, поведінку перезапуску та перевірку перезавантаження демона.
Налагоджувати інтегровані практичні сценарії LFCS, де ідентифікація, сховище та конфігурація служб взаємодіють на одному хості.

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

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

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

Мета — не перетворити вас на архітектора сховищ чи фахівця з PAM за одне заняття. Мета — зробити поширений адміністративний шлях надійним під тиском часу, використовуючи Linux-очікування епохи Kubernetes, де systemd є менеджером служб, постійні монтування використовують стабільні ідентифікатори, а робочі вузли Kubernetes 1.35+ усе ще залежать від коректних користувачів, файлових систем і служб Linux під рівнем контейнерів. Спочатку ви потренуєте кожну область окремо, а потім поєднаєте їх у практичній вправі, яка нагадує іспит: привести хост у відповідність до запитаного стану, перевірити кожен рівень і не залишити жодного крихкого тимчасового виправлення.

Ідентифікація, власність і sudo як цикл перевірки

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

Базові команди знайомі, але їхня послідовність має значення. useradd створює запис, passwd встановлює автентифікаційний матеріал, groupadd створює спільну адміністративну межу, а usermod -aG додає додаткове членство, не замінюючи наявний список. Прапорець -a — не прикраса; без нього usermod -G може видалити кожну додаткову групу, не названу в команді. Це класичний спосіб зламати доступ до sudo, намагаючись надати інший шлях доступу.

useradd alice
passwd alice
usermod -aG sudo alice
groupadd ops
getent passwd alice
getent group ops
id alice
sudo -l -U alice
visudo

Після виконання цих команд читайте вивід як докази, а не як шум. getent passwd alice підтверджує, що база даних облікових записів може розв’язати користувача через налаштовану службу імен, що має значення в системах, які використовують локальні файли, LDAP або інше джерело NSS. getent group ops підтверджує, що група існує через той самий шлях розв’язання. id alice показує фактичне членство у групах так, як його бачить система, а sudo -l -U alice тестує політику sudo для цього користувача, а не припускає, що назви групи достатньо в кожному дистрибутиві.

Власність і права доступу — це місце, де ідентифікація стає операційною. Режим файлу має сенс лише в парі з власником і групою, а режим каталогу має сенс лише тоді, коли ви пам’ятаєте, що право виконання для каталогу означає обхід, а не запуск програми. Якщо користувач не може відкрити /srv/app/config.yml, перш ніж щось змінювати, потрібно поставити два запитання: чи може користувач пройти кожен батьківський каталог і чи надає кінцевий файл право на читання через власника, групу, ACL чи інші біти режиму? Вгадування між chmod та chown повільніше, ніж уважне дослідження шляху.

chown alice:ops /srv/app/config.yml
chmod 640 /srv/app/config.yml
chmod u+rwx,g+rx,o-r /srv/app
setfacl -m u:alice:rw /srv/app/shared.txt

Перший рядок змінює власника й групу, а наступні два рядки виражають політику доступу в бітах режиму. Файл 640 дозволяє власнику читати й писати, дозволяє групі читати й не надає доступу іншим. Каталог із u+rwx,g+rx,o-r дозволяє власнику керувати записами, дозволяє групі переглядати й обходити та прибирає право на читання в усіх інших, хоча вам також варто подумати про право виконання для обходу, коли ви посилюєте захист каталогів. Приклад з ACL корисний, коли одному названому користувачеві потрібен виняток без зміни групової моделі для всіх.

Зробіть паузу й передбачте: якщо alice додано до ops, поки в неї вже відкрита оболонка, що, на вашу думку, покаже id усередині тієї старої оболонки? Більшість систем не переписують додаткові групи вже запущеного сеансу входу лише через те, що змінився /etc/group. Це означає, що ваша перевірка має використовувати нову оболонку входу, новий сеанс SSH або команду на кшталт su - alice -c 'id', коли потрібно довести, що нове членство справді є чинним.

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

Обмеження ресурсів і застосування сеансів PAM

Обмеження ресурсів виглядають оманливо просто, бо ulimit швидко друкує числа. Пастка в тому, що ulimit показує поточні фактичні обмеження оболонки, тоді як постійна політика живе у файлах, які застосовуються під час налаштування сеансу. Якщо ви зміните /etc/security/limits.conf або drop-in під /etc/security/limits.d/, оболонка вже перед вами не успадкує нові значення чарівним чином. Вам потрібен новий сеанс входу, який проходить через PAM, і вам потрібен pam_limits.so у відповідному стеку сеансу.

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

ulimit -a                   # all soft limits for current shell
ulimit -Ha                  # all hard limits
ulimit -n                   # soft open-file limit
ulimit -Hn                  # hard open-file limit
su - alice -c 'ulimit -a'  # check limits for another user

Наведений вище блок команд навмисно розділено між дослідженням поточної оболонки та контекстом нового входу іншого користувача. ulimit -n відповідає на те, що поточна оболонка може використати для відкритих файлів просто зараз, тоді як su - alice -c 'ulimit -a' запитує, що отримує сеанс входу для alice. Ця різниця має значення, коли ви усуваєте несправності службового облікового запису або перевіряєте завдання LFCS після редагування постійної політики. Перш ніж запускати це, який вивід ви очікуєте зміненим після редагування drop-in з обмеженнями та яка оболонка, на вашу думку, залишиться незмінною?

Елемент	Прапорець `ulimit`	Ключове слово `limits.conf`
Відкриті файли	`-n`	`nofile`
Макс. процесів	`-u`	`nproc`
Макс. розмір файлу	`-f`	`fsize`
Розмір дампа пам’яті	`-c`	`core`
Адресний простір	`-v`	`as`

Таблиця дає вам рівень перекладу між інтерактивним дослідженням і постійною конфігурацією. На іспиті вас можуть попросити встановити обмеження за назвою, а потім перевірити його за допомогою вбудованої команди оболонки. Якщо в завданні сказано «відкриті файли», пов’яжіть nofile із ulimit -n. Якщо сказано «максимум процесів», пов’яжіть nproc із ulimit -u. Коли ви можете перекладати в обидва боки, ви можете переходити від формулювання завдання до конфігурації та назад до перевірки, не порпаючись у пам’яті під тиском.

Постійні обмеження можуть жити в /etc/security/limits.conf, але drop-in часто чистіший, бо він обмежує область зміни й легше видаляється під час практики. Формат послідовний: домен, тип, елемент, значення. Доменом може бути конкретний користувач, група з префіксом @ або * для стандартної політики. Вам слід установлювати і м’яке, і жорстке значення, коли завдання вимагає обмеженого діапазону, бо встановлення лише одного може залишити поведінку неоднозначною.

# Format: <domain> <type> <item> <value>
# Example: set alice's open-file limits
alice    soft    nofile    4096
alice    hard    nofile    8192

# Set for a group (prefix with @)
@ops     soft    nproc     2048
@ops     hard    nproc     4096

# Set for all users
*        soft    nofile    1024
*        hard    nofile    65536

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

echo "alice soft nofile 4096" | sudo tee /etc/security/limits.d/90-alice.conf
echo "alice hard nofile 8192" | sudo tee -a /etc/security/limits.d/90-alice.conf

Відсутній місток між цими файлами та запущеним процесом — це PAM. Підключувані модулі автентифікації (Pluggable Authentication Modules) стосуються не лише паролів; PAM також запускає модулі облікового запису, пароля та сеансу для служб на кшталт login, SSH, sudo та неінтерактивних сеансів. Модуль, який читає файли обмежень, — це pam_limits.so, і він має з’явитися в тому стеку сеансу, який використовує шлях входу. Без цього модуля файл може бути ідеально відформатованим і все одно не мати жодного ефекту для користувача, якого ви тестуєте.

Login -> PAM stack -> pam_limits.so reads limits.conf -> session gets limits applied

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

grep pam_limits.so /etc/pam.d/common-session
grep pam_limits.so /etc/pam.d/common-session-noninteractive

Розмітка дистрибутивів різниться, тож ці шляхи найзнайоміші в системах сімейства Debian та Ubuntu. Інші системи можуть тримати еквівалентні визначення стеку у файлах, специфічних для служб, або в керованих профілем включеннях, але ідея незмінна: знайдіть стек сеансу для шляху входу, який ви тестуєте, і підтвердьте, що модуль обмежень бере участь. Якщо завдання дає вам Debian-подібне середовище, common-session та common-session-noninteractive — природні місця для дослідження. Якщо воно дає інакшу розмітку, застосовуйте ті самі міркування й уникайте випадкового редагування.

Модуль	Призначення
`pam_limits.so`	Застосувати обмеження ресурсів з limits.conf
`pam_unix.so`	Стандартна парольна автентифікація
`pam_pwquality.so`	Застосування складності пароля
`pam_access.so`	Контроль доступу до входу (/etc/security/access.conf)
`pam_faildelay.so`	Затримка після невдалої автентифікації
`pam_nologin.so`	Блокувати вхід не-root, коли існує /etc/nologin

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

ls /etc/pam.d/                  # per-service PAM configs
cat /etc/pam.d/common-auth      # authentication stack
cat /etc/pam.d/common-session   # session setup stack
cat /etc/pam.d/common-password  # password change rules
cat /etc/pam.d/common-account   # account validation

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

type    control    module-path    [module-arguments]

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

# Check if pam_pwquality is in the password stack
grep pam_pwquality /etc/pam.d/common-password

# If present, its config is in:
cat /etc/security/pwquality.conf
# minlen = 12
# dcredit = -1    (require at least 1 digit)
# ucredit = -1    (require at least 1 uppercase)

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

Файлові системи, постійні монтування та зростання LVM

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

lsblk
blkid
# run only ONE of these (choose ext4 OR xfs)
mkfs.ext4 /dev/sdb1
mkfs.xfs /dev/sdb1
mkdir -p /data
mount /dev/sdb1 /data
findmnt /data

Команди форматування в цьому блоці навмисно прямі, бо вони потужні. У реальній роботі та на практиці перед іспитом підтвердьте, що /dev/sdb1 — це призначений запасний пристрій, перш ніж запускати mkfs.ext4 чи mkfs.xfs; форматування неправильного розділу — це не відновлювана друкарська помилка з правами доступу. Для практики файл loopback часто безпечніший за фізичний запасний диск, але патерн перевірки залишається тим самим. Ви повинні вміти пояснити, яка команда створює файлову систему, а яка команда лише приєднує наявну файлову систему до дерева каталогів.

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

UUID=$(blkid -s UUID -o value /dev/sdb1)
echo "UUID=$UUID /data ext4 defaults 0 2" | sudo tee -a /etc/fstab
mount -a

Крок mount -a — це крок, що рятує на іспиті. Він просить систему обробити записи /etc/fstab зараз, поки ви ще можете виправити друкарську помилку, а не виявити проблему після завантаження. Якщо точка монтування вже має змонтовану призначену файлову систему, під час практики вам може знадобитися розмонтувати й перемонтувати, щоб ви тестували саме запис, а не попереднє ручне монтування. У будь-якому разі шлях перевірки завершується findmnt /data, df -h /data та швидким поглядом на точний рядок, який ви додали.

+----------------------+       +----------------------+       +----------------------+
| Block device         |       | Filesystem identity  |       | Mounted directory    |
| /dev/sdb1            |  -->  | UUID from blkid      |  -->  | /data via /etc/fstab |
+----------------------+       +----------------------+       +----------------------+

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

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

pvcreate /dev/sdb1
vgcreate vg_data /dev/sdb1
lvcreate -n lv_app -L 10G vg_data
mkfs.ext4 /dev/vg_data/lv_app
mkdir -p /srv/app
mount /dev/vg_data/lv_app /srv/app

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

+----------------+     +----------------+     +----------------+     +----------------+
| Physical volume | --> | Volume group   | --> | Logical volume | --> | Filesystem     |
| /dev/sdb1       |     | vg_data        |     | lv_app         |     | ext4 or XFS    |
+----------------+     +----------------+     +----------------+     +----------------+
                                                                     |
                                                                     v
                                                          +----------------------+
                                                          | Mount point /srv/app |
                                                          +----------------------+

Діаграма показує, чому усунення несправностей LVM не повинно одразу переходити до df. df бачить змонтовану файлову систему, а не всю ієрархію LVM. Якщо df показує замалий розмір після розширення, можливо, LV не виріс, можливо, файлова система не виросла або ви дивитеся на неправильну точку монтування. Працюйте вниз по ланцюжку за допомогою pvs, vgs, lvs, lsblk, findmnt та df -h, поки рівень, який не змінився, не стане очевидним.

lvextend -L +5G /dev/vg_data/lv_app
resize2fs /dev/vg_data/lv_app
lvs
lsblk
df -h /srv/app

Для файлових систем сімейства ext resize2fs збільшує файлову систему після того, як виріс логічний том. Важлива думка в тому, що збільшення блокового пристрою — це не те саме, що збільшення файлової системи, яка на ньому розташована. Якщо ви зупинитеся після lvextend, lvs може показати новий розмір LV, тоді як df -h /srv/app усе ще показує стару ємність файлової системи. Ця невідповідність — діагностична підказка, а не привід запускати випадкові команди.

lvextend -L +5G /dev/vg_data/lv_app
xfs_growfs /srv/app
lvs
df -h /srv/app

XFS використовує іншу команду зростання й націлюється на змонтований шлях файлової системи. Ця різниця — поширена пастка LFCS, бо команда LV виглядає однаково, але команда файлової системи змінюється. Який підхід ви б обрали тут і чому, якщо findmnt /srv/app повідомляє xfs, а не ext4? Правильна відповідь — дозволити фактичному типу файлової системи визначати команду зміни розміру, а потім перевірити ємність із точки монтування, яку використовують застосунки.

Служби, постійність після завантаження та докази systemd

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

apt update
apt install -y nginx
systemctl enable --now nginx
systemctl status nginx
systemctl is-enabled nginx
systemctl daemon-reload
systemctl restart nginx

Форма enable --now ефективна, бо вона виражає і постійність після завантаження, і негайний запуск. Усе ж після цього вам слід дослідити стан, бо юніт може бути водночас увімкненим і несправним. systemctl status nginx показує активний стан і свіжий контекст журналу, тоді як systemctl is-enabled nginx відповідає на те, чи встановлено політику завантаження. Якщо служба зазнає невдачі, прочитайте вивід status, перш ніж перевстановлювати пакети чи змінювати права доступу; багато збоїв спричинено відсутніми шляхами, недійсною конфігурацією, недоступними портами або користувачем, який не може прочитати потрібні файли.

systemctl daemon-reload має значення, коли визначення юнітів чи drop-in змінюються, бо systemd зберігає менеджерське подання метаданих юнітів. Перезапуск служби без перезавантаження після редагування файлу юніта може тестувати старе визначення, через що налагодження здається непослідовним. Правильна послідовність після редагування юніта чи drop-in — перезавантажити менеджер, перезапустити чи перезавантажити службу відповідно, дослідити стан і перевірити поведінку, яку зміна мала змінити. Ця послідовність невелика, але вона запобігає багатьом хибним висновкам.

Збої служб часто пов’язуються назад з ідентифікацією та сховищем. Демон може запускатися вручну як root, але виходити з ладу під systemd, бо його юніт використовує менш привілейований User=. Вебсервер може бути увімкнений правильно, але виходити з ладу, бо /srv/app ще не змонтовано або змонтовано з правами доступу, які виключають службовий обліковий запис. Процес може поводитися нормально в оболонці, але натрапляти на нижчі обмеження у своєму реальному середовищі служби. Коли симптоми перетинають рівні, не сплющуйте проблему до «systemd зламано»; рухайтеся за доказами від стану юніта до журналів, користувача, шляху, монтування та обмежень.

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

Інтегрований робочий процес іспиту

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

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

Найкорисніша іспитова звичка — залишати кожну зміну такою, що піддається тестуванню наступною людиною. Чистий /etc/security/limits.d/90-alice.conf легше дослідити, ніж непозначене редагування, поховане в довгому головному файлі конфігурації. Рядок /etc/fstab на основі UUID легше викликає довіру після перезавантаження, ніж ім’я пристрою ядра, яке залежить від порядку виявлення. Службу, яка водночас активна й увімкнена, легше захистити, ніж службу, яку ви запустили один раз. Модель прав доступу на основі груп легше підтримувати, ніж купу одноразових широких режимів.

Коли ви під тиском часу, опирайтеся широким виправленням, таким як chmod -R 777, переписування стека PAM з пам’яті чи дописування неперевірених рядків /etc/fstab. Такі зміни створюють більше невизначеності, ніж усувають. Натомість внесіть одну обмежену зміну, перевірте її, а потім переходьте до наступного рівня. Якщо пізніший рівень зазнає невдачі, ваша попередня перевірка стане корисним доказом, а не чимось, що доведеться переглядати з нуля.

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

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

Інший корисний патерн — вузька політика перед широкою політикою. Drop-in з обмеженнями для конкретного користувача безпечніший за зміну глобального стандарту, коли названо лише одного користувача. Власність групи безпечніша за режими, доступні для запису всім, коли двом операторам потрібен спільний доступ. Монтування на основі UUID безпечніші за монтування на основі імен пристроїв, коли постійність є частиною вимоги. Вузька політика працює, бо вона надає саме запитаному суб’єкту саме потрібний доступ, що залишає менше непередбаченої поведінки для подальшого налагодження.

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

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

Інший антипатерн — постійна конфігурація без тесту. Дописування до /etc/fstab, редагування файлу обмежень чи зміна drop-in юніта без запуску відповідної команди перевірки залишає вам відкладений збій. Краща альтернатива — негайна валідація: mount -a для синтаксису fstab і придатності до монтування, новий вхід для застосованих PAM обмежень та systemctl daemon-reload плюс дослідження стану для метаданих systemd. Тест є частиною зміни, а не необов’язковим етапом прибирання.

Останній антипатерн — ставлення до рівнів Linux як до взаємозамінних. df не доводить, що LV виріс, lvs не доводить, що файлова система виросла, sudo -l не доводить, що службовий обліковий запис може обійти /srv/app, а systemctl is-enabled не доводить, що служба зараз справна. Кожен інструмент звітує про один рівень. Кращий підхід — обрати інструмент, який відповідає твердженню, яке ви намагаєтеся довести, а потім зупинитися, коли докази безпосередньо відповідають на запитання.

Патерн	Використовуйте, коли	Чому працює	Сигнал перевірки
Перевірка після кожного рівня	Завдання охоплює користувачів, сховище, служби чи обмеження	Воно ізолює збої до того, як вони накопичаться	`id`, `findmnt`, `df -h`, `systemctl status` відповідають запитаному стану
Спершу вузька політика	Названий користувач, група, монтування чи служба має конкретну вимогу	Воно уникає широких побічних ефектів і зберігає найменші привілеї	Названий суб’єкт працює, тоді як непов’язані суб’єкти незмінні
Тестування в новому контексті	PAM, членство у групі, fstab чи systemd мають застосувати політику	Воно тестує контекст, який справді споживає конфігурацію	Новий вхід, `mount -a` чи перезавантажений юніт показує нову поведінку

Антипатерн	Що йде не так	Краща альтернатива
Використання режимів, доступних для запису всім, для виправлення доступу	Справжня проблема власника, групи, ACL чи службового користувача прихована	Дослідіть шлях і надайте найвужчий доступ, який задовольняє завдання
Редагування постійних файлів без валідації	Хост може вийти з ладу після перезавантаження чи наступного входу	Запустіть команду, яка одразу залучає постійний файл
Перевірка лише одного рівня сховища	Розмір LV, розмір файлової системи та змонтована ємність можуть розходитися	Перевірте ієрархію LVM і змонтовану файлову систему окремо

Рамка прийняття рішень

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

+-------------------------+
| What is failing?        |
+-----------+-------------+
            |
            v
+-------------------------+     user cannot act      +---------------------------+
| Is the consumer a user  | -----------------------> | Check getent, id, sudo,  |
| or service account?     |                          | ownership, modes, ACLs   |
+-----------+-------------+                          +---------------------------+
            |
            | path or capacity problem
            v
+-------------------------+     mount missing        +---------------------------+
| Is the storage visible  | -----------------------> | Check lsblk, blkid,      |
| from the mounted path?  |                          | findmnt, fstab, df       |
+-----------+-------------+                          +---------------------------+
            |
            | daemon state problem
            v
+-------------------------+                          +---------------------------+
| Is systemd managing the | -----------------------> | Check status, enablement,|
| expected unit metadata? |                          | logs, daemon-reload      |
+-------------------------+                          +---------------------------+

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

Ситуація	Перевага	Уникати	Причина
Одному названому користувачеві потрібні вищі обмеження на відкриті файли	Файл для конкретного користувача під `/etc/security/limits.d/`	Широка політика `*`, якщо не запитано	Воно задовольняє завдання, не змінюючи непов’язаних користувачів
Монтування має пережити перезавантаження	UUID у `/etc/fstab` плюс перевірка `mount -a`	Голі імена `/dev/sdX` без тестування	UUID залишаються стабільними, коли порядок виявлення пристроїв змінюється
Юніт служби було відредаговано	`systemctl daemon-reload`, перезапуск, дослідження стану	Перезапуск без перезавантаження метаданих менеджера	Інакше systemd може й далі використовувати старе визначення юніта
Спільному каталогу потрібен доступ на запис для команди	Власність групи, біти режиму та тестування нового членства	Рекурсивні права, доступні для запису всім	Групова політика залишається придатною для аудиту й обмеженою
LV було розширено, але ємність виглядає незмінною	Збільште файлову систему правильним інструментом для файлової системи	Сліпий запуск нових команд `lvextend`	LV і файлова система — окремі рівні

Чи знали ви?

Біти прав доступу до файлів Linux використовують окремі класи власника, групи та інших, тож один вісімковий режим на кшталт 640 кодує три різні рішення про доступ у трьох цифрах.
Шосте поле /etc/fstab контролює порядок перевірки файлової системи для інструментів, які його шанують; кореневі файлові системи зазвичай використовують 1, тоді як багато некореневих файлових систем використовують 2.
systemd став стандартною системою ініціалізації в багатьох великих дистрибутивах Linux упродовж 2010-х років, ось чому завдання служб LFCS тепер передбачають вільне володіння systemctl.
LVM розділяє фізичні томи, групи томів і логічні томи, що дозволяє збільшувати логічний том без перепроєктування всієї розмітки розділів диска.

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

Помилка	Чому трапляється	Як виправити
Заміна додаткових груп користувача через `usermod -G`	Команда виглядає як правильний інструмент керування групами, але відсутній `-a` змушує новий список замінити старий	Використовуйте `usermod -aG group user`, потім перевірте з нового входу через `id user`
Зміна бітів режиму, коли справжня проблема — власність	Помилка каже «у доступі відмовлено», тож учні хапаються за `chmod`, перш ніж перевірити власника й групу	Дослідіть кожен компонент шляху, потім оберіть `chown`, `chmod` чи `setfacl` на основі доказів
Редагування файлів обмежень і перевірка в тій самій оболонці	`ulimit` швидкий, але поточна оболонка вже має свої обмеження	Запустіть новий сеанс входу через `su - user -c 'ulimit -a'` і підтвердьте, що `pam_limits.so` є в стеку сеансу
Додавання запису `/etc/fstab` без його тестування	Ручне монтування спрацювало, тож постійний рядок здається паперовою роботою	Запустіть `mount -a`, потім перевірте через `findmnt` та `df -h`, перш ніж вважати завдання завершеним
Розширення лише логічного тому	`lvextend` звітує про успіх, що може приховати, що файлова система все ще старого розміру	Запустіть `resize2fs` для файлових систем сімейства ext або `xfs_growfs` для XFS, потім перевірте з точки монтування
Увімкнення служби без перевірки активного стану	Увімкнення й справність під час виконання легко сплутати	Використовуйте і `systemctl is-enabled`, і `systemctl status`, потім читайте журнали, якщо юніт несправний
Редагування юніта systemd з пропуском перезавантаження демона	Здається, що перезапуск має все перечитати з диска	Запустіть `systemctl daemon-reload` після змін юніта чи drop-in, потім перезапустіть і дослідіть стан

Тест

Запитання 1

Сценарій вправи: ви додали alice до групи ops, щоб вона могла читати /srv/app/config.yml, але її наявний термінал досі не може прочитати файл. Файл належить root:ops з режимом 640, а батьківський каталог дозволяє обхід для групи. Що слід перевірити спочатку?

A. Чи запустила alice новий сеанс входу, який включає нову додаткову групу B. Чи слід змінити /srv/app/config.yml на режим 777 C. Чи потрібно повторно запустити mkfs.ext4 на пристрої, що лежить в основі D. Чи було запущено systemctl daemon-reload після зміни групи

Відповідь і обґрунтування

Варіант A правильний, бо зміни додаткових груп не обов’язково з’являються всередині вже запущеного сеансу входу. Новий вхід або su - alice -c 'id' перевіряє членство у групі, яке справді використає рішення про доступ. Варіант B неправильний, бо права, доступні для запису всім, приховують справжню модель доступу й надають набагато більше, ніж вимагало завдання. Варіант C не пов’язаний зі збоєм доступу до наявного файлу, а варіант D неправильний, бо метадані менеджера systemd не контролюють інтерактивне членство у групі.

Запитання 2

Сценарій вправи: ви створили /etc/security/limits.d/90-alice.conf із alice soft nofile 4096, але ulimit -n у вашому терміналі root досі друкує старе значення. Який найкращий наступний крок перевірки?

A. Запустити su - alice -c 'ulimit -n' і підтвердити, що стек сеансу PAM включає pam_limits.so B. Видалити /etc/security/limits.d/90-alice.conf, бо обмеження ніколи не застосовуються після входу C. Відредагувати /etc/fstab, бо обмеження на відкриті файли монтуються з диска під час завантаження D. Перезапустити nginx, бо всі обмеження за замовчуванням є специфічними для служб

Відповідь і обґрунтування

Варіант A правильний, бо постійні обмеження застосовуються до нових сеансів, і PAM повинен включати pam_limits.so, щоб файл обмежень мав значення. Поточне значення ulimit у терміналі root нічого не доводить про наступну оболонку входу Alice. Варіант B неправильний, бо обмеження можуть застосовуватися, але лише в правильному контексті. Варіант C не пов’язаний з політикою обмежень ресурсів, а варіант D неправильний, бо завдання називає обмеження користувача, а не обов’язково перевизначення служби systemd.

Запитання 3

Сценарій вправи: /data змонтовано вручну з /dev/sdb1, і завдання каже, що воно має пережити перезавантаження. Яка дія найкраще задовольняє вимогу постійності?

A. Додати запис /etc/fstab на основі UUID, запустити mount -a і перевірити через findmnt /data B. Запустити df -h один раз і припустити, що наявне монтування повернеться після перезавантаження C. Додати /dev/sdb1 до /etc/passwd, щоб ім’я пристрою розв’язувалося послідовно D. Увімкнути nginx, бо systemd автоматично перемонтовує всі ручні монтування

Відповідь і обґрунтування

Варіант A правильний, бо стабільний UUID файлової системи в /etc/fstab виражає намір монтування на час завантаження, а mount -a тестує цей намір до перезавантаження. Варіант B неправильний, бо df -h лише доводить поточну змонтовану ємність. Варіант C некоректний, бо /etc/passwd зберігає інформацію про облікові записи, а не постійність блокового пристрою. Варіант D неправильний, бо увімкнення вебслужби не створює постійної політики монтування для довільних файлових систем.

Запитання 4

Сценарій вправи: ви запустили lvextend -L +5G /dev/vg_data/lv_app, і lvs показує більший логічний том, але df -h /srv/app досі показує старий розмір. Який крок найімовірніше пропущено?

A. Збільшити файлову систему за допомогою команди, що відповідає її типу файлової системи B. Знову створити групу ops, щоб каталог міг оновити ємність C. Запустити passwd alice, бо зростання сховища застосовується під час автентифікації D. Видалити /etc/fstab, бо постійні монтування перешкоджають зміні розміру файлової системи

Відповідь і обґрунтування

Варіант A правильний, бо зростання логічного тому й зростання файлової системи — окремі операції. Для файлових систем сімейства ext resize2fs збільшує файлову систему; для XFS xfs_growfs націлюється на змонтований шлях. Варіант B неправильний, бо створення групи не може змінити ємність файлової системи. Варіант C плутає автентифікацію облікового запису з розміткою сховища, а варіант D неправильний, бо дійсне постійне монтування не перешкоджає належному зростанню файлової системи.

Запитання 5

Сценарій вправи: ви відредагували drop-in юніта systemd для nginx, перезапустили службу, і нічого не змінилося. Синтаксис файлу юніта дійсний. Який крок слід додати до робочого процесу?

A. Запустити systemctl daemon-reload, потім перезапустити службу й дослідити стан B. Переформатувати файлову систему даних, бо метадані юніта живуть усередині журналу файлової системи C. Використати setfacl на /etc/systemd/system, щоб systemd помітив нові файли D. Замінити systemctl is-enabled на getent group nginx

Відповідь і обґрунтування

Варіант A правильний, бо systemd потребує daemon-reload після змін метаданих юніта чи drop-in, перш ніж менеджер використає нове визначення. Перезапуск без перезавантаження може й далі тестувати старе менеджерське подання. Варіант B не пов’язаний і руйнівний. Варіант C неправильний, бо ACL файлів — не звичайний механізм сповіщення для метаданих юнітів systemd, а варіант D перевіряє інший рівень, ніж стан менеджера служб.

Запитання 6

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

A. Перевірити стан і журнали systemd, підтвердити користувача юніта, перевірити монтування через findmnt, потім дослідити власність і режими B. Негайно запустити chmod -R 777 /srv/app, бо будь-яка помилка доступу означає, що всі режими надто суворі C. Заново створити логічний том, бо служби не можуть читати з файлових систем на основі LVM D. Вимкнути службу під час завантаження, бо увімкнені служби не можуть отримувати доступ до змонтованих шляхів

Відповідь і обґрунтування

Варіант A правильний, бо він рухається за доказами через рівні, залучені у збої: стан юніта, ідентичність служби, доступність монтування та доступ до шляху. Варіант B неправильний, бо він розширює доступ до діагностики справжньої причини. Варіант C некоректний, бо служби можуть нормально використовувати файлові системи на основі LVM, коли їх змонтовано й дозволено. Варіант D хибно розуміє увімкнення; постійність після завантаження потрібна, але вона має поєднуватися з правильними залежностями, монтуваннями та правами доступу.

Запитання 7

Сценарій вправи: завдання LFCS просить вас підготувати спільну адмінзону для двох операторів і довести результат. Який набір перевірок найкраще відповідає вимозі?

A. Використати getent group, id з нового сеансу, дослідження власності/режиму шляху та реальний тест читання-запису від імені одного оператора B. Використати лише lsblk, бо групи представлені як пристрої сховища після входу C. Використати лише systemctl is-enabled, бо політика sudo й доступ до каталогу є властивостями служб D. Використати лише passwd, бо встановлення пароля доводить доступ до спільного каталогу

Відповідь і обґрунтування

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

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

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

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

Завдання 1: побудувати спільну адмінзону

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

Група ops існує й розв’язується через getent group ops.
Двоє практичних користувачів існують і показують ops у виводі id з нового сеансу.
Спільний каталог має власність групи, встановлену на ops, і надає призначений груповий доступ.
Принаймні один практичний користувач може створити й прочитати тестовий файл у спільному каталозі.

Запропоноване рішення

sudo groupadd ops
sudo useradd -m alice
sudo useradd -m bob
sudo usermod -aG ops alice
sudo usermod -aG ops bob
sudo mkdir -p /srv/app/shared
sudo chown root:ops /srv/app/shared
sudo chmod 2770 /srv/app/shared
getent group ops
id alice
id bob
su - alice -c 'touch /srv/app/shared/alice-test && ls -l /srv/app/shared/alice-test'

Біт setgid на каталозі допомагає новим файлам успадковувати групу, що є поширеним патерном спільного каталогу. Якщо команда touch зазнає невдачі, дослідіть шлях каталогу через namei -l /srv/app/shared чи еквівалентні перевірки шляху, перш ніж широко змінювати режими.

Завдання 2: установити та перевірити обмеження ресурсів

Створіть тимчасовий тестовий обліковий запис або повторно використайте один практичний обліковий запис, установіть і м’яке, і жорстке обмеження на відкриті файли у файлі drop-in, перевірте, що шлях сеансу PAM включає pam_limits.so, і протестуйте з нової оболонки входу. Важлива частина — довести, що новий сеанс бачить налаштовані значення; перевірки старої оболонки недостатньо.

Drop-in з обмеженнями існує під /etc/security/limits.d/ для практичного облікового запису.
Стек сеансу PAM, який використовує лабораторний хост, включає pam_limits.so.
Нова оболонка входу повідомляє очікувані м’яке й жорстке обмеження на відкриті файли.
Drop-in можна чисто видалити після практики.

Запропоноване рішення

# Create a test user
sudo useradd -m testlimits

# Check default limits
su - testlimits -c 'ulimit -n'    # open files
su - testlimits -c 'ulimit -u'    # max processes

# Set custom limits
echo "testlimits soft nofile 4096" | sudo tee /etc/security/limits.d/90-testlimits.conf
echo "testlimits hard nofile 8192" | sudo tee -a /etc/security/limits.d/90-testlimits.conf
echo "testlimits soft nproc 512" | sudo tee -a /etc/security/limits.d/90-testlimits.conf

# Verify PAM is wired (critical — limits won't apply without this)
grep pam_limits.so /etc/pam.d/common-session

# Start a FRESH login shell and verify (same shell won't show new limits)
su - testlimits -c 'ulimit -n'    # should show 4096
su - testlimits -c 'ulimit -Hn'   # should show 8192
su - testlimits -c 'ulimit -u'    # should show 512

# Inspect the full session PAM stack
cat /etc/pam.d/common-session

# Confirm pam_limits.so is present and required
grep -n pam_limits /etc/pam.d/common-session

# Check password complexity rules
grep pam_pwquality /etc/pam.d/common-password
cat /etc/security/pwquality.conf 2>/dev/null

sudo rm /etc/security/limits.d/90-testlimits.conf
sudo userdel -r testlimits

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

Завдання 3: зробити сховище постійним

Використайте запасний лабораторний диск, розділ, створений для практики, чи пристрій loopback. Створіть файлову систему, змонтуйте її на /data, додайте запис /etc/fstab на основі UUID, протестуйте запис через mount -a і перевірте результат через findmnt та df -h. Не використовуйте виробничий диск для цього кроку практики.

lsblk показує призначений практичний пристрій чи відображення loopback.
Файлова система має UUID, про який повідомляє blkid.
/etc/fstab містить запис на основі UUID для /data.
mount -a, findmnt /data та df -h /data усі підтверджують очікуване постійне монтування.

Запропоноване рішення

lsblk
blkid
# run only ONE of these (choose ext4 OR xfs)
mkfs.ext4 /dev/sdb1
mkfs.xfs /dev/sdb1
mkdir -p /data
mount /dev/sdb1 /data
findmnt /data

UUID=$(blkid -s UUID -o value /dev/sdb1)
echo "UUID=$UUID /data ext4 defaults 0 2" | sudo tee -a /etc/fstab
mount -a

Оберіть або ext4, або XFS для реального лабораторного запуску; команди показано разом, щоб ви могли порівняти обидва варіанти файлової системи. Якщо ви обираєте XFS, зробіть тип файлової системи в /etc/fstab відповідним xfs, а не ext4.

Завдання 4: створити й збільшити сховище LVM

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

pvs, vgs чи lvs показує очікувані об’єкти LVM.
/srv/app змонтовано з логічного тому.
І логічний том, і файлова система більші після кроку зростання.
Перевірка використовує і інструменти LVM, і інструменти змонтованої файлової системи.

Запропоноване рішення

pvcreate /dev/sdb1
vgcreate vg_data /dev/sdb1
lvcreate -n lv_app -L 10G vg_data
mkfs.ext4 /dev/vg_data/lv_app
mkdir -p /srv/app
mount /dev/vg_data/lv_app /srv/app

lvextend -L +5G /dev/vg_data/lv_app
resize2fs /dev/vg_data/lv_app
lvs
lsblk
df -h /srv/app

lvextend -L +5G /dev/vg_data/lv_app
xfs_growfs /srv/app
lvs
df -h /srv/app

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

Завдання 5: установити та зробити постійною службу

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

Пакет встановлюється без нерозв’язаних помилок залежностей.
Служба активна після запуску.
Службу увімкнено для завантаження.
За будь-яким редагуванням юніта чи drop-in слідує systemctl daemon-reload перед перезапуском.

Запропоноване рішення

apt update
apt install -y nginx
systemctl enable --now nginx
systemctl status nginx
systemctl is-enabled nginx
systemctl daemon-reload
systemctl restart nginx

Після запуску служби перевірте точну умову успіху, яку називає завдання. Якщо завдання просить лише постійності після завантаження, доречний systemctl is-enabled. Якщо завдання просить запущену службу, доречні systemctl status та журнали. Якщо завдання просить службу читати з /srv/app, доречні власність шляху, біти режиму, стан монтування та ідентичність службового користувача.

Джерела

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

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