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.

Dado que el framebuffer EFI no proporciona el DPI de la pantalla, Plymouth ahora calcula si se debe usar un escalado 2x hiDPI según la resolución de la pantalla. Por lo tanto, Fedora 42 podría usar un factor de escala diferente para la pantalla inicial, lo que solo afecta a la pantalla inicial.

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:

Cambie =1 a =2 para forzar una escala de 2x. Tenga en cuenta que, si se usa esto, el factor de escala de la especie se aplicará a todas las pantallas.

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.

Las versiones anteriores de Fedora IoT utilizaban el servidor de aprovisionamiento Zezere para la configuración inicial. Sin embargo, este enfoque causó problemas a algunos usuarios, especialmente a aquellos que usaban IPv6. A partir de Fedora 42, Zezere se ha reemplazado por systemd-firstboot. Los usuarios que no han podido usar Zezere tendrán una forma más sencilla y directa de configurar su sistema, lo que resultará en menos frustración durante el crucial primer arranque.

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

Fedora CoreOS ahora recibe actualizaciones desde el link:https://quay.io/fedora/fedora-coreos en vez del repositorio OSTree de Fedora. El antiguo repositorio OSTree seguirá activo hasta el lanzamiento de Fedora 43. Las imágenes de disco se actualizarán primero, por lo que las nuevas instalaciones de Fedora CoreOS basadas en Fedora 42 usarán imágenes OCI desde el principio. Los nodos existentes serán migrados en el futuro.

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.

En esta versión de Fedora, el paquete ansible ha sido modernizado a la versión 11. Hay muchos cambios y para ver la lista completa de ellos, consulte el documentación ascendente.

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.

Lo más significativo es que Stratis 3.8.0 introduce una pila de almacenamiento revisada. Se describe el motivo de este cambio y la estructura general de la pila de almacenamiento [en una publicación aparte].

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.

La biblioteca de compresión de datos zlib-ng en Fedora 42 ha sido actualizado a la versión 2.2, concretamente a la 2.2.4. Esta versión actualizada ofrece optimizaciones nuevas, reescribe la asignación de memoria desinflada, y mejora los sistemas de compilación y las pruebas.

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.

Las variantes de Fedora Workstation utilizan comprobaciones de conectividad por defecto. Estas comprobaciones pueden fallar en huéspedes multihome (p. ej., LAN + Wi-Fi) donde firewalld utiliza IPv6_rpfilter=strict. Por lo tanto, a partir de Fedora 42, Fedora Workstation por defecto utiliza IPv6_rpfilter=loose para que las comprobaciones de conectividad funcionen correctamente.

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.

La interfaz de usuario de cockpit-files es diferente de la de cockpit-navigator pero ofrece la misma funcionalidad con la excepción de la creación de enlaces simbólicos. cockpit-files utiliza PatternFly como kit de herramientas de interfaz de usuario, lo que hace que la experiencia del usuario sea más consistente.

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.

La versión 15 de PostgreSQL se retirará de Fedora 42 debido a la existencia de versiones más recientes (16 y 17). La versión 16 ya es la predeterminada (anunciada en el cambio de PostgreSQL16), y la versión 17 sería la alternativa.

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

El paquete opendmarc incluía previamente un conjunto de binarios de soporte opcionales que no son necesarios para configurar el servicio, lo cual obligaba a extraer una gran cantidad (más de 80) de paquetes adicionales como dependencias. A partir de Fedora 42, el paquete opendmarc solo contiene utilidades básicas, y se pueden instalar herramientas adicionales por separado si es necesario, lo que podría ahorrar espacio para quienes no las necesiten. Los nuevos paquetes independientes son:

Anteriormente, el paquete git era complejo, estaba dividido en varios subpaquetes y proporcionaba el binario git. Para satisfacer las necesidades de los paquetes que requerían el binario git, el proceso de instalación era largo y computacionalmente intensivo. Con esta actualización, el binario git ahora se proporciona a través del paquete git-core, lo que debería reducir la cantidad de paquetes instalados como dependencias transitorias del paquete principal.

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.