systemd 259: modifiche chiave e requisiti di sistema

Informatec Digital » Risorse » systemd 259: Modifiche principali e requisiti di sistema

Il rilascio di systemd 259 in versione stabile rappresenta un'ulteriore svolta in uno dei componenti più controversi ed essenziali dell'ecosistema Linux. Stiamo parlando del framework per l'avvio e la gestione dei servizi che già domina la maggior parte delle distribuzioni, e questa versione inasprisce ulteriormente i requisiti tecnici, la sicurezza e l'abbandono delle tecnologie obsolete.

Questo aggiornamento giunge dopo diversi mesi di intenso lavoro e si concentra su tre aree principali: compatibilità con le nuove librerie C, sicurezza migliorata e pulizia del codice legacy (script SysV, TPM 1.2, iptables, ecc.). Introduce inoltre modifiche significative alla gestione dei privilegi con run0, alla gestione della memoria con systemd-oomd, all'archiviazione dei log e al modello di dipendenza interno di libsystemd.

systemd 259 e supporto sperimentale per musl

Una delle caratteristiche più discusse di questa versione è che systemd 259 incorpora, per la prima volta, il supporto parziale per la libreria standard C musl . Questa libreria è ampiamente utilizzata in sistemi leggeri, container minimalisti e ambienti embedded, dove sono desiderabili semplicità e un ridotto consumo di risorse rispetto a glibc.

Il supporto per musl viene abilitato impostando l'opzione "libc" del sistema di compilazione Meson su "musl" . Tuttavia, questa integrazione è tutt'altro che completa: musl non implementa il meccanismo Name Service Switch (NSS), che impone la disabilitazione di diverse parti di systemd durante la compilazione con questa libreria.

Nello specifico, la compilazione di systemd 259 con musl esclude componenti chiave come nss-systemd, nss-resolve, systemd-homed, systemd-userdbd e systemd-nsresourced . Non sono inoltre disponibili l'opzione DynamicUser e la possibilità di eseguire systemd-nspawn senza privilegi, aspetto particolarmente rilevante negli ambienti container che si basano fortemente su queste funzionalità.

Gli sviluppatori stessi riconoscono di non poter garantire un supporto a lungo termine . La sua continuazione dipenderà dall'effettivo interesse della community, dalla maturità dei livelli aggiuntivi che forniscono le funzionalità mancanti a musl e dalle segnalazioni di bug specifiche per questa libreria. Se la domanda dovesse essere bassa o la manutenzione si rivelasse troppo complessa, non sarebbe sorprendente se questo supporto venisse riconsiderato nelle versioni future.

Tuttavia, questa apertura a musl è importante a livello simbolico: systemd è stato criticato per anni per la sua dipendenza quasi esclusiva da glibc , che lo rendeva poco adatto a distribuzioni alternative e a scenari minimalisti. Questo passo non risolve tutti i problemi, ma rompe con l'immagine di un sistema completamente chiuso ad altre librerie C.

run0 e il nuovo modello di privilegi: un'alternativa a sudo

Un'altra caratteristica importante di systemd 259 è l'utilità run0, proposto come sostituto moderno e più sicuro di sudoQuesto strumento era già stato creato su systemd-run, ma ora acquisisce una funzionalità chiave: l'opzione --empower.

Il nuovo argomento `--empower` consente di avviare una sessione con privilegi elevati senza cambiare il proprio UID in root . Invece di un tradizionale cambio di utente, `run0` sfrutta le funzionalità del kernel (come `CAP_SYS_ADMIN`) per concedere esattamente le autorizzazioni necessarie per eseguire azioni privilegiate, riducendo al minimo il rischio di diventare completamente root.

Inoltre, i processi avviati con questo approccio vengono raggruppati in un gruppo logico "empower" con accesso a un'ampia gamma di azioni gestite da Polkit . L'idea è che l'aumento dei privilegi sia granulare e controllato, mantenendo una separazione più rigorosa rispetto a quella tipicamente offerta dal sudo tradizionale, dove l'accesso viene spesso aperto in modo eccessivo.

Questo approccio si allinea alla tendenza di evitare, ove possibile, l'uso diretto dell'utente root , un principio di sicurezza di grande importanza. Tuttavia, la reale efficacia di run0 deve ancora essere dimostrata in produzione: dovremo verificare come si integra con le policy di ciascuna distribuzione, come vengono configurate le sue funzionalità nella pratica e quanto bene l'amministrazione di sistema si adatta al nuovo flusso di lavoro.

Fine del supporto per SysV init e legacy cleanup

La versione 259 di systemd segna anche l' inizio della fine definitiva per gli script di servizio in stile System V. La compatibilità con questi meccanismi classici era stata indicata come "in via di estinzione" da anni, e ora è stato stabilito un calendario preciso per la loro rimozione.

Questa versione annuncia che, in vista della prossima importante release, I componenti storici come systemd-sysv-generator, systemd-rc-local-generator e systemd-sysv-install verranno rimossi.Cioè, gli script in /etc/init.d/ Non saranno più presi in considerazione da systemd, chiudendo così una transizione durata quasi un decennio.

Per gli amministratori che gestiscono ancora servizi personalizzati basati su script SysV , questo significa mettersi al lavoro: tutti questi script devono essere inventariati e migrati a unità native di systemd (.service, .socket, ecc.). Le distribuzioni più diffuse hanno già completato quasi interamente questa transizione, ma negli ambienti personalizzati o nelle installazioni più datate, alcune "reliquie" potrebbero essere ancora in esecuzione in background.

Questo processo di pulizia del codice legacy non si limita a SysV. Le versioni recenti di systemd hanno già rimosso il supporto per metodi classici come `/forcefsck` e `/fastboot` , sostituendoli con parametri del kernel e meccanismi di credenziali più moderni. Con la versione 259, la direzione è la stessa: minore compatibilità con le versioni precedenti in cambio di un codice più gestibile e coerente.

Requisiti minimi di systemd 259: kernel, librerie e ambiente

Uno dei cambiamenti che può avere il maggiore impatto sui sistemi più datati è l' aumento dei requisiti software minimi per eseguire systemd 259. Questa versione non tiene più conto dell'hardware o degli stack molto vecchi e punta chiaramente alle piattaforme moderne.

Tra i requisiti chiave consolidati in systemd 259 figurano: l'impegno verso piattaforme moderne

• Kernel Linux 5.10 minimo (con la raccomandazione di arrivare almeno alla 5.14).
• glibc2.34 come versione minima della libreria standard GNU.
• OpenSSL 3.0.0 come base obbligatoria per le funzioni di crittografia supportate.
• util-linux 2.37 come requisito per le utilità di base del sistema.
• libxcrypt 4.4.0 per la gestione delle funzioni crittografiche relative alle password.
• cryptsetup 2.4.0 e libseccomp 2.4.0 per la crittografia del volume e il filtraggio delle chiamate di sistema.
• Python 3.9.0 come dipendenza minima per gli strumenti ausiliari.
• Alcune note menzionano anche elfutils 0.177 come parte del set aggiornato di dipendenze.

Questo inasprimento dei criteri implica che i sistemi o le distribuzioni molto vecchi, che utilizzano versioni del kernel precedenti alla 5.10, saranno automaticamente esclusi dal supporto per questa versione, a meno che non aggiornino la tecnologia sottostante. In cambio, si ottiene un ecosistema più omogeneo, con meno casi particolari e soluzioni di compromesso.

Per la maggior parte delle distribuzioni desktop e server generiche, questi requisiti non dovrebbero rappresentare un problema: i moderni kernel LTS superano già ampiamente la versione 5.10 e le librerie menzionate sono ampiamente disponibili. I problemi maggiori possono sorgere nei sistemi embedded, negli appliance o nelle installazioni molto conservative che non vengono aggiornate frequentemente.

Sicurezza avanzata: TPM 2.0, crittografia e restrizioni del dispositivo

In ambito di sicurezza, systemd 259 accelera i suoi progressi con diverse decisioni significative. La più evidente è che systemd-boot e systemd-stub abbandonano definitivamente il supporto per TPM 1.2 , cosicché d'ora in poi solo TPM 2.0 viene considerato lo standard di riferimento.

Questa modifica implica che i sistemi che si affidavano a TPM 1.2 per gestire le policy di avvio sicuro o le chiavi di crittografia dovranno aggiornare l'hardware (ad esempio, sostituendo la scheda madre) se desiderano continuare a utilizzare queste funzionalità con le versioni più recenti di systemd-boot. Molti utenti di desktop Linux hanno TPM e Secure Boot disabilitati, quindi potrebbero non accorgersi nemmeno della modifica, ma questa potrebbe avere un impatto in ambienti aziendali o ad alta sicurezza.

Nelle versioni precedenti, come la systemd 258, erano già stati apportati cambiamenti significativi in ​​questo ambito: OpenSSL è diventata l'unica libreria di crittografia supportata da systemd-resolved e systemd-importd , escludendo alternative come GnuTLS e libgcrypt. Tutto ciò indica un consolidamento attorno a un insieme più piccolo e controllato di strumenti crittografici.

Sempre nella versione 258, sono state introdotte restrizioni di accesso predefinite più severe per tty/pts : i nodi vengono creati con permessi 0600 anziché 0620, impedendo ad altri utenti di scrivere sui nostri terminali. Questo è un altro esempio di come systemd abbia perfezionato nel tempo i dettagli di basso livello, che, nel loro insieme, rafforzano la sicurezza complessiva del sistema.

libsystemd è più modulare e caricato dinamicamente.

Nell'ottica di una maggiore efficienza e di una riduzione delle dipendenze, systemd 259 introduce profonde modifiche al modo in cui libsystemd interagisce con le altre librerie di sistema . L'obiettivo è impedire che tutto venga caricato fin dall'inizio, bensì solo quando necessario.

Nello specifico, libsystemd ora utilizza dlopen() per caricare dinamicamente librerie come libacl, libblkid, libseccomp, libselinux e libmount . Ciò significa che queste dipendenze non sono collegate rigidamente in fase di compilazione né vengono sempre caricate in memoria: vengono attivate solo quando una specifica funzione ne ha bisogno.

Questo stesso meccanismo con `dlopen()` si applica anche all'integrazione con il sottosistema di audit di Linux e PAM . In questo modo, l'avvio e il normale funzionamento di systemd possono essere più leggeri in ambienti che non richiedono tutti questi componenti contemporaneamente.

D'altro canto, la funzionalità precedentemente fornita dalla libreria libcap è stata integrata direttamente in libsystemd . Ciò elimina un'ulteriore dipendenza esterna, semplificando la catena di compilazione e riducendo i potenziali punti di errore o incompatibilità.

In termini generali, questo approccio offre una migliore modularità e un ingombro di memoria e disco inferiore , soprattutto nei sistemi in cui sono desiderabili tempi di avvio rapidi e un insieme compatto di servizi.

Modifiche alla rete e ai contenitori: addio iptables, benvenuto nftables

Anche l'area del networking e della virtualizzazione subisce cambiamenti significativi. A partire da systemd 259, systemd-networkd e systemd-nspawn non supportano più la creazione di regole NAT tramite iptables/libiptc . L'unico backend firewall supportato diventa nftables.

Questo problema riguarda direttamente i container gestiti con systemd-nspawn che si basavano sul NAT tramite iptables , nonché le reti definite in systemd-networkd che utilizzavano regole di traduzione degli indirizzi con il backend classico. Nei test con le release candidate, sono stati osservati errori silenziosi nella funzionalità NAT fino a quando l'intera configurazione non è stata migrata a nftables.

Oltre alla traduzione degli indirizzi, systemd-resolved acquisisce la capacità di utilizzare hook locali en /run/systemd/resolve.hook/Questi comandi vengono eseguiti ogni volta che viene eseguita una query di risoluzione dei nomi locale. Ciò apre le porte a personalizzazioni DNS avanzate e a logiche specifiche da parte dell'amministratore.

Nel campo dell'importazione e della gestione delle immagini, systemd-importd incorpora la logica nativa per lavorare con i file TAR, basandosi su libarchive dell'utility tar GNU. Inoltre, sia systemd-importd che systemd-machined possono ora essere eseguiti in modalità utente, gestendo le immagini di sistema posizionate in ~/.local/state/machines/.

Per controllare queste modalità, l' utility importctl aggiunge le opzioni "--user" e "--system" , che consentono di scegliere facilmente se operare nel contesto utente o a livello di sistema. Questo approccio è utile per gli ambienti di sviluppo e test in cui non si desidera modificare la configurazione globale della macchina.

Journaling persistente per impostazione predefinita e gestione dello spazio su disco

Un altro cambiamento con impatto pratico è la modifica del modalità di archiviazione del diario predefinita, il sottosistema di logging di systemd. Fino ad ora, il comportamento "automatico" dipendeva dall'esistenza o meno della directory /var/log/journal.

Con systemd 259, la modalità predefinita diventa "persistente ", indipendentemente dal fatto che la cartella esistesse in precedenza. Ciò significa che il registro verrà salvato permanentemente su disco per impostazione predefinita, anziché essere memorizzato nella RAM volatile.

Questa decisione presenta vantaggi e svantaggi. Da un lato, semplifica notevolmente la risoluzione dei problemi , poiché i log vengono conservati anche dopo il riavvio, senza richiedere alcun intervento specifico da parte dell'amministratore. Dall'altro lato, nei sistemi embedded, nei container leggeri o in ambienti con spazio di archiviazione molto limitato, può comportare un aumento significativo dell'utilizzo del disco.

In questi scenari, sarà più importante che mai regolare le politiche di rotazione e dimensione del journal , o addirittura forzare una diversa modalità di archiviazione se si desidera evitare un'usura eccessiva (ad esempio, nelle memorie flash con cicli di scrittura limitati).

systemd-oomd, monitoraggio OOM e controllo delle risorse

Anche la gestione della memoria e gli scenari di "memoria insufficiente" beneficiano di significativi miglioramenti. Il componente systemd-oomd, responsabile della gestione delle situazioni di memoria insufficiente , incorpora nuove proprietà per offrire una maggiore visibilità.

Nello specifico, le proprietà OOMKills e ManagedOOMKills sono ora disponibili per i servizi e registrano il numero di processi terminati dal kernel o da systemd-oomd stesso a causa di memoria insufficiente. Queste informazioni sono accessibili direttamente tramite gli strumenti di systemd, facilitando la successiva analisi degli incidenti.

Quando un processo sfugge al controllo e inizia a "divorare" la RAM al punto da compromettere il sistema , queste metriche consentono di vedere a colpo d'occhio quali unità sono state interessate, quante volte è stato attivato il meccanismo OOM (Out Of Memory) e quali componenti stanno causando la maggiore pressione sulla memoria.

Per gli amministratori di ambienti ad alto carico o di sistemi con risorse molto limitate, questa maggiore capacità di monitorare l'esaurimento della memoria (OOM) è particolarmente utile, in quanto aiuta a identificare servizi con dimensioni inadeguate o perdite di memoria che in precedenza potrebbero passare inosservate.

Altri notevoli miglioramenti in systemd 259

Oltre alle principali modifiche menzionate in precedenza, systemd 259 introduce numerosi miglioramenti e piccole modifiche sparse in tutto l'ecosistema . Molte di queste sono piuttosto tecniche, ma vale la pena esaminarle perché, nel loro insieme, rappresentano un cambiamento significativo.

Tra le nuove funzionalità dell'API, L'interfaccia basata sul protocollo Varlink è in fase di espansione per consentire l'accesso alla configurazione del servizio ed eseguire chiamate IPC come Reload() y Reexecute()Sono state aggiunte anche chiamate specifiche per gestire le funzionalità systemd-repart, systemd-resolved e systemd-networkd.

Nell'ambito della configurazione e delle unità, è stata introdotta l'opzione ExecReloadPost , che consente di avviare i comandi immediatamente dopo il ricaricamento della configurazione di un servizio. Inoltre, i file di configurazione con estensione ".ignore" vengono ora scartati automaticamente , un semplice trucco per disabilitare i file senza doverli eliminare o rinominare drasticamente.

Le unità temporanee acquisiscono la proprietà RootDirectoryFileDescriptor, che definisce il descrittore di file corrispondente alla directory radice, e viene aggiunta una nuova opzione Percorso dello spazio dei nomi utente, che consente di collegare un'unità a uno spazio dei nomi utente specificando un percorso in /procIn systemd-nspawn, la direttiva appare NamespacePath nella sezione dai file .nspawn per indicare lo spazio dei nomi di rete da utilizzare.

Altri componenti come systemd-sysext e systemd-confext incorporano file di configurazione dedicati en /etc/systemd/systemd-sysext.conf y /etc/systemd/systemd-confext.confVariabili d'ambiente SYSTEMD_SYSEXT_OVERLAYFS_MOUNT_OPTIONS y SYSTEMD_CONFEXT_OVERLAYFS_MOUNT_OPTIONS Consentono di regolare le opzioni di montaggio per le sovrapposizioni.

Nel mondo di udev, l'opzione è aggiunta OPZIONI=»dump-json» per systemd-udevd Per visualizzare lo stato corrente di un evento in formato JSON, la funzione net_id Genera nomi prevedibili per le interfacce wireless sui sistemi con DeviceTree e crea collegamenti simbolici. /dev/gpio/by-id/... per dispositivi GPIO.

Anche la sezione utenti e account verrà rafforzata: Il database utente include un campo UUIDL'utilità userdbctl supporta l'opzione "-uuid" per cercare tramite questo identificatore e homectl update Ora supporta "--recovery-key" per aggiungere chiavi di recupero agli account esistenti.

In systemd-homed, le opzioni "--prompt-shell" e "--prompt-groups" vengono incorporate durante il primo avvio tramite systemd-homed-firstboot.service, e in systemd-firstboot, "--prompt-keymap-auto" sembra richiedere la mappatura della tastiera quando si utilizza la console locale al primo avvio.

El Il gestore di avvio systemd-boot aggiunge la possibilità di definire il livello di dettaglio del registro con il parametro log-level en loader.conf o con il campo SMBIOS io.systemd.boot.loglevelInoltre, vengono consolidati requisiti più rigorosi per partizioni come XBOOTLDR, che ora devono essere in VFAT, in linea con quanto già richiesto per l'ESP nei moderni sistemi UEFI.

A livello di rete avanzata, systemd-networkd aggiunge le opzioni EmitDomain e Domain per il server DHCP e implementa un controller che determina i nomi host assegnati tramite DHCP utilizzando la risoluzione DNS. Nel frattempo, systemd-modules-load carica i moduli del kernel in parallelo , riducendo i tempi di avvio sui sistemi con molti driver.

Infine, nella sezione relativa all'integrità, systemd-integrity-setup aggiunge il supporto per gli algoritmi HMAC-SHA256, PHMAC-SHA256 e PHMAC-SHA512 , ampliando la gamma di opzioni crittografiche disponibili per proteggere l'integrità del sistema.

Con tutte queste modifiche, systemd 259 consolida la sua posizione di versione altamente tecnica, esigente e chiaramente orientata al futuro . Spinge gli utenti ad abbandonare tecnologie obsolete come SysV init, iptables e TPM 1.2, rafforza la sicurezza e il controllo delle risorse, migliora la modularità interna e apre le porte a nuove configurazioni con musl, seppur parzialmente e in modo condizionale. Per gli utenti finali che utilizzano distribuzioni di ultima generazione, molte di queste nuove funzionalità passeranno quasi inosservate; per gli amministratori e i progetti che utilizzano costantemente l'ultima versione, è giunto il momento di rivedere attentamente script, unit e requisiti hardware prima di effettuare l'aggiornamento.