Cambios en Fedora 42 Para Administradores del Sistema

Puede encontrar notas adicionales en la documentación de desarrollo.

Las imágenes de la arquitectura alternativa RISC-V con soporte no oficial ya están disponibles para Fedora 42 en sus versiones de servidor, nube y contenedor. Para más información, consulte el link: https://discussion.fedoraproject.org/t/fedora-42-risc-v-non-official-images-are-available/148866 [publicación de anuncio en Fedora Discussion].

En Fedora 42, el directorio /usr/sbin se convierte en un enlace simbólico a bin, lo que significa que rutas como /usr/bin/foo y /usr/sbin/foo apuntan al mismo lugar. /bin y /sbin ya son enlaces simbólicos a /usr/bin y /usr/sbin, por lo que /bin/foo y /sbin/foo también apuntan al mismo lugar. /usr/sbin se eliminará del $PATH predeterminado. El mismo cambio también se realiza para que /usr/local/sbin apunte a /bin, lo que hace que /usr/local/bin/foo y /usr/local/sbin/foo apunten al mismo lugar.

La definición de %_sbindir se ha cambiado a %_bindir, por lo que los paquetes comenzarán a usar el nuevo directorio después de una reconstrucción sin ninguna acción adicional.

Los mantenedores pueden dejar de usar %_sbindir, pero no es necesario.

En Fedora 42, la pantalla de inicio (plymouth) ahora utiliza de manera predeterminada el framebuffer del firmware EFI para mostrar la pantalla de inicio antes durante el arranque.

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.

El comportamiento anterior de esperar a que se cargue el controlador de la GPU antes de exhibir la pantalla de bienvenida se puede restaurar ejecutando:

Alternativamente, el factor de escala hiDPI estimado se puede anular ejecutando:

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

Como alternativa, en lugar de usar la línea de comandos del kernel, estos ajustes se pueden configurar editando /etc/plymouth/plymouthd.conf. Descomente la línea [Daemon] y luego agregue las líneas con:

Después de editar /etc/plymouth/plymouthd.conf, se debe regenerar el initrd para incluir el archivo actualizado ejecutando sudo dracut -f.

La utilidad fips-mode-setup se ha eliminado de Fedora. Para operar un sistema en modo FIPS, tiene una de las siguientes opciones:

Ya no se recomienda cambiar un sistema al modo FIPS después de la instalación. Por ejemplo, el cifrado de disco con LUKS o la generación de claves OpenSSH tomarán decisiones algorítmicas durante la instalación o el primer arranque que no cumplen con la normativa FIPS si no se ejecutan en modo FIPS.

Si aún necesita cambiar un sistema al modo FIPS tras la instalación y conoce los riesgos, puede agregar el argumento fips=1 a la línea de instrucción del kernel. Tenga en cuenta que si su /boot está en una partición separada, también deberá agregar el UUID de la partición a la línea de instrucciones para que el módulo initramfs de dracut FIPS pueda encontrar el kernel y su archivo de suma de comprobación; de lo contrario, el arranque fallará. La instrucción siguiente lo hace en un solo paso:

Para desactivar el modo FIPS, debe reinstalar el sistema. Si necesita cambiar un sistema existente (lo cual no se recomienda), puede usar grubby de nuevo para eliminar el argumento de la línea de instrucciones fips=1.

El mecanismo rpm integrado para crear usuarios del sistema a partir de metadatos de sysusers.d distribuidos por paquetes ahora se utiliza para crear usuarios del sistema, reemplazando el uso anterior de scriptlets rpm personalizados en paquetes individuales.

Para obtener más información sobre la creación de usuarios a través de sysusers.d, consulte el documentación de RPM ascendente.

En los sistemas Fedora Atomic Desktop, el montaje raíz del sistema (/) ahora se realiza mediante composefs, lo que lo convierte en un sistema de archivos de solo lectura, lo que aumenta la integridad y robustez del sistema. Este es el primer paso hacia una verificación completa de la integridad del sistema de archivos en tiempo de ejecución.

Este cambio sigue a uno similar en el Fedora 41 que habilitó ComposeFS de manera predeterminada en las ediciones Fedora CoreOS e IoT.

A partir de Fedora 42, Fedora Atomic Desktop ya no está disponible para la arquitectura PPC64LE (Power Little Endian de 64-bit) debido a la falta de interés. Quienes deseen usar Atomic en dicho sistema deben revertir a una instalación en modo paquete de Fedora o crear sus propias imágenes utilizando contenedores de arranque disponibles 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.

La sección Primeros pasos del Documentación de Fedora IoT se ha actualizado para reflejar este cambio.

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.

Este cambio ayuda a alinear Fedora CoreOS con la iniciativa en curso Contenedores de arranque.

Fedora se distribuye como contenedores de arranque a través del registro OCI. La instalación suele realizarse mediante la conversión a una imagen de máquina virtual o un instalador ISO a través del osbuild (generador de imágenes); sin embargo, el arranque desde la red es un flujo de trabajo útil para implementaciones de flotas sin sistema operativo. Anteriormente, los archivos necesarios para realizar dicha instalación no estaban disponibles en el repositorio OCI, que podía obtenerse del registro de forma similar al contenedor de arranque. Esto cambia en Fedora 42.

Anteriormente, los archivos Kickstart solo estaban disponibles en el repositorio RPM de Fedora, y podía resultar complicado encontrar la versión adecuada del repositorio RPM y extraer los archivos necesarios, en lugar de obtener todos los recursos necesarios únicamente del registro. Fedora 42 introduce un repositorio OCI con los archivos correspondientes para cada versión estable de Fedora.

Los archivos Kickstart también continuarán distribuyéndose en repositorios RPM.

Consulte la Página de cambios en Fedora Wiki para obtener más información.

Ahora Fedora proporciona imágenes WSL (Subsistyema Windows para Linux). Están disponibles para descarga en la página nube Getfedora.

WSL es un subsistema de Windows que permite a los usuarios de Windows ejecutar fácilmente múltiples distribuciones de Linux invitadas como contenedores dentro de una única máquina virtual administrada por un host de Windows.

El contenedor base de Fedora ya se puede utilizar con WSL, pero no es ideal ya que excluye intencionalmente la documentación y las herramientas no esenciales que proporciona esta imagen de nube.

Para obtener documentación sobre cómo utilizar estas imágenes, consulte el Documentos de 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.

Además, el paquete ansible-core se ha modernizado a la versión 2.18. Algunos de los cambios más destacados incluyen:

Para más detalles, consulte el documentación ascendente.

Intel Software Guard Extensions (SGX) es una tecnología que permite la creación de enclaves de ejecución. Su memoria está cifrada y, por lo tanto, protegida del resto del código que se ejecuta en la CPU, incluyendo el Modo de Administración del Sistema (SMM), el firmware, el kernel y el espacio de usuario.

Esta actualización de Fedora proporciona la pila de software del host SGX, los enclaves arquitectónicos y los paquetes de desarrollo. El cambio se centra en la habilitación de la infraestructura de software general. El propósito es introducir aplicaciones y funciones futuras , los cuales tengan una dependencia sobre SGX.

Fedora 42 introduce una nueva forma de gestionar la instalación de paquetes RPM desde repositorios mientras haya claves PGP obsoletas en el sistema. Anteriormente, estas claves debían eliminarse manualmente mediante la ejecución de rpmkeys --delete. A partir de esta versión, las claves caducadas se detectarán automáticamente antes de cualquier transacción DNF y se gestionarán adecuadamente mediante un nuevo complemento libDNF5, habilitado por defecto.

Para quienes usen el modo interactivo, ahora aparecerá un aviso informándoles sobre cada clave obsoleta en el sistema y solicitando confirmación para eliminarla. Para los usuarios no interactivos, el flujo de trabajo no cambiará.

Esta actualización mejora la forma en que se descargan e instalan los paquetes de software en Fedora. Este cambio ofrece una mejor experiencia a los usuarios, ya que reduce la cantidad de recursos de E/S necesarios y compensa el consumo de CPU de la descompresión de paquetes. Como resultado, el sistema operativo instala y actualiza los paquetes más rápido.

Tenga en cuenta que este comportamiento no está encendido de manera predeterminada, por lo que por ahora está habilitado explícitamente.

Stratis 3.8.0, lo cual consiste en stratisd 3.8.0 y stratis-cli 3.8.0 incluyen dos mejoras significativas, así como un número de mejoras menores.

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 también incorpora compatibilidad con múltiples vínculos para el cifrado mediante el mismo mecanismo. Anteriormente, Stratis solo permitía un único vínculo que utilizaba una clave del anillo del kernel; ahora, se pueden usar múltiples vínculos con diferentes claves para el mismo consorcio (pool). De igual forma, se pueden usar múltiples vínculos que utilizan el mecanismo de cifrado Clevis con el mismo consorcio. El número total de vínculos está limitado a 15.

Este cambio permite varios casos de uso que el esquema anterior no permitía. Por ejemplo, un consorcio podría configurarse para que se desbloquee con una clave perteneciente a un administrador de almacenamiento, para el mantenimiento ocasional necesario, y con una clave diferente por parte del usuario designado del consorcio (pool).

Anteriormente, al iniciar un grupo cifrado, el usuario debía designar un método de desbloqueo, como clevis o keyring. Dado que esta versión permite múltiples enlaces con un solo método de desbloqueo, se introduce un método más general para especificar un mecanismo de desbloqueo al iniciar el grupo. El usuario puede especificar --unlock-method=any y probar todos los métodos disponibles. También puede especificar que el grupo se abra con un enlace específico mediante la opción --token-slot. También puede optar por introducir una contraseña para desbloquear el grupo, ya sea mediante la opción --capture-key o un archivo de claves mediante la opción --keyfile-path. De forma similar, el comando unbind ahora requiere que el usuario especifique el enlace que se desvinculará mediante la opción --token-slot. El método rebind requiere que el usuario especifique una ranura de testigo específico con la opción --token-slot si el grupo tiene más de un enlace con el mismo método.

Además hubo un número de mejoras internas, arreglos de defectos menores, y actualizacoines de dependencia.

Por favor consulte las bitácoras de cambios en stratisd y stratis-cli para información adicional sobre la publicación.

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.

Puede encontrar notas de publicacion para la versión 2.2 en los enlaces siguientes:

El Servidor de Tráfico Apache (trafficserver) de Fedora se ha modernizado a la versión 10.x. El archivo /etc/trafficserver/records.config se actualizará automáticamente al nuevo formato records.yaml. Es posible que se requieran pasos de actualización adicionales si se utilizan funciones o API retiradas; consulte el documentación original.

Fedora 42 proporciona el paquete bpfman.

Bpfman es una pila de software que simplifica la gestión de programas eBPF en clústeres de Kubernetes o en hosts individuales. Consta de un demonio de sistema (bpfman), definiciones de recursos personalizadas (CRD) de eBPF, un agente (bpfman-agent) y un operador (bpfman-operator). Desarrollado en Rust sobre la biblioteca Aya, bpfman ofrece mayor seguridad, visibilidad, compatibilidad con múltiples programas y mayor productividad para los desarrolladores.

Para Fedora, la integración de bpfman optimizaría la carga de programas eBPF. Mejora la seguridad al restringir los privilegios al demonio bpfman controlado, simplifica la implementación en clústeres de Kubernetes y ofrece mayor visibilidad de los programas eBPF en ejecución. Esta integración se alinea con el compromiso de Fedora de proporcionar soluciones eficientes y seguras, facilitando a los usuarios aprovechar las ventajas de eBPF en sus 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 que se actualizan a Fedora 42, el nuevo valor de IPv6_rpfilter depende de si el usuario ha personalizado /etc/firewalld/firewalld.conf. De no ser así, el proceso de actualización de RPM actualizará la configuración a IPv6_rpfilter=loose. En caso afirmativo, se conservará la configuración existente.

Tenga en cuenta que este cambio es una desviación del firewalld upstream, que continúa con el valor predeterminado IPv6_rpfilter=strict.

Fedora 42 reemplaza el plugin Cockpit Navigator con Cockpit Files. El año pasado, el proyecto Cockpit lanzó un nuevo plugin Cockpit Files con soporte oficial, diseñado para ofrecer una alternativa moderna al plugin Cockpit Navigator existente. La última versión (14) es compatible con todas las funciones de Cockpit Navigator, excepto la creación de enlaces simbólicos, cuya implementación está prevista.

Reemplazar cockpit-navigator por cockpit-files produce un cambio visual dentro de Cockpit: el apunte del menú Navigator será reemplazada por un apunte nuevo del menú Archivo explorador en Herramientas.

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 permite que los hosts de virtualización lancen máquinas virtuales confidenciales mediante la tecnología SEV-SNP de AMD. La virtualización confidencial impide que los administradores con acceso root o con una pila de software de host comprometida accedan a la memoria de cualquier invitado en ejecución. SEV-SNP es una evolución de las tecnologías SEV y SEV-ES anteriores, que ofrece una mayor protección y desbloquea nuevas funciones, como un TPM virtual seguro.

Fedora ahora ofrece un mecanismo para cargar automáticamente binarios optimizados para las versiones más recientes de la arquitectura x86_64 mediante glibc-hwcaps. Los usuarios podrían notar tiempos de ejecución más rápidos para los binarios en los que el responsable del paquete ha habilitado este mecanismo. Para obtener una explicación completa, consulte el enlace: https://fedoraproject.org/wiki/Changes/Optimized_Binaries_for_the_AMD64_Architecture_v2[Página de cambios] en la wiki de 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.

Si aún no ha actualizado a la transmisión predeterminada 16, debe seguir la estrategia de modernización estándar:

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.

Los entornos en vivo de Fedora Linux ahora utilizan el Sistema de Archivos de Sólo-Lectura Mejorado (EROFS), un sistema de archivos de sólo lectura moderno y rico en funciones.

El pam_ssh_agent_auth paquete ha sido quitado de Fedora 42 debido a estar obsoleto y raramente utilizado.