Troubleshooting setup issues

ERROR: The /was/ssh directory with the Ansible connection
        parameters is empty. Make sure the wsa-ansible secret exists.

The wsa-ansible or wsa-ansible-win secret is missing with SSH or WinRM connection parameters. See Setting up secure remote access.

Failed to connect to the host via ssh: ssh: Could not
        resolve hostname <hostname>

Some servers might be configured with hostnames that cannot be resolved by DNS. In such cases, it might be necessary to configure WebSphere Automation with a custom host mapping. Use the .runbookManager.runbookRunner.hostAliases parameter in the WebSphereAutomation custom resource to provide more host or IP mappings. For example,

apiVersion: automation.websphere.ibm.com/v1
kind: WebSphereAutomation
metadata:
  name: wsa
spec:
  runbookManager:
    runbookRunner:
      hostAliases:
      - hostnames:
        - myvm
        ip: 9.46.84.208

Failed to connect to the host via ssh: Host key verification
        failed.

WebSphere Automation verifies host keys but the host key of one the servers changed. If the host key change was intentional, update the wsa-ansible-known-hosts configuration with the updated key. See Setting up WebSphere Automation for SSH to Linux or UNIX servers for details.

The operator reports that FixManagerReady and InstallationManagerReady are False when the wsa-secure-fixcentral-creds parameter is not configured. To enable the fix installation feature, you must configure WebSphere Automation with credentials to access IBM Fix Central. Without these credentials, WebSphere Automation cannot acquire the list of fixes for vulnerabilities in your managed servers.

For more information, see Setting up credentials for Fix Central.

If you are registering a WebSphere Application Server deployment manager, it must be version 9.0.5.14 or later. This requirement ensures that the usage metering feature properly reports the server type to WebSphere Automation. Support for version 8.5.5 is planned for a future release of WebSphere Application Server.

To enable registration for a deployment manager that you cannot upgrade to WebSphere Application Server 9.0.5.14, or for a WebSphere Application Server 8.5.5 deployment manager, contact IBM Support.

If you are attempting to register a server that is WebSphere Application Server 9.0.5.14 or later, or an earlier version that has been patched to support deployment manager registration, ensure that your version of WebSphere Automation is version 1.4.5 or later. Versions of WebSphere Application Server that support registration of deployment managers transmit the ServerType parameter during registration, and this parameter is not supported by earlier versions of WebSphere Automation.

Adding the proxy configuration as outlined in Configuring to use a proxy server does not take effect. The JVM_ARGS environment variable that is added twice in the CVE Monitor cron job is a symptom of this problem. You should see two entries for JVM_ARGS in the output of the following commands:

WSA_INSTANCE_NAMESPACE=websphere-automation
WSA_INSTANCE_NAME=$(oc get websphereautomation -o name -n $WSA_INSTANCE_NAMESPACE | cut -d/ -f2)
oc describe cronjob $WSA_INSTANCE_NAME-secure-cve-monitor -n $WSA_INSTANCE_NAMESPACE | grep JVM_ARGS

WSA_INSTANCE_NAMESPACE is the namespace of the instance where WebSphere Automation is installed. The default value is websphere-automation. If a different value was chosen at installation, change the value of WSA_INSTANCE_NAMESPACE accordingly. The following output is displayed for the commands:

JVM_ARGS: -Dhttps.proxyHost=http://10.x.x.x -Dhttps.proxyPort=80
JVM_ARGS: --add-opens=java.base/java.math=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED

To work around this issue, set the consolidated value in the configuration directly.

kind: WebSphereSecure
spec:
  cveMonitor:
    env:
      - name: JVM_ARGS
        value: -Dhttps.proxyHost=http://10.x.x.x -Dhttps.proxyPort=80 --add-opens=java.base/java.math=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED