Tengo un servidor Linux que se ejecuta en Redhat Enterprise (RHEL), pero las versiones de la herramienta en los administradores de paquetes a menudo son obsoletas. ¿Cómo puede alguien reclamar estabilidad para RHEL mientras todas las herramientas están tan desactualizadas? ¿Realmente vale la pena?

Realmente hay una idea errónea sobre el control de versiones de los paquetes que Red Hat ofrece a través de los canales.

El punto importante es: “¡ Red Hat mantiene una versión de paquete diferente y NO es exactamente lo mismo que los paquetes ascendentes! ” Sí, esto es cierto.

Permítanme poner todos los puntos que sé para justificar por qué las versiones del paquete son diferentes a las versiones anteriores.

1. Red Hat no solo toma las fuentes de arriba, sino que trabaja en esa fuente y la hace estable para los sistemas de nivel empresarial.
2. Para una máquina de nivel empresarial, la nueva característica puede ser una característica de arriba, pero estable, es realmente un punto positivo.
3. Como Red Hat mantiene un esquema de versiones de paquete diferente, casi todo el tiempo, las pruebas de vulnerabilidad que se realizan en base a versiones anteriores y allí ChangeLogs dan resultados falsos. (¡Las Pruebas de Vulnerabilidad que solo comparan las versiones de los paquetes con los paquetes anteriores), por lo que los Paquetes de Red Hat parecen ser ” demasiado viejos”!

Red Hat Engineering trabaja en un concepto llamado backporting de un parche desde arriba, lo que significa que, sin cambiar la versión / versión principal de un paquete, obtener el parche ascendente en el paquete xyz. Tiene algunas razones comerciales también. Considere que su organización ha realizado algún tipo de certificación en RHEL para un nivel de paquete en particular, y si Red Hat lanza algún tipo de actualización y cambia la versión de los paquetes a la misma velocidad, su certificación no durará mucho tiempo. Solo para agregar, Red Hat lanza actualizaciones de seguridad lo antes posible, lo cual es realmente admirado por los clientes. Red Hat envía los paquetes a largo plazo, es decir, el paquete y su versión se toman de la parte superior y se entregan a largo plazo, sin embargo, Red Hat todavía tiene que incluir las correcciones de errores y las últimas actualizaciones de los paquetes, esta es la razón Red Hat respalda los nuevos cambios en los paquetes en lugar de cambiar los números de versión a las versiones más altas. Mientras tanto, Ingeniería también tiene que mantener la compatibilidad con versiones anteriores. En palabras simples ” Agregue algo nuevo sin romper nada más que funcione “.

No se deben comparar las versiones de los paquetes ascendentes y los paquetes proporcionados por Red Hat para confirmar si los paquetes que proporciona Red Hat están desactualizados o no. 🙂

Para comprender el proceso completo de backporting, eche un vistazo al enlace Correcciones de seguridad de backporting.

Y lo último no siempre garantiza la estabilidad. Red Hat Engineering tiene que hacer muchas pruebas de regresión por parte del equipo de control de calidad. Para garantizar la estabilidad, asegúrese de obtener las actualizaciones de paquetes firmadas de los canales de Red Hat y, en caso de actualizaciones o declaraciones de vulnerabilidad de seguridad, consulte access.redhat.com | Base de datos CVE