- systemd 259 zavádza čiastočnú podporu pre musl, väčšiu modularitu v libsystemd a model privilégií vynútený pomocou run0 --empower.
- Latka požiadaviek sa zvyšuje: Linuxové jadro 5.10, glibc 2.34, OpenSSL 3.0.0 a ďalšie moderné knižnice sa stávajú povinnými minimami.
- Odchod starších systémov do dôchodku sa zrýchľuje: zbohom skriptom SysV, koniec podpory TPM 1.2, opustenie iptables a plné prijatie nftables.
- Zlepšujú pozorovateľnosť a bezpečnosť vďaka štandardnému trvalému denníku, novým metrikám OOMKills a viacerým úpravám v rámci sietí, kontajnerov a homed computingu.

Vydanie systemd 259 ako stabilnej verzie predstavuje ďalší zvrat v jednej z najkontroverznejších a najdôležitejších súčastí ekosystému Linuxu. Hovoríme o rámci pre iniciovanie a správu služieb, ktorý už dominuje väčšine distribúcií, a toto vydanie ešte viac uťahuje skrutky, pokiaľ ide o technické požiadavky, bezpečnosť a opustenie starších technológií.
Táto aktualizácia prichádza po niekoľkých mesiacoch intenzívnej práce a zameriava sa na tri hlavné oblasti: kompatibilitu s novými knižnicami jazyka C, vylepšené zabezpečenie a vyčistenie staršieho kódu (skripty SysV, TPM 1.2, iptables atď.). Zavádza tiež významné zmeny v správe privilégií pomocou run0, manipulácii s pamäťou pomocou systemd-oomd, ukladaní protokolov a internom modeli závislostí knižnice libsystemd.
systemd 259 a experimentálna podpora pre musl
Jednou z najdiskutovanejších funkcií tejto verzie je, že systemd 259 po prvýkrát obsahuje čiastočnú podporu pre štandardnú knižnicu jazyka C musl . Táto knižnica sa široko používa v ľahkých systémoch, minimalistických kontajneroch a vstavaných prostrediach, kde je požadovaná jednoduchosť a znížená spotreba zdrojov v porovnaní s glibc.
Podpora pre musl sa aktivuje nastavením možnosti „libc“ v zostavovacom systéme Meson na hodnotu „musl“ . Táto integrácia však zďaleka nie je úplná: musl neimplementuje mechanizmus Name Service Switch (NSS), ktorý pri kompilácii s touto knižnicou vynúti deaktiváciu niekoľkých častí systemd.
Konkrétne, zostavenie systemd 259 s musl vylučuje kľúčové komponenty ako nss-systemd, nss-resolve, systemd-homed, systemd-userdbd a systemd-nsresourced . Možnosť DynamicUser a možnosť spustiť systemd-nspawn bez privilégií tiež nie sú k dispozícii, čo je obzvlášť dôležité v kontajnerových prostrediach, ktoré sa na tieto funkcie vo veľkej miere spoliehajú.
Samotní vývojári uznávajú, že nemôžu zaručiť dlhodobú podporu . Jej pokračovanie bude závisieť od skutočného záujmu komunity, vyspelosti ďalších vrstiev, ktoré poskytujú funkcie, ktoré knižnici musia chýbať, a od hlásení chýb špecifických pre túto knižnicu. Ak bude dopyt nízky alebo sa údržba ukáže ako príliš zložitá, nebolo by prekvapujúce, keby sa táto podpora v budúcich verziách prehodnotila.
Toto otvorenie sa knižnici musl je však dôležité na symbolickej úrovni: systemd bol roky kritizovaný za svoju takmer výlučnú závislosť od glibc , čo ho robilo nepriateľským voči alternatívnym distribúciám a veľmi minimalistickým scenárom. Tento krok síce nerieši všetko, ale boří obraz systému úplne uzavretého voči iným knižniciam jazyka C.
run0 a nový model privilégií: alternatíva k sudo
Ďalšou dôležitou funkciou systemd 259 je utilita run0, navrhnutý ako moderná a bezpečnejšia náhrada za sudoTento nástroj bol už vytvorený na systemd-run, ale teraz získava kľúčovú funkciu: možnosť --empower.
Nový argument `--empower` vám umožňuje spustiť reláciu so zvýšenými oprávneniami bez zmeny UID na root . Namiesto tradičného prepínača používateľa `run0` využíva možnosti jadra (ako napríklad `CAP_SYS_ADMIN`) na udelenie presne tých oprávnení, ktoré sú potrebné na vykonávanie privilegovaných akcií, čím sa znižuje riziko úplného získania root oprávnení.
Okrem toho sú procesy iniciované týmto prístupom zoskupené do logickej skupiny „posilnenie“ s prístupom k širokej sade akcií spravovaných Polkitom . Myšlienka je taká, že zvyšovanie privilégií je podrobné a kontrolované, pričom sa zachováva prísnejšie oddelenie, než aké zvyčajne ponúka tradičný príkaz sudo, kde je prístup často otvorený príliš široko.
Tento prístup je v súlade s trendom vyhýbania sa priamemu použitiu používateľa root, kedykoľvek je to možné , čo je vysoko cenený bezpečnostný princíp. Skutočná účinnosť run0 sa však ešte musí preukázať v produkčnom prostredí: uvidíme, ako sa integruje s politikami každej distribúcie, ako sú jeho funkcie nakonfigurované v praxi a ako dobre sa systémová administrácia prispôsobí novému pracovnému postupu.
Koniec podpory pre inicializáciu SysV a čistenie starších verzií
Verzia systemd 259 tiež označuje začiatok definitívneho konca servisných skriptov v štýle System V. Kompatibilita s týmito klasickými mechanizmami bola roky označená ako „na konci“ a teraz bol stanovený jasný harmonogram ich odstránenia.
Táto verzia oznamuje, že s výhľadom na ďalšie významné vydanie, Historické komponenty ako systemd-sysv-generator, systemd-rc-local-generator a systemd-sysv-install budú odstránené.To znamená, že skripty v /etc/init.d/ Systemd ich už nebude brať do úvahy, čím sa uzatvára prechodný proces, ktorý trval takmer desaťročie.
Pre administrátorov, ktorí stále spravujú vlastné služby založené na skriptoch SysV , to znamená pustiť sa do práce: všetky tieto skripty je potrebné inventarizovať a migrovať do natívnych jednotiek systemd (.service, .socket atď.). Veľké distribúcie už takmer celý tento prechod dokončili, ale vo vlastných prostrediach alebo starších inštaláciách môžu niektoré „pozostatky“ stále bežať na pozadí.
Tento proces čistenia starších systémov sa neobmedzuje len na SysV. Nedávne verzie systemd už odstraňujú podporu pre klasické metódy ako `/forcefsck` a `/fastboot` a nahrádzajú ich parametrami jadra a modernejšími mechanizmami poverení. S verziou 259 je smer rovnaký: menej spätnej kompatibility výmenou za udržiavateľnejšiu a konzistentnejšiu kódovú základňu.
Minimálne požiadavky systemd 259: jadro, knižnice a prostredie
Jednou zo zmien, ktorá môže mať najväčší vplyv na staršie systémy, je zvýšenie minimálnych softvérových požiadaviek na spustenie systemd 259. Táto verzia sa už nestará o veľmi starý hardvér ani stacky a jednoznačne sa zameriava na moderné platformy.
Medzi kľúčové požiadavky zlúčené v systemd 259 patria: záväzok k moderným platformám
- Linuxové jadro minimálne 5.10 (s odporúčaním prejsť aspoň na 5.14).
- glibc 2.34 ako minimálna verzia štandardnej knižnice GNU.
- Otvorte SSL 3.0.0 ako povinný základ pre podporované šifrovacie funkcie.
- util-linux 2.37 ako požiadavka pre základné funkcie systému.
- libxcrypt 4.4.0 na správu kryptografických funkcií súvisiacich s heslami.
- cryptsetup 2.4.0 a libseccomp 2.4.0 pre šifrovanie zväzkov a filtrovanie systémových volaní.
- Python 3.9.0 ako minimálna závislosť od pomocných nástrojov.
- V niektorých poznámkach sa tiež spomína elfutils 0.177 ako súčasť aktualizovanej sady závislostí.
Toto sprísnenie znamená, že veľmi staré systémy alebo distribúcie, ktoré sa držia vetiev jadra pred verziou 5.10, sú automaticky vylúčené z podpory pre túto verziu, pokiaľ neaktualizujú svoju základnú technológiu. Na oplátku sa dosiahne homogénnejší ekosystém s menším počtom špeciálnych prípadov a kompromisných riešení.
Pre väčšinu univerzálnych distribúcií desktopových a serverových systémov by tieto požiadavky nemali byť problémom: moderné vetvy jadra LTS už ďaleko prekračujú hranicu 5.10 a spomínané knižnice sú široko dostupné. Najväčšie problémy môžu nastať vo vstavaných systémoch, zariadeniach alebo veľmi konzervatívnych inštaláciách, ktoré sa často neaktualizujú.
Vylepšené zabezpečenie: TPM 2.0, šifrovanie a obmedzenia zariadení
V oblasti bezpečnosti systemd 259 zrýchľuje svoj pokrok niekoľkými významnými rozhodnutiami. Najviditeľnejším je, že systemd-boot a systemd-stub definitívne ukončujú podporu pre TPM 1.2 , takže odteraz sa za referenčný štandard považuje iba TPM 2.0.
Táto zmena znamená, že systémy, ktoré sa spoliehali na TPM 1.2 na správu politík zabezpečeného spúšťania alebo šifrovacích kľúčov, budú musieť mať aktualizovaný hardvér (napríklad výmenou základnej dosky), ak chcú tieto funkcie naďalej používať s novšími verziami systemd-boot. Mnoho používateľov desktopových systémov Linux má TPM a Secure Boot vypnuté, takže si túto zmenu možno ani nevšimnú, ale mohla by mať vplyv na firemné alebo vysoko zabezpečené prostredia.
V predchádzajúcich vydaniach, ako napríklad systemd 258, už boli v tejto oblasti vykonané významné úpravy: OpenSSL sa stal jedinou šifrovacou knižnicou podporovanou nástrojmi systemd-resolved a systemd-importd , čím sa vynechali alternatívy ako GnuTLS a libgcrypt. To všetko poukazuje na konsolidáciu okolo menšej a kontrolovanejšej sady kryptografických nástrojov.
Vo vetve 258 boli tiež zavedené prísnejšie štandardné obmedzenia prístupu pre tty/pts : uzly sú vytvorené s oprávneniami 0600 namiesto 0620, čo bráni ostatným používateľom v zápise do našich terminálov. Toto je ďalší príklad toho, ako systemd už nejaký čas dolaďuje detaily na nízkej úrovni, čo v kombinácii posilňuje celkovú bezpečnosť systému.
Balík libsystemd je modulárnejší a dynamicky sa načítava.
V snahe o väčšiu efektivitu a zníženie závislostí zavádza systemd 259 zásadné zmeny v spôsobe, akým libsystemd interaguje s inými systémovými knižnicami . Cieľom je zabrániť prenosu všetkého od začiatku, namiesto toho sa to načíta iba vtedy, keď je to potrebné.
Konkrétne, libsystemd teraz používa dlopen() na dynamické načítanie knižníc ako libacl, libblkid, libseccomp, libselinux a libmount . To znamená, že tieto závislosti nie sú počas kompilácie pevne prepojené ani nie sú vždy načítané do pamäte: aktivujú sa iba vtedy, keď ich vyžaduje konkrétna funkcia.
Rovnaký mechanizmus s funkciou `dlopen()` platí aj pre integráciu so subsystémom auditu Linuxu a PAM . Týmto spôsobom môže byť spustenie systemd a bežná prevádzka jednoduchšia v prostrediach, ktoré nevyžadujú všetky tieto komponenty súčasne.
Na druhej strane, funkcionalita, ktorú predtým poskytovala knižnica libcap, bola priamo integrovaná do knižnice libsystemd . To eliminuje ďalšiu externú závislosť, zjednodušuje reťazec zostavovania a znižuje potenciálne body zlyhania alebo nekompatibility.
Vo všeobecnosti tento prístup poskytuje lepšiu modularitu a menšiu pamäťovú a diskovú zaťaženosť , najmä v systémoch, kde sú požadované rýchle časy spúšťania a husto usporiadaná sada služieb.
Zmeny v sieti a kontajneroch: zbohom iptables, ahoj nftables
Oblasť sietí a virtualizácie tiež prechádza významnými zmenami. Počnúc verziou systemd 259, systemd-networkd a systemd-nspawn už nepodporujú vytváranie pravidiel NAT pomocou iptables/libiptc . Jediným podporovaným backendom firewallu sa stáva nftables.
Toto priamo ovplyvňuje kontajnery spravované pomocou systemd-nspawn, ktoré sa spoliehali na NAT prostredníctvom iptables , ako aj siete definované v systemd-networkd, ktoré používali pravidlá prekladu adries s klasickým backendom. V testoch s kandidátmi na verziu boli pozorované tiché zlyhania vo funkčnosti NAT, kým nebola celá konfigurácia migrovaná do nftables.
Okrem prekladu adries, systemd-resolved získava možnosť používať lokálne hooky en /run/systemd/resolve.hook/Tieto príkazy sa vykonávajú vždy, keď sa vykoná lokálny dotaz na rozlíšenie názvov. To otvára dvere k pokročilým prispôsobeniam DNS a špecifickej logike zo strany správcu.
V oblasti importu a správy obrázkov, systemd-importd obsahuje natívnu logiku pre prácu so súbormi TAR, pričom sa spolieha na libarchive z utility GNU tar. Okrem toho je teraz možné spustiť systemd-importd aj systemd-machined v používateľskom režime a spravovať obrazy systému umiestnené v ~/.local/state/machines/.
Na ovládanie týchto režimov pridáva utilita importctl možnosti „--user“ a „--system“ , ktoré vám umožňujú jednoducho si vybrať, či chcete pracovať v kontexte používateľa alebo na úrovni systému. Tento prístup je užitočný pre vývojové a testovacie prostredia, kde nechcete upravovať globálnu konfiguráciu počítača.
Trvalé zapisovanie do denníka v predvolenom nastavení a správa miesta na disku
Ďalšou zmenou s praktickým dopadom je úprava predvolený režim ukladania denníka, logovací podsystém systemd. Doteraz „automatické“ správanie záviselo od existencie alebo neexistencie adresára /var/log/journal.
V systemd 259 sa predvolený režim zmení na „perzistentný “ bez ohľadu na to, či priečinok predtým existoval. To znamená, že denník sa štandardne natrvalo uloží na disk, namiesto toho, aby sa uložil do volatilnej pamäte RAM.
Toto rozhodnutie má výhody aj nevýhody. Na jednej strane výrazne zjednodušuje riešenie problémov , pretože protokoly prežijú reštartovanie bez nutnosti akéhokoľvek špeciálneho zásahu zo strany správcu. Na druhej strane, vo vstavaných systémoch, ľahkých kontajneroch alebo prostrediach s veľmi obmedzeným úložiskom to môže viesť k výraznému zvýšeniu využitia disku.
V týchto scenároch bude dôležitejšie ako kedykoľvek predtým upraviť pravidlá rotácie a veľkosti žurnálov alebo dokonca vynútiť iný režim úložiska, ak sa chcete vyhnúť nadmernému opotrebovaniu (napríklad vo flash pamätiach s obmedzenými cyklami zápisu).
systemd-oomd, sledovanie OOM a riadenie zdrojov
Správa pamäte a scenáre „Nedostatok pamäte“ tiež dostávajú výrazné vylepšenia. Komponent systemd-oomd, zodpovedný za reakciu na situácie s nedostatkom pamäte , obsahuje nové vlastnosti pre lepšiu viditeľnosť.
Konkrétne sú teraz k dispozícii vlastnosti OOMKills a ManagedOOMKills pre služby , ktoré zaznamenávajú počet procesov ukončených jadrom alebo samotným systemd-oomd z dôvodu nedostatku pamäte. K týmto informáciám je možné pristupovať priamo pomocou nástrojov systemd, čo uľahčuje následnú analýzu incidentov.
Keď sa proces vymkne spod kontroly a začne „hltať“ pamäť RAM do takej miery, že ohrozuje systém , tieto metriky vám umožnia na prvý pohľad vidieť, ktoré jednotky boli ovplyvnené, koľkokrát bol spustený mechanizmus OOM a ktoré komponenty spôsobujú najväčší tlak na pamäť.
Pre správcov vysoko zaťažených prostredí alebo systémov s veľmi obmedzenými zdrojmi je táto väčšia schopnosť pozorovať OOM obzvlášť užitočná, pretože pomáha identifikovať služby s nízkou veľkosťou alebo úniky pamäte, ktoré by predtým mohli zostať nepovšimnuté.
Ďalšie významné vylepšenia v systemd 259
Okrem vyššie uvedených hlavných zmien prichádza systemd 259 s množstvom vylepšení a menších úprav roztrúsených po celom ekosystéme . Mnohé sú dosť technické, ale stojí za to si ich pozrieť, pretože spolu predstavujú významnú zmenu.
Medzi nové funkcie rozhrania API patria Rozhranie založené na protokole Varlink sa rozširuje umožniť prístup ku konfigurácii služby a vykonávať IPC volania, ako napríklad Reload() y Reexecute()Pridané sú aj špecifické volania na spracovanie funkcií systemd-repart, systemd-resolved a systemd-networkd.
V oblasti konfigurácie a jednotiek bola zavedená možnosť ExecReloadPost , ktorá umožňuje spustenie príkazov ihneď po opätovnom načítaní konfigurácie služby. Okrem toho sa konfiguračné súbory s príponou „.ignore“ teraz automaticky zahodia , čo je jednoduchý trik na deaktiváciu súborov bez nutnosti ich mazania alebo drastického premenovania.
Dočasné jednotky získavajú vlastníctvo Koreňový adresárSúborovýDescriptor, ktorý definuje deskriptor súboru zodpovedajúci koreňovému adresáru a pridá sa nová možnosť Cesta k priestoru názvov používateľa, ktorý umožňuje prepojiť disk s menným priestorom používateľa zadaním cesty v /procV systemd-nspawn sa zobrazí direktíva Cesta k mennému priestoru v sekcii zo súborov .nspawn na označenie sieťového menného priestoru, ktorý sa má použiť.
Ďalšie komponenty, ako napr. systemd-sysext a systemd-confext obsahujú vyhradené konfiguračné súbory en /etc/systemd/systemd-sysext.conf y /etc/systemd/systemd-confext.confPremenné prostredia SYSTEMD_SYSEXT_OVERLAYFS_MOUNT_OPTIONS y SYSTEMD_CONFEXT_OVERLAYFS_MOUNT_OPTIONS Umožňujú vám upraviť možnosti montáže pre Overlayfs.
Vo svete udev je pridaná možnosť MOŽNOSTI = »dump-json« do systemd-udevd Na zobrazenie aktuálneho stavu udalosti vo formáte JSON slúži funkcia net_id Generuje predvídateľné názvy pre bezdrôtové rozhrania v systémoch s DeviceTree a vytvára symbolické odkazy. /dev/gpio/by-id/... pre GPIO zariadenia.
Sekcia pre používateľov a účty sa tiež posilňuje: Databáza používateľov obsahuje pole UUIDNástroj userdbctl podporuje možnosť „-uuid“ na vyhľadávanie podľa tohto identifikátora a homectl update Teraz podporuje „--recovery-key“ na pridanie obnovovacích kľúčov k existujúcim účtom.
V systemd-homed sú možnosti „--prompt-shell“ a „--prompt-groups“ začlenené počas prvého spustenia pomocou systemd-homed-firstboot.service a v systemd-firstboot sa zobrazí „--prompt-keymap-auto“, ktorá pri prvom spustení pri použití lokálnej konzoly vyžiada mapu klávesnice.
El Správca zavádzania systemd-boot pridáva možnosť definovať úroveň detailov protokolu. s parametrom log-level en loader.conf alebo pomocou poľa SMBIOS io.systemd.boot.loglevelOkrem toho sa konsolidujú prísnejšie požiadavky na oddiely, ako napríklad XBOOTLDR, ktoré musia byť teraz vo formáte VFAT, v súlade s tým, čo sa už vyžaduje od ESP v moderných systémoch UEFI.
Na pokročilej úrovni sietí systemd-networkd pridáva možnosti EmitDomain a Domain pre DHCP server a implementuje radič, ktorý určuje názvy hostiteľov vydané prostredníctvom DHCP pomocou DNS rozpoznávania. systemd-modules-load zároveň načítava moduly jadra paralelne , čím skracuje časy zavádzania na systémoch s mnohými ovládačmi.
Nakoniec, v sekcii integrity, systemd-integrity-setup pridáva podporu pre algoritmy HMAC-SHA256, PHMAC-SHA256 a PHMAC-SHA512 , čím rozširuje rozsah kryptografických možností dostupných na ochranu integrity systému.
Vďaka všetkým týmto zmenám si systemd 259 upevňuje pozíciu vysoko technickej, náročnej a jasne na budúcnosť orientovanej verzie . Núti používateľov opustiť staršie technológie ako SysV init, iptables a TPM 1.2, posilňuje bezpečnosť a kontrolu zdrojov, zlepšuje vnútornú modularitu a otvára dvere novým konfiguráciám s musl, aj keď čiastočne a podmienečne. Pre koncových používateľov na distribúciách s jednotlivými vydaniami zostanú mnohé z týchto nových funkcií takmer bez povšimnutia; pre administrátorov a projekty, ktoré neustále používajú najnovšiu verziu, je čas pred prechodom starostlivo skontrolovať skripty, jednotky a hardvérové požiadavky.