Resolución de problemas de tiempo de ejecución

Editar en línea

Es posible que se encuentre con algún problema durante el funcionamiento normal de WebSphere Automation, como investigaciones de estado fallidas. Descubra cómo solucionar los problemas de tiempo de ejecución más comunes.

Los problemas siguientes podrían provocar que una investigación de estado fallase. Si una investigación falla, descargue el archivo de archivado de la investigación utilizando la interfaz de usuario de WebSphere Automation o la API REST. Abra el archivo y examine el archivo analysis.log para ver si hay errores.

El servidor habilitado para FIPS no se registra en WebSphere Automation después de instalar un fixpack JDK con unSecureRandom SHA2DRBG for provider not availablemensaje de error

La instalación de un paquete de corrección de tiempo de ejecución de Java SDK en un servidor WebSphere Application Server o WebSphere Application Server Liberty registrado que esté configurado para cumplir con los Estándares Federales de Procesamiento de Información (FIPS) podría fallar con el siguiente error.

Stack Dump = java.lang.RuntimeException: SecureRandom SHA2DRBG for provider <provider_name> not available

Para resolver este problema, configure el servidor registrado de acuerdo con las instrucciones de los siguientes artículos.

No hay contacto con el servidor o se ha perdido el contacto con el servidor registrado

WebSphere Automation utiliza la característica de calibración de uso de WebSphere Application Server y WebSphere Application Server Liberty para registrar servidores y mantener un contacto regular con ellos. Si WebSphere Automation no puede ponerse en contacto con un servidor, o si se pierde el contacto con un servidor registrado durante más de seis horas, WebSphere Automation muestra indicadores visuales en la interfaz de usuario para que conozca la situación. Si la pérdida de contacto no se debe a una razón conocida y aceptable, realice los pasos siguientes para diagnosticar y resolver el problema.

Asegúrese de que la calibración de uso se haya configurado correctamente en el servidor de destino.
Para obtener más información, consulte Configuración de la supervisión de seguridad.
Reinicie el servidor .
Si el servidor se ha eliminado de WebSphere Automation, o si la característica de calibración de uso se ha inhabilitado, habilite la característica y reinicie el servidor de destino. Esta acción conduce a que el servidor se vuelva a registrar con WebSphere Automation . Para obtener más información, consulte Cancelar el registro de servidores.
Compruebe la conectividad de red.
Si la característica de calibración de uso se ha configurado correctamente pero no se ha establecido el contacto, compruebe los registros en el servidor de destino para obtener indicaciones de los problemas de conectividad de red que pueden bloquear la comunicación entre el servidor y WebSphere Automation.

Investigación no creada para una alerta de Instana

Este problema puede deberse a que el host no tiene ningún servidor registrado. Si el gestor de investigación no encuentra ningún servidor registrado para el host, el mensaje de error siguiente se graba en el archivo de registro del gestor de investigación:

Investigation cannot be started because no assets are registered with the example.com host.

Error de falta de memoria para el trabajo del ejecutor de análisis de memoria

(In version 1.3 or later) java.lang.OutOfMemoryError: Java heap space
(In version 1.2) JVMDUMP039I Processing dump event "systhrow", detail "java/lang/OutOfMemoryError"

De forma predeterminada, la solicitud de memoria y el límite de memoria del trabajo de ejecutor de análisis de memoria se establecen en 4 GB. Estos valores son suficientes para que el trabajo del ejecutor analice la mayoría de los volcados de almacenamiento dinámico. Este mensaje de error implica que el analizador no tenía suficiente memoria para analizar el volcado de almacenamiento dinámico. Puede asignar más memoria al valor memoryAnalysisRunner en recursos personalizados de WebSphereHealth. Para obtener más información, consulte el recurso personalizado « WebSphereHealth ». Como alternativa, puede editar la instancia de WebSphereHealth con el siguiente mandato:

oc edit WebSphereHealth <instance-name> -n <namespace>

El nombre de instancia predeterminado es wsa-health. El espacio de nombres predeterminado es wasautomation.

Nota: La memoria toma como valor predeterminado 4Gi con un límite de 4Gi. Puede aumentar la memoria a un valor mayor, como por ejemplo 20Gi, como en el ejemplo siguiente. Establezca la solicitud de memoria y el límite de memoria en el mismo valor. La máquina virtual Java utiliza la cantidad de memoria especificada por el límite para calcular el tamaño máximo de almacenamiento dinámico. Kubernetes sólo garantiza que el proceso puede obtener la cantidad de memoria especificada por la solicitud.

spec:
  analysisManager:
    Image: …
    memoryAnalysisRunner:
      resources:
        limits:
          cpu: '1'
          memory: 20Gi
        requests:
          cpu: 500m
          memory: 20Gi

Nota: Cuando asigne más recursos a memoryAnalysisRunner, asegúrese de que los nodos trabajadores puedan manejar las solicitudes.

No se ha podido identificar el servidor en el host example.com

Failed to identify the server on host example.com

Hay varios problemas que pueden causar este error. Para resolver el problema, pruebe los pasos siguientes:

Asegúrese de que se cumplan todos los requisitos previos de los servidores gestionados. Para obtener más información, consulte Requisitos del servidor gestionado.
Pruebe la conexión entre WebSphere Automation y el servidor gestionado.
Resuelva los problemas de configuración.

El rol MyCustomRole incluye un permiso no válido: can_view_websphere_inventory

Si ha incluido el permiso can_view_websphere_inventory en un rol personalizado en la versión 1.1, este permiso se ha eliminado en la versión 1.2. Para corregir los roles personalizados, debe utilizar la API:

Obtenga la clave de API de la interfaz de usuario cpd.
Desde la consola cpd, haga clic en Usuario > Perfil y configuración, y luego haga clic en el botón Clave API.

Obtenga una señal portadora para utilizar para las llamadas de API:

curl -k -X POST -H 'Content-Type: application/json' -d '{"username":"<user_name>","api_key":"<api_key>"}' https://$(oc get route -n wasautomation -o jsonpath='{.items[?(@.spec.to.name=="ibm-nginx-svc")].spec.host}')/icp4d-api/v1/authorize

Obtenga una lista de los roles. Esta lista es necesaria para obtener el nombre de extensión y los metadatos JSON, que se utilizan en un paso posterior para modificar el rol personalizado roto:

curl -X GET -k -v -H "Authorization: Bearer <bearer_token>" --header "Content-Type: application/json" --header "Accept: application/json" https://$(oc get route -n wasautomation -o jsonpath='{.items[?(@.spec.to.name=="ibm-nginx-svc")].spec.host}')/api/v1/usermgmt/v1/roles

Ejemplo:

curl -X GET -k -v -H "Authorization: Bearer eyJhbGciOiJSUz..." --header "Content-Type: application/json" --header "Accept: application/json" -d '{"role_name":"mycustomrole","description":"","permissions":[]}' https://$(oc get route -n wasautomation -o jsonpath='{.items[?(@.spec.to.name=="ibm-nginx-svc")].spec.host}')/api/v1/usermgmt/v1/roles

Respuesta (truncada):

{"rows":[{"id":"f60b72c3-ae7e-4860-8f98-649e316af6d2","key":"f60b72c3-ae7e-4860-8f98-649e316af6d2","doc":{"_id":"f60b72c3-ae7e-4860-8f98-649e316af6d2","extension_id":"_ce_703424172539772929","extension_name":"f60b72c3-ae7e-4860-8f98-649e316af6d2","role_name":"mycustomrole","description":"","permissions":["can_view_websphere_inventory"]...],"messageCode":"success","message":"success"}

Para cada rol personalizado que contiene el permiso can_view_websphere_inventory, elimine dicho permiso y sustitúyalo por el permiso can_view_application_runtime_security.

curl -X PUT -k -v -H "Authorization: Bearer <bearer_token>" --header "Content-Type: application/json" --header "Accept: application/json" -d '{"role_name":"","description":"","permissions":['can_view_application_runtime_security']}' https://$(oc get route -n wasautomation -o jsonpath='{.items[?(@.spec.to.name=="ibm-nginx-svc")].spec.host}')/api/v1/usermgmt/v1/role/<extension_name>

Ejemplo:

curl -X PUT -k -v -H "Authorization: Bearer eyJhbGciOiJSUz..." --header "Content-Type: application/json" --header "Accept: application/json" -d '{"role_name":"mycustomrole","description":"","permissions":["can_view_application_runtime_security"]}' https://$(oc get route -n wasautomation -o jsonpath='{.items[?(@.spec.to.name=="ibm-nginx-svc")].spec.host}')/api/v1/usermgmt/v1/role/f60b72c3-ae7e-4860-8f98-649e316af6d2

Respuesta (truncada):

{"id":"f60b72c3-ae7e-4860-8f98-649e316af6d2","messageCode":"success","message":"success"}

La instalación del arreglo falla con unConnection error: read operation timed outmensaje de error

Si la instalación de un arreglo falla con este error en el archivo runbook.log , pulse Instalar arreglo en la interfaz de usuario más adelante para reiniciar la instalación del arreglo.

La instalación del arreglo falla en WebSphere Application Server Liberty para un usuario no root con Installation Manager en modalidad de grupo en Linux o UNIX

Este error se produce porque el archivo InstallationManager.dat al que accede WebSphere Automation no se encuentra en el directorio de inicio del usuario no root como se esperaba. Para solucionar este problema, cree un archivo InstallationManager.dat en el directorio de inicio del usuario no root que tenga un enlace simbólico a la ubicación real del archivo InstallationManager.dat . Consulte el ejemplo siguiente.

ln -s /<my_group_name>/InstallationManager_AppData/etc/.ibm/registry/InstallationManager.dat \
/home/<non-root-username>/etc/.ibm/registry/InstallationManager.dat

Errores en el estado de ejecución o la sincronización del agente de nodo después de instalar un fixpack

Después de utilizar WebSphere Automation para instalar un fixpack en un nodo en WebSphere Application Server Network Deployment, es posible que vea uno de los problemas siguientes:

Un estado de ejecución incorrecto para el nodo en la consola de administración
Una sincronización incorrecta para el nodo en la consola de administración

Un error similar al siguiente en el archivo SystemOut.log :

ADMD0026W: The version of the deployment manager (9.0.5.11) is earlier than that of this node (node1, 9.0.5.12).

Estos problemas se producen porque la versión del fixpack del nodo es superior a la versión del host del gestor de despliegue. Para resolver el problema, actualice manualmente el host del gestor de despliegue a una versión igual o superior a la versión del fixpack.

Installation of the fix cannot proceedmensaje de error

Si el mandatoInstallation of the fix cannot proceedaparece un mensaje de error, puede deberse a uno de los problemas siguientes:

Es posible que exista un problema de comunicación entre WebSphere Automation e IBM Fix Central.
Es posible que exista un problema de configuración que impida que WebSphere Automation se autentique con IBM Fix Central.
Es posible que exista un problema de privilegio de usuario que impide que WebSphere Automation instale el arreglo en el servidor gestionado.

Compruebe las configuraciones para asegurarse de que son correctas. Si las configuraciones son correctas y se sospecha que hay un problema de comunicación, intente iniciar el arreglo de nuevo después de aproximadamente una hora.

Problem with request to install fixmensaje de error

Si el mandatoProblem with request to install fixaparece el mensaje de error, se debe a que se ha iniciado más de una instalación de arreglo en un host determinado. Solo se puede instalar un arreglo en un host determinado a la vez. Espere hasta que se complete el proceso de instalación del arreglo actual antes de intentar instalar otro arreglo en ese host.

Instalación de un arreglo en un servidor de Windows

Si el proceso de instalación de un arreglo en un servidor de Windows se estanque durante un tiempo no razonable, reinicie el servidor de Windows y, a continuación, reinicie la instalación del arreglo.

El pod de instalación de correcciones se bloquea con ContainerStatusUnknown al instalar correcciones

Es posible que una instalación de arreglo se pare y muestreInstalling fixen la interfaz de usuario de WebSphere Automation y para que el pod install-fix permanezca en estado ContainerStatusUnknown . Mientras esté en esta condición, los posteriores intentos de instalación en el mismo host no continuarán y generarán el siguiente mensaje de error.

WIORM0806E: Se están instalando otros arreglos en el host 'myhost.com'. Vuelva a intentarlo más tarde.

Para comprobar el estado del pod, ejecute el mandato oc get pod . Busque el estado ContainerStatusUnknown .

oc get pod | grep install-fix
install-fix-f6054b58-f20d-4351-8c44-7c1efd93f2d5-9m89j    0/1    ContainerStatusUnknown   1    48m

Para solucionar este problema, debe suprimir la instalación estancada que nunca pasa del estado in-progress y, a continuación, suprimir el trabajo de instalación-arreglo relacionado.

Suprima la instalación estancada con los mandatos de interfaz de usuario o CLI de Swagger.

Para suprimir la instalación estancada con Swagger UI, busque su valor installationId y, a continuación, utilice el valor en una operación DELETE . Para obtener instrucciones generales sobre cómo utilizar Swagger UI, consulte la serie «Cómo hacerlo» n.º 10 de Automatización de WebSphere : Cómo ver las API REST de Automatización de WebSphere utilizando Swagger UI.
1. Busque la instalación en un host que todavía esté en estado in-progress con una operación GET en /installations que utilice los parámetros de consulta hostName y status .
2. Suprima las instalaciones con una operación DELETE que utilice el valor installationId .
```
DELETE /installations/{installationId}
```
Para eliminar la instalación paralizada con comandos CLI, primero obtenga los valores de token y URL y, a continuación, utilice las API REST de WebSphere Automation a través de CLI para eliminar la instalación.
1. Obtenga el valor de señal. Visualización de la API REST detalla cómo adquirir el valor de señal para un perfil de usuario autorizado.
  1. Obtenga la contraseña de la cuenta de administrador.
```
oc -n WSA_INSTANCE_NAMESPACE get secret ibm-iam-bindinfo-platform-auth-idp-credentials -o jsonpath='{.data.admin_password}' | base64 -d && echo
```
    WSA_INSTANCE_NAMESPACE es el espacio de nombres de la instancia donde está instalado WebSphere Automation ; si se eligió el valor por defecto en la instalación, el valor es websphere-automation.
  2. Sustituya <password> en el siguiente comando por el valor devuelto por el comando del paso anterior, y utilice el valor correcto para WSA_INSTANCE_NAMESPACE.
```
curl -k -X POST -H 'Content-Type: application/json' -d '{"username":"cpadmin","password":"<password>"}' https://$(oc get route -n WSA_INSTANCE_NAMESPACE -o jsonpath='{.items[?(@.spec.to.name=="ibm-nginx-svc")].spec.host}')/icp4d-api/v1/authorize | jq -r .token
```
2. Copie el resultado del mandato curl en una variable TOKEN.
3. Obtenga el valor de URL necesario para utilizarlo en los comandos de curl. Añada un prefijo de https:// y un sufijo de /websphereauto/secvul/apis/v1 alrededor del resultado del mandato siguiente.
```
oc get route -n WSA_INSTANCE_NAMESPACE -o jsonpath='{.items[?(@.spec.to.name=="ibm-nginx-svc")].spec.host}'
```
  Para establecer una variable URL en Linux, puede utilizar el siguiente comando.
```
URL=https://$(oc get route -n WSA_INSTANCE_NAMESPACE
 -o jsonpath='{.items[?(@.spec.to.name=="ibm-nginx-svc")].spec.host}')/websphereauto/secvul/apis/v1
```
4. Obtenga el installationId para la instalación atascada in-progress en un host específico. Puede utilizar el mandato siguiente después de sustituir HOSTNAME.
```
curl -k -X GET "${URL}/installations?hostName=HOSTNAME&status=in-progress" -H "accept: application/json" -H "Authorization: Bearer $TOKEN" | jq . | grep id
```
5. Suprima esa instalación. Sustituya INSTALLATIONID en el mandato por el valor installationId del paso anterior.
```
curl -k -X DELETE "${URL}/installations/INSTALLATIONID" -H "accept: application/json" -H "Authorization: Bearer $TOKEN"
```
Suprima el trabajo de instalación-arreglo.
1. Obtenga el nombre del trabajo con el mandato oc get job .
```
oc get job | grep install-fix
install-fix-306dfd00-cb07-456c-91bb-7d3be8e5c0d7   0/1      14h   14h
```
2. Suprima el trabajo install-fix relacionado con el mandato oc delete job job_name .
```
oc delete job install-fix-306dfd00-cb07-456c-91bb-7d3be8e5c0d7
```

La instalación de iFix en un servidor de destino con un sistema operativo AIX falla con un errorchmod: A flag or octal number is not correct

Este error está relacionado con el uso de Ansible en el sistema operativo AIX cuando el usuario de conexión y become_user no tienen privilegios. Para evitar que este problema se repita, realice los pasos siguientes:

Añada --from-literal=ansible_pipelining=true a su secreto.
Inhabilite requiretty en el archivo /etc/sudoers para todos los hosts gestionados.
Puede hacerlo comentando la línea Defaults requiretty , tal como se muestra en el ejemplo siguiente.
```
#Defaults requiretty
```

No se ha podido invocar un webhook después de que se haya detectado una pérdida de memoria

Las actualizaciones inesperadas del esquema de alertas de Instana pueden causar este problema. WebSphere Automation utiliza un esquema JSON para validar el JSON que se envía desde Instana. El esquema que utiliza WebSphere Automation se establece en la correlación de configuración wsa-schema-instana-alerts . Asegúrese de que la variable de entorno $WSA_INSTANCE_NAMESPACE esté establecida en el espacio de nombres de instancia de WebSphere Automation .

Recupere el esquema de alertas de Instana predeterminado del ConfigMap predeterminado como un archivo local denominado instana-alerts-custom.json.
```
oc get cm wsa-schema-instana-alerts -n $WSA_INSTANCE_NAMESPACE -o "jsonpath={.data['instanaAlerts\.json']}" > instana-alerts-custom.json
```
Realice los cambios necesarios en el archivo JSON instana-alerts-custom.json .

Cree el ConfigMappersonalizado.

oc create cm wsa-schema-instana-alerts-custom -n $WSA_INSTANCE_NAMESPACE --from-file=instanaAlerts.json=instana-alerts-custom.json

El trabajo de importación de boletín falla en una instalación aislada

En una instalación aislada, es posible que los pods de wsa-secure-bulletins-import no se completen. Por ejemplo, si ejecuta el mandato siguiente:

oc get pods | grep import

Es posible que vea la salida con errores:

wsa-secure-bulletins-import-1.6.0-8526l 0/1 Error 0 2d15h
wsa-secure-bulletins-import-1.6.0-b7jld 0/1 Error 0 2d15h
wsa-secure-bulletins-import-1.6.0-c4cxf 0/1 Error 0 2d15h
wsa-secure-bulletins-import-1.6.0-dsmdg 0/1 Error 0 2d15h
wsa-secure-bulletins-import-1.6.0-fgj7p 0/1 Error 0 2d21h
wsa-secure-bulletins-import-1.6.0-kw9qm 0/1 Error 0 2d15h
wsa-secure-bulletins-import-1.6.0-t5sgl 0/1 Error 0 2d15h

Si es así, suprima el trabajo de importación de boletines.

oc delete job wsa-secure-bulletins-import-1.6.0

Se crea un nuevo trabajo de importación de boletines.

Se ha superado el tiempo de espera al acceder a la página Operate > Application runtimes.

Cuando el WebSphereSecure UI no es capaz de contactar con la instancia Platform UI cuando utiliza los Red Hat OpenShift, se produce este problema. Cuando la aplicación no se puede comunicar, el navegador experimenta un tiempo de espera excedido, mostrando el error siguiente:

timeout of 20000ms exceeded

Para solucionar este problema, elimine la implementación de WebSphereSecure UI (<instance-name>-secure-ui) para reiniciar la aplicación.

Por ejemplo, con un WebSphere Automation nombre de instancia wsa, debe suprimir wsa-secure-ui.

Suprima el despliegue relacionado con el mandato oc delete deployment deployment_name .

oc delete deployment <instance-name>-secure-ui -n <namespace>

En un entorno habilitado para FIPS, las instalaciones de arreglos o la investigación de pérdida de memoria no progresan

Si utiliza un par de claves SSH que se ha generado en un sistema no FIPS en una instalación habilitada para FIPS de WebSphere Automation, es posible que la aplicación de arreglos o las investigaciones de pérdida de memoria no progresen. El registro de pod puede detenerse en las líneas siguientes:

[07/28/23 18:27:00:516 UTC] 1    com.ibm.ws.automation.core.runbook.runner.RunbookRunnerCLI INFO start Request received to execute runbook: install-fix against server: server1.example.com (correlationId: 65301e97-5754-4001-afbe-0c669d6774ff)
[07/28/23 18:27:00:607 UTC] 1    com.ibm.ws.automation.core.runbook.runner.AnsibleRunner INFO runRunbook Here is the standard output of the command:

[07/28/23 18:27:00:613 UTC] 1    com.ibm.ws.automation.core.runbook.runner.AnsibleRunner INFO runRunbook was:
[07/28/23 18:27:00:613 UTC] 1    com.ibm.ws.automation.core.runbook.runner.AnsibleRunner INFO runRunbook   hosts:
[07/28/23 18:27:00:613 UTC] 1    com.ibm.ws.automation.core.runbook.runner.AnsibleRunner INFO runRunbook     server1.example.com:
[07/28/23 18:27:00:613 UTC] 1    com.ibm.ws.automation.core.runbook.runner.AnsibleRunner INFO runRunbook       ansible_user: root
[07/28/23 18:27:00:625 UTC] 1    com.ibm.ws.automation.core.runbook.runner.AnsibleRunner INFO runRunbook Agent pid 41

Este problema se produce porque el mandato ssh-keygen en un sistema que no es FIPS utiliza el algoritmo de resumen MD5 para generar claves. En un sistema habilitado para FIPS, el algoritmo de resumen MD5 está inhabilitado. Los pares de claves SSH sin frase de contraseña no se ven afectados.

Cuando ejecute WebSphere Automation en un clúster habilitado para FIPS, elija una de las opciones siguientes para utilizar un par de claves SSH protegidas con frase de contraseña en un sistema habilitado para FIPS.

Genere un nuevo par de claves SSH protegidas con frase de contraseña en un sistema habilitado para FIPS.

Convierta la clave privada existente a un formato compatible con FIPS:

$ openssl pkcs8 -topk8 -v2 aes128 -in <INPUT FILENAME> -out <OUTPUT FILENAME>
Enter pass phrase for id_rsa:   <PASSPHRASE OF EXISTING KEY>
Enter Encryption Password:      <PASSPHRASE FOR NEW KEY>
Verifying - Enter Encryption Password:    <PASSPHRASE FOR NEW KEY>

Las notificaciones de correo electrónico no se envían, mensaje de error de Can't verify identity of server en el registro de pod de wsa-secure-vulnerability-notifier

A partir de WebSphere Automation 1.7 , se utiliza un servicio Javamail más seguro que en versiones anteriores, que impone la identidad del servidor al establecer la conexión TLS. Si el certificado no coincide con el nombre de host del servidor de correo, no se puede establecer una conexión segura y no se envían correos electrónicos.

Para inhabilitar la verificación de nombre de host al enviar correos electrónicos, puede establecer una propiedad mail.smtps.ssl.checkserveridentity en false en la página Notificaciones .

Inicie sesión en WebSphere Automation como usuario con privilegios Gestionar notificaciones .
Haga clic en el icono del menú > Operar > Tiempos de ejecución de aplicaciones y, a continuación, abra la página Notificaciones.
En la página Notificaciones , en Servidor de correo electrónico, pulse Configurar servidor.
Pulse el botón Añadir en Añadir campos adicionales.
Añada un parámetro mail.smtps.ssl.checkserveridentity y establezca su valor en false.
Pulse Guardar.

Los registros de runbook contienen errores de permiso de acceso a archivo

Los playbooks de WebSphere Automation requieren que el perfil de usuario definido para la variable de conexión ansible_user tenga acceso de lectura a los siguientes archivos tradicionales de WebSphere Application Server y a sus directorios padre.

app_server_root/properties/profileRegistry.xml
app_server_root/properties/version/installed.xml

Si el perfil definido para la variable de conexión ansible_user no puede leer los archivos, es posible que vea errores similares a los siguientes en los registros de runbook:

ValueError: File not found or no permissions to access app_server_root/properties/version/installed.xml

Permission denied: 'app_server_root/properties/profileRegistry.xml'

Para otorgar permisos de acceso de lectura a los archivos, utilice las herramientas del sistema operativo para cambiar los permisos de archivo. Por ejemplo:

chmod +r /opt/IBM/WebSphere/AppServer/properties/profileRegistry.xml
chmod +r /opt/IBM/WebSphere/AppServer/properties
chmod +r /opt/IBM/WebSphere/AppServer/properties/version/installed.xml
chmod +r /opt/IBM/WebSphere/AppServer/properties/version

Encontrará información adicional que puede resultarle útil en Conceder permiso de escritura para tareas relacionadas con el perfil en la WebSphere Application Server documentación. Consulte el paso 8 en particular y tenga en cuenta que el caso de uso en la documentación enlazada es diferente; no siga estas instrucciones explícitamente.

No hay opción iFix para corregir vulnerabilidades en un tiempo de ejecución de Java SDK

En el diálogo Preparar arreglo , no se muestra ningún arreglo temporal (iFixes) como opciones para arreglar vulnerabilidades en un tiempo de ejecución de Java SDK. Debe seleccionar Fixpack como Tipo de arreglo en la página Elegir opciones globales y, a continuación, elegir un fixpack para instalar en la página Elegir arreglos .