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.

Since the EFI framebuffer does not provide the screen’s DPI, plymouth now guesses whether 2x hiDPI scaling should be used or not based on the screen’s resolution. So Fedora 42 may use a different scaling factor for the bootsplash than before, this only impacts the 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:

Change =1 to =2 to force 2x scaling. Note if this is used the specified scale-factor will apply to all displays.

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.

Previous Fedora IoT releases used the Zezere provisioning server for initial configuration. However, this approach caused problems for some users, notably those using IPv6. Starting with Fedora 42, Zezere has been replaced with systemd-firstboot. Users who have been unable to use Zezere will have an easier and more straightforward way to configure their system, resulting in less frustration during the critical first boot experience.

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

Fedora CoreOS now receives updates from OCI registry instead of the Fedora OSTree repository. The old OSTree repository will continue to be active until Fedora 43 release. Disk images will be updated first, so new installations of Fedora 42-based Fedora CoreOS will use OCI images from the start. Existing nodes will be migrated in the future.

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 this Fedora release the ansible package has been upgraded to version 11. There are many changes and for a full list of them see the link: upstream documentation.

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.

Most significantly, Stratis 3.8.0 introduces a revised storage stack. The motivation for this change and overall structure of the storage stack is described in a separate post.

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.

The zlib-ng data compression library in Fedora 42 has been updated to version 2.2, specifically 2.2.4. The updated version provides new optimizations, rewrites deflate memory allocation, and improves the build systems and tests.

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.

Fedora Workstation variants use connectivity checks by default. These checks can fail for multi-homed (e.g. LAN + Wi-Fi) hosts where firewalld uses IPv6_rpfilter=strict. Therefore, starting in Fedora 42, Fedora Workstation now defaults to IPv6_rpfilter=loose to allow connectivity checks to function as intended.

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.

The UI of cockpit-files is different from cockpit-navigator but offers the same functionality with the exception of symlink creation. cockpit-files uses PatternFly as UI toolkit, making the user experience more consistent.

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.

PostgreSQL version 15 will be retired from Fedora 42 since there are newer versions (16 and 17). Version 16 is already the default version (announced in PostgreSQL 16 change), and version 17 would be the alternative.

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

The opendmarc package previously included a set of optional supporting binaries which are not required to configure the service, which caused them to pull a high number (80+) additional packages as dependencies. Starting with Fedora 42, the opendmarc package only contains core utilities, and additional tools can be installed separately if needed, potentially saving space for those who don’t need them. The new separate packages are:

Previously, the git package was complex, divided into multiple sub-packages, and was providing the git binary. If you wanted to satisfy those packages that required the git binary, you experienced a long and computationally intensive installation process. With this update, the git binary is now provided through the git-core package, which should reduce the amount of packages installed as a transient dependency of the main package.

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.