Red Hat Training
A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform
4.2. Realizando o patching ao JBoss EAP 6
4.2.1. Mecanismos de Aplicação de Patch
Os JBoss patches são distribuídos em duas formas: zip (para todos os produtos) e RPM (para um subconjunto de produtos).
Importante
A instalação do produto JBoss deve sempre ser atualizada usando um método de patch: tanto patches zip ou RPM. Apenas os patches cumulativos e de segurança estarão disponíveis através do RPM e os clientes usando a instalação RPM não poderão efetuar atualização usando patches de zip.
Os JBoss patches podem tanto ser uma atualização assíncrona ou uma atualização planejada:
- Atualizações assíncronas: Patches individuais que são lançados no ciclo de atualização normal do produto existente. Isto pode incluir patches de segurança, assim como outros patches individuais fornecidos pelo Red Hat Global Support Services (GSS) para correção de problemas específicos.
- Atualizações planejadas: Os patches cumulativos de um produto existente, que inclui todas as atualizações anteriores para a versão do produto.
A decisão de que um patch é ou não lançado como parte de uma atualização planejada ou uma atualização assíncrona depende na severidade do problema sendo corrigido. Um problema de baixo impacto é normalmente adiado e é resolvido no próximo patch cumulativo ou do menor lançamento do produto afetado, contendo uma correção para apenas um problema específico.
As atualizações de segurança para os produtos JBoss são fornecidas por uma errata (para ambos os métodos zip e RPM). A errata encapsula uma lista de falhas resolvidas, sua classificação de falhas e a referência aos demais patches. As atualizações de correção de bug não são comunicadas através de errata.
Importante
É importante notar que após um patch ser aplicado, os jars obtidos no período de execução são obtidos a partir do diretório
EAP_HOME/modules/system/layers/base/.overlays/$PATCH_ID/$MODULE. Os arquivos originais são mantidos no EAP_HOME/modules/system/layers/base/$MODULE. O mecanismo patching desabilita os arquivos jar originais por motivos de segurança. Isto significa que caso um patch que atualiza um módulo seja aplicado, os arquivos de jar do módulo original são alterados para não serem utilizáveis. Caso o patch seja revertido, os arquivos originais serão revertidos de volta a seu estado utilizável. Isto significa que o procedimento correto de reversão deve ser usado para reverter qualquer patch aplicado. Consulte a Seção 4.2.2.3, “Reversão do Aplicativo de um Patch no Formulário Zip usando o Patch Management System” para o procedimento de reversão apropriado.
Maiores informações sobre como a Red Hat avalia as falhas de segurança do JBoss podem ser encontradas na: Seção 4.2.5, “Classificação de impacto e gravidade do JBoss Security Patches (Patches de Segurança JBoss)”
A Red Hat mantém uma lista de correio para notificação aos subscritos sobre a segurança das falhas relacionadas. Consulte a Seção 4.2.4, “Subscrição para as Listas de Correio Patch”
