Manage Omnissa Access Control Plane Cluster Nodes

This topic describes how to replace an existing Control Plane deployment by adding Omnissa Infrastructure/Platform nodes and Access nodes, and explains what happens when a node becomes unhealthy and is removed from the cluster.

Add an Omnissa Access Node to the Cluster

You can replace an existing Control Plane node by adding an Omnissa Access Linux node to the cluster. New nodes are onboarded using the wso cp deploy command from the bootstrap node.

Prerequisites

• The new node's IP address has been added to cp-cluster.ini under the appropriate host group before you run the deploy command.
• The new node is reachable over SSH from the bootstrap node.

Procedure:

1. Open the /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini file and add the new node IP address under the appropriate host group. For example:

   Option 1 - Omnissa Access Node: If you are adding a new Omnissa Access node, add it under these sections:

   [general_compute_access_linux]
   10.0.0.x
   10.0.0.x  # New node
   [vault_server_linux]
   10.0.0.x  # New node
   [consul_server_linux]
   10.0.0.x  # New node
   [nomad_server_linux]
   10.0.0.x  # New node
   [general_compute_nginx_http]
   10.0.0.x  # New node
   

   Option 2 - Infrastructure/Platform Node: If you are adding a new node for Infrastructure/Platform Node, add it under all sections except for the following sections:

   [general_compute_access_linux]
   [general_compute_nginx_http]
   [asset_server_linux]
   
   # If the new node is a candidate for asset-server-linux that will replace existing asset-server, you must add a node IP in asset_server_linux, too.
   

   Important: Do not add the bootstrap node IP address to the inventory. Validation fails if the bootstrap IP is detected.

2. From the bootstrap node, run wso cp deploy to onboard the node.

   • To onboard one or more specific nodes, use the -t (--target-hosts) flag:

     # navigate to your cluster working directory
     cd /opt/wss/<cluster_name>
     wso cp deploy -t "10.0.0.x"
     

     For multiple nodes:

     cd /opt/wss/<cluster_name>
     wso cp deploy -t "10.0.0.x,10.0.0.x"
     

3. Run the following command to check if the cluster is healthy:

   wso healthcheck
   

4. Move workloads (services) to the new node. By default, no workloads will be running on the newly added node. You should log in to the Nomad UI using the Nomad Token and perform the below steps

   1. Log in to the Nomad UI at https://10.0.0.x:4646/ui/jobs
   2. Click Clients.
   3. Click the Node ID that you want to move the workloads from.
   4. Click Drain to move the workloads to new VM

   Note: Upon completion of the drain operation, all the workloads will be moved to new VM. You cannot move selected services to the new node.

5. Remove the existing node from the cluster by executing the following command.

   # From the bootstrap VM
   source /opt/wss/<cluster_name>/cp-cluster/cp-cluster.env
   server_id = <node_ip> # IP of the node being removed
   
   # API to remove peer
   curl -sk \
   -H "X-Vault-Token: $VAULT_TOKEN" \
   -H "Content-Type: application/json" \
   -X POST \
   -d '{"server_id":"$server_id"}' \
   "$VAULT_ADDRESS/v1/sys/storage/raft/remove-peer"
   

6. Verify the health of the cluster and services.

   wso healthcheck
   wso access check-service-readiness
   

Troubleshooting

Remove an Omnissa Access Node from the Cluster

There is no dedicated CLI command to remove a node from the Control Plane cluster. When a node becomes unavailable or unhealthy, the cluster handles removal automatically:

• The node stops receiving new workload allocations after approximately two missed heartbeats.
• Existing workloads on the node are rescheduled to healthy nodes.
• No manual removal command is required.

1. Remove the old node IP from the cp-cluster.ini file from all relevant sections.
2. Power off the removed node.

Note: Cluster membership cleanup happens on a different timeline than failure detection:

• Consul automatically purges inactive nodes from its member list from anywhere between 24 to 72 hours.
• Nomad removes stale nodes during its next garbage-collection cycle.
• Because of this, a removed node might remain visible in the Nomad or Consul UI for some time after it stops receiving traffic, even though it is no longer used for scheduling.

Password Management for Control Plane Cluster Nodes

The default password expiry for the configuser and root accounts is 60 days. You must change the password on every Control Plane cluster node before it expires.

The root password and the configuser password do not need to match each other, but each must be identical across every node in the cluster. For example, the root password must be the same on every node, and the configuser password must be the same on every node.

Reset the configuser or root password

Single node, logged in as root or via sudo:

passwd configuser
passwd root

Across all nodes at once, from the Bootstrap node:

export TARGETS='general_compute_linux:general_compute_access_linux'
wso control-plane ansible -- -b -m shell -a "echo 'configuser:NEW_PASSWORD' | chpasswd" "${TARGETS}"
wso control-plane ansible -- -b -m shell -a "echo 'root:NEW_PASSWORD' | chpasswd" "${TARGETS}"

Replace NEW_PASSWORD with the actual password before running, and ${TARGETS} with the Ansible inventory group or host pattern for the nodes to update — don't leave the literal placeholder in a saved script or your shell history.

Important: After changing the configuser password, update the same password in cp-cluster.ini on the Bootstrap node, or wso CLI operations against the cluster will start failing authentication. Active configuser sessions do not need to be invalidated after a reset.

Change the password expiration period

The 60-day expiration is controlled by password-aging fields on each account.

Note: If running as configuser, use sudoin front of the commands.

Check the current setting with:

chage -l configuser
chage -l root

Change it per account (single node):

chage -M <days> configuser
chage -M <days> root

-M sets the maximum number of days a password stays valid; -1 disables expiration (not generally recommended for root or service accounts).

Recover a completely forgotten root password

This requires console (hypervisor) access to the affected VM — it cannot be done over SSH, and only recovers one node at a time.

1. Reboot the VM and interrupt at the GRUB menu.

2. Highlight the boot entry and press e to edit it.

3. Find the line starting linux (or linux16), go to the end of it, and append:

   rd.break enforcing=0
   

4. Press Ctrl+X (or F10) to boot with the modified parameters — this drops you into the Dracut emergency shell.

5. Remount the root filesystem read-write and chroot into it:

   mount -o remount,rw /sysroot
   chroot /sysroot
   

6. Set the new password:

   passwd root
   

7. Flag the filesystem for an SELinux relabel on next boot, since SELinux was in permissive mode for this session:

   touch /.autorelabel
   

8. Exit the chroot and reboot:

   exit
   reboot
   

   The first boot after this takes longer than usual because of the SELinux relabel.