Known issues, limitations, and workarounds

In phase 13 of Core recertification, not all certificates and secret keys are removed.

Workaround:Old certificates and secret keys should be removed.

Self-signed agent certificates are issued with 8 years of validity instead of 10 years of validity.

Workaround:Manually update the validity period in the database by running the following command on the SA Core:

/opt/opsware/bin/python -m opsware_common.config_editors update spin --name "spin.cogbot.crypto_validity_period" --value 3650 .

CA certificates in the components folder are not removed by upgrade process on satellites.

Workaround: Remove the following files from the satellite servers once the upgrade is completed:

• /var/opt/opsware/crypto/wordbot/admin-ca.crt
• /var/opt/opsware/crypto/wordbot/agent-ca.crt
• /var/opt/opsware/crypto/wordbot/opsware-ca.crt
• /var/opt/opsware/crypto/wordcache/admin-ca.crt
• /var/opt/opsware/crypto/wordcache/agent-ca.crt
• /var/opt/opsware/crypto/wordcache/opsware-ca.crt

Resumed core installation updates security.conf to default values

Workaround: Add the fips.mode, crypto.hash_algorithm and the crypto.key_length parameters in the cdf.xml file used for the resumed install. You can find the correct values for these parameters in the /etc/opt/opsware/crypto/security.conf file.

Package install does not work by default in Ubuntu 16.04.

Workaround: Install python and python-apt packages on the target managed server to enable the install package functionality.

System Diagnostics jobs created prior to the SA10.60 upgrade fail with the following error message:

"Invalid component buildmgr specified Valid components are :['truth', 'spin', 'word', 'way', 'vault', 'twist']"

This is expected behavior, since the Build Manager component is no longer included in SA 10.60 and later. SA required this component only for executing OS Sequences, which have been completely replaced by OS Build Plans.

Upgrading a Mesh to SA 10.60 after a CORD patch rollback fails if the crypto.hash_algorithm, fips.mode or crypto.key_length parameters do not have the default values.

Workaround: Add the fips.mode, crypto.hash_algorithm and the crypto.key_length parameters in the cdf.xml file used for the upgrade. You can find the correct values for these parameters in the /etc/opt/opsware/crypto/security.conf file.

When adding slices to a core, the CSRs for the new slices are generated with default values for the crypto.key_length, crypto.hash_algorithm and fips.mode parameters

Workaround: Add the fips.mode, crypto.hash_algorithm and the crypto.key_length parameters in the cdf.xml file used when adding the new slices. You can find the correct values for these parameters in the /etc/opt/opsware/crypto/security.conf file.

By default, when working in third-party certificate mode, you cannot use the BRDC HPSA agent sanitizer APX. This limitation is due to the recent changes introduced in the SA Agent Install flow which accommodate the new third-party certification mode.

Workaround: When working in third-party certificate mode, set the spin.agent.bootstrap_enabled parameter to 1. This allows SA Agents to register with the SA Core using the Bootstrap certificate. You can then replace this SA self-signed certificate with a third-party one. For more information see Self-signed temporary SA Agent certificates section in the SA 10.60 Administration guide.

Secondary Core installation fails when trying to connect to a primary Core that uses Oracle Database 11g.

This error occurs if the secondary Core you are installing is using SA 10.50 and later. These versions install Oracle Database 12c for all the SA Cores.

Ensure your secondary Core is using the same database version as the one on the primary Core.

You cannot upgrade to SA 10.60 if the SA Core’s existing certificate is MD5 base.

Workaround: Recertify the SA Core to use a different signature algorithm.

Some failed patch installations may show up as successful although they have been rolled back during server reboot.

Workaround: Always check the Patch Compliance page of the Job Status window to make sure you are getting the correct result for your remediation job.

When upgrading a Core, SA may show UNITS and REALM_UNITS tables conflicts.

Workaround: Resolve conflicts manually or use the Force Resolver script then continue with the upgrade. To minimize the number of model repository conflicts, run all operations on units through the master spin.

Patch Management

Duplicated patches exist between HPLN Patches and WSUSSCN2.CAB Patches.

Workaround: A hotfix is available on the HPE support site.

The uninstallation of SP1 on Windows 2008 R2 fails with timeout.

Workaround: No workaround; the issue corrects itself with the next scan.

The W2k12 software policy remediation fails with the error, "AGENT_ERROR_PATCH_DATABASE_CERTIFICATE_ERROR".

Workaround: Import and run the latest Microsoft patch CAB file.

The second recommended binaries for KB979309 and KB2416400 are not shown as recommended binaries in SA, but are available in scanpatchoutput.

Core Recert on FIPS enabled core will cause buildmgr to fail starting after phase 9.

When importing RedHat 6 rpms using redhat_import, any "++" characters available in the package title are converted to spaces.

This leads to the following error when trying to apply patches: "An error occurred while installing or removing this package. The package may not be applicable to the selected server. Parameters: results: {0} package: {1} command: {2} Action: Ensure that the package is correctly defined and applicable to the selected server. If the problem persists, please contact technical support".

The tokens used by recurring application configuration compliance jobs have a limited lifetime of one year. This causes the recurring jobs to stop working without a warning.