- У версії systemd 259 представлено часткову підтримку musl, більшу модульність у libsystemd та модель привілеїв, що застосовується за допомогою run0 --empower.
- Планка вимог підвищується: ядро Linux 5.10, glibc 2.34, OpenSSL 3.0.0 та інші сучасні бібліотеки стають обов'язковими мінімумами.
- Вихід із застарілих версій прискорюється: прощання зі скриптами SysV, припинення підтримки TPM 1.2, відмова від iptables та повне впровадження nftables.
- Вони покращують спостережуваність та безпеку завдяки постійному веденню журналу за замовчуванням, новим метрикам OOMKills та численним налаштуванням у мережі, контейнерах та домашній інфраструктурі.
Випуск стабільної версії systemd 259 є черговим поворотом в одному з найбільш суперечливих і найважливіших компонентів екосистеми Linux. Йдеться про фреймворк для запуску та управління службами, який вже домінує в більшості дистрибутивів, і цей реліз ще більше затягує гайки з точки зору технічних вимог, безпеки та відмови від застарілих технологій.
Це оновлення вийшло після кількох місяців інтенсивної роботи та зосереджено на трьох основних напрямках: сумісність з новими бібліотеками C, покращена безпека та очищення застарілого коду (скрипти SysV, TPM 1.2, iptables тощо). Воно також вносить суттєві зміни в управління привілеями за допомогою run0, обробку пам'яті за допомогою systemd-oomd, зберігання журналів та модель внутрішніх залежностей libsystemd.
systemd 259 та експериментальна підтримка musl
Одна з найбільш обговорюваних особливостей цієї версії полягає в тому, що systemd 259 вперше включає часткову підтримку стандартної бібліотеки C musl . Ця бібліотека широко використовується в легких системах, мінімалістичних контейнерах та вбудованих середовищах, де бажана простота та зменшене споживання ресурсів порівняно з glibc.
Підтримка musl вмикається шляхом встановлення параметра "libc" системи збірки Meson у значення "musl" . Однак ця інтеграція далеко не завершена: musl не реалізує механізм перемикання служби імен (NSS), який змушує вимикати кілька частин systemd під час компіляції з цією бібліотекою.
Зокрема, збірка systemd 259 з musl виключає ключові компоненти, такі як nss-systemd, nss-resolve, systemd-homed, systemd-userdbd та systemd-nsresourced . Опція DynamicUser та можливість запуску systemd-nspawn без привілеїв також недоступні, що особливо актуально в контейнерних середовищах, які сильно залежать від цих можливостей.
Самі розробники визнають, що не можуть гарантувати довгострокову підтримку . Її продовження залежатиме від фактичної зацікавленості спільноти, зрілості додаткових шарів, що забезпечують функції, яких, мабуть, бракує, та звітів про помилки, характерних для цієї бібліотеки. Якщо попит буде низьким або обслуговування виявиться занадто складним, не дивно, якщо цю підтримку буде переглянуто в майбутніх версіях.
Однак, це відкриття для musl важливе на символічному рівні: systemd роками критикували за майже виключну залежність від glibc , що робило його недружнім до альтернативних дистрибутивів та дуже мінімалістичних сценаріїв. Цей крок не вирішує все, але він руйнує образ системи, повністю закритої для інших бібліотек C.
run0 та нова модель привілеїв: альтернатива sudo
Ще однією важливою особливістю systemd 259 є утиліта run0, запропонований як сучасна та безпечніша заміна sudoЦей інструмент вже був створений на базі systemd-run, але тепер він отримав ключову можливість: опцію --empower.
Новий аргумент `--empower` дозволяє розпочати сеанс із підвищеними привілеями, не змінюючи свій UID на root . Замість традиційного перемикання користувача, `run0` використовує можливості ядра (такі як `CAP_SYS_ADMIN`), щоб надати саме ті дозволи, які необхідні для виконання привілейованих дій, зменшуючи ризик повного отримання root-прав.
Крім того, процеси, ініційовані за допомогою цього підходу, групуються в логічну групу "розширення прав" з доступом до широкого набору дій, якими керує Polkit . Ідея полягає в тому, що збільшення привілеїв є детальним та контрольованим, підтримуючи суворіший розподіл, ніж той, який зазвичай пропонує традиційний sudo, де доступ часто відкривається занадто широко.
Такий підхід відповідає тенденції уникати прямого використання користувача root, коли це можливо , що є високоцінним принципом безпеки. Однак справжня ефективність run0 все ще потребує демонстрації у виробництві: нам доведеться побачити, як він інтегрується з політиками кожного дистрибутива, як його можливості налаштовані на практиці та наскільки добре системне адміністрування адаптується до нового робочого процесу.
Кінець підтримки ініціалізації SysV та очищення застарілих версій
systemd 259 також знаменує собою початок остаточного кінця для сервісних скриптів у стилі System V. Сумісність з цими класичними механізмами роками позначалася як така, що «припиняється», і тепер встановлено чіткий графік їх видалення.
У цій версії повідомляється, що, з огляду на наступний великий реліз, Історичні компоненти, такі як systemd-sysv-generator, systemd-rc-local-generator та systemd-sysv-install, будуть видалені.Тобто, скрипти в /etc/init.d/ Вони більше не враховуватимуться systemd, що завершить перехідний період, який тривав майже десять років.
Для адміністраторів, які досі підтримують користувацькі служби на основі скриптів SysV , це означає, що потрібно взятися за роботу: усі ці скрипти потрібно інвентаризувати та перенести до рідних одиниць systemd (.service, .socket тощо). Великі дистрибутиви вже майже повністю завершили цей перехід, але в користувацьких середовищах або старіших інсталяціях деякі «релікти» все ще можуть працювати у фоновому режимі.
Цей процес очищення від застарілих систем не обмежується лише SysV. Останні версії systemd вже видаляють підтримку класичних методів, таких як `/forcefsck` та `/fastboot` , замінюючи їх параметрами ядра та сучаснішими механізмами облікових даних. У версії 259 напрямок той самий: менше зворотної сумісності в обмін на більш зручну в обслуговуванні та узгоджену кодову базу.
Мінімальні вимоги systemd 259: ядро, бібліотеки та середовище
Одна зі змін, яка може мати найбільший вплив на старіші системи, — це збільшення мінімальних вимог до програмного забезпечення для запуску systemd 259. Ця версія більше не звертає уваги на дуже старе обладнання чи стеки та явно орієнтована на сучасні платформи.
Серед ключових вимог, закріплених у systemd 259, є: відданість сучасним платформам
- Ядро Linux версії не менше 5.10 (з рекомендацією перейти хоча б на версію 5.14).
- glibc 2.34 як мінімальна версія стандартної бібліотеки GNU.
- Відкрийте SSL 3.0.0 як обов'язкова основа для підтримуваних функцій шифрування.
- util-linux 2.37 як вимога для основних утиліт системи.
- libxcrypt 4.4.0 для управління криптографічними функціями, пов'язаними з паролями.
- cryptsetup 2.4.0 та libseccomp 2.4.0 для шифрування томів та фільтрації системних викликів.
- Python 3.9.0 як мінімальна залежність від допоміжних інструментів.
- У деяких нотатках також згадується elfutils 0.177 як частину оновленого набору залежностей.
Це посилення означає, що дуже старі системи або дистрибутиви, що чіпляються за гілки ядра до версії 5.10, автоматично виключаються з підтримки цієї версії, якщо вони не оновлять свою базову технологію. Натомість досягається більш однорідна екосистема з меншою кількістю особливих випадків та компромісних рішень.
Для більшості універсальних дистрибутивів для настільних комп'ютерів та серверів ці вимоги не повинні бути проблемою: сучасні гілки ядра LTS вже значно перевищують бар'єр 5.10 , а згадані бібліотеки широко доступні. Найбільші проблеми можуть виникнути у вбудованих системах, пристроях або дуже консервативних інсталяціях, які не оновлюються часто.
Посилена безпека: TPM 2.0, шифрування та обмеження пристроїв
У сфері безпеки systemd 259 прискорює свій прогрес завдяки кільком важливим рішенням. Найбільш помітним є остаточне припинення підтримки TPM 1.2 у systemd-boot та systemd-stub , тож відтепер еталонним стандартом вважатиметься лише TPM 2.0.
Ця зміна означає, що системам, які використовували TPM 1.2 для керування політиками безпечного завантаження або ключами шифрування, потрібно буде оновити своє обладнання (наприклад, замінити материнську плату), якщо вони хочуть продовжувати використовувати ці функції з новішими версіями systemd-boot. Багато користувачів настільних комп’ютерів Linux вимкнули TPM та Secure Boot, тому вони можуть навіть не помітити змін, але це може вплинути на корпоративні середовища або середовища з високим рівнем безпеки.
У попередніх випусках, таких як systemd 258, у цій області вже було внесено значні зміни: OpenSSL стала єдиною бібліотекою шифрування, що підтримується systemd-resolved та systemd-importd , залишивши поза увагою такі альтернативи, як GnuTLS та libgcrypt. Все це вказує на консолідацію навколо меншого, більш контрольованого набору криптографічних інструментів.
Також у гілці 258 було запроваджено суворіші обмеження доступу за замовчуванням для tty/pts : вузли створюються з правами доступу 0600 замість 0620, що забороняє іншим користувачам записувати дані в наші термінали. Це ще один приклад того, як systemd протягом деякого часу налаштовував низькорівневі деталі, що в поєднанні зміцнює загальну безпеку системи.
libsystemd є більш модульною та динамічно завантажується.
У прагненні до більшої ефективності та зменшення навантаження залежностей, systemd 259 вносить суттєві зміни у взаємодію libsystemd з іншими системними бібліотеками . Мета полягає в тому, щоб запобігти перенесенню всього з самого початку, а натомість завантажувати його лише за потреби.
Зокрема, libsystemd тепер використовує dlopen() для динамічного завантаження бібліотек, таких як libacl, libblkid, libseccomp, libselinux та libmount . Це означає, що ці залежності не є жорстко пов'язаними під час компіляції, а також не завжди завантажуються в пам'ять: вони активуються лише тоді, коли цього вимагає певна функція.
Цей самий механізм з `dlopen()` також застосовується до інтеграції з підсистемою аудиту Linux та PAM . Таким чином, запуск systemd та його звичайна робота можуть бути легшими в середовищах, які не потребують усіх цих компонентів одночасно.
З іншого боку, функціональність, яку раніше надавала бібліотека libcap, була безпосередньо інтегрована в libsystemd . Це усуває ще одну зовнішню залежність, спрощує ланцюжок збірки та зменшує потенційні точки збою або несумісності.
Загалом, цей підхід забезпечує кращу модульність та менший обсяг пам'яті й дискового простору , особливо в системах, де потрібні швидке завантаження та щільно упакований набір служб.
Зміни в мережі та контейнерах: прощавай, iptables, привіт, nftables
Область мереж та віртуалізації також зазнає значних змін. Починаючи з версії systemd 259, systemd-networkd та systemd-nspawn більше не підтримують створення правил NAT за допомогою iptables/libiptc . Єдиним підтримуваним сервером брандмауера стає nftables.
Це безпосередньо впливає на контейнери, керовані за допомогою systemd-nspawn, які покладалися на NAT через iptables , а також на мережі, визначені в systemd-networkd, які використовували правила трансляції адрес із класичним бекендом. У тестах з реліз-кандидатами спостерігалися тихі збої у функціональності NAT, доки вся конфігурація не була перенесена до nftables.
Окрім перекладу адрес, systemd-resolved отримує можливість використовувати локальні перехоплювачі (hooks). en /run/systemd/resolve.hook/Ці команди виконуються щоразу, коли виконується локальний запит на розв'язання імен. Це відкриває адміністратору доступ до розширених налаштувань DNS та специфічної логіки.
У сфері імпорту та управління зображеннями, systemd-importd включає вбудовану логіку для роботи з TAR-файлами, спираючись на libarchive з утиліти GNU tar. Крім того, systemd-importd та systemd-machined тепер можна запускати в режимі користувача, керуючи образами системи, розміщеними в ~/.local/state/machines/.
Для керування цими режимами утиліта importctl додає опції "--user" та "--system" , що дозволяє легко вибрати, чи працювати в контексті користувача, чи на рівні системи. Такий підхід корисний для середовищ розробки та тестування, де ви не хочете змінювати глобальну конфігурацію машини.
Постійне ведення журналу за замовчуванням та управління дисковим простором
Ще однією зміною з практичним впливом є модифікація режим зберігання журналу за замовчуванням, підсистема ведення журналу systemd. Досі «автоматична» поведінка залежала від існування чи відсутності каталогу /var/log/journal.
У systemd 259 режим за замовчуванням стає "постійним ", незалежно від того, чи існувала папка раніше. Це означає, що журнал за замовчуванням буде постійно збережено на диску, а не в енергозалежній оперативній пам'яті.
Це рішення має свої плюси та мінуси. З одного боку, воно значно спрощує усунення несправностей , оскільки журнали зберігаються після перезавантаження, не вимагаючи жодних спеціальних дій від адміністратора. З іншого боку, у вбудованих системах, легких контейнерах або середовищах з дуже обмеженим обсягом пам'яті це може призвести до значного збільшення використання дискового простору.
У цих сценаріях буде важливіше, ніж будь-коли, налаштувати політики ротації та розміру журналів або навіть примусово вибрати інший режим зберігання, якщо ви хочете уникнути надмірного зносу (наприклад, у флеш-пам'яті з обмеженими циклами запису).
systemd-oomd, відстеження OOM та керування ресурсами
Керування пам'яттю та сценарії "Недостатньо пам'яті" також отримали значні покращення. Компонент systemd-oomd, відповідальний за реагування на ситуації з недостатньою пам'яттю , має нові властивості для кращої видимості.
Зокрема, властивості OOMKills та ManagedOOMKills тепер доступні для служб , які записують кількість процесів, завершених ядром або самим systemd-oomd через недостатню кількість пам'яті. До цієї інформації можна отримати доступ безпосередньо за допомогою інструментів systemd, що полегшує подальший аналіз інцидентів.
Коли процес виходить з-під контролю та починає «поглинати» оперативну пам’ять до такої міри, що це ставить під загрозу роботу системи , ці показники дозволяють одразу побачити, які пристрої постраждали, скільки разів спрацьовував механізм OOM та які компоненти створюють найбільше навантаження на пам’ять.
Для адміністраторів середовищ з високим навантаженням або систем з дуже обмеженими ресурсами ця більша можливість спостерігати за OOM особливо корисна, оскільки допомагає виявляти служби з поганим розміром або витоки пам'яті, які раніше могли залишатися непоміченими.
Інші помітні покращення в systemd 259
Окрім головних змін, згаданих вище, systemd 259 постачається з численними покращеннями та незначними налаштуваннями, розкиданими по всій екосистемі . Багато з них досить технічні, але варто їх переглянути, оскільки разом вони створюють значну зміну.
Серед нових функцій API, Інтерфейс на основі протоколу Varlink розширюється щоб дозволити доступ до конфігурації служби та виконувати IPC-виклики, такі як Reload() y Reexecute()Також додано спеціальні виклики для обробки функцій systemd-repart, systemd-resolved та systemd-networkd.
В області конфігурації та юнітів було введено опцію ExecReloadPost , яка дозволяє запускати команди одразу після перезавантаження конфігурації служби. Крім того, файли конфігурації, що закінчуються на ".ignore", тепер автоматично відкидаються , що є простим способом відключення файлів без необхідності їх видалення або кардинального перейменування.
Тимчасові одиниці отримують право власності Кореневий каталогДескриптор файлу, який визначає файловий дескриптор, що відповідає кореневому каталогу, та додається новий параметр Шлях до простору імен користувача, що дозволяє прив’язати диск до простору імен користувача, вказавши шлях у /procУ systemd-nspawn з'являється директива Шлях простору імен у розділі з файлів .nspawn, щоб вказати мережевий простір імен, який слід використовувати.
Інші компоненти, такі як systemd-sysext та systemd-confext містять спеціальні файли конфігурації en /etc/systemd/systemd-sysext.conf y /etc/systemd/systemd-confext.confЗмінні середовища SYSTEMD_SYSEXT_OVERLAYFS_MOUNT_OPTIONS y SYSTEMD_CONFEXT_OVERLAYFS_MOUNT_OPTIONS Вони дозволяють налаштувати параметри кріплення для накладок.
У світі udev додано опцію ОПЦІЇ=»dump-json» до systemd-udevd Щоб відобразити поточний стан події у форматі JSON, функція net_id Він генерує передбачувані імена для бездротових інтерфейсів у системах з DeviceTree та створює символічні посилання. /dev/gpio/by-id/... для пристроїв GPIO.
Розділ користувачів та облікових записів також посилюється: База даних користувачів містить поле UUIDУтиліта userdbctl підтримує параметр "-uuid" для пошуку за цим ідентифікатором, а також homectl update Тепер підтримується параметр "--recovery-key" для додавання ключів відновлення до існуючих облікових записів.
У systemd-homed опції "--prompt-shell" та "--prompt-groups" додаються під час першого завантаження за допомогою systemd-homed-firstboot.service, а в systemd-firstboot з'являється "--prompt-keymap-auto", щоб запитувати розкладку клавіатури під час використання локальної консолі під час першого завантаження.
El Менеджер завантаження systemd-boot додає можливість визначати рівень деталізації журналу. з параметром log-level en loader.conf або за допомогою поля SMBIOS io.systemd.boot.loglevelКрім того, для розділів, таких як XBOOTLDR, які тепер повинні бути у форматі VFAT, встановлюються суворіші вимоги, що відповідає вже існуючим вимогам ESP у сучасних системах UEFI.
На розширеному рівні мережевих технологій, systemd-networkd додає опції EmitDomain та Domain для DHCP-сервера та реалізує контролер, який визначає імена хостів, видані через DHCP, використовуючи роздільну здатність DNS. Тим часом, systemd-modules-load завантажує модулі ядра паралельно , зменшуючи час завантаження на системах з великою кількістю драйверів.
Нарешті, у розділі цілісності, systemd-integrity-setup додає підтримку алгоритмів HMAC-SHA256, PHMAC-SHA256 та PHMAC-SHA512 , розширюючи діапазон криптографічних опцій, доступних для захисту цілісності системи.
З усіма цими змінами systemd 259 зміцнює свою позицію як високотехнічної, вимогливої та явно орієнтованої на майбутнє версії . Вона спонукає користувачів відмовитися від застарілих технологій, таких як SysV init, iptables та TPM 1.2, посилює безпеку та контроль ресурсів, покращує внутрішню модульність та відкриває двері для нових конфігурацій з musl, хоча частково та умовно. Для кінцевих користувачів дистрибутивів з точковими випусками багато з цих нових функцій залишаться майже непоміченими; для адміністраторів та проектів, які постійно використовують останню версію, настав час ретельно переглянути скрипти, модулі та вимоги до обладнання, перш ніж переходити.
