Rechercher

4.2. Corriger JBoss EAP 6

download PDF

4.2.1. Mécanismes de correction

Les correctifs de JBoss sont distribués sous deux formes : zip (pour tous les produits) et RPM (pour un sous-groupe de produits).

Important

Une installation de produits JBoss doit toujours être mise à jour par la méthode: soit Zip, soit RPM. Seuls les correctifs de sécurité et les correctifs cumulatifs sont disponibles via RPM, et les clients qui utilisent une installation RPM ne seront pas en mesure d'effectuer les mises à jour par la méthode Zip.
Les correctifs de JBoss peuvent être sous forme de mise à jour asynchrône ou plannifiée :
  • Mises à jour asynchrônes : correctifs ponctuels publiés en dehors d'un cycle de mise à jour normal du produit existant. Ces mises à jour peuvent inclure des correctifs de sécurité, ainsi que d'autres correctifs ponctuels fournis par GSS (Red Hat Global Support Services) pour résoudre ces problèmes particuliers.
  • Mises à jour planifiées : les correctifs cumulatifs d'un produit existant, qui incluent toutes les mises à jour développées auparavant pour cette version du produit.
La décision de savoir si un patch doit être divulgué ou non dans le cadre d'une mise à jour planifiée ou d'une mise à jour asynchrone dépend de la sévérité du problème que l'on tente de régler. Les problèmes de faible impact sont généralement différés, et sont résolus dans la prochaine version mineure des produits concernés. Les problèmes dont l'impact est modéré ou supérieur sont généralement traités par ordre d'importance sous forme de mise à jour de produit lors d'une sortie asynchrone et sont résolus par un correctif au problème particulier.
Les mises à jour de sécurité pour les produits de JBoss sont fournis par un erratum (pour les zip et les méthodes RPM). L'erratum comprend une liste de défauts résolus, leurs indices de gravité, les produits concernés, une description textuelle des défauts et une référence de correctifs. Les mises à jour de correction de bogues sont annoncées par un erratum.

Important

Il est important de noter qu'une fois qu'un correctif a été appliqué, les jars sont collectés en cours d'exécution à partir du répertoire EAP_HOME/modules/system/layers/base/.overlays/$PATCH_ID/$MODULE. Les fichiers d'origine sont laissés en EAP_HOME/modules/system/layers/base/.overlays/$PATCH_ID/$MODULE. Le mécanisme de correction paralyse les fichiers jar d'origine pour des raisons de sécurité. Cela signifie que si vous appliquez un correctif qui met à jour un module, les fichiers jar du module d'origine seront modifiés afin de devenir inutilisables. Si le correctif est renversé, les fichiers d'origine reviennent dans à un état utilisable. Il faut également que la procédure appropriée soit utilisée pour renverser l'action de tout correctif appliqué. Voir Section 4.2.2.3, « Annulation d'un correctif sous forme zip par le système de gestion des correctifs » pour la procédure de rollback qui convient.
Pour savoir comment Red Hat évalue les erreurs dans JBoss, consultez : Section 4.2.5, « Évaluation de la gravité et de l'impact des correctifs JBoss Security »
Red Hat maintient une liste de distribution pour notifier les abonnés à propos des défauts liés à la sécurité. Voir Section 4.2.4, « Abonnez-vous aux listes de diffusion de correctifs (Patch Mailing Lists) »
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.