Modifiche in Fedora 42 Per amministratori di sistema

Puoi trovare note aggiuntive nel documentazione upstream.

Le immagini per l’architettura alternativa RISC-V con supporto non ufficiale sono ora disponibili per Fedora 42 nelle varianti server, cloud e container. Per ulteriori informazioni, consultare il link: https://discussion.fedoraproject.org/t/fedora-42-risc-v-non-official-images-are-available/148866[post di annuncio su Fedora Discussion].

In Fedora 42, la directory /usr/sbin diventa un collegamento simbolico a bin, il che significa che percorsi come /usr/bin/foo e /usr/sbin/foo puntano alla stessa posizione. /bin e /sbin sono già collegamenti simbolici a /usr/bin e /usr/sbin, quindi di fatto anche /bin/foo e /sbin/foo puntano alla stessa posizione. /usr/sbin verrà rimosso dal percorso predefinito $PATH. La stessa modifica viene apportata anche per fare in modo che /usr/local/sbin punti a /bin, di fatto facendo in modo che /usr/local/bin/foo e /usr/local/sbin/foo puntino alla stessa posizione.

La definizione di %_sbindir è stata modificata in %_bindir, quindi i pacchetti inizieranno a utilizzare la nuova directory dopo una ricostruzione, senza ulteriori azioni.

I manutentori possono smettere di usare %_sbindir, ma non è obbligatorio.

Su Fedora 42, il boot-splash (plymouth) ora utilizza per impostazione predefinita il framebuffer del firmware EFI per visualizzare il boot-splash in anticipo durante l’avvio.

Poiché il framebuffer EFI non fornisce i DPI dello schermo, Plymouth ora calcola se utilizzare o meno il ridimensionamento 2x hiDPI in base alla risoluzione dello schermo. Quindi Fedora 42 potrebbe utilizzare un fattore di ridimensionamento diverso per il bootsplash rispetto a prima, ma questo influisce solo sul bootsplash.

Il vecchio comportamento di attesa del caricamento del driver GPU prima di visualizzare lo splash può essere ripristinato eseguendo:

In alternativa, è possibile sovrascrivere il fattore di scala hiDPI ipotizzato eseguendo:

Modificare =1 in =2 per forzare la scala 2x. Notare che se si utilizza questo parametro, il fattore di scala specificato verrà applicato a tutti i display.

In alternativa, invece di utilizzare la riga di comando del kernel, queste impostazioni possono essere configurate modificando /etc/plymouth/plymouthd.conf. Rimuovi il commento dalla riga [Daemon] e aggiungi le righe con:

Dopo aver modificato /etc/plymouth/plymouthd.conf, è necessario rigenerare l’initrd per includere il file aggiornato eseguendo sudo dracut -f.

L’utilità fips-mode-setup è stata rimossa da Fedora. Per utilizzare un sistema in modalità FIPS, è possibile scegliere una delle seguenti opzioni:

Non è più consigliabile impostare un sistema in modalità FIPS dopo l’installazione. Ad esempio, la crittografia del disco con LUKS o la generazione di chiavi OpenSSH effettueranno scelte algoritmiche durante l’installazione o il primo avvio non approvate da FIPS, se l’installazione o il primo avvio non vengono eseguiti in modalità FIPS.

Se dopo l’installazione è ancora necessario impostare un sistema in modalità FIPS e si è consapevoli dei rischi, è possibile aggiungere l’argomento fips=1 alla riga di comando del kernel. Si noti che se /boot si trova su una partizione separata, sarà necessario aggiungere anche l’UUID della partizione alla riga di comando affinché il modulo dracut FIPS initramfs possa trovare il kernel e il relativo file di checksum, altrimenti l’avvio non riuscirà. Il seguente comando esegue questa operazione in un unico passaggio:

Per disabilitare la modalità FIPS, è necessario reinstallare il sistema. Se è necessario cambiare un sistema esistente, cosa sconsigliata, è possibile utilizzare nuovamente grubby per rimuovere l’argomento fips=1 dalla riga di comando.

Il meccanismo rpm integrato per creare utenti di sistema dai metadati sysusers.d distribuiti dai pacchetti viene ora utilizzato per creare utenti di sistema, sostituendo il precedente utilizzo di scriptlet rpm personalizzati nei singoli pacchetti.

Per maggiori informazioni sulla creazione di utenti tramite sysusers.d, vedere il collegamento:https://github.com/rpm-software-management/rpm/blob/master/docs/manual/users_and_groups.md#users-and-groups[documentazione RPM upstream].

Sui sistemi Fedora Atomic Desktop, il mount della root del sistema (/) viene ora montato tramite composefs, il che lo rende un file system realmente di sola lettura, aumentandone l’integrità e la robustezza. Questo è il primo passo verso una verifica completa dell’integrità del file system a runtime.

Questa modifica segue un’altra simile nel Fedora 41 che abilitava ComposeFS per impostazione predefinita nelle edizioni Fedora CoreOS e IoT.

A partire da Fedora 42, Fedora Atomic Desktop non è più disponibile per l’architettura PPC64LE (Power Little Endian a 64 bit) a causa della mancanza di interesse. Chi desidera utilizzare Atomic su tali sistemi deve tornare all’installazione in modalità pacchetto Fedora o creare immagini personalizzate utilizzando i contenitori avviabili disponibili per PPC64LE.

Le precedenti versioni di Fedora IoT utilizzavano il server di provisioning Zezere per la configurazione iniziale. Tuttavia, questo approccio ha causato problemi ad alcuni utenti, in particolare a quelli che utilizzavano IPv6. A partire da Fedora 42, Zezere è stato sostituito da systemd-firstboot. Gli utenti che non sono stati in grado di utilizzare Zezere avranno a disposizione un modo più semplice e diretto per configurare il proprio sistema, con conseguente riduzione della frustrazione durante la critica fase del primo avvio.

La sezione Introduzione del collegamento:https://docs.fedoraproject.org/it/iot/ignition/[documentazione di Fedora IoT] è stata aggiornata per riflettere questa modifica.

Fedora CoreOS ora riceve gli aggiornamenti dal link:https://quay.io/fedora/fedora-coreos invece che dal repository Fedora OSTree. Il vecchio repository OSTree continuerà a essere attivo fino al rilascio di Fedora 43. Le immagini disco verranno aggiornate per prime, quindi le nuove installazioni di Fedora CoreOS basate su Fedora 42 utilizzeranno immagini OCI fin dall’inizio. I nodi esistenti verranno migrati in futuro.

Questa modifica aiuta ad allineare Fedora CoreOS con l’iniziativa in corso Bootable Containers.

Fedora è distribuita come container avviabile tramite il registro OCI. L’installazione viene in genere eseguita tramite conversione in un’immagine VM o in un programma di installazione ISO tramite il osbuild (image builder); tuttavia, l’avvio dalla rete è un flusso di lavoro utile per le distribuzioni bare-metal. In precedenza, i file necessari per eseguire tale installazione non erano disponibili nel repository OCI e potevano essere recuperati dal registro in modo simile al container avviabile. Questo cambia in Fedora 42.

In precedenza, i file Kickstart erano disponibili solo nel repository RPM di Fedora e poteva risultare complicato trovare la versione appropriata del repository RPM ed estrarre i file necessari, invece di recuperare tutte le risorse necessarie solo dal registro. Fedora 42 introduce un repository OCI con i file in questione per ogni versione stabile di Fedora.

I file Kickstart continueranno a essere distribuiti anche nei repository RPM.

Per maggiori informazioni, consultare il collegamento:https://fedoraproject.org/wiki/Changes/KickstartOciArtifacts[Modifica pagina] su Fedora Wiki.

Fedora ora fornisce immagini WSL (Windows Subsystem for Linux). Sono disponibili per il download al link: https://fedoraproject.org/cloud/download[Accedi alla pagina cloud di Fedora].

WSL è un sottosistema Windows che consente agli utenti Windows di eseguire facilmente più distribuzioni Linux guest come contenitori all’interno di un’unica macchina virtuale gestita da un host Windows.

Il contenitore di base Fedora può già essere utilizzato con WSL, ma non è la soluzione ideale in quanto esclude intenzionalmente la documentazione e gli strumenti non essenziali forniti da questa immagine cloud.

Per la documentazione su come utilizzare queste immagini, vedere il collegamento:https://docs.fedoraproject.org/it/cloud/[Documentazione Fedora Cloud].

In questa versione di Fedora, il pacchetto ansible è stato aggiornato alla versione 11. Sono state apportate numerose modifiche, per un elenco completo consultare il link: https://docs.ansible.com/ansible/latest/roadmap/COLLECTIONS_11.html [documentazione originale].

Inoltre, il pacchetto ansible-core è stato aggiornato alla versione 2.18. Tra le modifiche più importanti, si segnalano:

Per maggiori dettagli consultare il link: documentazione upstream.

Intel Software Guard Extensions (SGX) è una tecnologia che consente la creazione di enclave di esecuzione. La loro memoria è crittografata e quindi protetta da tutto il codice in esecuzione sulla CPU, inclusi System Management Mode (SMM), firmware, kernel e spazio utente.

Questo aggiornamento di Fedora fornisce lo stack software host SGX, enclave architetturali e pacchetti di sviluppo. La modifica si concentra sull’abilitazione dell’infrastruttura software generale. L’obiettivo è introdurre in futuro applicazioni e funzionalità che dipenderanno da SGX.

Fedora 42 introduce un nuovo modo per gestire l’installazione di pacchetti RPM dai repository quando nel sistema sono presenti chiavi PGP obsolete. In precedenza, tali chiavi dovevano essere rimosse manualmente eseguendo rpmkeys --delete. A partire da questa versione, le chiavi scadute verranno rilevate automaticamente prima di qualsiasi transazione DNF e gestite in modo appropriato tramite un nuovo plugin libDNF5, abilitato di default.

Per chi utilizza la modalità interattiva, verrà visualizzato un messaggio che informa su ogni chiave obsoleta presente nel sistema e chiede conferma per la sua rimozione. Per gli utenti non interattivi, il flusso di lavoro non subirà alcuna modifica.

Questo aggiornamento migliora il download e l’installazione dei pacchetti software su Fedora. La modifica offre un’esperienza migliore agli utenti, riducendo la quantità di risorse I/O richieste e compensando il consumo di CPU per la decompressione dei pacchetti. Di conseguenza, il sistema operativo installa e aggiorna i pacchetti più velocemente.

Si noti che questo comportamento non è attivato per impostazione predefinita e pertanto per il momento è esplicitamente richiesto.

Stratis 3.8.0, che consiste in stratisd 3.8.0 e stratis-cli 3.8.0 include due miglioramenti significativi, oltre a una serie di piccoli miglioramenti.

In particolare, Stratis 3.8.0 introduce uno stack di storage rivisto. Le motivazioni di questa modifica e la struttura complessiva dello stack di storage sono descritte [in un post separato].

Stratis 3.8.0 introduce anche il supporto per binding multipli per la crittografia che utilizzano lo stesso meccanismo. In precedenza, Stratis consentiva un singolo binding che utilizzava una chiave nel keyring del kernel; ora è possibile utilizzare più binding con chiavi diverse per lo stesso pool. Analogamente, è possibile utilizzare più binding che utilizzano un meccanismo di crittografia Clevis con lo stesso pool. Il numero totale di binding è limitato a 15.

Questa modifica consente una serie di casi d’uso che lo schema precedente non consentiva. Ad esempio, un pool potrebbe essere configurato in modo da poter essere sbloccato con una chiave appartenente a un amministratore di storage, per la manutenzione occasionale necessaria, e con una chiave diversa dall’utente designato del pool.

In precedenza, all’avvio di un pool crittografato, l’utente doveva designare un metodo di sblocco, clevis o keyring. Poiché questa versione consente più binding con un unico metodo di sblocco, introduce un metodo più generale per specificare un meccanismo di sblocco all’avvio del pool. L’utente può specificare --unlock-method=any e provare tutti i metodi disponibili. L’utente può anche specificare che il pool venga aperto con un binding specifico, utilizzando l’opzione --token-slot. In alternativa, l’utente può scegliere di immettere una passphrase per sbloccare il pool, specificando l’opzione --capture-key o un file chiave utilizzando l’opzione --keyfile-path. Analogamente, il comando unbind ora richiede all’utente di specificare quale binding annullare utilizzando l’opzione --token-slot. E il metodo rebind richiede all’utente di specificare un particolare slot token con l’opzione --token-slot se il pool ha più di un binding con lo stesso metodo.

Sono stati apportati anche numerosi miglioramenti interni, piccole correzioni di bug e aggiornamenti delle dipendenze.

Per ulteriori informazioni sulla versione, consultare i changelog ai link: stratisd e link: stratis-cli.

La libreria di compressione dati zlib-ng in Fedora 42 è stata aggiornata alla versione 2.2, in particolare alla 2.2.4. La versione aggiornata offre nuove ottimizzazioni, riscrive l’allocazione di memoria di deflate e migliora i sistemi di compilazione e i test.

Potete trovare le note di rilascio per la versione 2.2 ai seguenti link:

Apache Traffic Server (trafficserver) in Fedora è stato aggiornato alla versione 10.x. Il file /etc/trafficserver/records.config verrà aggiornato automaticamente al nuovo formato records.yaml. Potrebbero essere necessari ulteriori passaggi di aggiornamento se si utilizzano funzionalità o API rimosse; consultare il link: https://docs.trafficserver.apache.org/en/10.0.x/release-notes/upgrading.en.html[documentazione upstream].

Fedora 42 fornisce il pacchetto bpfman.

Bpfman è uno stack software che semplifica la gestione dei programmi eBPF nei cluster Kubernetes o su singoli host. Comprende un demone di sistema (bpfman), definizioni di risorse personalizzate (CRD) eBPF, un agente (bpfman-agent) e un operatore (bpfman-operator). Sviluppato in Rust sulla libreria Aya, bpfman offre maggiore sicurezza, visibilità, supporto multi-programma e maggiore produttività per gli sviluppatori.

Per Fedora, l’integrazione di bpfman semplificherebbe il caricamento dei programmi eBPF. Migliora la sicurezza limitando i privilegi al demone bpfman controllato, semplifica l’implementazione nei cluster Kubernetes e offre una migliore visibilità sui programmi eBPF in esecuzione. Questa integrazione è in linea con l’impegno di Fedora nel fornire soluzioni efficienti e sicure, semplificando l’utilizzo da parte degli utenti dei vantaggi di eBPF nei propri sistemi.

Le varianti di Fedora Workstation utilizzano i controlli di connettività per impostazione predefinita. Questi controlli possono fallire su host multi-homed (ad esempio, LAN + Wi-Fi) in cui firewalld utilizza IPv6_rpfilter=strict. Pertanto, a partire da Fedora 42, Fedora Workstation utilizza ora IPv6_rpfilter=loose per consentire ai controlli di connettività di funzionare correttamente.

Per i sistemi che eseguono l’aggiornamento a Fedora 42, il nuovo valore di IPv6_rpfilter dipende dalla personalizzazione del file /etc/firewalld/firewalld.conf da parte dell’utente. In caso contrario, il processo di aggiornamento RPM aggiornerà la configurazione a IPv6_rpfilter=loose. In caso contrario, la configurazione esistente verrà mantenuta.

Si noti che questa modifica è una deviazione da firewalld upstream, che continua a utilizzare per impostazione predefinita IPv6_rpfilter=strict.

Fedora 42 sostituisce il plugin Cockpit Navigator con Cockpit Files. L’anno scorso, il progetto Cockpit ha rilasciato un nuovo plugin Cockpit Files ufficialmente supportato, concepito per fornire un’alternativa moderna al plugin Cockpit Navigator esistente. L’ultima versione (14) supporta tutte le funzionalità di Cockpit Navigator, tranne la creazione di collegamenti simbolici, la cui implementazione è prevista.

La sostituzione di cockpit-navigator con cockpit-files comporta un cambiamento visivo all’interno di Cockpit: la voce di menu Navigator verrà sostituita con una nuova voce di menu File browser in Strumenti.

L’interfaccia utente di cockpit-files è diversa da quella di cockpit-navigator, ma offre le stesse funzionalità, con l’eccezione della creazione di collegamenti simbolici. cockpit-files utilizza PatternFly come toolkit per l’interfaccia utente, rendendo l’esperienza utente più coerente.

Fedora 42 consente agli host di virtualizzazione di avviare macchine virtuali riservate utilizzando la tecnologia SEV-SNP di AMD. La virtualizzazione riservata impedisce agli amministratori con accesso alla shell di root, o a uno stack software host compromesso, di accedere alla memoria di qualsiasi guest in esecuzione. SEV-SNP è un’evoluzione delle tecnologie SEV e SEV-ES precedentemente fornite, offrendo una protezione più avanzata e sbloccando nuove funzionalità come un TPM virtuale sicuro.

Fedora ora fornisce un meccanismo per il caricamento automatico dei binari ottimizzati per le versioni più recenti dell’architettura x86_64 tramite glibc-hwcaps. Gli utenti potrebbero notare tempi di esecuzione più rapidi per i binari per i quali il responsabile del pacchetto ha optato per l’utilizzo di questo meccanismo. Per una spiegazione completa, consultare il link: https://fedoraproject.org/wiki/Changes/Optimized_Binaries_for_the_AMD64_Architecture_v2[pagina delle modifiche] sul Wiki di Fedora.

La versione 15 di PostgreSQL verrà ritirata da Fedora 42, in quanto sono disponibili versioni più recenti (16 e 17). La versione 16 è già la versione predefinita (annunciata nella modifica a PostgreSQL16), e la versione 17 sarebbe l’alternativa.

Se non hai ancora effettuato l’aggiornamento al flusso predefinito 16, dovresti seguire la strategia di aggiornamento standard:

In precedenza, il pacchetto opendmarc includeva un set di file binari di supporto opzionali, non necessari per configurare il servizio, che causavano l’estrazione di un numero elevato (oltre 80) di pacchetti aggiuntivi come dipendenze. A partire da Fedora 42, il pacchetto opendmarc contiene solo le utilità principali e, se necessario, è possibile installare separatamente strumenti aggiuntivi, risparmiando potenzialmente spazio per chi non ne ha bisogno. I nuovi pacchetti separati sono:

In precedenza, il pacchetto git era complesso, suddiviso in più sotto-pacchetti e forniva il binario git. Per soddisfare i pacchetti che richiedevano il binario git, era necessario un processo di installazione lungo e computazionalmente impegnativo. Con questo aggiornamento, il binario git viene ora fornito tramite il pacchetto git-core, il che dovrebbe ridurre il numero di pacchetti installati come dipendenza temporanea del pacchetto principale.

Gli ambienti live di Fedora Linux ora utilizzano l’Enhanced Read-Only FileSystem (EROFS), un file system di sola lettura moderno e ricco di funzionalità.

Il pacchetto pam_ssh_agent_auth è stato rimosso in Fedora 42 perché obsoleto e raramente utilizzato.