Modifiche in Fedora 41 Per amministratori di sistema

Il gestore pacchetti predefinito in Fedora 41 è DNF 5. Questo è un aggiornamento di grandi dimensioni che apporta molti miglioramenti, in particolare:

Per informazioni su questa versione, consultare il collegamento:https://dnf5.readthedocs.io/en/latest/[documentazione DNF5 upstream], in particolare il collegamento:https://dnf5.readthedocs.io/ en/latest/changes_from_dnf4.7.html[elenco delle modifiche tra DNF e DNF5]. Gli sviluppatori dovrebbero anche controllare il collegamento:https://dnf5.readthedocs.io/en/latest/dnf_daemon/dnf5daemon_dbus_api.8.html[Associazione API DBus per dnfdaemon].

RPM in Fedora 41 è stato aggiornato alla versione 4.20, che fornisce una serie di miglioramenti, come:

Vedi il note sulla versione upstream per i dettagli.

A partire da Fedora 41, i desktop Fedora Atomic, Fedora CoreOS e Fedora IOT forniranno bootc e DNF5 come parte dell’immagine. Ora puoi utilizzare i comandi "dnf" come parte delle build di contenitori che utilizzano queste varianti di Fedora come immagine di base. Sebbene rpm-ostree sia ancora disponibile, ora puoi utilizzare bootc per gestire le distribuzioni e gli aggiornamenti della modalità immagine.

Quando si esegue dnf su un sistema in modalità immagine avviato, DNF fornirà un messaggio di errore migliore che indica gli strumenti disponibili sul sistema avviato per eseguire l’attività. Questo è l’inizio di un processo per abilitare DNF con le funzionalità rpm-ostree e concentrarsi nuovamente su bootc per gestire le distribuzioni in modalità immagine.

I pacchetti RPM utilizzano identificatori SPDX come standard per le licenze. Il 90% dei pacchetti è stato migrato al identificatori SPDX. Si stima che i pacchetti rimanenti verranno migrati su SPDX in Fedora 42. Un elenco di tutte le licenze consentite (e utilizzate) in Fedora Linux può essere trovato al Pagina legale di Fedora. Sul 90%, il 9% dei pacchetti ha una licenza temporanea "LicenseRef-Callaway-*" conforme a SPDX, ma deve ricevere l’ID di licenza corretto dall’organizzazione SPDX.

NetworkManager rimuove il supporto per i profili di connessione archiviati nel formato ifcfg. È deprecato a monte e il formato Keyfile nativo è valido e rappresenta un sostituto migliore. I seguenti pacchetti verranno eliminati. "NetworkManager-initscripts-ifcfg-rh", "NetworkManager-dispatcher-routing-rules" e "NetworkManager-initscripts-updown".

Per supportare il rafforzamento generale del sistema (esecuzione di software con il minor numero di privilegi possibili), il servizio SSSD è ora configurato per essere eseguito con l’utente "sssd" o "root" utilizzando i file di configurazione del servizio "systemd". Questo utente del servizio ora utilizza per impostazione predefinita "sssd" e, indipendentemente da quale utente del servizio sia configurato, "root" o "sssd", tutte le funzionalità root vengono eliminate ad eccezione di alcuni processi di supporto privilegiati.

Lo strumento sss_ssh_knownhostsproxy era deprecato nella versione precedente e ora è stato rimosso. Viene sostituito dallo strumento sss_ssh_knownhosts. Vedi man sss_ssh_knownhosts(1) per imparare come usarlo.

In precedenza, l’edizione Fedora Cloud veniva utilizzata per impostare il parametro della riga di comando del kernel net.ifnames=0 durante il processo kickstart. Ciò disabiliterebbe la coerenza dei nomi per i dispositivi di rete e garantirebbe che i dispositivi Ethernet mantenessero i loro nomi tradizionali come "eth0", "eth1" e così via. Con questo aggiornamento, net.ifnames=0 è stato rimosso dal file kickstart di Fedora Cloud per garantire coerenza nella denominazione dei dispositivi di rete e per allinearsi con le altre edizioni di Fedora.

Con questo aggiornamento, il pacchetto "network-scripts" da tempo deprecato verrà rimosso. Il pacchetto forniva le utilità legacy "ifup" e "ifdown", nonché "network.service". Gli script di rete dipendono fortemente dal client DHCP (Dynamic Host Configuration Protocol) e senza uno sviluppo attivo non è possibile aggiornarli per utilizzare un client alternativo.

Pacchetti che dipendono in una certa misura dagli script di rete:

Tieni presente che questa modifica interessa anche tutti gli utenti con script di rete personalizzati locali che richiedono funzionalità dal pacchetto "network-scripts".

A partire da Fedora 41, tutte le versioni supportate di Kubernetes, CRI-O e CRI-Tools saranno disponibili contemporaneamente. Ad esempio, Fedora 41 ha i seguenti RPM Kubernetes al momento del rilascio:

Questo è un cambiamento significativo rispetto alle precedenti versioni di Fedora, che avevano solo una singola versione di Kubernetes disponibile nei repository Fedora. Anche gli RPM CRI-O e CRI-Tools condividono questa modifica con le versioni disponibili per integrare Kubernetes. Per maggiori informazioni, vedere questo collegamento: Fedora Quick Doc.

TuneD ha sostituito power-profiles-daemon come demone predefinito per la gestione dei profili di potenza per le seguenti workstation Fedora:

Gli utenti del server possono personalizzare i profili di potenza esposti sul desktop modificando il file /etc/tuned/ppd.conf nella riga di comando. Gli utenti della workstation possono impostare il profilo energetico tramite il centro di controllo della GUI.

Il pacchetto tuned-ppd fornisce un sostituto immediato per power-profiles-daemon, che ne consente l’utilizzo con i desktop attuali.

Le applicazioni che già utilizzano power-profiles-daemon possono accedere a TuneD senza modificare il codice.

Netavark è uno strumento di rete di contenitori utilizzato da Podman. Netavark gestisce le interfacce e le regole del firewall e con questo aggiornamento di Fedora utilizzerà nftables per impostazione predefinita per creare regole del firewall per i contenitori.

Sui desktop Atomic, la policy che controlla l’accesso al demone rpm-ostree è stata aggiornata in:

Sui sistemi Fedora CoreOS e Fedora IoT, il montaggio root del sistema (/) è ora montato utilizzando composefs, che lo rende un filesystem veramente di sola lettura, aumentando l’integrità e la robustezza del sistema. Questo è il primo passo verso una verifica completa in fase di esecuzione dell’integrità del filesystem.

Sui desktop Atomic, il bootloader viene ora aggiornato automaticamente utilizzando "bootupd". I nuovi sistemi vengono ora installati con una configurazione GRUB statica che si basa solo sui file di configurazione delle specifiche del boot loader e non viene rigenerata per ogni aggiornamento.

Il progetto Kubernetes upstream mantiene 3 versioni simultanee con una nuova versione ogni 4 mesi. In precedenza, in Fedora, veniva sempre fornita solo una di queste versioni, abbinata ad una specifica release. A partire da Fedora 41, vengono fornite tutte le versioni Kubernetes attualmente supportate, utilizzando pacchetti separati che prendono il nome da ciascuna versione principale. Utilizzando l’rpm kubernetes-client come esempio, invece di kubernetes-client-1.29.2-1.fc41, Fedora ora offre kubernetes1.29-client-1.29.2-1.fc41, kubernetes1. 28-client-1.28.5-1.fc41 e "kubernetes1.27-client-1.27.8-1.fc41".

L’aggiornamento a Fedora 41 su una macchina con Fedora 40 o Fedora 39 richiede un passaggio manuale da parte dell’utente per selezionare il pacchetto Kubernetes con la versione appropriata.

Per maggiori informazioni, vedere il collegamento:https://docs.fedoraproject.org/en-US/quick-docs/using-kubernetes-versioned/[Fedora Quick Docs].

Fedora 41 è la prima versione di Fedora che fornisce il target del mappatore di dispositivi dm-vdo (ottimizzatore di dati virtuali), insieme al pacchetto di strumenti utente vdo.

Il target "dm-vdo" fornisce deduplica in linea, compressione e thin provisioning. Queste funzionalità possono essere aggiunte allo stack di archiviazione, compatibili con qualsiasi file system. Una destinazione "dm-vdo" può essere supportata da un massimo di 256 TB di spazio di archiviazione e può presentare una dimensione logica fino a 4 PB. Questo target è stato originariamente sviluppato a partire dal 2009. È stato rilasciato per la prima volta nel 2013 e da allora è stato utilizzato negli ambienti di produzione. È stato reso open source nel 2017 e incorporato nel kernel Linux upstream nel 2024.

Per supportare i target "dm-vdo", il pacchetto di strumenti utente "vdo" fornisce i seguenti strumenti:

Nel pacchetto "vdo" sono inclusi anche strumenti diagnostici aggiuntivi. Tuttavia, sono raramente necessari per il normale funzionamento.

Sebbene non sia obbligatorio, si consiglia vivamente di utilizzare lvm2 per gestire i volumi vdo. Consulta la documentazione di lvm2 per ulteriori informazioni.

Se hai un volume vdo creato con il modulo kvdo, assicurati di fare riferimento al collegamento: documentazione kvdo per considerazioni importanti prima di tentare l’aggiornamento a un volume dm- obiettivo vdo.

Vedi il collegamento: dm-vdo e il collegamento: vdo documentazione upstream per ulteriori dettagli.

Questo aggiornamento include le versioni di stratisd 3.7.3 e stratis-cli 3.7.0. Include un miglioramento significativo, diversi miglioramenti minori e una serie di piccoli miglioramenti.

Ancora più significativo, Stratis 3.7.3 estende le sue funzionalità per consentire a un utente di ripristinare uno snapshot, ovvero di sovrascrivere un filesystem Stratis con uno snapshot precedentemente acquisito di quel filesystem. Il processo di ripristino richiede due passaggi. Innanzitutto è necessario pianificare il ripristino di uno snapshot. Tuttavia, il ripristino può avvenire solo all’avvio di un pool. Questo può essere fatto mentre stratisd è in esecuzione, arrestando e riavviando il pool. Un ripristino può anche essere causato dal riavvio del sistema su cui è in esecuzione stratisd. Anche il riavvio di stratisd causerà un ripristino programmato, a condizione che il pool contenente il filesystem da ripristinare sia già stato arrestato. Per supportare questa funzionalità, "stratis-cli" include due nuovi sottocomandi del filesystem, "schedule-revert" e "cancel-revert".

Sono state aggiunte alcune funzionalità aggiuntive per supportare questa funzionalità di ripristino. Innanzitutto, il campo origine di un filesystem è ora incluso tra le sue proprietà D-Bus e aggiornato in modo appropriato. "stratis-cli" mostra un valore di origine nella vista dettagliata del filesystem appena introdotta. stratisd supporta anche un nuovo metodo D-Bus del filesystem che restituisce i metadati del filesystem. I comandi di debug del filesystem in "stratis-cli" ora includono un’opzione get-metadata che visualizzerà i metadati del filesystem per un dato pool o filesystem. È stata introdotta una funzionalità equivalente anche per i metadati del pool.

"stratisd" include anche un numero considerevole di aggiornamenti della versione delle dipendenze, correzioni minori e test aggiuntivi, mentre "stratis-cli" include miglioramenti all’implementazione dell’analisi della riga di comando.

Si prega di consultare il collegamento: stratisd e il collegamento: https://github.com/stratis-storage/stratis- cli/blob/rebase-3.6.0/CHANGES.txt[stratis-cli] log delle modifiche per ulteriori informazioni sulla versione.

Fedora 41 fornisce un nuovo strumento per interrogare i repository, fedora-repoquery, un piccolo strumento a riga di comando per eseguire repository dei repository di pacchetti Fedora, EPEL, eln e Centos Stream. Avvolge il repository dnf separando i dati del repository memorizzati nella cache con nomi di repository separati per un’esecuzione delle query memorizzata nella cache più rapida.

Vedi il readme upstream per esempi di utilizzo, o usa fedora-repoquery --help dopo l’installazione.

OpenSSL in Fedora 41 non si fida più delle firme SHA-1 per impostazione predefinita e ne blocca anche la creazione. Questa modifica è stata implementata perché gli attacchi di collisione con prefisso scelto su SHA-1 stanno diventando sempre più fattibili. Ciò avvicina le impostazioni di sicurezza predefinite di Fedora a ciò che è considerato sicuro nel panorama crittografico moderno.

Puoi ripristinare il comportamento predefinito precedente sia a livello di sistema utilizzando update-crypto-policies --set FEDORA40, sia per processo con runcp FEDORA40 command args, utilizzando lo strumento crypto-policies-extra link disponibile:+ https://copr.fedorainfracloud.org/coprs/asosedkin/crypto-policies-extras+[Copr]. Queste vecchie politiche verranno mantenute in Fedora per diverse versioni future. Tuttavia, il loro utilizzo è generalmente sconsigliato.

Le build dei pacchetti Fedora sono ora più deterministiche, avvicinando la distribuzione all’obiettivo di ottenere build completamente riproducibili per tutti i suoi pacchetti.

Per maggiori informazioni, vedere il Documentazione sulle build riproducibili di Fedora.

La rete virtuale libvirt è stata modificata per preferire l’uso del backend firewall nftables invece di iptables.

Questa modifica ha un potenziale impatto sulla compatibilità; vedere il collegamento: Cambia pagina per dettagli e soluzioni alternative.

Redis è stato sostituito con Valkey in Fedora 41 a causa della modifica della licenza di Redis a RASLv2/SSPL che lo ha reso incompatibile con i principi Free e Open Source. Valkey sostituisce completamente Redis che preserva la licenza BSD originale.

Quando si aggiorna a Fedora Linux 41, i sistemi con redis installato passeranno a valkey tramite il pacchetto valkey-compat. La modifica dovrebbe essere per lo più trasparente per gli utenti poiché il pacchetto valkey-compat fornisce la configurazione e la migrazione dei dati per le configurazioni più comuni. Le unità systemd "valkey" avranno alias per "redis" per facilitare la migrazione per gli utenti.

Il supporto per i motori OpenSSL è deprecato in Fedora 41. I motori non sono compatibili con FIPS e l’API corrispondente è deprecata a partire da OpenSSL 3.0. Coloro che attualmente utilizzano i motori OpenSSL dovrebbero passare all’utilizzo dei provider.