Translated message

A translation of this page exists in English.

¿Cómo se soporta una versión específica de RHEL?

Actualizado -

ISSUE

  • La información en la página Ciclo de Vida de Red Hat Enterprise Linux no es lo suficientemente específica o detallada para determinar la compatibilidad de un problema.

  • Tengo un problema y no estoy seguro que tenga o este disponible una solución para mí.

  • ¿Existen diferentes criterios de inclusión para Red Hat Enterprise Linux en función de la Fase de Producción de la versión menor actual?

AMBIENTE

  • Red Hat Enterprise Linux (Cualquier Versión)

SOLUCIÓN

Tres datos puntuales determinan la capacidad de soporte al problema reportado de un cliente:

  • ¿En qué versión menor ha sido reportado el problema?

  • ¿Donde, en su Ciclo de vida, se encuentra la versión mayor de RHEL actualmente?

  • ¿Qué suscripciones activas tiene en su cuenta el cliente?

Ejemplos:

  • Si un problema de soporte se registra en un paquete perteneciente a la versión menor activa actual y dados los criterios de inclusión de la Fase de producción actual en su ciclo de vida, los clientes tienen derecho tanto al soporte de GSS como al soporte de Ingeniería de la versión mayor en ese momento. Por lo tanto, los clientes pueden reportar errores y descargar/instalar correcciones que se entregan asincrónicamente dentro de la versión actual.

  • Si se registra un problema de soporte técnico en un paquete perteneciente a una versión menor pasada, los clientes todavía tienen derecho a la compatibilidad con Red Hat. Sin embargo, los paquetes de correcciones de ingeniería sólo se pueden proponer en una futura versión menor activa y de forma asíncrona (si procede, dado los criterios de inclusión del ciclo de vida) en la versión menor activa actual.

    • Definición de "soporte" a versiones menores pasadas:

      • Si se encuentra la causa raíz de un defecto y es identificado como resuelto dentro de la versión menor actual activa, Red Hat Support deberá aconsejar al cliente actualizar al paquete liberado con la corrección. Una corrección a un defecto no puede ser retroportada a una versión menor no actual.

      • Si no se encuentra la causa raíz de un defecto o no ha sido identificado como resuelto dentro de la versión menor actual activa, Red Hat Support solicitará al cliente primero intentar reproducir el problema observado con el paquete correspondiente en la versión menor activa actual.

        • Si el paquete de la versión menor activa resuelve el problema, se recomienda al cliente que confiera este paquete a su entorno de producción.

        • Si el paquete de la versión menor activa no resuelve el problema, y un paquete de corrección está disponible, Red Hat Support puede proponer la corrección a la próxima versión menor activa y, posiblemente, una errata distribuido de forma asíncrona (si cumple con los criterios de liberación asincrónicos).

      • NOTA: Los clientes no están obligados a actualizar sus sistemas a la versión menor activa en su totalidad, sólo los paquetes específicos relevantes afectados.

      • NOTA: Para la mayoría de las situaciones, una corrección a un defecto debe primero ser confiada al upstream de la comunidad antes de ser propuesta en un lanzamiento menor de RHEL.

  • Si un problema de soporte se registra en un paquete perteneciente a una versión activa EUS (Extended Update Support), entonces el cliente tiene derecho al soporte de GSS y de ingeniería, suponiendo que cumple con los criterios de inclusión de EUS y los criterios actuales de inclusión de RHEL en una versión menor.

    • Definición de "soporte" al componente EUS:

      • Si un defecto ya se ha corregido en una versión menor, entonces Red Hat Support puede solicitar que Red Hat Engineering porte la corrección a la versión activa específica de EUS.

      • Si un defecto es nuevo en el producto, entonces Red Hat Support puede solicitar que el defecto se solucione en la versión menor activa actual, así como que Red Hat Engineering realice back port (clone) la corrección a la versión activa específica de EUS.

    • NOTA: Una corrección a un defecto debe primero ser confiada a la última liberación menor activa antes de ser confiada a la liberación activa específica de EUS.

  • Si un problema de soporte técnico se registra en un paquete compatible y la arquitectura está asociada a una versión de ELS(soporte de ciclo de vida extendido), se solicitarán correcciones de errores y se desarrollarán contra la última versión menor activa. Por ejemplo, si un cliente tiene una suscripción de complemento de ELS pero ejecuta RHEL 5.7, todas las correcciones solicitadas se desarrollarán con RHEL 5.9. Tenga en cuenta que el soporte oficial no se niega a versiones menores anteriores recientes, pero las correcciones contra una suscripción de complemento de ELS se realizan en la última versión menor.

  • Si se ha corregido un defecto y ha sido incluido en un Errata publicado, el soporte de Red Hat no proporcionará una solución alternativa/provisional. Red Hat Support recomienda que los clientes actualicen sus sistemas con la Errata aplicable.

GLOSARIO

  • Soportabilidad - Definido como soporte por Red Hat Global Support Services y/o Red Hat Engineering. Por ejemplo, puede existir una situación en la que un cliente pueda ser apoyado por Servicios de Soporte Global, pero no soportado por Ingeniería dependiendo de qué versión menor es con la que se informa el problema, donde el Ciclo de Vida de la versión mayor de Red Hat Enterprise Linux es la actual, además de qué suscripciones están activas en la cuenta del cliente.

  • Versión Mayor - Ejemplos: RHEL 4.0, 5.0, 6.0, 7.0 etc...

  • Versión menor - Ejemplos: RHEL 4.9, 5.11, 6.6, etc..

  • Versión menor activa actual: una versión menor que sigue recibiendo correcciones, actualizaciones y/o erratas de seguridad basadas en su Ciclo de vida

  • Versión menor pasada  (Versión menor caducada) - Versión que ya no está activa, y por lo tanto no recibe correcciones, actualizaciones y/o erratas de seguridad

  • Entrega asincróna: las correcciones se entregan entre versiones menores según sea necesario o bajo demanda

  • Complemento EUS (Extended Update Support) - El complemento EUS proporciona un flujo independiente de aquellos RHSAs de impacto crítico y una selección de RHBAs Prioritarios Urgentes para versiones específicas durante 24 meses después de la disponibilidad general. Para los suscriptores del complemento EUS, Red Hat continuará proporcionando las correcciones de seguridad de impacto crítico independientemente de las solicitudes de los clientes.

  • Complemento de ELS (Soporte de ciclo de vida extendido) - El componente ELS proporciona soluciones de seguridad de impacto crítico y soluciones de defectos de prioridad urgente seleccionadas que son Disponibles y calificados para un subconjunto de paquetes más allá de las fases de producción del ciclo de vida. Para los suscriptores del complemento ELS, Red Hat continuará proporcionando las correcciones de seguridad de impacto crítico independientemente de las solicitudes de los clientes.

REFERENCIAS

Comments