Bekannte Probleme und Einschränkungen

Sicherheitsbulletins, die vor 2018 veröffentlicht wurden, werden nicht ausgewertet

Mehrere Instanzen können nicht in einem Namensbereich enthalten sein

Mehrere Instanzen von WebSphere Automation können nicht in demselben Namensbereich implementiert werden. Mehrere Instanzen können in separaten Namensbereichen im Cluster implementiert werden.

Node-Agent-CVEs sind nicht im CVE-Bericht enthalten.

WebSphere Automation verwendet die Funktion zur Nutzungsüberwachung in WebSphere Application Server, um Daten zu Ihren Servern zu erfassen, damit deren Schwachstellenstatus beurteilt werden kann. Die Nutzungsmessung wird nicht in Node Agents ausgeführt. Weitere Informationen zur Nutzungsmessung finden Sie auf der Übers ichtsseite.

Nicht behobene Sicherheitslücken und -risiken können sich auf Ihre Node Agents auswirken. Werten Sie neue Sicherheitsbulletins manuell aus, um festzustellen, ob sie für Ihre Node Agents gelten.

API zeigt Version 9.0.5 für traditionelle WebSphere Application Server-Versionen 9.0.5.0 bis 9.0.5.3

Nachdem ein traditioneller WebSphere Application Server-Server beim Service zur Nutzungsüberwachung registriert wurde, können Sie das Serverasset in der Swagger-Benutzerschnittstelle anzeigen. Für die Versionen 9.0.5.0 bis 9.0.5.3hat die API 9.0.5 als Wert für version . Die Versionsnummer des Fixpacks (0, 1, 2 oder 3) fehlt.

"version": "9.0.5",

Für Versionen nach 9.0.5.3zeigt der Wert version die Fixpacknummer der Version korrekt an. Beispiel: Version 9.0.5.6 hat die vollständige Versionsnummer mit 6 für die Fixpacknummer.

"version": "9.0.5.6",

WebSphere Application Server Traditionell wird für die Nummerierung von Versionen das Format „ IBM Version, Release, Modification, Fix Pack“ ( V.R.M.F ) verwendet.

WebSphere Application Server-Basisserver werden möglicherweise nicht ordnungsgemäß als anfällig angezeigt

WebSphere Automation weist möglicherweise fälschlicherweise darauf hin, dass WebSphere Application Server-Basisserver anfällig sind. Sicherheitsbulletins, die nur für WebSphere Application Server ND-Server gelten, gelten fälschlicherweise für WebSphere Application Server -Basisserver. In diesen Fällen schlägt der Versuch, den vorläufigen Fix (iFix) aus dem Sicherheitsbulletin auf einen Basisserver anzuwenden, fehl. WebSphere Automation zeigt weiterhin die Sicherheitslücke für diesen Server als nicht behoben an.

Es ist möglich, die Sicherheitslücke manuell mithilfe der REST-API zu beheben. Die REST-APIs sind in diesem Release eine Technologievorschau und werden daher nicht unterstützt. Weitere Informationen finden Sie unter Anzeigen der REST-API.

WebSphere Application Server for z/OS - spezifische Sicherheitslücken

Sicherheitslücken, die ausschließlich für WebSphere Application Server for z/OS und IBM Java™ Development Kit for z/OS gelten, sind nicht in der Gruppe der Sicherheitslücken enthalten, die WebSphere Automationbekannt sind oder von überwacht werden. Sicherheitslücken, die auf den ibm.com/support -Seiten gemeldet werden, die sich auf mehrere Editionen auswirken, einschließlich WebSphere Application Server for z/OS, werden überwacht. Diese Sicherheitslücken, die nur über das Sicherheitsportal von IBM Z gemeldet werden, sind nicht enthalten, und die Benutzer dieses Portals müssen diese Sicherheitslücken weiterhin für diese Probleme verwenden, die nur über das Portal gemeldet wurden.

Registrierte Windows 2022-Server werden als ältere Windows -Version angezeigt

Wenn Sie einen Windows 2022-Server bei WebSphere Application Server 9.0.5.xregistrieren, gibt die JSON-Datei getAssets eine ältere Windows-Serverversion für den Parameter operatingSystem zurück. Dieser Fehler hat keine negativen Auswirkungen auf die WebSphere Automation -Operation. Das Problem wird in Java 8.0.7.5 (SR7 FP5) behoben, aber die Java-Standardversion für WebSphere Application Server 9.0.5.x ist 8.0.7.0.

Die folgende getAssets -JSON-Beispieldatei zeigt den Fehler operatingSystem: Windows Server version 2009 :

{
  "id": "c7eea541-b685-3d9a-88d3-ea62f01e601f",
  "name": "server1@hostname.example.com",
  "type": "traditional",
  "edition": "nd",
  "productName": "WebSphere Application Server Network Deployment",
  "version": "9.0.5.10",
  "apars": [
    "PH37034",
    "PH42728",
    "PH42762"
  ],
  "hostName": "hostname.example.com",
  "cellName": "NonAdminCell01",
  "nodeName": "DefaultNode01",
  "serverName": "server1",
  "installDirectory": "/C:/wsauser/IBM/WAS",
  "profileDirectory": "/C:/wsauser/IBM/WAS/profiles/AppSrv01",
  "operatingSystem": "Windows Server version 2009",
  "operatingSystemVersion": "10.0",
  "jdkId": "3003f49f-d42a-3f7d-9bd1-a7edb1ac96a7",

Fixes können für bestimmte Betriebssysteme nicht installiert werden

WebSphere Automation kann keine Fixes unter WebSphere Application Server oder WebSphere Application Server Liberty installieren, die auf z/OS -oder iSeries -Plattformen installiert sind.

Fixes können in bestimmten Installationen nicht installiert werden

Es ist nicht möglich, Fixes für die folgenden Typen von Anwendungsserverinstanzen zu installieren:

• Instanzen, WebSphere Application Server Liberty die aus dem Archiv installiert werden. Fixes können nur auf Liberty-Instanzen angewendet werden, die mit Installation Managerinstalliert werden.
• Instanzen von WebSphere Application Server oder, WebSphere Application Server Liberty die für die Verwendung von Schwenkprofilen konfiguriert sind.

Fix-Management-Datensätze schlagen möglicherweise fehl, weil sich der Status während der Zeitlimitintervalle nicht geändert hat

Wenn ein aktiver Fix-Management-Datensatz (auch bekannt als Installationsdatensatz) auf einem Host vorhanden ist, können Sie erst dann einen weiteren Fix-Management-Datensatz erstellen, wenn der erste abgeschlossen oder fehlgeschlagen ist. Wenn Fix-Management-Datensätze über einen langen Zeitraum im selben Status bleiben, aktualisiert ein Zeitlimitmonitor ihren Status in "Fehlgeschlagen".

Der Zeitlimitmonitor wird einmal pro Stunde in jedem Pod ausgeführt. Die voreingestellten Zeitlimitintervalle lauten wie folgt.

Wenn Sie einen Fix-Management-Datensatz haben, der lange im selben Status bleibt, erstellen Sie einen neuen, nachdem das Zeitlimitintervall abgelaufen ist.

Die Unterstützung für die Registrierung von Bereitstellungsmanagern erfordert WebSphere Application Server 9.0.5.14 oder 8.5.5.23

Wenn Sie einen WebSphere Application Server Bereitstellungsmanager registrieren, muss es sich um die Version 9.0.5.14 oder 8.5.5.23 handeln. Diese Anforderung stellt sicher, dass die Nutzungsüberwachungsfunktion den Servertyp ordnungsgemäß an WebSphere Automationmeldet.

Um die Registrierung für einen Deployment Manager zu aktivieren, den Sie nicht auf WebSphere Application Server 9.0.5.14 oder 8.5.5.23 aktualisieren können, wenden Sie sich bitte an den IBM -Support.

Keine Option iFix zum Beheben von Sicherheitslücken in einer Java SDK-Laufzeit

Im Dialog Fix vorbereiten werden keine vorläufigen Fixes (iFixes) als Optionen zum Beheben von Schwachstellen in einer Java SDK-Laufzeit angezeigt. Sie müssen Fixpack als Fixtyp auf der Seite Globale Optionen auswählen und anschließend auf der Seite Fixes auswählen ein Fixpack für die Installation auswählen.

Sicherheitsbulletins Betroffene Produkte Größenbeschränkungen

Sicherheitsbulletins mit mehr als 8 betroffenen Produkten werden bis zur Veröffentlichung 1.9.0 von WSA nicht unterstützt. Sicherheitsbulletins mit bis zu 32 betroffenen Produkten werden ab 1.10.0 der WSA-Version unterstützt.

Die Installation schlägt in der Airgap-Umgebung fehl, wenn die Fallversion 1.9.0 oder 1.10.0 verwendet wird

WebSphere Automation Die Installation schlägt in der Airgap-Umgebung fehl, wenn die Fallversion 1.9.0 oder 1.10.0 verwendet wird.

Um dieses Problem zu beheben, führen Sie den folgenden Befehl aus, um den Operator zu installieren.

Beispiel für „ v1.9.0 “

oc ibm-pak launch \
   $CASE_NAME \
   --version $CASE_VERSION \
   --inventory $CASE_INVENTORY_SETUP \
   --action install-operator \
   --namespace $WSA_OPERATOR_NAMESPACE \
   --args "--channelName v1.9"