- A systemd 259 kísérleti támogatást vezet be a musl-hoz, és megerősíti a rendszerindítási biztonságot azáltal, hogy csak a TPM 2.0-ra összpontosít.
- Ez a verzió fejlesztéseket tartalmaz a run0, a systemd-oomd és a belső infrastruktúra számára, új IPC-képességekkel és párhuzamos modulbetöltéssel.
- A minimális rendszerkövetelményeket emelik, a systemd-t a modern platformokhoz igazítják, és elhagyják a túl régi környezeteket.
- A stabil disztribúciók, mint például a Linux Mint 22.3, konzervatívabb megközelítést alkalmaznak, integrálják a systemd korábbi verzióit, és az asztali élményt helyezik előtérbe.
A systemd 259-es verziójával a Linux ökoszisztéma ismét jelentős változásokon megy keresztül. A GNU/Linuxban legszélesebb körben használt rendszerkeretrendszer ezen verziója mélyreható változásokat vezet be a kompatibilitás, a biztonság és az erőforrás-kezelés terén, amelyek messze túlmutatnak egy egyszerű rutinfrissítésen. Bár ezek az új funkciók technikai jellegűek, közvetlen következményekkel járnak a disztribúciók, a rendszergazdák és a haladó felhasználók számára egyaránt.
Ebben a kiadásban a systemd kulcsfontosságú fordulatot vesz azzal, hogy megnyitja az utat a musl előtt, mint a glibc alternatívája, szigorítja a minimális követelményeit, megerősíti álláspontját a TPM 2.0-val történő biztonságos rendszerindítás mellett, továbbra is népszerűsíti a run0-t sudo helyettesítőként, és finomítja a systemd-oomd viselkedését a memóriafogyasztás jobb szabályozása érdekében. Mindezt úgy, hogy megőrzi a projektet évek óta kísérő kiterjedt és ellentmondásos jelleget.
systemd, a modern Linux központi és ellentmondásos darabja
Manapság a systemd az alapértelmezett rendszer keretrendszer a legtöbb általános célú GNU/Linux disztribúcióban: kezeli a rendszerindítást, a szolgáltatásokat, a naplózást, a felhasználói munkameneteket és számos alacsony szintű feladatot, amelyek korábban több eszköz között voltak elosztva. Az egyre több funkció integrálásának filozófiája óriási jelentőséget adott neki a rendszeren belül.
A kritikus folyamatok, függőségek és segédprogramok központosításának képessége széles körű elterjedéshez vezetett, de heves vitákat is kiváltott a közösségen belül. Sokak számára leegyszerűsíti az adminisztrációt és szabványosítja a gyakorlatokat; mások számára egyetlen meghibásodási pontot és nehezen auditálható komplexitást jelent, mivel túl sok felelősség koncentrálódik ugyanarra a projektre.
Már több verzió esetében is őrült tempójú a fejlesztés, a gyakori kiadások új komponenseket, interfészeket és belső fejlesztéseket adnak hozzá . A systemd 259 tökéletesen illeszkedik ebbe a trendbe: nem csak apró módosításokat hoz, hanem stratégiai döntéseket is, amelyek befolyásolják a disztribúciók fordítását, a rendszerek indítását és az erőforrások kezelését nyomás alatt.
Ebben az összefüggésben a systemd 259 fordulópontot jelent a C könyvtárak kompatibilitása, a biztonsági hardvertámogatás, a jogosultság-eszkalációs eszközök és a platformkövetelmények terén, tovább erősítve a systemd szerepét az operációs rendszer középpontjában.
Kísérleti támogatás a muszlimoknak: búcsút inthetünk a glibc monopóliumának
A leginkább figyelemfelkeltő fejlemény a musl kísérleti támogatásának megjelenése a systemd 259-ben. Eddig a projekt nagyon szorosan kapcsolódott a glibc-hez, a legtöbb hagyományos GNU/Linux disztribúció referencia C könyvtárához.
A musl egy pehelykönnyű C könyvtár, amelyet nagyra értékelnek minimalista rendszerekben , konténerekben és hatékonyságorientált disztribúciókban, mint például az Alpine Linux és más, az erőforrás-fogyasztás és a támadási felület csökkentésére összpontosító változatok. Évekig a systemd és a musl közötti kapcsolat bonyolult volt pontosan a glibc-től való függőség miatt.
Ezzel a lépéssel, bár még kísérleti fázisban van, a systemd már nem annyira kizárólagos a libc-vel való kapcsolatában . Ez megnyitja a valódi lehetőséget a systemd és a musl kombinálására olyan környezetekben, ahol korábban alternatív init rendszereket használtak, vagy a systemd-t kompatibilitási korlátok miatt teljesen elkerülték.
Ennek a támogatásnak az érkezése jelentős belső változásokkal jár: a fordítási feltételezéseket, a interfészeket és a specifikus glibc-hívásokat módosítani kellett , hogy a musl integrálható legyen a várt viselkedés felborulása nélkül. Rövid távon ez intenzív tesztelést igényel a forgalmazók és a haladó felhasználók részéről, de megalapozza a nagyobb technológiai sokszínűséget a Linux ökoszisztémán belül.
Ez a lépés a systemd más C könyvtárakhoz képest „zárt” jellegével kapcsolatos történelmi kritikákra is reagál . Bár a musl ebben a kontextusban még nem támogatott ugyanolyan fejlettségi szinten, mint a glibc, az a tény, hogy ebben az irányban történt munka, egyértelműen jelzi a látókör szélesítésére és a klasszikus GNU veremtől való merev függőségek csökkentésére irányuló vágyat.
Biztonságosabb rendszerindítás: csak TPM 2.0 a systemd-boot és a systemd-stub számára
A systemd 259 egy másik jelentős változása közvetlenül befolyásolja az UEFI rendszereken történő biztonságos rendszerindítást . A systemd-boot (az integrált rendszerindítás-kezelő) és a systemd-stub (az UEFI környezetekben történő rendszerindítás megkönnyítéséért felelős) összetevők már nem támogatják a TPM 1.2-t, kizárólag a TPM 2.0-ra összpontosítva.
A döntés mögött a biztonság megerősítése áll, mivel csak a TPM legrobusztusabbnak és naprakésznek tartott verzióját támogatják . A TPM 2.0 továbbfejlesztett kriptográfiai képességeket és rugalmasabb keretrendszert kínál olyan forgatókönyvekhez, mint a mért rendszerindítás, az integritás-ellenőrzés és a rendszerállapothoz kapcsolódó titkok lezárása.
A hátránya egyértelmű: azok a rendszerek, amelyek továbbra is a TPM 1.2-re támaszkodnak, nem kapnak támogatást ezekhez a funkciókhoz . A gyakorlatban ez azt jelentheti, hogy lecserélik az alaplapot, vagy elhagyják a systemd-boot és systemd-stub parancsokon alapuló bizonyos biztonságos rendszerindítási funkciókat, ha a hardver nincs frissítve.
Sok otthoni környezetben azonban a Secure Boot és a TPM gyakran le van tiltva a Linux telepítésekben, mind a kényelem, mind a meghajtóprogram-kompatibilitás, az alternatív rendszerindítási lehetőségek vagy a Windows kettős rendszerei közötti történelmi súrlódások miatt.
Ennek ellenére a TPM 2.0-val rendelkező biztonságos rendszerindítási lánctól függő vállalati vagy professzionális forgatókönyvek esetében ez a változás összhangban van az iparági trenddel: leegyszerűsíti a kódot azáltal, hogy kiküszöböli a korábbi kompatibilitást, és csökkenti a régebbi kriptográfiai veremekkel kapcsolatos kockázatokat.
A run0 súlygyarapodása modern alternatívája a sudo-nak
A systemd ökoszisztémában a leginkább kíváncsiságot felkeltő eszközök közé tartozik a run0, amelyet a sudo leváltására terveztek . A sudo évtizedek óta a de facto szabvány a parancsok emelt jogosultságokkal történő végrehajtására Unix-szerű rendszereken, de a kialakítása és konfigurációja történelmi tehetetlenséget hordoz magában.
A run0 használatával a systemd csapat a következőt keresi: integráltabb és ellenőrzöttebb megközelítést kínálni a privilégiumok eszkalációjáhozA 259-es verzió egy kulcsfontosságú új funkciót tartalmaz: az argumentumot. --empower, amely lehetővé teszi új munkamenet indítását megnövelt jogosultságokkal anélkül, hogy explicit módon a root felhasználóra váltanánk.
Ennek a lehetőségnek a filozófiája a root fiók közvetlen használatának további csökkentése , amit a biztonsági szakemberek mindig megpróbálnak elkerülni, vagy legalábbis a lehető legnagyobb mértékben korlátozni. A rootként való bejelentkezés vagy a privilegizált shellekkel való visszaélés helyett egy emelt szintű munkameneteken alapuló modellt javasolnak, finomabb szabályozással.
Ennek ellenére nem minden módszer egyforma a megemelt jogosultságok kezelésére, és a run0 széles körű elterjedése még korai szakaszban van . A rendszergazdáknak és a terjesztőknek fel kell mérniük, hogy a modellje jobban illeszkedik-e a sudo-nál az adott forgatókönyvekhez, figyelembe véve a naplózást, a meglévő eszközökkel való kompatibilitást és a bevett hozzáférési szabályzatokat.
Mindenesetre a run0 aktív fejlesztése azt jelzi, hogy a systemd nem korlátozódik a szolgáltatások koordinálására, hanem a rendszeradminisztráció több rétegét is lefedi , beleértve a jogosultságok napi kezelését is, amelyet eddig szinte teljes egészében külső segédprogramoknak delegáltak.
systemd-oomd: nagyobb kontroll a memóriaigényes folyamatok felett
A rendszer stabilitása szempontjából a systemd 259 megerősíti a systemd-oomd memóriahiány-kezelő szerepét . Ez a komponens felelős a RAM elfogyásakor történő reagálásért, szelektíven leállítva a folyamatokat, mielőtt a teljes rendszer lefagyna.
A legfontosabb új funkció az OOMKills és a ManagedOOMKills tulajdonságok hozzáadása a szolgáltatásegységekhez. Ezek a tulajdonságok lehetővé teszik annak megszámlálását, hogy a kernel vagy maga a systemd-oomd hány folyamatot szakított meg, így sokkal jobb rálátást biztosítva a memóriaválságok megoldására.
Ez az információ különösen hasznos, ha egy alkalmazás kontrollálatlanul kezdi fogyasztani a RAM-ot , legyen szó memóriaszivárgásról, helytelen konfigurációról vagy váratlan terhelésről. Azzal, hogy nyomon tudják követni, hányszor aktiválódott a pénzhiány (OOM) mechanizmus, a rendszergazdák észlelhetik a problémás mintákat, és módosíthatják a korlátokat, mielőtt a helyzet megismétlődne.
Az ötlet az, hogy a rendszer a teljes blokkolás helyett szelektíven leállítja a legkárosabb folyamatokat , megőrizve az általános válaszadási képességet. Mivel ezek a számlálók elérhetők a systemd egységekből, könnyebbé válik annak auditálása, hogy mely szolgáltatások a kritikus helyzetek visszatérő okai.
Összességében a systemd-oomd fejlesztései egy egyértelmű trendet erősítenek: az automatizált erőforrás-kezelést a katasztrofális hibák elleni első védelmi vonallá kell tenni , részletesebb mutatókkal és kevésbé átláthatatlan döntésekkel a rendszert kezelők számára.
Egyéb belső fejlesztések és releváns változások a systemd 259-ben
A főbb címszavakon túl a systemd 259 számos technikai módosítást tartalmaz, amelyek a keretrendszer különböző területeit csiszolják , és amelyek észrevétlenek maradhatnak, de gyakorlati hatással vannak a valós környezetekben.
Egyrészt a Varlink implementációja az IPC kommunikációhoz a szolgáltatáskezelőn belül kibővült, és most sokkal több képességet kínál. Ez megkönnyíti a külső eszközök és a felügyeleti rétegek számára a systemd-vel való gazdagabb és strukturáltabb interakciót, jobban kihasználva a kezelt belső információkat.
Az olyan komponensek, mint a systemd-udevd és a systemd-repart, szintén fejlesztéseken estek át a blokkeszközökön lévő partíciós táblák újraolvasása tekintetében. Az új megközelítés fokozatosabb és körültekintőbb, csökkentve az inkonzisztenciák vagy megszakítások kockázatát a partíciók gyorscseréje vagy a lemezek kezelése során összetett rendszerekben.
A systemd-boot a TPM-változások mellett mostantól különböző naplózási szinteket is tartalmaz , amelyek segítenek a rendszerindítási problémák hibakeresésében és az igényeknek megfelelő részletesség beállításában: a stabil környezetekhez szükséges csendesebb kilépésektől a diagnosztikai munkamenetek részletes naplóiig.
Egy másik érdekes szempont, hogy olyan funkciók, mint pl. Linux audit támogatás, PAM, libacl, libblkid, libseccomp, libselinux és libmount ezután felszámítják őket dlopen() a szabványos dinamikus linkelés helyett. Ez a stratégia csökkenti a bináris fájl alapsúlyát, és könnyebb környezeteket tesz lehetővé, ami különösen hasznos konténerekben, ahol nincs mindig szükség a teljes könyvtárkészletre.
Továbbá a systemd-modules-load mostantól párhuzamosan tölti be a kernel modulokat , felgyorsítva a rendszerindítási folyamatot a több konfigurált modullal rendelkező gépeken. Mivel a rendszerek egyre több funkciót tartalmaznak modulok formájában, ez a párhuzamosítás segít a modern CPU-k jobb kihasználásában.
A kriptográfiai területen a systemd-integrity-setup kibővítette a támogatott algoritmusok körét , és mostantól támogatja a HMAC-SHA256, PHMAC-SHA256 és PHMAC-SHA512 algoritmusokat, megerősítve a lehetőségek körét az érzékeny adatok és konfigurációk integritásának biztosítására.
Egy változás, amit sok rendszergazda észre fog venni, az az, hogy az alapértelmezett naplótárolási mód mostantól „állandó” az „automatikus” helyett. Ez azt jelenti, hogy amennyiben van támogatás, a naplók alapértelmezés szerint véglegesen lemezre kerülnek mentésre, megkönnyítve az auditokat és a diagnosztikát anélkül, hogy manuálisan kellene módosítani a kezdeti konfigurációt.
Szigorúbb minimumkövetelmények: csak modern platformokra
A 259-es verzió jelentősen megnöveli a systemd támogatott körülmények között történő futtatásához szükséges minimális rendszerkövetelményeket is. Ez a döntés megerősíti a modernebb platformokkal való összhangot.
A közzétett követelmények közül a glibc 2.34 emelkedik ki minimális verzióként , amely közvetlenül kizárja a nagyon régi C könyvtárakban rögzített környezeteket. A Linux 5.10 is szükséges kernel verzióként , bár a fejlesztők az 5.14-es ágat ajánlják a jelenlegi funkciókkal jobban összhangban lévő teljesítmény érdekében.
A kriptográfia területén az OpenSSL 3.0.0 lesz az új minimumszabvány , amely felülírja a korábbi verziókat, amelyek támogatási ciklusai a végéhez közelednek. A rendszer olyan függőségekkel is kiegészül, mint a cryptsetup 2.4.0 és a libseccomp 2.4.0, amelyek szükségesek a titkosítási és izolációs funkciók megfelelő használatához.
A systemd 259 bizonyos eszközökhöz és szkriptekhez Python 3.9-es vagy újabb verziót igényel , ami azt jelenti, hogy a régebbi Python ágakat tartalmazó rendszereket frissíteni kell, ha további javítások nélkül szeretnék fenntartani az integrált munkafolyamatokat.
Ezenkívül olyan alapvető komponensek is szerepelnek , mint a libxcrypt 4.4.0, az util-linux 2.37 és más felhasználói térbeli könyvtárak , amelyek mindegyike a technológiai bázis egységesítését célozza olyan verziókon, amelyek garantálják a biztonságot és az ökoszisztéma többi részével való konzisztenciát.
Mellékhatásként ezek a követelmények korlátozhatják a systemd 259 bevezetését régebbi hardvereken vagy nagyon konzervatív disztribúciókon , de ugyanakkor leegyszerűsítik a kódkarbantartást és csökkentik az elavult API-kkal való kompatibilitás átvitelének szükségességét.
A forgalmazásra és a végfelhasználóra gyakorolt hatás
A gyakorlatban a legtöbb asztali felhasználó számára a systemd frissítései általában nem kritikus pillanatok . A pontkiadású disztribúciókban (a tipikusak, amelyek rendszeresen frissülnek a főverziókkal) normális, hogy egy systemd verzió a teljes életciklusa alatt lefagy, kivéve a főbb biztonsági vagy stabilitási javításokat.
Azok, akik mindig a keretrendszer legújabb verzióját szeretnék használni, általában a gördülő kiadású disztribúciókat választják, mint például az Arch Linux vagy az openSUSE Tumbleweed, ahol a systemd 259 viszonylag hamar megérkezik, és gyorsan integrálódik a frissítési folyamatba.
Más projektek, mint például a Fedora, azt a politikát követik, hogy a systemd ugyanazt a főverzióját megtartják minden stabil kiadás élettartama alatt, ami nagyobb kiszámíthatóságot biztosít a legújabb nyers kiadáshoz képesti kismértékű késésért cserébe.
Eközben a származtatott disztribúciók univerzuma, mint például a Linux Mint vagy annak Ubuntu LTS-alapú változatai, hajlamosak szinkronizálni az alaprendszer ütemével, amelyre épülnek . Például a Linux Mint 22.3 tartalmazza a systemd 255-öt, és nem veszi át azonnal a 259-et, a stabilitást helyezve előtérbe a legújabb verzióért folytatott versennyel szemben.
A nyughatatlan rendszergazdák és az új funkciók iránt lelkesedők számára mindig ott a lehetőség, hogy a systemd 259-et tesztkörnyezetekben vagy gördülő disztribúciókban teszteljék , kiértékelve a kompatibilitást, a kulcsfontosságú szolgáltatásokra gyakorolt hatást és az adott hardverrel való viselkedést, mielőtt az éles környezetben történő migráción gondolkodnának.
Linux Mint 22.3 kontraszt: stabilitás kontra élvonalbeli
Ellenpontként érdemes megnézni a Linux Mint 22.3 "Zena " verzióját, amely jól mutatja, hogy egyes disztribúciók hogyan helyezik előtérbe a stabilitást, miközben a systemd ökoszisztéma továbbra is függetlenül fejlődik. Ez a verzió a jelenlegi sorozat legújabb frissítéseként kerül bemutatásra, és minden típusú felhasználó számára ajánlott, garantált támogatással 2029 áprilisáig.
A Mint 22.3 az Ubuntu LTS-en alapul , annak frissített, de konzervatív stackjével , és egy Linux 6.14 kernellel érkezik, amelyet többek között az AMD processzorok legújabb generációjának jobb támogatására terveztek. Tartalmazza a systemd 255-öt és a Mesa 25-öt is, modern környezetet teremtve az egyes komponensek legújabb verziójára való frissítés kockázata nélkül.
A disztribúció elsősorban az asztali felhasználói élmény finomítására összpontosít . A Cinnamon 6.6, a fő környezete, egy újratervezett, modernebb és rugalmasabb, lekerekített sarkokkal rendelkező alkalmazásmenüt, valamint egy oldalsávot tartalmaz, amely csoportosítja a felhasználói parancsikonokat, helyeket és kedvenc alkalmazásokat. A kategóriák háttérbe szorulnak, hogy maguk az alkalmazások közvetlenebb hangsúlyt kapjanak.
Ez a menü nemcsak új kinézetű, de alapos belső átalakításon is átesett , modernebb kóddal, amely javítja a billentyűzettel való navigációt, a tartalomfrissítést és a jövőbeni karbantartást. A cél az, hogy a felhasználók zökkenőmentesebb felhasználói élményt tapasztaljanak, és a projekt stabilabb alapot teremtsen a jövőbeli fejlesztéshez.
Továbbá a Mint megerősíti a billentyűzetkiosztások és beviteli módok támogatását , egységesítve a hagyományos elrendezések és az IBus-alapú metódusok kezelését. Ez lehetővé teszi az XKB-elrendezések kombinálását összetett metódusokkal, például japán vagy kínai nyelven, ami fontos a többnyelvű környezetekben.
Mindez a Mint és a Cinnamon jövőbeli stratégiájával összhangban van: a teljes Wayland kompatibilitás biztosítása . Eddig a Wayland alatti billentyűzettámogatás meglehetősen korlátozott volt, de ezzel a kiadással mind a szabványos elrendezések, mind a beviteli módok megfelelően működnek, és a képernyő-billentyűzetet natívan átírták, kiküszöbölve a külső függőségeket.
Ezen fejlesztések ellenére a Cinnamon alapértelmezés szerint továbbra is fut X11-en, bár kínál egy kísérleti munkamenetet a Waylanddel , amelyet még nem ajánlott éles környezetbe. Ez a munkamenet azonban tesztelési terepként szolgál a Muffin ablakkezelő és más kulcsfontosságú komponensek fejlesztéséhez.
Az asztali környezetet a Nemo 6.6-os fájlkezelő fejlesztései teszik teljessé, amely egy átfogóbb sablonkezelőt tartalmaz , lehetővé teszi a fájlműveletek szüneteltetését és folytatását, finomítja a keresés pontosságát, valamint javítja a bélyegképek és az osztott panelek kezelését. Emellett világosabb vizuális jelzőket vezet be a függőben lévő értesítésekhez, és egy intuitívabb munkaterület-váltó kisalkalmazást is bevezet.
Ezenkívül számos apró módosítás történt a rendszerben : egy éjszakai fény kisalkalmazás több opcióval, fejlesztések a törtszámú méretezésben, több konfigurációs lehetőség az Alt-Tab választóban, valamint egy családok és variánsok szerint átszervezett témaválasztó, amelynek célja a megjelenés testreszabásának egyszerűsítése.
Ahogy a Mint 22.3 lezárja ciklusát és előkészíti a terepet a közelgő Ubuntu 26.04 LTS-en alapuló Linux Mint 23-nak, a systemd 259-cel való különbség szembetűnő: a rendszer keretrendszer szédítő ütemben fejlődik , míg a stabil-orientált disztribúciók gondosan kiválasztják, hogy mely technológiai ugrásokat integrálják az adott pillanatban.
Mindezen elemek birtokában a systemd 259 jelentős mérföldkövet jelent az init és a szolgáltatáskezelő fejlődésében , megszakítva a glibc-től való kizárólagos függőséget, megerősítve a biztonságot a TPM 2.0-val, finomítva az olyan eszközöket, mint a run0 és a systemd-oomd, és magasabbra téve a lécet a kortárs Linuxhoz való alkalmazkodás követelményei tekintetében. Azoknak, akik teljes mértékben ki szeretnék használni ezeket az új funkciókat, kompatibilis platformokba és hardverekbe kell befektetniük, míg a konzervatívabb disztribúciók továbbra is a saját ütemüket diktálják, hogy egyensúlyt teremtsenek a stabilitás, a hosszú távú támogatás és ezen képességek fokozatos bevezetése között.
