Po nekaj več kot treh mesecih razvoja, zagon nova različica sistemski 259. Ta posodobitev uvaja spremembe v arhitekturi sistema, pri čemer poudarja odprtost za alternativne standardne knjižnice, strožje upravljanje privilegijev in strožje tehnične zahteve za prihodnje različice.
Eno najbolj odmevnih gibanj v tem ciklu je prehod k večji modularnosti in odpravljanju zastarelih odvisnosti, kar utira pot ekosistemu Linuxa, ki se dokončno oddaljuje od standardov preteklih desetletij.
Glavne novosti systemd 259
Nova različica systemd 259 izstopa kot prva različica, ki dodaja delno združljivost z Musl, priljubljena standardna knjižnica C v lahkih distribucijah in vgrajenih okoljih. Ta integracija Upravlja se prek možnosti libc v sistemu za gradnjo Meson. Ker pa Musl ne izvaja funkcionalnosti NSS (Name Service Switch), v tej konfiguraciji ostane več komponent systemd onemogočenih.
Med aopazne odsotnosti pri sestavljanju z Musl so nss-systemd, nss-resolve, systemd-homed, systemd-userdbd in parameter DynamicUserPoleg tega ni mogoče zagnati systemd-nspawn brez privilegijev v tej knjižnici. Razvijalci so opozorili, da bo ohranitev te podpore v prihodnjih različicah odvisna od povpraševanja skupnosti in stabilnosti vseh dodatnih razvitih plasti združljivosti.
Druga novost nove različice je v pripomočku run0, zasnovan kot moderna in varna alternativa ukazu sudo, ki je prejel nova možnost – opolnomočenje. Ta funkcija Omogoča vam prijavo s povišanimi privilegiji. brez potrebe po spreminjanju uporabniškega identifikatorja (UID) v root.
Poleg tega, namesto delegiranja popolnega nadzora prek preklapljanja uporabnikov, –empower uporablja indikatorje zmogljivosti jedra, kot je CAP_SYS_ADMIN, izdati nujno potrebna dovoljenja za izvajanje privilegiranih sistemskih klicev. Poleg tega so nastali procesi integrirani v posebno skupino, ki jim omogoča dostop do dejanj Polkit, s čimer se ohranja robustnejša ločitev privilegijev kot pri tradicionalnem modelu sudo.
Konec neke dobe: Zbogom sistemu V in novim zahtevam
systemd 259 označuje začetek konca za združljivost z Skripti storitev System VNapovedano je bilo, da bodo v naslednji različici trajno odstranjene starejše komponente, kot so systemd-sysv-generator, systemd-rc-local-generator in systemd-sysv-install.
Skupaj s tem čiščenjem stare kode so bile znatno zvišane tudi minimalne programske zahteve za ekosistem systemd:
- Jedro Linuxa: Najmanjša različica 5.10.
- Glibc: 2.34.
- OpenSSL: 3.0.0.
- Util-linux: 2.37.
- Drugo: Python 3.9.0, cryptsetup 2.4.0 in libseccomp 2.4.0.
Modularnost in dinamično nalaganje v libsystemd
Como del pobude za zmanjšanje odvisnosti neposredno ob zagonu, libsystemd zdaj uporablja dinamično nalaganje prek dlopen() Knjižnice, kot so libacl, libblkid, libseccomp, libselinux in libmount, bo sistem naložil v pomnilnik le, če proces zahteva njihove specifične funkcije, s čimer se optimizira poraba virov. Poleg tega je bila funkcionalnost libcap integrirana neposredno v libsystemd, kar poenostavlja verigo odvisnosti.
El Obdelava dnevnikov je spremenila svojo privzeto konfiguracijo: način shranjevanja dnevnika (List) spremembe iz "samodejnega" v "trajno", ne glede na to, ali je imenik /var/log/journal prej obstajal.
Na področju omrežij in virtualizacije:
- systemd-networkd in systemd-nspawn: Podpora za pravila NAT z uporabo iptables je odstranjena, tako da je nftables edina združljiva možnost.
- sistemsko razrešeno: Zdaj omogoča uporabo lokalnih kavljev (hookov) v /run/systemd/resolve.hook/ za posredovanje pri zahtevah za razreševanje imen.
- systemd-importd: Logika za delo z datotekami TAR je bila izvorno integrirana. Poleg tega je zdaj mogoče tako `importd` kot `machined` izvajati na ravni uporabnika, kar omogoča upravljanje slik v lokalnem imeniku uporabnika (`~/.local/state/machines/`).
Druge novosti
API, ki temelji na protokolu Varlink je prejel izboljšave, ki omogočajo dostop do nastavitev storitev in opravljanje klicev IPC. kot sta Reload() in Reexecute(). Za sistemske skrbnike bo vključitev lastnosti OOMKills v storitve zelo koristna, saj jim bo omogočila sledenje, kolikokrat je bil proces prekinjen zaradi pomanjkanja pomnilnika neposredno iz orodij systemd.
Končno je postopek zagona sistema postal sodobnejši z odpravo podpore za TPM 1.2 v systemd-boot, s čimer se vsa varnostna prizadevanja osredotočijo na standard TPM 2.0.
Če vas zanima več o tem, se lahko obrnete na podrobnosti na naslednji povezavi.