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.

Como o framebuffer EFI não fornece o DPI da tela, o Plymouth agora estima se a escala 2x hiDPI deve ser usada ou não com base na resolução da tela. Portanto, o Fedora 42 pode usar um fator de escala diferente para o bootsplash do que antes, mas isso afeta apenas o 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:

Altere =1 para =2 para forçar a escala 2x. Observe que, se isso for usado, o fator de escala da espécie será aplicado a todas as exibições.

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.

Versões anteriores do Fedora IoT utilizavam o servidor de provisionamento Zezere para a configuração inicial. No entanto, essa abordagem causou problemas para alguns usuários, principalmente aqueles que utilizavam IPv6. A partir do Fedora 42, o Zezere foi substituído por systemd-firstboot. Usuários que não conseguiam usar o Zezere terão uma maneira mais fácil e direta de configurar seus sistemas, resultando em menos frustração durante a experiência crítica da primeira inicialização.

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

O Fedora CoreOS agora recebe atualizações do link:https://quay.io/fedora/fedora-coreos em vez do repositório OSTree do Fedora. O antigo repositório OSTree continuará ativo até o lançamento do Fedora 43. As imagens de disco serão atualizadas primeiro, portanto, novas instalações do Fedora CoreOS baseado no Fedora 42 usarão imagens OCI desde o início. Os nós existentes serão migrados no futuro.

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.

Nesta versão do Fedora, o pacote ansible foi atualizado para a versão 11. Há muitas alterações e para uma lista completa delas, veja a link: documentação upstream.

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.

Mais significativamente, o Stratis 3.8.0 apresenta uma pilha de armazenamento revisada. A motivação para essa alteração e a estrutura geral da pilha de armazenamento são descritas [em uma publicação separada].

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.

A biblioteca de compressão de dados zlib-ng no Fedora 42 foi atualizada para a versão 2.2, especificamente 2.2.4. A versão atualizada traz novas otimizações, reescreve a alocação de memória deflate e aprimora os sistemas de compilação e os testes.

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.

As variantes do Fedora Workstation usam verificações de conectividade por padrão. Essas verificações podem falhar em hosts multi-homed (por exemplo, LAN + Wi-Fi) onde o firewalld usa IPv6_rpfilter=strict. Portanto, a partir do Fedora 42, o Fedora Workstation agora usa como padrão IPv6_rpfilter=loose para permitir que as verificações de conectividade funcionem conforme o esperado.

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.

A interface do usuário do cockpit-files é diferente do cockpit-navigator, mas oferece a mesma funcionalidade, com exceção da criação de links simbólicos. O cockpit-files usa o PatternFly como kit de ferramentas de interface do usuário, tornando a experiência do usuário mais consistente.

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.

A versão 15 do PostgreSQL será descontinuada do Fedora 42, pois existem versões mais recentes (16 e 17). A versão 16 já é a versão padrão (anunciada na alteração do PostgreSQL 16), e a versão 17 seria a alternativa.

Se você ainda não atualizou para o fluxo padrão 16, siga a estratégia de atualização padrão:

O pacote opendmarc incluía anteriormente um conjunto de binários de suporte opcionais que não são necessários para configurar o serviço, o que os levou a extrair um grande número (mais de 80) pacotes adicionais como dependências. A partir do Fedora 42, o pacote opendmarc contém apenas utilitários básicos, e ferramentas adicionais podem ser instaladas separadamente, se necessário, potencialmente economizando espaço para quem não precisa delas. Os novos pacotes separados são:

Anteriormente, o pacote git era complexo, dividido em vários subpacotes, e fornecia o binário git. Se você quisesse atender aos pacotes que exigiam o binário git, passaria por um processo de instalação longo e computacionalmente intensivo. Com esta atualização, o binário git agora é fornecido através do pacote git-core, o que deve reduzir a quantidade de pacotes instalados como dependência transitória do pacote principal.

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.