This topic describes the recommended procedure for updating an existing Control Plane-based Omnissa Access deployment. It covers updating operating system packages, the Control Plane asset bundle, Access services, and the bootstrap VM.
Important: These update instructions are not applicable for upgrading versions 2412 or earlier.
Prerequisites
- Run all commands from the bootstrap VM unless otherwise specified.
- The existing deployment must be healthy. Run
wso healthcheckandwso access check-service-readinessto confirm system health before you begin. - The offline asset bundle for the target release is downloaded and available in the bootstrap VM.
- The OS security RPM is downloaded and available in the bootstrap VM, if this update includes OS package updates.
Update Workflow
An update consists of the following phases:
- Update Phase 1 - Download and configure the local repository for operating system updates (only when operating system package updates are required).
- Update Phase 2 - Download and configure the new Control Plane asset bundle.
- Update Phase 3 - Update the Control Plane, optionally including OS package updates.
- Update Phase 4 - Update Access services and validate services status.
- Update Phase 5 - If Update Phase 1 was applicable, update the bootstrap VM operating system.
Regardless of which phase you start from, complete the Prep section below first.
Prep - Export Shell Variables
Set the following variables in your shell before you begin. Later phases depend on them, including phases you might start from directly if you skip Update Phase 1.
export WORKDIR="/opt/wss/<cluster_name>"
export BOOTSTRAP_IP="<bootstrap-node-ip>"
export TARGETS="general_compute_linux:general_compute_access_linux"
export ASSET_DIR="${WORKDIR}/assets-<version>"
Update Phase 1 - Configure the Local Repository for OS Updates
Note: If this update does not include operating system package updates, skip to Update Phase 2 - Configure the New Asset Bundle.
Procedure:
-
Untar the OS security RPM file you downloaded.
tar -zxvf <filename> # Where <filename> is the name of the OS security RPM file. -
Run the DNF repository update script on the bootstrap VM:
sh /usr/local/sbin/update-dnf-repo.sh /opt/wss/<filename> -
Enable the local repository on the bootstrap VM and stage its CA certificate for distribution to the cluster nodes:
sed -i 's/enabled=0/enabled=1/' /etc/yum.repos.d/localrepo.repo mkdir -p ${WORKDIR}/access/localrepo_ca_path cp -f /etc/nginx/localrepo-certs/root-ca.crt \ ${WORKDIR}/access/localrepo_ca_path/root-ca.crt -
Push the local repository configuration to the cluster nodes:
-
Create the certificate directory on the cluster nodes:
wso control-plane ansible -- -b -m file \ -a "path=/etc/nginx/localrepo-certs state=directory owner=root group=root mode=0755" \ "${TARGETS}" -
Copy the root CA certificate to the cluster nodes:
wso control-plane ansible -- -b -m copy \ -a "src=/workdir/access/localrepo_ca_path/root-ca.crt dest=/etc/nginx/localrepo-certs/root-ca.crt owner=root group=root mode=0644 force=yes" \ "${TARGETS}" -
Point the cluster nodes at the bootstrap HTTPS repository:
wso control-plane ansible -- -b -m ini_file \ -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=baseurl value=https://${BOOTSTRAP_IP}/" \ "${TARGETS}" wso control-plane ansible -- -b -m ini_file \ -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=sslverify value=1" \ "${TARGETS}" wso control-plane ansible -- -b -m ini_file \ -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=sslcacert value=/etc/nginx/localrepo-certs/root-ca.crt" \ "${TARGETS}" wso control-plane ansible -- -b -m ini_file \ -a "path=/etc/yum.repos.d/localrepo.repo section=localrepo option=enabled value=1" \ "${TARGETS}" -
Rebuild the DNF cache on the cluster nodes only from the local repository. This step must be repeated if you are applying multiple updates on top of the released version.
wso control-plane ansible -- -b -m shell \ -a "dnf clean all && rm -rf /var/cache/dnf/* && dnf --refresh makecache --disablerepo='*' --enablerepo=localrepo && dnf --refresh --disablerepo='*' --enablerepo=localrepo list available" \ "${TARGETS}"
-
Update Phase 2 - Configure the New Asset Bundle
Procedure:
-
Create a directory for the new asset bundle and download it:
mkdir -p ${ASSET_DIR} cd ${ASSET_DIR} # Copy the target release asset bundle to this location ${ASSET_DIR}Important: Download the asset bundle that corresponds to your target release. Do not reuse a bundle from an older release.
-
Extract the bundle and add the CLI to your path:
# Ensure that you are in ${ASSET_DIR} before you unzip the asset bundle unzip asset-bundle.zip cp cli-distribution/linux/wso /usr/bin/ cp: overwrite '/usr/bin/wso'? y # It will prompt for overwrite wso eula Do you agree to these terms ? [y/n]: y -
Configure the CLI to use the new bundle:
cd ${WORKDIR} wso configure ${ASSET_DIR}
Update Phase 3 - Update the Control Plane
Procedure:
-
Deploy the Control Plane with the new asset bundle. Include
-uif this update also updates OS packages on the cluster nodes:# To update without OS packages update nohup wso cp deploy & # To update with OS packages update nohup wso cp deploy -u &This step will take some time to complete.
-
Verify the deployment:
wso version wso healthcheck -
If you deployed with
-u, unseal the cluster:Note: You can skip this step if you have deployed without
-uwso cp unsealThis step will take some time to complete.
Update Phase 4 - Update Access Services
Procedure:
-
Reconcile the Access configuration for the update:
cd ${WORKDIR} wso access update-config set -
If a
servicesdirectory exists in the working directory from a prior patch or update, use the command below so the deployment uses the images from the new bundle instead:mv ${WORKDIR}/services to ${WORKDIR}/services.bk -
Deploy all Access services:
nohup wso services deploy --type full & -
Check the health of the services:
wso access check-service-readiness -
After all services report healthy, exit update mode:
wso access update-config reset -
Clean up assets from the previous release:
wso cp reset-assets
Update Phase 5 - Update the Bootstrap VM Operating System
Perform this phase only after the cluster update has completed successfully. You can perform your cluster operations once you complete Update Phase 4.
For this phase, choose either to perform in-place update or to replace the VM.
In-Place Update
-
Update packages and reboot the bootstrap VM:
dnf update -y reboot -
After the bootstrap VM comes back online, validate the cluster:
wso healthcheck wso access check-service-readiness
Replace the VM
Use this option when you want to deploy a new bootstrap VM from the latest Omnissa OVA instead of patching the existing bootstrap VM in place. This approach is recommended for major OS updates.
Step 1 - Create a Migration Package from the Existing Bootstrap VM
cd /opt/wss/<cluster_name>
tar czpvf /opt/wss/<cluster_name>-migration-$(date +%Y%m%d).tar.gz \
profile.yml \
logging \
telegraf_plugin \
ansible_extra_vars.yml \
access \
cp-cluster \
additional_env_vars.env \
deploy_services.log \
deployment-config.yml
Step 2 - Copy the Migration Package to the New Bootstrap VM
scp /opt/wss/<cluster_name>-migration-*.tar.gz configuser@<new-bootstrap-machine>:/home/configuser/
Step 3 - Restore the Configuration on the New Bootstrap VM
mkdir -p /opt/wss/<cluster_name>
cd /opt/wss/<cluster_name>
tar xzpvf /home/configuser/cp-cluster-migration-*.tar.gz
The new bootstrap VM now contains the same deployment configuration as the previous bootstrap VM.
Step 4 - Configure the Asset Bundle
Copy the asset bundle used with the existing bootstrap VM to the new bootstrap VM and then execute the steps that follow.
mkdir -p assets
cd assets
# COPY asset bundle at this path.
unzip asset-bundle.zip
cp cli-distribution/linux/wso /usr/bin/
wso eula
wso configure /opt/wss/<cluster_name>/assets/
cd ..
Step 5 - Validate the New Bootstrap VM
wso version
wso healthcheck
wso access check-service-readiness
Verify that the CLI version, Control Plane image version, CPS image version, cluster health, and Access service readiness are all correct. All Access services should report a status of READY.
Was this page helpful?