dux (Omnissa CLI) - Content Gateway commands

This document contains commands to deploy and manage Content Gateway (CG) containers using dux CLI.

Installation
Usage
Prerequisites
Steps to deploy Content Gateway container
Perform operations on deployed Content Gateway containers
Troubleshooting

Installation

Dux can be installed on Linux, Mac OS and Windows. For instructions on installing Dux, please refer to the README.html - https://packages.omnissa.com/ws1-tunnel/dux/3.1.0.886/README.html

Usage

Check version of Dux cli

Get the version of Dux cli deployed. For example:

$ dux version 
Omnissa CLI - dux
3.1.0.886

Get list of commands supported:

$ dux help
CLI to deploy and manage containers based on the manifest file

Usage:
  dux [command]

Available Commands:
  about       Get legal and privacy information about Dux
  cg          CLI to deploy and manage Content Gateway containers
  eic         CLI to deploy and manage EIC containers
  pacreader   CLI to deploy and manage PAC Reader container
  seg         CLI to deploy and manage SEG containers
  tunnel      CLI to deploy and manage Tunnel containers
  version     Get the version of dux

Flags:
  -h, --help   Print help information

Use "dux [command] --help" for more information about a command.

Get legal and privacy information about Dux

$ dux about

Copyright © 2024-2026 Omnissa. All rights reserved. This product is protected by copyright and intellectual property laws in the United States and other countries as well as by international treaties. Its use is subject to the legal terms in place between you and Omnissa.

  • Omnissa's general and offering-specific legal terms for its products and services are available at: https://www.omnissa.com/legal-center/

  • Omnissa's privacy notice for products and services is located at: https://www.omnissa.com/omnissa-products-services-privacy-notice/

  • Omnissa's open-source software notices can be found at: https://www.omnissa.com/open-source-notices/

  • Omnissa products and services are covered by one or more patents listed at: https://www.omnissa.com/omnissa-patent-information/

Omnissa, the Omnissa Logo, Workspace ONE, and Horizon are registered trademarks or trademarks of Omnissa in the United States and other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies. "Omnissa" refers to Omnissa, LLC, Omnissa International Unlimited Company, and/or their subsidiaries.

Prerequisites

In the host/VM from where dux is to be installed and run:
a. AlmaLinux, CentOS/RHEL, macOS or Windows

b. SSH (Secure Shell) should be installed and running on your local Mac/Linux/Windows machine. You can verify this by opening a terminal and typing ssh followed by pressing Enter. If SSH is installed, you will see a list of available options. If not, please install SSH using the appropriate package manager for your system.

c. SSH keys need to be set up for users to log in to the remote VMs (where CG container is to be deployed) securely without passwords. If you haven't set up SSH keys before, follow these steps:
i. Generate SSH keys using the command: For example: ssh-keygen -t rsa.
ii. Follow the prompts to create the SSH keys. By default in Linux and Mac OS, they will be saved in ~/.ssh/id_rsa (private key) and ~/.ssh/id_rsa.pub (public key) if RSA is chosen. In Windows, the default path for the keys will be in C:\Users<user_name>.ssh
iii. Copy the contents of the public key (id_rsa.pub) to the remote VM's ~/.ssh/authorized_keys file.
You can use the ssh-copy-id command for this purpose: ssh-copy-id username@remote_host.
Note that on Windows, PowerShell and Command Prompt do not include ssh-copy-id. Users must manually copy the public key using scp, sftp, or append/paste it manually to authorized_keys.
Please note that if using Git Bash or WSL on Windows, ssh-copy-id might be available.

d. If you wish to enable ssh_host_key_check in the cg_manifest.yml, ensure that the known_hosts file exists on your local machine.
This file is used to store information about host keys for SSH connections. If it doesn't exist, it will be created automatically when you connect to a remote host for the first time/when running dux commands.
If the known_hosts file does not exist, follow these steps to create it:
- SSH to the remote host using the command: ssh username@remote_host.
- You will be prompted to confirm the authenticity of the host. Type yes and press Enter to continue.
- After successful authentication, the host key will be added to the known_hosts file on your local machine.

e. Content Gateway docker container image bundle (tar.gz) has to be downloaded and should be placed in the images directory under dux home directory. The dux tool will use the container image from the dux home directory by default.
In the Linux VMs/hosts where Content Gateway container needs to be deployed:
a. SSH has to be enabled in the remote host/VM and SSH server daemon sshd has to be running in the remote host.
For example, in AlmaLinux check if sshd is running with the command: systemctl status sshd.

b. Docker/Podman/Podman-docker has to be installed and running in the Linux host/VM. Currently Snap docker (if ubuntu) is not supported.
Please ensure to install Docker CE/Podman/Podman-docker.
i. Dux commands perform docker operations using the 'docker' command. If Podman is installed on the VM, a symbolic link from podman to /usr/bin/docker is required to ensure compatibility.
```
The dry-run command (dux deploy -d) automatically creates this symlink if needed. Alternatively, the user can manually create it using the following command:
`sudo ln -sf $(which podman) /usr/bin/docker`
```
c. If Dux can be allowed to use sudo for the execution of commands (no_sudo: true in the manifest files): Ensure that the user can do sudo without password in the remote VM/host where Content Gateway container needs to be deployed
i.e In the sudoers file in the remote host, add an entry to grant passwordless access to your desired user.
To allow users to execute commands with sudo privileges without entering a password on the remote VM, follow these steps:
i. SSH to the remote VM as a user with administrative privileges.
ii. Edit the sudoers file using the command: sudo visudo.
iii. Add the following line to the end of the file to grant sudo privileges without password prompt: Replace username with the actual username of the user.
username ALL=(ALL) NOPASSWD: ALL
iv. Save and exit the sudoers file.
d. Connectivity to UEM Console API.
e. Connectivity to AWCM.
f. Docker Permissions:
Ensure that the Linux user running the Dux CLI has the necessary permissions to execute Docker commands. If you intend to use Docker without sudo (i.e., no_sudo: true in the manifest), the user must be added to the Docker group. Without this, you may encounter the following error:
```
Error: Please ensure the Linux user is added to the docker group or has sufficient permissions to access the Docker daemon socket on <host>
```
Steps to Add User to Docker Group:
1. Add the user to the Docker group:
```
```bash
sudo usermod -aG docker <username>
```
```
1. Log out and log back in for the changes to take effect.
2. Verify the user's access to Docker:
```
```bash
docker ps
```
If the command runs without errors, the user has sufficient permissions.
```
Note: If the no_sudo option in the manifest file is set to false, Dux will use sudo for Docker commands, and adding the user to the Docker group is not required.
Deployment of Content Gateway container in Dux VM
To deploy Content Gateway container in the same Linux VM as Dux, and to use dux commands locally without the need to use ssh:
- In the 'address' field under the 'hosts' group, you may use any of the following for localhost deployment: 127.0.0.1, localhost, the host's interface IP, or the hostname.
  Note that the localhost deployment of Content Gateway container is not supported in Mac OS / Windows.

Deploying Different Containers Using Dux CLI

The dux CLI tool supports deploying and managing multiple types of containers, including Tunnel container, PAC (Proxy Auto Configuration) Reader, SEG (Secure Email Gateway), EIC (EIC policy engine) and Content Gateway (CG).
This section explains how to use dux to deploy and manage different containers based on the container type.

Initializing a Container

The dux init command prompts the user to select the container type they want to initialize. Based on the selection, the CLI generates a manifest file template specific to the selected container type. This manifest file contains the necessary configuration parameters for deploying the container.

Example:

$ dux init
Select a container type to initialize:
1. Tunnel
2. EIC
3. PAC Reader
4. SEG
5. Content Gateway
Enter the number of the container type: 5
Content Gateway manifest file successfully created at: /opt/omnissa/dux/cg_manifest.yml

The generated manifest file is stored in the default directory based on the platform as outlined in the Installation section.

Using Dux Commands with Single or Multiple Containers

Behavior based on manifest files
If only one manifest file is present in the default directory, dux commands automatically use that manifest file.
If multiple manifest files are present, the user must select a container type or explicitly specify it in the command.
This flexibility allows users to manage multiple container types efficiently using the dux CLI tool.

Single Container Deployment

If only one type of container is deployed (i.e., only one manifest file is present in the default directory), all dux commands work as usual without requiring the user to specify the container type.
Example (if only cd_manifest.yml was present in the default directory):

$ dux status 

Status of Content Gateway containers deployed

1. Host: 192.168.84.166  Status: Not Deployed

Multiple Container Deployment

If multiple containers are deployed or multiple manifest files are present in the default directory, dux commands prompt the user to select a container type before executing the command.
Example:

Multiple manifests found. Please select a container type:
1. Tunnel (/opt/omnissa/dux/ts_manifest.yml)
2. EIC (/opt/omnissa/dux/eic_manifest.yml)
3. Content Gateway (/opt/omnissa/dux/cg_manifest.yml)

Enter the number of the container: 3

Status of Content Gateway containers deployed

1. Host: 192.168.84.166	Status: UP	Version: 25.12.0.7 	Operating System: Linux	Deployment Method: appliance

Explicitly Specifying Container Type

To avoid prompts, you can explicitly specify the container type in the command using the format: dux <container_type> <dux_command> <args>
For commands to deploy/manage CG containers, you can use : dux cg <dux_command> <args>

Example:

$ dux cg status

Status of Content Gateway containers deployed

1. Host: 192.168.84.166	Status: UP	Version: 25.12.0.7	Operating System: Linux	Deployment Method: appliance

Steps to deploy Content Gateway container

1. Execute init command

This command creates a sample manifest file for configuring Content Gateway container for deployment.

Note that the init command should be run the first time a container type is deployed, as it generates the manifest template file necessary for deployment.
This command creates a sample manifest (cg_manifest.yml) under the directory dux based on the platform (by default). If you wish to use a different path where the cg_manifest.yml file need to be created the command "dux init <some_path>" can be given. Please ensure to specify the path of manifest with -m option in the other commands.
For example, in Linux VM where dux is installed:

$ dux init --help
Select a container type to initialize:
1. Tunnel
2. EIC
3. PAC Reader
4. SEG
5. Content Gateway
Enter the number of the container type: 5
Create a manifest file for configuring Content Gateway details for deployment and management

Usage:
  dux cg init [path] [flags]

Examples:
        dux cg init                             # initialize manifest under default path (/opt/omnissa/dux/)
        dux cg init /some/path                  # initialize manifest under the specified path


Global Flags:
  -h, --help      Print help information
  -v, --verbose   Show verbose logs

$ dux init
Select a container type to initialize:
1. Tunnel
2. EIC
3. PAC Reader
4. SEG
5. Content Gateway
Enter the number of the container type: 5
Directory: /opt/omnissa/dux/scripts already exists
setup_host_for_cg.sh created at /opt/omnissa/dux/scripts/setup_host_for_cg.sh
Content Gateway manifest file successfully created at: /opt/omnissa/dux/cg_manifest.yml

$ cd /opt/omnissa/dux
$ ls -ltr
total 12
drwxr-xr-x. 2 admin admin    6 Nov 27 04:12 images
drwxr-xr-x. 2 admin admin   42 Nov 27 06:10 logs
drwxr-xr-x. 2 admin admin    6 Nov 27 04:12 scripts
drwxr-xr-x. 2 admin admin   42 Nov 27 06:10 certs
-rw-r--r--. 1 admin admin 3720 Nov 27 08:06 cg_manifest.yml

2. Edit cg_manifest.yml

Edit cg_manifest.yml generated in an editor of your choice.
Please refer to the section "Points to be noted while editing cg_manifest.yml" under Troubleshooting section.

Here are a few parameters:

image_name : Input details of Content Gateway container image to deploy

  # Enter the filename of the image or the repo path to deploy below.
  # File: This must match against the Content Gateway container image filename from the default directory (refer to the note below) or the absolute path.
  # example: cg_image.tar.gz or /home/admin/cg_image.tar.gz
  # Note: The default directory where the images are recommended to be present is:
  #   - for linux: /opt/omnissa/dux/images
  #   - for Mac OS on Intel/AMD64: /usr/local/var/opt/omnissa/dux/images/
  #   - for Mac OS on Apple Silicon/ARM64: /opt/homebrew/var/opt/omnissa/dux/images/
  #   - for Windows: <path of dux installation directory>/images
  # Repository: Repository path of the image with the tag can be given as well:
  # For example: your-local-repo.com/<path>/content-gateway:<tag>


#Copy the bundle to the working directory
# eg. in Linux: cp ~/Downloads/cg_image.tar.gz /opt/omnissa/dux/images/
$ ls -ltr /opt/omnissa/dux/images 
total 735112
-rw-r--r--@ 1 admin  admin  376374902 Feb 16 18:12 cg_image.tar.gz
#image_name in manifest
    image_name: cg_image.tar.gz

ssh_login_credentials

If all hosts have common authentication credentials, you may want to use the parameter - ssh_login_credentials.
However if you want to use different set of credentials for a host, the parameter host_info can be used. Refer to the sub-section which talks about hosts below.
For authentication, provide the ssh user name and ssh key path below

Please ensure to create a ssh key and copy the key to the remote VMs. Refer to https://linuxhint.com/generate-ssh-keys-on-linux/

If all hosts use a different SSH port other than 22, uncomment the ssh_port parameter and enter the port number. If not provided, default value of 22 will be used.

For example:

ssh_login_credentials:
  ssh_user: administrator
  # Input the path of ssh key - e.g /home/admin/id_rsa
  ssh_key_path: "/home/admin/id_rsa"
  ## Optional: Input the ssh port. Default value - 22
  #ssh_port:

ssh_host_key_check: Input if the identity of the remote host needs to be verified

SSH (Secure Shell) host key checking is a crucial security measure that helps verify the authenticity of a remote server before establishing a connection. When a client connects to a server for the first time, SSH presents the server's host key to the client. The client then checks this key against its list of known host keys to ensure it matches.

If the host key presented by the server matches an entry in the client's known_hosts file, the connection proceeds without interruption. However, if there's no match, SSH prompts the user to confirm the authenticity of the server by displaying the key fingerprint. This fingerprint serves as a unique identifier for the server's key.

The purpose of SSH host key checking is to prevent man-in-the-middle attacks, where an attacker intercepts communication between the client and server, posing as the legitimate server. By verifying the host key, SSH ensures that the client is connecting to the intended server and not a malicious entity.

By default the option to check host keys of remote VMs is enabled and the user will be prompted. If you do not wish to receive the prompts, ssh_host_key_check can be set to 0 to disable the check.

  # SSH Host key check - verify the identity of the remote host 
  # By default this is enabled and the user will be prompted to confirm the fingerprint of the public key of the remote host.
  # If disabled, dux will connect similar to the ssh option StrictHostKeyChecking=no and UserKnownHostsFile=/dev/null
  # 1 - enable host key checking
  # 0 - disable host key checking
  ssh_host_key_check: 1

global_base_dir: Specify the global working directory for dux

This parameter defines the global working directory under which all directories for dux related to Content Gateway container deployment will be created for all hosts. If not specified, the default value is the home directory of the ssh user ($HOME). Use the parameter host_base_dir if the hosts have different working directories based on permission requirements for each host.

For example:

  # Global value for base directory for dux under which all directories for Content Gateway container deployment will be created for all hosts.
  # Default is $HOME directory of the ssh user
  global_base_dir: $HOME

container_logging: Configure logging behavior for Content Gateway container

This section controls the logging behavior of the Content Gateway container. It allows you to specify the maximum size of each log file and the number of log files to retain.

max_size: Defines the maximum size of each log file. Once the size is reached, the log file is rotated. Supported units are K (Kilobytes), M (Megabytes), and G (Gigabytes). The default value is "10M".
max_num_files: Specifies the maximum number of log files to retain. Older files are deleted when the limit is reached. The default value is "5".

For example:

    container_logging:
        max_size: "20M"
        max_num_files: "10"

hosts: Input docker host information for Content Gateway container deployment. Add an entry for each host.

Fill in the IP address / host name of the host where Content Gateway container needs to be deployed.
For example:

  # Content Gateway container Host(s) Information
  # Input docker host information for Content Gateway container deployment. Add an entry for each host.
  hosts:
    # Enter IP address of the host below
    - address: 192.168.84.166

host_info: For authentication info specific to this host, uncomment the parameters under the parameter host_info.

If both ssh_key_path and ssh_password are provided, ssh_key_path is preferred. Note that for security reasons, giving password information in manifest is not recommended. But it is still provided as an option.
The values can be passed as environment variables.
If all hosts have common ssh credential info, you may use the global parameter: ssh_login_credentials mentioned in the section above.
If both host_info and ssh_login_credentials are given, the credentials under host_info are preferred.

If the host uses a different SSH port other than 22, uncomment the ssh_port parameter and enter the port number. If not provided, default value of 22 will be used.
For example:

      host_info:
        ssh_user: admin
        ## Input the path of ssh key - e.g /home/admin/id_rsa
        ssh_key_path: /home/admin/id_rsa
        ## For security reasons, the ssh_password is not recommended. 
        #ssh_password: 
        ## Input the ssh port. Default value - 22
        #ssh_port:

host_base_dir: To override the global_base_dir for the host, uncomment the fields under parameter host_base_dir

The host_base_dir parameter specifies the working directory on the host under which all directories for the Content Gateway container deployment will be created.
This parameter allows you to override the global_base_dir for a specific host. If all hosts share a common working directory, you can use the global_base_dir parameter instead.
Example: Setting host_base_dir: /home/admin/dux/ ensures that all directories for the Content Gateway deployment on this specific host will be created under /home/admin/dux/.

    ## Host base directory for dux under which all directories of dux for Content Gateway container deployment will be created for this host.
    ## If all hosts have common base directory, you may use the global parameter - 'global_base_dir'. Default is $HOME directory.
    host_base_dir: /home/admin/dux

host_entries: Add entries to the container hosts file to manually link FQDN to IP address

If host entries need to be specified (e.g Content repository or servers ) in the remote host, specify the host names and ip addresses in this section.

  # Add entries to the container hosts file to manually link FQDN to IP address
  # Format:
  ## - host_name:
  ##   ip_address:
  host_entries:
    - host_name: example.com
      ip_address: 1.2.3.4

uem: Workspace ONE UEM Information

The details of UEM profile such as UEM url, GUID, Content Gateway Endpoint port, Content Gateway Endpoint address from the UEM configuration, user name to authenticate with Workspace ONE UEM API Server need to be given in this section.

Example of configuration parameters related to UEM:

#Workspace ONE UEM Information
uem:
  # The Workspace ONE UEM API server URL. The destination URL must contain the protocol and hostname or IP address
  # Example: https://load-balancer.example.com
  url: 
  # Content Gateway Endpoint address
  cg_endpoint_address: 
  # Content Gateway Endpoint port as configured in the UEM console in Content Gateway (CG) configuration
  api_port: 8443
  # GUID of your Content Gateway configuration. This is shown on the Content Gateway Configuration page on the UEM console.
  api_uuid: 
  admin:
    # The username to authenticate with the Workspace ONE UEM API server.
    username:

permissions: Command Permissions Configuration

The permissions section in the cg_manifest.yml file controls whether specific operations require sudo privileges during the execution of dux commands. This section allows you to configure the behavior of dux for different types of operations, ensuring flexibility and security based on your environment.

permissions:
  # Docker commands (run, stop, logs, inspect, etc.)
  # no_sudo: false (default) = use sudo, no_sudo: true = don't use sudo

  docker:
    no_sudo: false

  # File operations (mkdir, cp, rm, chown, etc.)

  file_operations:
    no_sudo: false

  # System commands (systemctl, sysctl, ulimit, etc.)

  system:
    no_sudo: false

  # Network configuration (ip route, iptables, ifconfig, etc.)

  network:
    no_sudo: false

Field	Description	no_sudo: true	no_sudo: false
Docker Commands	Controls whether sudo is required for Docker-related operations, such as running, stopping, inspecting, and fetching logs from containers.	Docker commands will be executed without sudo. Requires the user to have appropriate permissions to run Docker commands without sudo.	Docker commands will be executed with sudo. This is the default setting for security purposes.
File Operations	Controls whether sudo is required for file-related operations, such as creating directories, copying files, removing files, and changing ownership.	File operations will be executed without sudo. Requires the user to have appropriate permissions to perform file operations without sudo.	File operations will be executed with sudo. This is the default setting for security purposes.
System Commands	Controls whether sudo is required for system-level commands, such as managing services (systemctl), modifying system limits (ulimit), or configuring system parameters (sysctl).	System commands will be executed without sudo. Requires the user to have appropriate permissions to execute system commands without sudo.	System commands will be executed with sudo. This is the default setting for security purposes.
Network Configuration	Controls whether sudo is required for network-related operations, such as configuring IP routes, managing firewall rules (iptables), or modifying network interfaces.	Network configuration commands will be executed without sudo. Requires the user to have appropriate permissions to perform network operations without sudo.	Network configuration commands will be executed with sudo. This is the default setting for security purposes.

Default Behavior: By default, all fields in the permissions section are set to false, meaning that sudo is required for all operations. This ensures maximum security, as elevated privileges are used to execute commands.

When to Set no_sudo: true: You can set no_sudo: true for specific fields if:

The user running the CLI tool has the necessary permissions to execute the commands without sudo.
You want to avoid using sudo for specific operations to simplify execution in environments where elevated privileges are not required.

CA Certificates Configuration

The ca_cert_files field in the cg_manifest.yml file allows you to specify additional CA certificates to be added to the container's certificate store. These certificates are essential for enabling secure communication between the Content Gateway container and external systems.

# Additional CA certificates to be added to the container cert store
# Give file names of the cert to be added. Multiple filenames can be given separated by comma - e.g., cert1.crt, cert2.crt
# The default directory where the certs are recommended to be present is:
#  - for linux: /opt/omnissa/dux/certs
#  - for Mac OS on Intel/AMD64: /usr/local/var/opt/omnissa/dux/certs/
#  - for Mac OS on Apple Silicon/ARM64: /opt/homebrew/var/opt/omnissa/dux/certs/
#   - for Windows: <path of dux installation directory>/certs/
# Absolute path of the cert can be given as well - /home/admin/proxy.crt
ca_cert_files:

Note: The following sections assume that there is only cg_manifest.yml present in the default directory to deploy and manage CG containers. Hence, the commands are in the format: dux <command> <args>.

3. Execute deploy command

Once the manifest is updated with the required configuration details, deploy command can be run to deploy the Content Gateway container in the hosts specified.

deploy help

$ dux deploy -h
Deploy Content Gateway containers

Usage:
  dux cg deploy [flags]

Flags:
  -d, --dry-run                   Check if manifest is good to deploy
  -p, --ip stringArray            Hostname or IP as specified in the manifest to deploy on a single host
  -m, --manifest-file string      Custom manifest file path (default "/opt/omnissa/dux/cg_manifest.yml")
  -n, --node-number stringArray   Node number as listed in manifest to deploy on a single host
  -q, --quiet                     Quiet mode: interactive ssh password prompts are disabled
  -u, --uem-password string       Password to authenticate with the Workspace ONE UEM API server
  -y, --yes                       Auto accept all prompts

Global Flags:
  -h, --help      Print help information
  -v, --verbose   Show verbose logs

Check if manifest is good to run

To catch if there the manifest is syntactically correct, run "deploy --dry-run or -d ".
Following checks are done when dux deploy --dry-run command is run:

Syntax check of the manifest file (eg. cg_manifest.yml)
Validation of the fields in manifest file so that the required fields are filled in
Deployment pre-requisites
a. SSH connectivity to remote hosts
b. Check if docker is installed and running on remote hosts
c. Check if the Linux user is configured to use sudo (if no_sudo is marked as 'false' in the permissions section of the manifest file)
d. Check if passwordless sudo is setup for the Linux user (if no_sudo is marked as 'false' in the permissions section of the manifest file)

$ dux deploy -d
Manifest file syntax validation is successful

Verifying Content Gateway container image location given in manifest: content_gateway_image.tar.gz
Verifying remote host deployment prerequisites

Verifying deployment prerequisites on 192.168.84.166
Checking ssh connectivity to host: 192.168.84.166
Verifying docker is installed and running on 192.168.84.166

Checking for host working directory: /home/user1

Checking for availablility of sufficient free disk space in the host working directory: /home/user1
Host 192.168.84.166 is good to deploy
Manifest file and hosts are good to deploy!
#In case of error in the manifest, for example, if image_name was not filled up, you may get an error like below:
$ dux deploy -d
Manifest verification failed error="Incorrect data in manifest: the image_name field must be populated"

Host Key Verification

For security requirements, when dux commands are executed, host key verification is done during the SSH handshake at the first time. If the host is unknown, a prompt is displayed to check the fingerprint of the host's key. If the user confirms the host key is correct, the host is added to known hosts.
If the fingerprint of the host changes, the user is prompted again to ensure there is no intruder attack.

The authenticity of host '192.168.99.185:22' can't be established.
Fingerprint of the host's key:SHA256:AOy8f1sChEM7xLJyYP190vjjVxDLYI9ORDaKZCNKzzE
Do you want to continue connecting? (yes/no):

Deploy

This command deploys the Content Gateway containers in the hosts in the order as listed in manifest. The image is copied to remote host which will take few minutes depending on the network connectivity.
Note:

Ensure the image to be deployed is in the images directory or the absolute path specified in the image_name in manifest.
If image to be deployed is already loaded in remote host, the step to copy Content Gateway container image will be skipped.
The command given without options (-n or -p) will deploy containers in all hosts as listed in manifest.

#Sample run
$ dux deploy      
Host 192.168.84.166: using per-host working dir /home/administrator
Enter UEM password: 
Preparing for Content Gateway container deployment on 192.168.84.166
Content Gateway container image is already present on the host. Will not need to copy the image for deployment
Deploying new Content Gateway container on 192.168.84.166....

faf4586871d5187aa0c8525b1a6b9f0fb4606ccccec433b6eba59a5b5e84f014

Checking if Content Gateway container is running on 192.168.84.166....
Fetching the deployment status. Please wait. This may take some time... \Status: UP     Version: 25.12.0.7 Operating System: Linux
Deployment is up!
Deploy command has completed on 192.168.84.166

——

Running setup script if sudo permissions are false (no_sudo: true)

Content gateway deployment requires specific users and groups to be created, and permissions of directories to be set. This requires sudo permissions.
The script setup_host_for_cg.sh is created by dux init command under /opt/omnissa/dux/scripts directory for linux ( note: the path will vary for different platforms)
This script needs to be copied and executed from dux host to the container host (if remote) manually before the execution of dux deploy command. This will be prompted to user during deployment.

$ dux deploy
Enter UEM password: 
Preparing for Content Gateway container deployment on 192.168.84.166
⚠️  Host 192.168.84.166: Sudo permissions for 'system' and 'file_operations' are required to run the setup script. Deployment may fail.
Please manually copy and run the setup script (/opt/omnissa/dux/scripts/setup_host_for_cg.sh) on the host: 192.168.84.166 before proceeding
Do you want to continue deployment on this host? (y/n): n
Deployment failed error="deployment aborted by user due to lack of sudo permissions on host: 192.168.84.166"
exit status 1

Steps to Execute Setup Script Before Deployment

If no_sudo: true is set in the cg_manifest.yml file, you must manually execute the setup_host_for_cg.sh script on the container host before proceeding with the deployment. Follow these steps:

Copy the Script to the Remote Host
Use scp or any file transfer method to copy the script to the remote host.
Replace <remote_user> with the SSH user and <remote_host> with the IP address or hostname of the remote machine.

$ scp /opt/omnissa/dux/scripts/setup_host_for_cg.sh <remote_user>@<remote_host>:/home/<remote_user>/

Make the Script Executable
On the remote host, ensure the script has executable permissions.

$ chmod +x /home/<remote_user>/setup_host_for_cg.sh

Run the Script with Sudo
Execute the script on the remote host using sudo. Replace <host_working_dir> with the host_base_dir or global_base_dir directory specified in the cg_manifest.yml file (e.g., /path/to/working/dir) and <remote_user> with the SSH user defined in the manifest.

$ sudo ./setup_host_for_cg.sh <host_working_dir> <remote_user>

Example:
If the host_base_dir is /home/user1/cg and the ssh_user defined in the manifest is user1, run:

$ sudo ./setup_host_for_cg.sh /home/user1/cg user1

Note:

Ensure the setup_host_for_cg.sh script is executed successfully before proceeding with the deployment.
If you are using dux on a Windows machine and need to copy the setup_host_for_cg.sh script to a remote host, you may encounter issues with CRLF (Carriage Return and Line Feed) characters in the script. These characters are specific to Windows and can cause errors when running the script on a Linux-based remote host.

To resolve this issue, you need to convert the CRLF line endings to LF (Line Feed) on the remote host.

Convert CRLF to LF on the Remote Host
After copying the script, log in to the remote host using SSH:

ssh <remote_user>@<remote_host>

Navigate to the directory where the script was copied:

cd /home/<remote_user>/

Use the tr command to convert the CRLF line endings to LF:

tr -d '\r' < setup_host_for_cg.sh > setup_host_for_cg_fixed.sh

This command creates a new file named setup_host_for_cg_fixed.sh with the corrected line endings.
2. Make the converted script executable and run the script with sudo.

To use a different manifest

To use a manifest from a different path -m flag can be used. If not specified, cg_manifest.yml from the directory where dux is run from is used by default.

#For eg.
$ dux deploy -m ~/Downloads/cg_manifest_xyz.yml

To deploy Content Gateway container in specific/few remote hosts

To deploy Content Gateway containers in few remote hosts specified by ip or node-number (as per the order in manifest).

#For eg.
$dux deploy -n 1 -n 3$ dux deploy -p 1.2.3.4

To give UEM password as command line option:

$ dux deploy -u <uem_password>

Perform operations on deployed Content Gateway containers

Once the deployment of containers is successful, other commands can be used to check status of deployment, fetch logs, and perform operations like stop, restart, and even destroy the deployments.

1.Check status of deployment

#status help
$ dux status -h
Get the status of the Content Gateway containers deployed

Usage:
  dux cg status [flags]

Flags:
  -p, --ip stringArray            Hostname or IP as specified in the manifest for filtering
  -m, --manifest-file string      Custom manifest file path (default "/opt/omnissa/dux/cg_manifest.yml")
  -n, --node-number stringArray   Node number as listed in manifest for filtering
  -q, --quiet                     Quiet mode: interactive ssh password prompts are disabled

Global Flags:
  -h, --help      Print help information
  -v, --verbose   Show verbose logs
#To get status of all deployments - sample run. 
$ dux status 
Host 192.168.84.166: using per-host working dir /home/administrator

Status of Content Gateway containers deployed

1. Host: 192.168.84.166   Status: UP      Version: 25.12.0.7  Operating System: Linux Deployment Method: appliance    %              

#Get status of a host/hosts by IP
#Multiple ips can be specified too. eg. dux status -p 1.2.3.4 -p 1.2.3.5 
$ dux status -p 10.87.132.110 

#Get status of a specific host with node-number as listed in the manifest file
#Multiple node numbers can be given too: eg. dux status -n 1 -n 3 
$ dux status -n 1

2.Fetch logs from the deployed containers

Fetch Content Gateway log bundle from the deployed containers. If the container deployment is down, the docker logs of the container are fetched.
Note that the logs are stored in the logs directory based on the platform.
For linux: /opt/omnissa/dux/logs/
For Mac OS on Intel (AMD64): /usr/local/var/opt/omnissa/dux/logs
For Mac OS on Apple Silicon (ARM64): /opt/homebrew/var/opt/omnissa/dux/logs
For Windows: <INSTALL_DIR>\logs

The option -f can be used to continously view the docker logs output of a Content Gateway container deployed till Ctrl-C is given.

# logs help
$ dux logs -h
Get logs from the Content Gateway containers deployed

Usage:
  dux cg logs [flags]

Flags:
  -f, --follow                    Follow/View logs of a CG container specified by node-number (-n) or ip (-p) option
  -p, --ip stringArray            Hostname or IP as specified in the manifest for filtering
  -m, --manifest-file string      Custom manifest file path (default "/opt/omnissa/dux/cg_manifest.yml")
  -n, --node-number stringArray   Node number as listed in manifest for filtering
  -q, --quiet                     Quiet mode: interactive ssh password prompts are disabled

Global Flags:
  -h, --help      Print help information
  -v, --verbose   Show verbose logs

#Get logs of all containers deployed as per manifest
#Sample run - Note if the deployment is not up, the container logs are fetched.
$ dux logs 
Host 192.168.84.166: using per-host working dir /home/administrator
Retrieve Content Gateway container logs from 192.168.84.166
Copy log bundle from Remote to Local machine..
Logs from 192.168.84.166 downloaded at: /usr/local/var/opt/omnissa/dux/logs/cg_logs_dir.192.168.84.166_20251202151718.tar.gz


#Logs from a single deployment or multiple deployments can be obtained by specifying IP / node-number in the order as per the manifest
#eg. 
# dux logs -p 1.2.3.4 -p 1.2.3.5
# dux logs -n 2 -n 4

#To continuously view/follow the run logs of container , give -f option for the specific node/host ip
# dux logs -n 1 -f 
#Press Ctrl-C to stop viewing

3.Stop deployed containers

In case an Content Gateway container needs to be stopped for some reason, dux stop command can be given.

# stop help
$ dux stop -h                      
Stop Content Gateway containers on the given host(s) from the manifest file. To restart the containers again, you may use `dux restart` command.

Usage:
  dux cg stop [flags]

Flags:
  -p, --ip stringArray            Hostname or IP as specified in the manifest for filtering
  -m, --manifest-file string      Custom manifest file path (default "/opt/omnissa/dux/cg_manifest.yml")
  -n, --node-number stringArray   Node number as listed in manifest for filtering
  -q, --quiet                     Quiet mode: interactive ssh password prompts are disabled
  -y, --yes                       Auto accept all prompts

Global Flags:
  -h, --help      Print help information
  -v, --verbose   Show verbose logs

# Stop all deployments 
$ dux stop  

Are you sure you want to stop the Content Gateway containers deployed in all the hosts given in the manifest? 
ip : 10.87.132.166 node-number : 1 
Please confirm (y/n): y
Content Gateway container was successfully stopped on 10.87.132.166

#Deployment of Content Gateway containers can be stopped by specifying IPs or node-number in the order as per the manifest
#eg.
# dux stop -p 1.2.3.4
# dux stop -n 4

#To auto accept all prompts for y/n , -y option can be given
#eg.
# dux stop -y

4.Restart deployed containers

Stopped containers can be restarted by dux restart command

#restart help
$ dux restart -h
Restart the Content Gateway containers on given hosts

Usage:
  dux cg restart [flags]

Flags:
  -p, --ip stringArray            Hostname or IP as specified in the manifest for filtering
  -m, --manifest-file string      Custom manifest file path (default "/opt/omnissa/dux/cg_manifest.yml")
  -n, --node-number stringArray   Node number as listed in manifest for filtering
  -q, --quiet                     Quiet mode: interactive ssh password prompts are disabled
  -y, --yes                       Auto accept all prompts

Global Flags:
  -h, --help      Print help information
  -v, --verbose   Show verbose logs

#Restart all deployments
#Sample run
$ dux restart   


Are you sure you want to restart the Content Gateway containers deployed in all the hosts given in the manifest? 
ip : 10.87.132.166 node-number : 1 
Please confirm (y/n): y
Content Gateway container was successfully restarted on 10.87.132.166

#Deployment of Content Gateway containers can be restarted by specifying IPs or node-number in the order as per the manifest
#eg.
# dux restart -p 1.2.3.4
# dux restart -n 4

#To auto accept all prompts for y/n , -y option can be given
#eg.
# dux restart -y

5.Destroy deployed containers

To stop and remove the deployed container from the remote Content Gateway container host, dux destroy command can be used.

$ dux destroy -h
Destroy the Content Gateway containers on the given hosts

Usage:
  dux cg destroy [flags]

Flags:
  -p, --ip stringArray            Hostname or IP as specified in the manifest for filtering
  -m, --manifest-file string      Custom manifest file path (default "/opt/omnissa/dux/cg_manifest.yml")
  -n, --node-number stringArray   Node number as listed in manifest for filtering
  -q, --quiet                     Quiet mode: interactive ssh password prompts are disabled
  -y, --yes                       Auto accept all prompts

Global Flags:
  -h, --help      Print help information
  -v, --verbose   Show verbose logs

#Destroy all deployments
#Sample run
$ dux destroy       

Are you sure you want to destroy the Content Gateway containers deployed in all the hosts given in the manifest? 
ip : 10.87.132.166 node-number : 1 
Please confirm (y/n): y
Content Gateway container was successfully destroyed on 10.87.132.166

#Deployment of Content Gateway containers can be destroyed by specifying IPs or node-number in the order as per the manifest
#eg.
# dux destroy -p 1.2.3.4
# dux destroy -n 4

#To auto accept all prompts for y/n , -y option can be given
#eg.
# dux destroy -y

6. Get verbose logs

If you wish to get verbose logs for any command, use the -v or --verbose option.
For example:

$ dux deploy -v

7. Open interactive shell with Content Gateway container

If you wish to start a shell with Content Gateway container you can use the command 'exec-shell'

$ dux exec-shell -h
Open interactive shell with Content Gateway container

Usage:
  dux cg exec-shell [flags]

Flags:
  -p, --ip stringArray            Hostname or IP as specified in the manifest for filtering
  -m, --manifest-file string      Custom manifest file path (default "/opt/omnissa/dux/cg_manifest.yml")
  -n, --node-number stringArray   Node number as listed in manifest for filtering
  -q, --q                         Quiet mode: interactive ssh password prompts are disabled

Global Flags:
  -h, --help      Print help information
  -v, --verbose   Show verbose logs

$ dux exec-shell -n 1

Starting the interactive shell with Content Gateway container in host: 192.168.84.166
[cg-user@faf4586871d5 content-gateway]$ pwd
/opt/omnissa/content-gateway
[cg-user@faf4586871d5 content-gateway]$ ls
bin  conf  content-gateway.jar  dux  fetch-config  kerberos-client  logs  scripts  service  smb-connector  tmp  tools  version.txt
[cg-user@faf4586871d5 content-gateway]$ exit
exit

Troubleshooting

For any installation issues please refer to the package manager instructions (yum/dnf/brew) for the specific error.
For example, if you are using dnf and encounter issues with installing dux, check if the cache is updated. Try "dnf makecache" to update metadata cache.
Ensure "dux init" command is run the first time.
Do a dry-run before deploying to ensure there are no issues with the manifest, and to ensure that the deployment pre-requisites are met.

 dux deploy -d

For any issues, please check the file dux.log under logs directory as per the platform - for e.g /opt/omnissa/dux/logs/dux.log in Linux.
If docker is installed with snap in the Linux system, you may encounter permission issues during deployment of Content Gateway containers with dux.
Ubuntu commonly uses snap to install packages.
If snap docker is used it is recommended to uninstall snap docker, and install docker as mentioned in https://docs.docker.com/engine/install/ubuntu/ .

sudo snap remove docker --purge
sudo reboot 
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin

Note: Please check if there are other containers running in your VM with snap docker. While technically possible, running both Snap Docker and Docker CE on the same Ubuntu system is generally not recommended due to the potential for conflicts and complexity - wrt port usage, networking, system resources usage etc.

Please ensure the conditions in the Prerequisites section are met.
In Windows, if dux is installed under system directories like C:\Program Files, Windows Powershell/Command Prompt should be run as administrator for dux commands to work. Please check for errors related to access issues.
Passwords with Special Characters

When using command line option (-u) to input password to authenticate with the UEM API server, always wrap your password. This prevents issues with special characters being misinterpreted by the shell during deployment.
- Example: If the password is Secret123!, input it as 'Secret123!'.
- This recommendation applies only to the -u parameter for UEM Password in the deploy command. Passwords entered via prompts (e.g., Enter UEM password:) do not require wrapping in single quotes and will work as is.
Resolving ANSI Characters Display Issue in Windows PowerShell

If you encounter ANSI escape characters (e.g., \u001b[31m) while using dux commands in Windows PowerShell, it indicates that ANSI escape code support is not enabled. This can cause colored or formatted output to appear incorrectly.

To resolve this issue, you can enable ANSI escape code support in your terminal by modifying a registry setting. Follow the steps below:
1. Open Command Prompt (cmd.exe) or PowerShell with administrator privileges.
2. Run the following command to enable ANSI escape code support:
```
reg add HKCU\Console /v VirtualTerminalLevel /t REG_DWORD /d 1
```
1. Restart your terminal for the changes to take effect.
If Podman is used in the Linux VM, containers might not automatically restart after a system reboot. To address this, configure the container as a systemd service. This ensures that systemd manages the container's lifecycle and restarts it automatically after a reboot.

For detailed steps on configuring the container as a systemd service, contact support.

To avoid errors while editing the cg_manifest.yml, please refer to the following guide:

Points to be noted while editing cg_manifest.yml file

Open the YAML File
- Right-click on the cg_manifest.yml file and choose "Open With" from the context menu. Select a text editor such as TextEdit (Mac), or any code editor like Visual Studio Code, Sublime Text, or Atom.
- Alternatively, you can open the text editor first and then navigate to the file using the "File" menu.
Understand YAML Syntax
- YAML uses a human-readable syntax based on indentation and key-value pairs.
- Each entry in the YAML file consists of a key followed by a colon : and then the corresponding value.
- Indentation (whitespace at the beginning of a line) is crucial in YAML to denote hierarchical structure.
- Please ensure there is a space post colon as this is a common user error :
  image_name: cg_image.tar.gz
Make Changes
- Locate the section of the YAML file you wish to modify. Be careful not to change the structure or indentation, as YAML is sensitive to these.
- Edit the values according to your requirements.
- Take note of any comments (#) in the YAML file as they provide context or explanations about specific entries.
Save Changes
- After making the necessary edits, save the file by clicking on "File" in the menu and then selecting "Save" or by pressing Ctrl + S (Linux) or Cmd + S (Mac).
- Ensure that you save the file with the .yml extension to maintain its YAML format.
Validate Changes (Optional)
- If you're unsure whether your changes are syntactically correct, you can validate the YAML file using online YAML validators (https://www.yamllint.com/) or command-line tools.
- YAML linting tools can identify syntax errors or formatting issues, helping you ensure the file is valid.
Backup (Optional but Recommended)
- Before making extensive changes, consider creating a backup of the original YAML file. This ensures you can revert to the previous configuration if needed.
Sample cg_manifest.yml file for reference

# Version number for the Content Gateway Container deployment manifest. This is auto generated and should not be altered.
version: "3.1.0.886"

#Configuration parameters needed to deploy Content Gateway container
content_gateway:
  # Enter the filename of the image or the repo path to deploy below.
  # File: This must match against the Content Gateway container image filename from the default directory (refer to the note below) or the absolute path.
  # example: cg_image.tar.gz or /home/admin/cg_image.tar.gz
  # Note: The default directory where the images are recommended to be present is:
  #   - for linux: /opt/omnissa/dux/images
  #   - for Mac OS on Intel/AMD64: /usr/local/var/opt/omnissa/dux/images/
  #   - for Mac OS on Apple Silicon/ARM64: /opt/homebrew/var/opt/omnissa/dux/images/
  #   - for Windows: <path of dux installation directory>/images 
  # Repository: Repository path of the image with the tag can be given as well:
  # For example: your-local-repo.com/<path>/content-gateway:<tag>
  image_name: cg_image.tar.gz
 
  #Container Host(s) Authentication Information 
  # If all hosts have common authentication credentials, you may want to use the parameter - 'ssh_login_credentials'
  # For authentication, provide the ssh user name and ssh key path below
  # If all hosts use a different SSH port other than 22, uncomment the `ssh_port` parameter and enter the port number.
  # If not provided, default value of 22 will be used.
  ssh_login_credentials:
    ssh_user: user1
    # Input the path of ssh key - e.g /home/admin/id_rsa
    ssh_key_path: /home/user1/.ssh/id_rsa
    ## Optional: Input the ssh port. Default value - 22
    #ssh_port:
  
  # SSH Host key check - verify the identity of the remote host 
  # By default this is enabled and the user will be prompted to confirm the fingerprint of the public key of the remote host.
  # If disabled, dux will connect similar to the ssh option StrictHostKeyChecking=no and UserKnownHostsFile=/dev/null
  # 1 - enable host key checking
  # 0 - disable host key checking
  ssh_host_key_check: 1 
  # Global value for working directory for dux under which all directories of dux for Content Gateway container deployment will be created for all hosts.
  # Default is $HOME directory
  global_base_dir: /home/user1

    # Container Logging Configuration
  # These parameters control the logging behavior of the Content Gateway container.
  # max_size: Maximum size of each log file. Once the size is reached, the log file is rotated.
  # Supported units: K (Kilobytes), M (Megabytes), G (Gigabytes). Default: "10M".
  # max_num_files: Maximum number of log files to retain. Older files are deleted when the limit is reached. Default: "5". 
  container_logging:
    max_size: "10M"
    max_num_files: "5"

  # Content Gateway container Host(s) Information
  # Input docker host information for Content Gateway container deployment. Add an entry for each host.
  hosts:
    # Enter IP address of the host below
    - address: 192.168.84.166

      ######################################################################
      ## THE FOLLOWING ARE OPTIONAL PARAMETERS FOR CONTENT GATEWAY CONTAINER DEPLOYMENT. 
      ## PLEASE EDIT THEM AS PER YOUR REQUIREMENTS
      ######################################################################

      ## For information specific to this host, uncomment 'host_info' and the parameters under it as needed.

      ## For authentication info specific to this host, uncomment the 'ssh_user' and 'ssh_key_path/ssh_password' as needed.
      ## If both 'ssh_key_path' and 'ssh_password' are provided, 'ssh_key_path' is preferred.
      ## The values can also be passed as environment variables
    
      ## SSH Port information
      ## If the host uses a different SSH port other than 22, uncomment the `ssh_port` parameter and enter the port number.
      ## If not provided, default value of 22 will be used.

      host_info:
        ssh_user: 
        ## Input the path of ssh key - e.g /home/admin/id_rsa
        ssh_key_path: 
        ## For security reasons, the ssh_password is not recommended. 
        ssh_password:  
        ## Input the ssh port. Default value - 22
        #ssh_port:

      ## Host working directory for dux under which all directories of dux for Content Gateway container deployment will be created for this host.
      ## Default is $HOME directory. If all hosts have common working directory, you may use the global parameter - 'global_base_dir'
      #host_base_dir: 
  # Add entries to the container hosts file to manually link FQDN to IP address
  # Format:
  ## - host_name:
  ##   ip_address: 
  #host_entries:
    # Example:
    #- host_name: example.com
    #  ip_address: 192.168.1.1
      
#Workspace ONE UEM Information
uem:
  # The Workspace ONE UEM API server URL. The destination URL must contain the protocol and hostname or IP address
  # Example: https://load-balancer.example.com
  url: https://example-uem-api.com 
  # Content Gateway Endpoint address
  cg_endpoint_address: https://cgtest.com
  # Content Gateway Endpoint port as configured in the UEM console in Content Gateway (CG) configuration 
  api_port: 8443 
  # GUID of your Content Gateway configuration. This is shown on the Content Gateway Configuration page on the UEM console.
  api_uuid: 519bb7c9-001a-4955-98af-6425f2dadads
  admin:
    # The username to authenticate with the Workspace ONE UEM API server.
    username: uemuser

# Additional CA certificates to be added to the container cert store
# Give file names of the cert to be added. Multiple filenames can be given separated by comma - e.g., cert1.crt, cert2.crt
# The default directory where the certs are recommended to be present is:
#  - for linux: /opt/omnissa/dux/certs
#  - for Mac OS on Intel/AMD64: /usr/local/var/opt/omnissa/dux/certs/
#  - for Mac OS on Apple Silicon/ARM64: /opt/homebrew/var/opt/omnissa/dux/certs/
#   - for Windows: <path of dux installation directory>/certs/
# Absolute path of the cert can be given as well - /home/admin/proxy.crt
ca_cert_files: 

# Command Permissions Configuration
# This section controls which operations require sudo privileges.
# Set no_sudo: true to run commands without sudo (requires appropriate user permissions)
# Set no_sudo: false to run commands with sudo (default for security)

permissions:
  # Docker commands (run, stop, logs, inspect, etc.)
  # no_sudo: true (default) = use sudo, no_sudo: true = don't use sudo

  docker:
    no_sudo: false

  # File operations (mkdir, cp, rm, chown, etc.)

  file_operations:
    no_sudo: false

  # System commands (systemctl, sysctl, ulimit, etc.)

  system:
    no_sudo: false

  # Network configuration (ip route, iptables, ifconfig, etc.)

  network:
    no_sudo: false

dux (Omnissa CLI) - Content Gateway commands

Table of Contents

Installation

Usage

Check version of Dux cli

Get list of commands supported:

Get legal and privacy information about Dux

Prerequisites

Deploying Different Containers Using Dux CLI

Initializing a Container

Using Dux Commands with Single or Multiple Containers

Single Container Deployment

Multiple Container Deployment

Explicitly Specifying Container Type

Steps to deploy Content Gateway container

1. Execute init command

2. Edit cg_manifest.yml

image_name : Input details of Content Gateway container image to deploy

ssh_login_credentials

ssh_host_key_check: Input if the identity of the remote host needs to be verified

global_base_dir: Specify the global working directory for dux

container_logging: Configure logging behavior for Content Gateway container

hosts: Input docker host information for Content Gateway container deployment. Add an entry for each host.

host_info: For authentication info specific to this host, uncomment the parameters under the parameter host_info.

host_base_dir: To override the global_base_dir for the host, uncomment the fields under parameter host_base_dir

host_entries: Add entries to the container hosts file to manually link FQDN to IP address

uem: Workspace ONE UEM Information

permissions: Command Permissions Configuration

CA Certificates Configuration

3. Execute deploy command

deploy help

Check if manifest is good to run

Host Key Verification

Deploy

Running setup script if sudo permissions are false (no_sudo: true)

Steps to Execute Setup Script Before Deployment

To use a different manifest

To deploy Content Gateway container in specific/few remote hosts

To give UEM password as command line option:

Perform operations on deployed Content Gateway containers

1.Check status of deployment

2.Fetch logs from the deployed containers

3.Stop deployed containers

4.Restart deployed containers

5.Destroy deployed containers

6. Get verbose logs

7. Open interactive shell with Content Gateway container

Troubleshooting

Passwords with Special Characters

Resolving ANSI Characters Display Issue in Windows PowerShell

Points to be noted while editing cg_manifest.yml file