Dopo poco più di tre mesi di sviluppo, il lancio di la nuova versione di sistema 259. Questo aggiornamento introduce modifiche all'architettura del sistema, evidenziando l'apertura a librerie standard alternative, una gestione dei privilegi più rigorosa e requisiti tecnici più severi per le versioni future.
Uno dei movimenti più discussi di questo ciclo è la transizione verso una maggiore modularità e l'eliminazione delle dipendenze legacy, che apre la strada a un ecosistema Linux che si allontana definitivamente dagli standard dei decenni passati.
Principali novità di systemd 259
La nuova versione 259 di systemd si distingue per essere la prima versione ad aggiungere una compatibilità parziale con Musl, la popolare libreria standard C nelle distribuzioni leggere e negli ambienti embedded. Questa integrazione Viene gestito tramite l'opzione libc nel sistema di compilazione Meson. Tuttavia, poiché Musl non implementa la funzionalità NSS (Name Service Switch), diversi componenti systemd rimangono disabilitati in questa configurazione.
Tra gli aassenze notevoli durante la compilazione con Musl trovato nss-systemd, nss-resolve, systemd-homed, systemd-userdbd e il parametro DynamicUserInoltre, non è possibile eseguire systemd-nspawn senza privilegi con questa libreria. Gli sviluppatori hanno avvertito che il mantenimento di questo supporto nelle versioni future dipenderà dalla richiesta della community e dalla stabilità di eventuali livelli di compatibilità aggiuntivi che verranno sviluppati.
Un'altra novità della nuova versione è nell'utilità run0, progettato come alternativa moderna e sicura a sudo, che ha ricevuto la nuova opzione – potenziare. Questa funzione Ti consente di accedere con privilegi elevati. senza dover modificare l'identificativo utente (UID) in root.
A parte quello, invece di delegare il controllo totale attraverso il cambio utente, –empower utilizza indicatori di capacità del kernel, come CAP_SYS_ADMIN, per concedere i permessi strettamente necessari per effettuare chiamate di sistema privilegiate. Inoltre, i processi risultanti vengono integrati in un gruppo specifico che garantisce loro l'accesso alle azioni Polkit, mantenendo una separazione dei privilegi più solida rispetto al tradizionale modello sudo.
La fine di un'era: addio al System V e ai nuovi requisiti
systemd 259 segna l'inizio della fine per compatibilità con il Script di servizio System VÈ stato annunciato che nella prossima versione i componenti legacy quali systemd-sysv-generator, systemd-rc-local-generator e systemd-sysv-install verranno rimossi definitivamente.
Oltre a questa pulizia del vecchio codice, i requisiti software minimi per l'ecosistema systemd sono stati notevolmente aumentati:
- Kernel Linux: versione minima 5.10.
- Glibc: 2.34.
- OpenSSL: 3.0.0.
- Util-linux: 2.37.
- Altro: Python 3.9.0, cryptsetup 2.4.0 e libseccomp 2.4.0.
Modularità e caricamento dinamico in libsystemd
Come parte di un'iniziativa per ridurre le dipendenze direttamente all'avvio, libsystemd ora utilizza il caricamento dinamico tramite dlopen() Per librerie come libacl, libblkid, libseccomp, libselinux e libmount, il sistema le caricherà in memoria solo quando le loro funzioni specifiche saranno richieste da un processo, ottimizzando l'utilizzo delle risorse. Inoltre, la funzionalità libcap è stata integrata direttamente in libsystemd, semplificando la catena delle dipendenze.
El La gestione dei log ha modificato la sua configurazione predefinita: la modalità di archiviazione del giornale (News) cambia da "automatico" a "persistente", indipendentemente dal fatto che la directory /var/log/journal esistesse in precedenza.
Nel campo delle reti e della virtualizzazione:
- systemd-networkd e systemd-nspawn: Il supporto per le regole NAT che utilizzano iptables è stato rimosso, lasciando nftables come unica opzione compatibile.
- systemd-risolto: Ora consente l'uso di hook locali (hook) in /run/systemd/resolve.hook/ per intervenire nelle richieste di risoluzione dei nomi.
- systemd-importd: La logica per lavorare con i file TAR è stata integrata in modo nativo. Inoltre, sia `importd` che `machined` possono ora essere eseguiti a livello utente, consentendo la gestione delle immagini nella directory locale dell'utente (`~/.local/state/machines/`).
Altre innovazioni
L'API basata sul protocollo Varlink ha ricevuto miglioramenti per consentire l'accesso alle impostazioni del servizio e per effettuare chiamate IPC come Reload() e Reexecute(). Per gli amministratori di sistema, l'inclusione della proprietà OOMKills nei servizi sarà molto utile, poiché consentirà loro di tenere traccia di quante volte un processo è stato terminato per mancanza di memoria direttamente dagli strumenti systemd.
Infine, il processo di avvio del sistema diventa più moderno con la rimozione del supporto per TPM 1.2 in systemd-boot, concentrando tutti gli sforzi di sicurezza sullo standard TPM 2.0.
Se sei interessato a saperne di più, puoi consultare il dettagli nel seguente collegamento.