SpanVA runs on the CentOS operating system. CentOS has announced the EOL (End of Life) June 30, 2024. You can read more from CentOS here.
June 21, 2024 Broadcom shipped SpanVA version 1.15.3.160.0-2024 runs on Oracle Linux. Older SpanVA's running CentOS are supported through the expected EOS (End of Service) date.
New features and bug fixes will only be available in this new SpanVA version 1.15.3.160.0-2024. Older SpanVA's will have to be migrated in order to receive new features or fixes. These older SpanVA's will continue to function as expected after June 30th, 2024 and do not require the upgrade for day to day operations.
June 21, 2024 Broadcom shipped SpanVA version 1.15.3.153.0-19rc is the last SpanVA to run the latest CentOS platform. This version upgrade is a required for the SpanVA migration path to 1.15.3.160.0-2024. *.153 has a better settings backup to facilitate the migration to *.160 Other fixes include enforcing strict SSH ciphers by default and an improved ADSync Password change experience.
How to Upgrade\Migrate:
Upgrade SpanVA 1.15.3.153.0-19rc (CentOS)
Existing SpanVA's: Auto-update or manually apply as configured from the SpanVA
Migrate to SpanVA 1.15.3.160.0-2024 (Oracle Linux)
See .160 migration procedure for more details.
New deployments are 1.15.3.160.0-2024 by default.
See What's New in Symantec SpanVA for more detail.
Q&A:
Q: Can I upgrade directly to 1.15.3.160.0-2024?
A: NO, 1.15.3.153.0-19rc is a required prerequisite. The enhanced back-up gathers SpanVA settings, tokens and mappings. The SpanVA does not store audit data.
Q: Will the SpanVA fail if I do not immediately upgrade\migrate to *.160 before June 30th, 2024?
A: The SpanVA will continue to function. Any new features or fixes would only be available after the migration to *.160. Having a good backup from the *.153 version will cut down on risk as the backup can be restored to the new *.160 deployment.
Q: Can I delete the SpanVA and provision a new one?
A: Data-sources cannot be moved to a different SpanVA. The data-sources would need to be recreated. If CloudSOC is tokenized the tokens would be lost and IP2user mappings would be lost if not restored.