Alterações no Fedora 42 para administradores de sistema

Você pode encontrar notas adicionais no documentação upstream.

Imagens para a arquitetura alternativa RISC-V com suporte não oficial já estão disponíveis para o Fedora 42 nas versões de servidor, nuvem e contêiner. Para mais informações, consulte a postagem de anúncio no Fedora Discourse.

No Fedora 42, o diretório /usr/sbin se torna um link simbólico para bin, o que significa que caminhos como /usr/bin/foo e /usr/sbin/foo apontam para o mesmo lugar. /bin e /sbin já são links simbólicos para /usr/bin e /usr/sbin, então, efetivamente, /bin/foo e /sbin/foo também apontam para o mesmo lugar. /usr/sbin será removido do $PATH padrão. A mesma alteração também foi feita para fazer com que /usr/local/sbin aponte para /bin, fazendo com que /usr/local/bin/foo e /usr/local/sbin/foo apontem para o mesmo lugar.

A definição de %_sbindir foi alterada para %_bindir, então os pacotes começarão a usar o novo diretório após uma reconstrução sem nenhuma ação adicional.

Os mantenedores podem parar de usar %_sbindir, mas não precisam.

No Fedora 42, o boot-splash (plymouth) agora usa por padrão o framebuffer do firmware EFI para mostrar o boot-splash mais cedo durante a inicialização.

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.

O antigo comportamento de esperar o driver da GPU carregar antes de mostrar o splash pode ser restaurado executando:

Alternativamente, o fator de escala hiDPI estimado pode ser substituído executando:

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

Alternativamente, em vez de usar a linha de comando do kernel, essas configurações podem ser definidas editando /etc/plymouth/plymouthd.conf. Descomente a linha [Daemon] e adicione as linhas com:

Após editar /etc/plymouth/plymouthd.conf, o initrd deve ser regenerado para incluir o arquivo atualizado executando sudo dracut -f.

O utilitário fips-mode-setup foi removido do Fedora. Para operar um sistema no modo FIPS, você tem uma das seguintes opções:

Não é mais recomendado alternar um sistema para o modo FIPS após a instalação. Por exemplo, a criptografia de disco com LUKS ou a geração de chaves OpenSSH fará escolhas algorítmicas durante a instalação ou a primeira inicialização que não são aprovadas pelo FIPS quando a instalação ou a primeira inicialização não estiver em modo FIPS.

Se você ainda precisar alternar um sistema para o modo FIPS após a instalação e estiver ciente dos riscos, pode adicionar o argumento fips=1 à linha de comando do kernel. Observe que, se o seu /boot estiver em uma partição separada, você também precisará adicionar o UUID da partição à linha de comando para que o módulo dracut FIPS initramfs consiga encontrar o kernel e seu arquivo de checksum, ou a inicialização falhará. O comando a seguir faz isso em uma única etapa:

Para desativar o modo FIPS, você deve reinstalar o sistema. Se precisar trocar um sistema existente — o que não é recomendado — você pode usar grubby novamente para remover o argumento de linha de comando fips=1.

O mecanismo rpm embutido para criar usuários do sistema a partir de metadados em sysusers.d distribuídos por pacotes agora é usado para criar usuários do sistema, substituindo o uso anterior de scriptlets rpm personalizados em pacotes individuais.

Para obter mais informações sobre a criação de usuários por meio de sysusers.d, consulte a documentação upstream do RPM.

Em sistemas Fedora Atomic Desktop, a montagem raiz do sistema (/) agora é montada usando composefs, o que o torna um sistema de arquivos verdadeiramente somente leitura, aumentando a integridade e a robustez do sistema. Este é o primeiro passo para uma verificação completa da integridade do sistema de arquivos em tempo de execução.

Esta alteração segue uma semelhante no Fedora 41 que habilitou o ComposeFS por padrão nas edições Fedora CoreOS e IoT.

A partir do Fedora 42, o Fedora Atomic Desktop não está mais disponível para a arquitetura PPC64LE (Power Little Endian de 64 bits) devido à falta de interesse. Aqueles que desejam usar o Atomic nesse sistema devem reverter para uma instalação em modo de pacote do Fedora ou criar suas próprias imagens usando Contêineres Inicializáveis, disponíveis para 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.

A seção Introdução do documentação do Fedora IoT foi atualizada para refletir essa alteração.

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.

Essa alteração ajuda a alinhar o Fedora CoreOS com a iniciativa em andamento Contêineres inicializáveis.

O Fedora é distribuído como contêiner inicializável via registro OCI. A instalação normalmente é feita pela conversão em uma imagem de VM ou instalador ISO via osbuild (também conhecido como "image builder"). No entanto, a inicialização pela rede é um fluxo de trabalho útil para implantações de frotas bare-metal. Os arquivos necessários para realizar essa instalação não estavam disponíveis anteriormente no repositório OCI, que podia ser obtido do registro de maneira semelhante ao contêiner inicializável. Isso mudou no Fedora 42.

Anteriormente, os arquivos do Kickstart estavam disponíveis apenas no repositório RPM do Fedora, e encontrar a versão apropriada do repositório RPM e extrair os arquivos necessários podia ser complicado, em vez de buscar todos os recursos necessários apenas no registro. O Fedora 42 introduz um repositório OCI com os arquivos em questão para cada versão estável do Fedora.

Os arquivos do Kickstart também continuarão a ser distribuídos em repositórios RPM.

Veja a página de alterações no Fedora Wiki para mais informações.

O Fedora agora oferece imagens WSL (Subsistema Windows para Linux). Elas estão disponíveis para download na página do cloud do Getfedora.

WSL é um subsistema do Windows que permite que usuários do Windows executem facilmente várias distribuições Linux convidadas como contêineres dentro de uma única máquina virtual gerenciada por um host Windows.

O contêiner base do Fedora já pode ser usado com o WSL, mas não é o ideal, pois exclui intencionalmente a documentação e as ferramentas não essenciais, que esta imagem de nuvem fornece.

Para documentação sobre como usar essas imagens, consulte a documentação do 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.

Além disso, o pacote ansible-core foi atualizado para a versão 2.18. Algumas das alterações notáveis incluem:

Para mais detalhes, consulte a documentação upstream.

Intel Software Guard Extensions (SGX) é uma tecnologia que permite a criação de enclaves de execução. Sua memória é criptografada e, portanto, protegida de todos os outros códigos em execução na CPU, incluindo o Modo de Gerenciamento do Sistema (SMM), firmware, kernel e espaço do usuário.

Esta atualização do Fedora fornece a pilha de software host SGX, enclaves arquitetônicos e pacotes de desenvolvimento. A alteração se concentra na capacitação da infraestrutura de software geral. O objetivo é introduzir aplicativos e recursos no futuro, que dependerão do SGX.

O Fedora 42 apresenta uma nova maneira de lidar com a instalação de pacotes RPM a partir de repositórios enquanto chaves PGP desatualizadas estiverem presentes no sistema. Anteriormente, essas chaves precisavam ser removidas manualmente executando rpmkeys --delete. A partir desta versão, chaves expiradas serão detectadas automaticamente antes de qualquer transação DNF e tratadas adequadamente usando o novo plugin libDNF5, habilitado por padrão.

Para aqueles que usam o modo interativo, um prompt aparecerá informando sobre cada chave desatualizada no sistema e solicitando confirmação para removê-la. Para usuários não interativos, não haverá alterações no fluxo de trabalho.

Esta atualização melhora a forma como os pacotes de software são baixados e instalados no Fedora. A mudança proporciona uma melhor experiência para os usuários, pois reduz a quantidade de recursos de E/S necessários e compensa o custo de CPU da descompactação de pacotes. Como resultado, o sistema operacional instala e atualiza os pacotes mais rapidamente.

Observe que esse comportamento não está ativado por padrão e, portanto, é explicitamente opcional por enquanto.

O Stratis 3.8.0, que consiste em stratisd 3.8.0 e stratis-cli 3.8.0, inclui duas melhorias significativas, bem como uma série de pequenas melhorias.

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.

O Stratis 3.8.0 também introduz suporte para múltiplas ligações para criptografia usando o mesmo mecanismo. Anteriormente, o Stratis permitia apenas uma única ligação que utilizasse uma chave no conjunto de chaves do kernel; agora, múltiplas ligações com chaves diferentes podem ser usadas para o mesmo conjunto. Da mesma forma, múltiplas ligações que utilizam um mecanismo de criptografia Clevis podem ser usadas com o mesmo conjunto. O número total de ligações é limitado a 15.

Essa alteração possibilita uma série de casos de uso que o esquema anterior não permitia. Por exemplo, um pool pode ser configurado para ser desbloqueado com uma chave pertencente a um administrador de armazenamento, para manutenção ocasional necessária, e com uma chave diferente pelo usuário designado do pool.

Anteriormente, ao iniciar um pool criptografado, o usuário precisava designar um método de desbloqueio, clevis ou keyring. Como esta versão permite múltiplas vinculações com um método de desbloqueio, ela introduz um método mais geral para especificar um mecanismo de desbloqueio no início do pool. O usuário pode especificar --unlock-method=any e todos os métodos disponíveis podem ser tentados. O usuário também pode especificar que o pool deve ser aberto com uma vinculação específica, usando a opção --token-slot. Ou o usuário pode optar por inserir uma senha para desbloquear o pool, especificando a opção --capture-key ou um arquivo de chave usando a opção --keyfile-path. Da mesma forma, o comando unbind agora exige que o usuário especifique qual vinculação desvincular usando a opção --token-slot. E o método rebind exige que o usuário especifique um slot de token específico com a opção --token-slot se o pool tiver mais de uma vinculação com o mesmo método.

Também houve uma série de melhorias internas, pequenas correções de bugs e atualizações de dependências.

Por favor, consulte os changelogs do stratisd e do stratis-cli para informações adicionais sobre a versão.

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.

Você pode encontrar notas de lançamento para a versão 2.2 nos seguintes links:

O Apache Traffic Server (trafficserver) no Fedora foi atualizado para a versão 10.x. O arquivo /etc/trafficserver/records.config será atualizado automaticamente para o novo formato records.yaml. Etapas adicionais de atualização podem ser necessárias se recursos ou APIs removidos estiverem em uso; consulte a documentação upstream.

O Fedora 42 fornece o pacote bpfman.

Bpfman é uma pilha de software que simplifica o gerenciamento de programas eBPF em clusters Kubernetes ou em hosts individuais. Ele compreende um daemon de sistema (bpfman), Custom Resource Definitions (CRDs) do eBPF, um agente (bpfman-agent) e um operador (bpfman-operator). Desenvolvido em Rust na biblioteca Aya, o bpfman oferece segurança aprimorada, visibilidade, suporte a múltiplos programas e produtividade aprimorada para desenvolvedores.

Para o Fedora, a integração do bpfman agilizaria o carregamento de programas eBPF. A integração aumenta a segurança ao restringir privilégios ao daemon bpfman controlado, simplifica a implantação em clusters Kubernetes e oferece melhor visibilidade dos programas eBPF em execução. Essa integração está alinhada ao compromisso do Fedora em fornecer soluções eficientes e seguras, facilitando o aproveitamento dos benefícios do eBPF pelos usuários em seus sistemas.

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.

Para sistemas em atualização para o Fedora 42, o novo valor de IPv6_rpfilter depende se o usuário personalizou /etc/firewalld/firewalld.conf. Caso contrário, o processo de atualização do RPM atualizará a configuração para IPv6_rpfilter=loose. Em caso afirmativo, a configuração existente será mantida.

Observe que essa alteração é um desvio do firewalld upstream, que continua com o padrão IPv6_rpfilter=strict.

O Fedora 42 substitui o plugin Cockpit Navigator pelo Cockpit Files. No ano passado, o projeto Cockpit lançou um novo plugin oficialmente suportado, o Cockpit Files, com o objetivo de oferecer uma alternativa moderna ao plugin Cockpit Navigator existente. A versão mais recente (14) suporta tudo o que o Cockpit Navigator fazia, exceto a criação de links simbólicos, cuja implementação está prevista.

Substituir cockpit-navigator por cockpit-files leva a uma mudança visual no Cockpit: a entrada do menu Navegador será substituída por uma nova entrada do menu Navegador de arquivos em Ferramentas.

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.

O Fedora 42 permite que hosts de virtualização iniciem máquinas virtuais confidenciais usando a tecnologia SEV-SNP da AMD. A virtualização confidencial impede que administradores com acesso root ou uma pilha de software de host comprometida acessem a memória de qualquer convidado em execução. O SEV-SNP é uma evolução das tecnologias SEV e SEV-ES fornecidas anteriormente, proporcionando proteção mais robusta e desbloqueando novos recursos, como um TPM virtual seguro.

O Fedora agora oferece um mecanismo para carregar automaticamente binários otimizados para versões mais recentes da arquitetura x86_64 usando glibc-hwcaps. Os usuários podem notar tempos de execução mais rápidos para binários nos quais o mantenedor do pacote optou por usar esse mecanismo. Para uma explicação completa, consulte a página de alterações no Fedora Wiki.

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 você ainda não atualizou para o fluxo padrão 16, siga a estratégia de atualização padrão:

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.

Os ambientes ativos do Fedora Linux agora usam o Enhanced Read-Only FileSystem (EROFS), um sistema de arquivos somente leitura moderno e rico em recursos.

O pacote pam_ssh_agent_auth foi removido do Fedora 42 por estar desatualizado e raramente usado.