Initializing the Omnissa Access Control Plane Cluster

Follow the procedures below to initialize the Omnissa Access Control Plane cluster from the Bootstrap node. All commands must be run from Bootstrap node.

Initialize the Control Plane Cluster

Procedure:

• Follow the inline instructions below to initialize the Control Plane cluster.

  Note: Run the following command, substituting <size_of_your_deployment> with extra small, small, medium, or large to match the OVA size you deployed.

  Omnissa Access 26.10 introduced the concept of deployment type to the installation process. Deployment type can be defined as: development, UAT, and production. For a deployment type production, NFS storage is a requirement. For all other deployment types, NFS is recommended, but not required.

  This procedure assumes an installation location of: /opt/wss/<cluster_name>. The installation path may vary, depending the original version of the Omnissa Access initial deployment.

  cd /opt/wss/<cluster_name>
  

  Deployment type can be explicitly specified via the -t parameter.

  wso access init -n cp-cluster -s <size_of_your_deployment> -t <development/UAT/production>
  

  Deployment type does not have to be explicitly defined. If no deployment type is specified, then the installation process will assume a deployment type of production.

  wso access init -n cp-cluster -s <size_of_your_deployment>
  

  When you run this command, the output presents similarly to the following:

  cd /opt/wss/<cluster_name>
  wso access init -n cp-cluster -s small
  
  # Output
  <timestamp> Control Plane name: cp-cluster
  <timestamp> Created a sample profile.yml file
  <timestamp> Sample Control Plane inventory file created
  <timestamp> Created a sample telemetry config file: /opt/wss/<cluster_name>/telegraf_plugin/prometheus_remote_write.conf.example
  <timestamp> Successfully initialized
  

Results:

This command creates the following files:

• Cluster inventory file: /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini
• Deployment configuration file: /opt/wss/<cluster_name>/profile.yml

Configure the Cluster Inventory

The cp-cluster.ini file defines the following items:

• Infrastructure/Platform Nodes
• Omnissa Access Nodes

Generate an SSH Private Key File:

If you plan to use ansible_ssh_private_key_file to connect to cluster nodes (instead of ansible_password), generate the key file below before you populate the cp-cluster.ini file.

# On bootstrap node follow below steps
# change to configuser
su configuser

# Generate Public and private keys
ssh-keygen -t <cipher>

# Copy public Key to all other machines (Access+Infra+platform)
ssh-copy-id configuser@10.0.0.X 
# Repeat this for all cluster VMs from bootstrap VM

# Test login work with other machines without password
ssh configuser@10.0.0.X
# You should be able to login to 10.0.0.X from bootstrap without credentials

# Exit from 10.0.0.X by using exit command, so that you are in bootstrap machine. 
exit 
# Exit as configuser; run again to return to root

# Create a directory in bootstrap machine
mkdir -p /opt/wss/<cluster_name>/cp-cluster/private-key

# Copy the private key to PATH
cp /home/configuser/.ssh/id_<cipher> /opt/wss/<cluster_name>/cp-cluster/private-key

# Change the permission of file
chmod 400 /opt/wss/<cluster_name>/cp-cluster/private-key/id_<cipher>

# Change directory
cd /root/<cluster_name>/cp-cluster

# Create directory cp-cluster
mkdir -p cp-cluster

# Statically link private-key
ln -sfn ../private-key cp-cluster/private-key

Procedure to Auto-populate the cp-cluster.ini File:

Execute the following command:

update-cluster-ini INI_FILE=/opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini

# Output

[root@bootstrap configuser]# update-cluster-ini INI_FILE=/opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini
Enter User (this is the user created at OVA deployment): configuser
Use (1) password or (2) ssh_private_key_file?
Enter 1 or 2: 1
Enter password:
Deployment size: (1) extra small  (2) small  (3) medium  (4) large
Enter 1, 2, 3 or 4: 2
Enter Omnissa Access Node IPs (2 IPs required, comma or space separated): 10.0.0.x 10.0.0.x
Enter infra and platform node IPs (3 IPs required, comma or space separated): 10.0.0.x 10.0.0.x 10.0.0.x 
Moved existing /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini to /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini.bkp.20260714_052152
Written /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini (small): access=2, infra=3, asset=2.

Note: When prompted for the password, enter the same password used for the configuser account at OVA deployment. This password must be identical across all Bootstrap, Omnissa Access, and Infrastructure/Platform nodes in the cluster.

Manual Procedure to Update cp-cluster.ini File:

1. Open the cp-cluster.ini file. For example:

   vi /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini
   

2. Follow the inline instructions below to update the file.

   Note: ansible_user must always be set to configuser.

   Then choose one authentication method:

   • ansible_password — confirm the field is set to the configuser password.
   • ansible_ssh_private_key_file — the SSH private key generated for configuser (see Generate an SSH Private Key File above).

   Use one or the other, not both.

   [linux:children]
   asset_server_linux
   consul_server_linux
   general_compute_linux
   kafka_controller_linux
   kafka_server_linux
   nomad_server_linux
   opensearch_leader_linux
   opensearch_data_linux
   postgres_linux
   vault_server_linux
   general_compute_nginx_http
   general_compute_access_linux
   
   # This template includes sample IPs. Please update these to match your specific environment settings.
   
   # Provide IPs of asset server nodes
   [asset_server_linux]
   10.0.0.1
   10.0.0.2
   
   # Provide IPs of all Infrastructure/Platform nodes
   [consul_server_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs of all Infrastructure/Platform nodes
   [vault_server_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs of all Infrastructure/Platform nodes
   [nomad_server_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs of kafka controller nodes
   [kafka_controller_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs of kafka server nodes
   [kafka_server_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs of postgres server nodes
   [postgres_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs of Opensearch leader nodes
   [opensearch_leader_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs of Opensearch data nodes
   [opensearch_data_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs of General compute nodes
   [general_compute_linux]
   10.0.0.1
   10.0.0.2
   10.0.0.3
   
   # Provide IPs of access compute nodes
   [general_compute_access_linux]
   10.0.0.4
   10.0.0.5
   
   # Provide IPs of Nginx HTTP server nodes
   [general_compute_nginx_http]
   10.0.0.4
   10.0.0.5
   
   [linux:vars]
   # Uncomment ansible_user, ansible_password or ansible_ssh_private_key_file below to provide common credentials to connect to each of the specified nodes
   # Only one of password or ssh private key can be provided
   #ansible_user=
   #ansible_password=
   #ansible_ssh_private_key_file=
   

Update profile.yml File

This procedure ensures that only core infrastructure services are deployed initially.

The profile.yml file (/opt/wss/<cluster_name>/profile.yml) contains deployment-level configuration settings for the cluster environment. It is primarily used to configure:

• Time synchronization (NTP)

• Shared storage (NFS)

• Centralized logging integration

  The logging section allows cluster services to forward logs to centralized logging platforms such as:

  • Loki
  • OpenSearch
  • Syslog

  Example structure:

  # logging:
  # loki_server:
  #    url:
  #    username:
  #    password:
  # opensearch:
  #    url: https://10.0.0.x:<port>
  #    username: host-logging-writer
  #    password: *******
  #    index_prefix: access_logs
  # syslog_servers:
  #    host:
  #    protocol: udp
  #    port: 514
  #    syslog_cert_passphrase:   # only if your syslog client key in the logging directory is passphrase-protected  
  

Important Notes

• Logging configuration changes after deployment might require redeployment or upgrade to take effect.
• Uncomment and configure only the required sections.
• Ensure all external services (NTP, NFS, logging servers) are reachable from cluster nodes.
• This is not a mandatory procedure, but if your organization has an NTP server, you can enable and update the NTP server configuration with the server address

Procedure:

1. Open the profile.yml file. For example:

   vi /opt/wss/<cluster_name>/profile.yml
   

2. Uncomment the settings used to configure NFS-based shared storage (if desired) and the NTP server (recommended) for the cluster, as such:

   # Uncomment and provide NTP server to configure for time synchronization on the cluster nodes
   # ntp_server:
   
   # Uncomment and provide NFS server to configure Network File Share on the cluster nodes
   # nfs_host: 10.0.0.x
   # nfs_path:
   # nfs_version: 4
   

3. Review the rest of the profile.yml file and update other necessary sections, such as logging and metrics.

4. Save the profile.yml file.

5. Run the following command to validate the profile.yml file.

   wso cp precheck
   
   # Output
   Cluster Size is (small)...
   The following warnings were found in the cluster configuration:
   telemetry configuration is not set; configuring it post-deployment requires redeployment
   Note: fixing warnings are *recommended* for Development cluster but are *required* for Production cluster.
   
   The following errors were found in the cluster configuration:
   nfs backup server info is not set; configuring it post-deployment requires redeployment
   ntp server is not set
   
   Please fix the above errors and validate the cluster configuration again.
   

Validate the Cluster Inventory File

• After updating the inventory file (.ini), validate it. For example:

  wso access validate
  
  # OUTPUT
  <timestamp> Inventory file validated successfully.
  

  Note: wso access validate might report success even if wso cp precheck reported configuration errors earlier. This is expected behavior — proceed with wso access validate regardless of any precheck warnings.