O Systemd 253 prepara um lançamento estável para breve. Por enquanto, saiu o terceiro e possivelmente o último candidato a lançamento. Portanto, em breve a systemd 253 deve lançar uma versão RC3 para teste.
O systemd 253-rc1 estreou no final de janeiro e, em seguida, o systemd 252-rc2 chegou na semana passada. O lançamento de hoje do systemd 253-rc3 tem mais correções de bugs e outras atualizações menores para o systemd 253, mas nenhum novo recurso importante funciona neste estágio final.
systemd v253-rc3
systemd 253 deve lançar em breve versão RC3 para teste. Os destaques desta próxima versão incluem:
- Uma nova ferramenta com o systemd 253 é a ferramenta “ukify” para criar, medir e assinar Unified Kernel Images (UKIs). A intenção é que o systemd ukify substitua a funcionalidade atualmente fornecida por “dracut –uefi” enquanto fornece mais funcionalidade como parte da nova filosofia UKI / de inicialização confiável.
- Os ambientes Initrd que não estão em um sistema de arquivos temporário agora são suportados.
- Uma nova opção MemoryZSwapMax= para configurar as propriedades do cgroup memory.zswap.max.
- Unidades de escopo do Systemd agora suportam a opção OOMPolicy= com escopos de sessão de login agora padronizados para OOMPolicy=continue para que sobrevivam ao OOM killer encerrando alguns processos no escopo.
- A taxa máxima na qual os recarregamentos do daemon são executados agora pode ser controlada por meio das opções ReloadLimitIntervalSec= e ReloadLimitBurst=.
- O Systemd agora executa geradores em um namespace de montagem “sandbox” com a maior parte do sistema de arquivos sendo somente leitura e, em seguida, apenas acesso de gravação para diretórios de saída e um ponto de montagem /tmp temporário.
- Um novo tipo de unidade de Type=notify-reload onde quando uma unidade é recarregada via sinal, o gerente irá esperar até receber uma notificação “READ=1” da unidade.
- Uma nova variável de ambiente $SYSTEMD_DEFAULT_MOUNT_RATE_LIMIT_BURST pode ser usada para substituir o limite de taxa de estouro das unidades de montagem para analisar /proc/self/mountinfo, com um valor padrão de 5.
- O Systemd-boot agora passa sua semente aleatória diretamente para o RNG do kernel através da tabela de configuração LINUX_EFI_RANDOM_SEED_TABLE_GUID.
- O Systemd-boot agora pode ser carregado de uma inicialização direta do kernel no QEMU, quando incorporado ao firmware ou outros cenários não ESP.
- “systemctl kexec” agora suporta Xen.
- Várias novas opções para systemd-dissect e systemd-repart.
- systemd-cryptenroll agora suporta desbloqueio via tokens FIDO2.
- Novas opções de configuração de tempo de construção do Meson de -Ddefault-timeout-sec= e -Ddefault-user-timeout-sec= para controlar os segundos para o tempo limite padrão de iniciar/parar/interromper o sistema e as unidades do usuário. Isso tornará mais fácil para cenários como o Fedora Linux trabalhar para reduzir seu tempo de desligamento, reforçando os padrões para desligar os serviços do systemd.
- systemd-boot adiciona um modo “if-safe” para executar o registro de certificado automatizado UEFI Secure Boot da EFI System Partition (ESP) somente se for considerado “seguro” fazê-lo. Para esta versão, é considerado “seguro” se executado em uma máquina virtual.
- systemd-sysusers agora criará automaticamente /etc se estiver faltando.
- Uma nova configuração de SuspendEstimationSec= para controlar o intervalo para medir o nível de carga da bateria como parte do serviço de suspensão e depois hibernação do sistema.
- A configuração padrão do tmpfiles.d agora criará automaticamente o diretório de armazenamento de credenciais com as permissões seguras apropriadas.
- A lógica de dissecação de imagem DDI usada por RootImage= em arquivos de unidades de serviço, a opção “–image=” em ferramentas como systemd-nspawn, etc., agora montará apenas sistemas de arquivos dos tipos Btrfs, EXT4, XFS, EROFS , SquashFS ou VFAT. Isso pode ser substituído usando a variável de ambiente $SYSTEMD_DISSECT_FILE_SYSTEMS, mas essa lista suportada de sistemas de arquivos está sendo baseada em ser bem suportada e mantida nos kernels atuais, particularmente em torno de suporte e correções de segurança.
- As unidades de serviço têm uma nova configuração OpenFile= que pode ser usada para abrir arquivos arbitrários no sistema de arquivos ou soquetes AF_UNIX arbitrários enquanto passa o descritor de arquivo aberto para o processo chamado por meio do protocolo de passagem FD. A intenção com essa funcionalidade do OpenFile é que serviços não privilegiados acessem arquivos selecionados com modos de acesso restritivos.
Aqueles que desejam buscar o systemd 253-rc3 antes do lançamento oficial podem encontrar a versão recém-lançada no GitHub.