4.2. Aplicación de parches en JBoss EAP 6
4.2.1. Mecanismos para uso de parches
Los parches de JBoss se distribuyen en dos formas: zip (para todos los productos) y RPM (para un subgrupo de productos).
Importante
Una instalación del producto JBoss siempre se debe actualizar utilizando un solo método de parches: ya sea parches zip o RPM. Solo los parches de seguridad y acumulativos estarán disponibles a través de RPM, y los clientes que utilizan una instalación RPM no podrán actualizar mediante parches zip.
Los parches de JBoss pueden ser una actualización asincrónica o planeada:
- Actualizaciones asincrónicas: parches individuales que se lanzan por fuera del ciclo normal de actualización del producto existente. Estos pueden incluir parches de seguridad así como otros parches individuales proporcionados por los servicios globales de soporte de Red Hat (GSS) para solucionar problemas específicos.
- Actualizaciones planeadas: los parches acumulativos de un producto existente, lo cual incluye las actualizaciones desarrolladas anteriormente para esa versión del producto.
El decidir si un parche se lanza como parte de una actualización planeada o como una actualización asincrónica depende de la gravedad del problema que se está arreglando. Un problema de bajo impacto usualmente se pospone y se resuelve en el siguiente parche acumulativo o lanzamiento menor de los productos afectados. Los problemas de impacto moderado o mayor usualmente se abordan en orden de importancia con una actualización del producto con un lanzamiento asincrónico y solo contiene una solución para un problema específico.
Las actualizaciones de seguridad para los productos JBoss se proporcionan por medio de erratas (para métodos zip y RPM). Las erratas encapsulan una lista de las fallas resueltas, el grado de gravedad, los productos afectados, la descripción textual de las fallas y una referencia a los parches. Las actualizaciones de las correcciones de errores no se anuncian por medio de erratas.
Importante
Es importante observar que después de que se ha aplicado un parche, las jars que se detectan en tiempo de ejecución se detectan del directorio
EAP_HOME/modules/system/layers/base/.overlays/$PATCH_ID/$MODULE. Los archivos originales se dejan en EAP_HOME/modules/system/layers/base/$MODULE. El mecanismo de aplicación de parches inhabilita los archivos jar originales por razones de seguridad. Esto significa que si aplica un parche que actualiza un módulo, los archivos jar del módulo original se alteran y no se pueden utilizar. Si el parche se deshace entonces los archivos originales se podrán volver a utilizar. Esto significa que se debe utilizar el procedimiento apropiado para deshacer para poder deshacer cualquier parche aplicado. Consulte Sección 4.2.2.3, “Deshacer la aplicación de un parche en forma zip utilizando el sistema de administración de parches” para ver el procedimiento para deshacer apropiadamente.
Para obtener mayor información sobre la manera en que Red Hat evalúa las fallas de seguridad de JBoss, consulte: Sección 4.2.5, “Clasificación de gravedad e impacto de los parches de seguridad de JBoss”
Red Hat mantiene una lista de correo para notificar a los suscriptores sobre las fallas relacionadas con la seguridad. Consulte: Sección 4.2.4, “Suscripción a las listas de correo de parches”
