Red Hat Training

A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform

4.2. Patches für JBoss EAP 6

4.2.1. Zu Patching-Mechanismen

JBoss-Patches gibt es in zwei Formen: Zip (für alle Produkte) und RPM (für einen Teil der Produkte).

Wichtig

Eine JBoss-Produktinstallation darf stets nur mittels einer Patch-Methode aktualisiert werden: entweder Zip- oder RPM-Patches. Nur kumulative und Sicherheits-Patches stehen als RPM zur Verfügung. Kunden, die eine RPM-Installation verwenden, können keine Zip-Patches zur Aktualisierung verwenden.
JBoss-Patches können entweder ein asynchrones Update oder ein geplantes Update enthalten:
  • Asynchrone Updates: Individuelle Patches, die außerhalb des regulären Upgrade-Zyklus des bestehenden Produkts veröffentlicht werden. Diese können Sicherheits-Patches sowie andere individuelle, vom Red Hat Global Support Services (GSS) zur Behebung spezifischer Probleme bereitgestellte Patches beinhalten.
  • Geplante Updates: Diese beinhalten kumulative Patches bestehender Produkte, einschließlich von zuvor entwickelten Updates für diese Version des Produkts.
Die Entscheidung darüber, ob ein Patch als Teil eines geplanten Updates oder als asynchrones Update veröffentlicht wird, hängt vom Schweregrad des zu behebenden Fehlers ab. Fehler von nur geringem Schweregrad werden in der Regel aufgeschoben und in der nächsten Nebenrelease des betreffenden Produkts behoben. Fehler von mittlerem bis schwerwiegenderem Grad werden in der Regel je nach Wichtigkeit als ein Update zu dem Produkt mit einer asynchronen Release angegangen und enthalten nur eine Behebung des jeweiligen Fehlers.
Sicherheits-Updates für JBoss-Produkte werden von einem Erratum bereitgestellt (für sowohl Zip- als auch RPM-Methoden). Das Erratum beinhaltet eine Liste der behobenen Fehler, deren Sicherheitseinstufungen der betroffenen Produkte, schriftliche Beschreibungen der Fehler und einen Verweis zu den Patches. Updates zu Fehlerbehebungen werden nicht mittels Erratum mitgeteilt.

Wichtig

IEs ist wichtig, dass nach der Anwendung eines Patch die zur Runtime aufgenommenen Jars aus dem EAP_HOME/modules/system/layers/base/.overlays/$PATCH_ID/$MODULE-Verzeichnis genommen werden. Die Originaldateien bleiben in EAP_HOME/modules/system/layers/base/$MODULE. Der Patching-Mechanismus macht die originalen Jar-Dateien aus Sicherheitsgründen unbrauchbar. Dies bedeutet, dass bei Anwendung eines ein Modul aktualisierenden Patch, die Jar-Dateien des Originalmoduls so verändert werden, dass sie nicht mehr verwendet werden können. Wird der Patch zurückgesetzt, so werden die Originaldateien wieder in einen verwendbaren Zustand zurückversetzt. Dies bedeutet auch, dass die ordnungsgemäße Vorgehensweise bei Zurücksetzen jedes angewendeten Patch verwendet werden muss. Siehe Abschnitt 4.2.2.3, »Zurücksetzen der Anwendung eines Patches in Zip-Form mithilfe des Patch Management Systems« zur ordnungsgemäßen Vorgehensweise beim Zurücksetzen.
Weitere Informationen über die Einstufung von JBoss-Sicherheitsfehlern durch Red Hat finden Sie hier: Abschnitt 4.2.5, »Schweregrad und Einstufung der JBoss Security Patches«
Red Hat besitzt eine Mailing-Liste, die Abonnenten über Sicherheitsfehler informiert. Siehe Abschnitt 4.2.4, »Abonnieren von Patch-Mailing-Listen«