dux (Omnissa CLI)

This document contains instructions to install and use dux CLI which will be used to setup, deploy and perform operations of containers - Tunnel container, PAC Reader, SEG, Content Gateway and EIC.

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

Installation

Dux can be installed on Linux (including RHEL/AlmaLinux and Ubuntu), Mac OS and Windows.

Installing dux for Linux

Dux for Linux (RHEL) can be installed using the package managers - yum or dnf.

Note: If you had installed the Beta version 2.0.0.3 earlier, please perform the following steps to cleanup before proceeding with installation:

# Remove dux.repo 
sudo rm /etc/yum.repos.d/dux.repo

#Clean the package manager cache
sudo yum clean all
or
sudo dnf clean all

Create dux.repo and install

$ cat << EOF | sudo tee /etc/yum.repos.d/dux.repo
[dux]
name=Omnissa CLI - dux
baseurl=https://packages.omnissa.com/ws1-tunnel/dux
enabled=1
gpgcheck=1
gpgkey=https://packages.omnissa.com/ws1-tunnel/dux-apt/gpg.key
EOF

# 4. Install dux
#If using yum:
$ sudo yum install -y dux 
# If using dnf 
$ sudo dnf install -y dux

After installation the following directory structures will be created:
/opt/omnissa/dux/
/opt/omnissa/dux/images/
/opt/omnissa/dux/logs/

$ cd /opt/omnissa/
$ ls -ltr
drwxr-xr-x. 4 root root 32 Feb 16 17:59 dux
$ cd dux/
$ ls -ltr
total 0
drwxr-xr-x. 2 root root 6 Feb 16 13:27 logs
drwxr-xr-x. 2 root root 6 Feb 16 13:27 images
drwxr-xr-x. 2 root root 6 Feb 16 13:27 scripts
drwxr-xr-x. 2 root root 6 Feb 16 13:27 certs
$ which dux
/usr/bin/dux

Installing rpm package for Linux

Download the dux rpm as per the architecture of the host from where dux would be executed (x86_64 for AMD/Intel or aarch64 for ARM/Apple M1).
For example, if OS is Linux and Arch is amd64, the rpm dux-4.0.0.1162-1.x86_64.rpm should be downloaded.
The url to download the rpms for Dux 4.0 is as follows:
For AMD64/Intel: https://packages.omnissa.com/ws1-tunnel/dux/4.0.0/dux-4.0.0.1162-1.x86_64.rpm
For ARM64/Apple Silicon: https://packages.omnissa.com/ws1-tunnel/dux/4.0.0/dux-4.0.0.1162-1.aarch64.rpm

# 1. Import the Omnissa GPG public key (if not already imported)
$ sudo rpm --import https://packages.omnissa.com/ws1-tunnel/dux-apt/gpg.key

# 2. Download the RPM
$ wget <url to download>   # or download manually

# 3. Verify the RPM signature before installing
$ rpm --checksig dux-4.0.0.1162-1.x86_64.rpm
dux-4.0.0-1123.x86_64.rpm: digests signatures OK

# If the signature check fails (output shows MISSING KEY or BAD), do not install the package.
# Re-import the key (step 1) and re-download the RPM to rule out a corrupted download.

# 4. Install the verified RPM
$ sudo rpm -i dux-4.0.0.1162-1.x86_64.rpm
installed
$ cd /opt/omnissa/
$ ls -ltr
drwxr-xr-x. 4 root root 32 Feb 16 17:59 dux
$ cd dux/
$ ls -ltr
total 0
drwxr-xr-x. 2 root root 6 Feb 16 13:27 logs
drwxr-xr-x. 2 root root 6 Feb 16 13:27 images
drwxr-xr-x. 2 root root 6 Feb 16 13:27 scripts
drwxr-xr-x. 2 root root 6 Feb 16 13:27 certs
$ which dux
/usr/bin/dux

$ dux version
Omnissa CLI - dux
4.0.0.1162

Note: If you had an older version of Dux package installed by rpm, please ensure to delete the package before installing

sudo rpm -e <package_name>

Installing dux for Ubuntu (and Debian-based systems)

Dux for Ubuntu and other Debian-based systems is provided as a .deb package, available via the Omnissa APT repository or as a direct download.

Option 1 — Install from the Omnissa APT repository (recommended)

This method supports apt upgrade dux for future updates.

# 1. Import the Omnissa GPG public key
curl -fsSL https://packages.omnissa.com/ws1-tunnel/dux-apt/gpg.key \
  | sudo gpg --dearmor -o /usr/share/keyrings/omnissa-dux.gpg

# 2. Add the Omnissa DUX repository
echo "deb [signed-by=/usr/share/keyrings/omnissa-dux.gpg] https://packages.omnissa.com/ws1-tunnel/dux-apt stable main" \
  | sudo tee /etc/apt/sources.list.d/omnissa-dux.list

# 3. Install dux
sudo apt update
sudo apt install dux

# Verify
dux version

To upgrade dux to the latest release:

sudo apt update && sudo apt upgrade dux

To remove dux:

sudo apt remove dux

Note: /opt/omnissa/dux/ and its subdirectories (logs/, certs/, scripts/) are preserved on removal.

Option 2 — Install directly from a downloaded `.deb`

Download the package that matches your host architecture (amd64 for Intel/AMD, arm64 for ARM) from the release page.

# Replace VERSION and ARCH with actual values (e.g. 4.0.0 and amd64)
VERSION=4.0.0.1162
ARCH=amd64

curl -fsSL -o /tmp/dux.deb \
  "https://packages.omnissa.com/ws1-tunnel/dux/${VERSION}/dux_${VERSION}_${ARCH}.deb"

sudo apt install /tmp/dux.deb

# Verify
dux version

After installation, the following directory structure is created:

/usr/bin/dux — the dux binary
/opt/omnissa/dux/ — working directory
/opt/omnissa/dux/images/, /opt/omnissa/dux/logs/, /opt/omnissa/dux/certs/, /opt/omnissa/dux/scripts/

Installing dux for Mac OS

Dux can be installed on Mac OS using the package manager - brew.

$ brew tap wsonetunnel/tunnel
$ brew install dux

After installation the following directory structures will be created based on if you are using Mac on Intel (AMD64) or Mac on Apple Silicon (ARM):
For Mac OS on Intel/AMD64:
/usr/local/var/opt/omnissa/dux/
/usr/local/var/opt/omnissa/dux/images
/usr/local/var/opt/omnissa/dux/logs
/usr/local/var/opt/omnissa/dux/scripts
/usr/local/var/opt/omnissa/dux/certs

For Mac OS on Apple Silicon/ARM64:
/opt/homebrew/var/opt/omnissa/dux
/opt/homebrew/var/opt/omnissa/dux/images
/opt/homebrew/var/opt/omnissa/dux/logs
/opt/homebrew/var/opt/omnissa/dux/scripts
/opt/homebrew/var/opt/omnissa/dux/certs

# For example
$ cd /usr/local/var/opt/omnissa/dux/
$ ls -ltr
total 0
drwxr-xr-x. 2 admin admin 6 Feb 16 13:27 logs
drwxr-xr-x. 2 admin admin 6 Feb 16 13:27 images
drwxr-xr-x. 2 admin admin 6 Feb 16 13:27 scripts
drwxr-xr-x. 2 admin admin 6 Feb 16 13:27 certs
$ which dux
/usr/local/bin/dux

The default path where dux looks for Tunnel container images is the directory images based on the platform as mentioned above.
The logs of execution of dux (dux.log, tunnel snap, vpnserver logs) are stored under the directory logs based on the platform as mentioned above.
The scripts used by Dux are created under the directory scripts (for Tunnel, SEG and CG).
The default path where dux looks for certificates is the directory certs.

To update the dux version for Mac OS if you had installed an older version earlier:

brew update
brew upgrade dux

Installing dux for Windows

To install Dux for Windows, download the msi installer from the url based on the architecture:
For AMD64/Intel: https://packages.omnissa.com/ws1-tunnel/dux/4.0.0.1162/dux-windows-amd64.msi
For ARM64/Apple Silicon: https://packages.omnissa.com/ws1-tunnel/dux/4.0.0.1162/dux-windows-arm64.msi

Installation Steps

Download the MSI installer for your architecture from the URLs provided above.
Run the MSI installer.
Select an installation directory for Dux. The default installation directory is: C:\Program Files\Omnissa\Dux
Follow the on-screen instructions to complete the installation.

Post-Installation Notes

After installation, the following directory structures will be created under the selected installation directory:
<INSTALL_DIR>\images
<INSTALL_DIR>\logs
<INSTALL_DIR>\scripts
<INSTALL_DIR>\certs

Dux commands can be run from a Powershell/Command Prompt in Windows.
If Dux is installed in a protected directory (e.g., C:\Program Files), you must run PowerShell or Command Prompt as an administrator to execute Dux commands.

Usage

Check version of Dux cli

Get the version of Dux cli deployed

$ dux version 
Omnissa CLI - dux
4.0.0.1162

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, Ubuntu, 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 Tunnel 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 ts_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. Tunnel container docker image bundle (tar.gz) has to be downloaded and should be available in the host from where the cli will be run.
f. Ensure the image is available in the default path - This step is applicable only after dux is installed and the folder structure is created.
For dux on Linux:
Use /opt/omnissa/dux/images/
For dux on macOS
Use /usr/local/var/opt/omnissa/dux/images for macOS on Intel/AMD64
Use /opt/homebrew/var/opt/omnissa/dux/images/ for macOS on Apple Silicon/ARM64
For dux on Windows
Use <INSTALL_DIR>\images - where INSTALL_DIR is the directory chosen by user during installation of dux
The dux tool will use the container image from the above folder path by default. A custom folder may be used. Ensure the complete full directory path is provided in the manifest file if using a custom folder.
In the Linux VMs/hosts where Tunnel 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: false in the manifest files): Ensure that the user can execute sudo in the remote VM/host where Tunnel container needs to be deployed.
Dux will prompt for the sudo password if passwordless sudo is not configured. To avoid interactive prompts, you may configure passwordless sudo:
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.
```
Note: If passwordless sudo is not configured, Dux will prompt for the sudo password during command execution. Use the `-q` (quiet) flag to disable interactive password prompts.
```
d. Connectivity to UEM Console API.
e. Connectivity to AWCM.
f. If running cascade mode, Front-end to Back-end connection (direct or load-balanced) is required.
g. 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 Tunnel container in Dux VM
To deploy Tunnel 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 Tunnel 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, PAC (Proxy Auto Configuration) Reader, SEG (Secure Email Gateway), Content Gateway and EIC (Endpoint Integrity Check) policy engine.
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: 4
SEG manifest file successfully created at: /opt/omnissa/dux/seg_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 ts_manifest.yml was present in the default directory):

$ dux status 

Status of Tunnel 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. SEG (/opt/omnissa/dux/seg_manifest.yml)

Enter the number of the container: 2

Status of EIC containers deployed

1. Host: 192.168.84.166	
Health check: 200 OK	Version: 1.5	State: RUNNING	Policy: READY	ALLOW: BLOCK: 0

Explicitly Specifying Container Type

To avoid prompts, you can explicitly specify the container type in the command using the format:
Example:

$ dux eic status

Status of EIC containers deployed

1. Host: 192.168.84.166
Health check: 200 OK	Version: 1.5	State: RUNNING	Policy: READY	BLOCK: ALLOW: 0

For Tunnel container commands, dux commands can be specified as dux tunnel <dux_command> <args>

Steps to deploy Tunnel container

1.a. Execute init command

This command creates a sample manifest file for configuring Tunnel 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. If you wish to update a ts_manifest.yml of older version (2.2.0.247 or 2.3.0.405) please refer to the next sub-section 1.b
This command creates a sample manifest (ts_manifest.yml) and the scripts used to configure remote host for performance tuning and enabling L3 VPN feature under the directory scripts based on the platform (by default). If you wish to use a different path where the files 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: 1
Create a manifest file for configuring Tunnel container details for deployment and management

Usage:
  dux tunnel init [path] [flags]

Examples:
	dux tunnel init                             # initialize manifest under default path (/opt/omnissa/dux/)
	dux tunnel init /some/path                  # initialize manifest under the specified path
	dux tunnel init -g                          # initialize manifest using interactive TUI editor

Flags:
  -g, --gui   Launch interactive TUI editor to create manifest

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
Enter the number of the container type: 1
Directory: /opt/omnissa/dux/scripts already exists
perf_tune.sh created at /opt/omnissa/dux/scripts/perf_tune.sh
enable_l3_vpn.sh created at /opt/omnissa/dux/scripts/enable_l3_vpn.sh
Directory: /opt/omnissa/dux/certs already exists
Deployment manifest initialized successfully in /opt/omnissa/dux/

$cd /opt/omnissa/dux
abc@abc dux $ ls -ltr
total 16
drwxr-xr-x  3 abc  xyz    96 Feb 16 18:12 images
drwxr-xr-x  3 abc  xyz    96 Feb 16 18:12 certs
drwxr-xr-x  3 abc  xyz    96 Feb 16 18:12 scripts
-rw-r--r--  1 abc  xyz  2335 Feb 19 11:11 ts_manifest.yml
drwxr-xr-x  9 abc  xyz    288 Feb 19 11:11 logs

1.b Upgrade the manifest for Tunnel container

If previous Dux version (2.2.0.247 / 2.3.0.405 / 3.0.0.641 / 3.1.2.1076) is already installed and the Tunnel container manifest file has the configuration details, the manifest can be upgraded by opening it in the TUI editor with dux tunnel edit. Dux will detect the outdated version, upgrade it automatically, and open it for editing.

$ dux tunnel edit -m ./ts_2.3.orig.yml 

DUX Manifest Editor - Tunnel Server
Launching interactive editor...

Manifest backed up: ./ts_2.3.orig.yml.bak_2026-08-05_16-41-46
Manifest file generated: ./ts_2.3.orig.yml

Manifest saved: ./ts_2.3.orig.yml
Manifest updated successfully

alt text

⚠️ Critical: Before saving the upgraded manifest, press Ctrl+P immediately after the editor opens. This is required to restore the older preference settings so the form shows the correct fields from the previous manifest.

If the preferences are not updated before saving, fields controlled by those settings may be hidden and silently lost from the manifest when you press Ctrl+S.

Your original manifest is backed up automatically before it is overwritten. The backup uses a timestamped name such as ts_3.1.yml.bak_2026-08-05_16-41-46, so you can refer to it to compare the files or restore the original configuration if any issue is found after saving.

Follow these steps:

Open the upgraded manifest with dux tunnel edit -m <manifest_path>.

Press Ctrl+P to open the Preferences page.

Match the preferences to the older manifest configuration (for example, shared SSH credentials, global base directory, L3 VPN, labels, comments, and non-sudo mode).

Save the preferences in that page using Ctrl+P.

Confirm the expected fields are visible again, then save the manifest with Ctrl+S.

Note that if an outdated version of manifest is used the commands will not work as before and a warning will be presented to upgrade the manifest.

$ dux status -m ./ts_2.3.yml 
Warning: Manifest version 2.3.0.405 is outdated. Current Dux version is 4.0.0
Please update the manifest with the command: `dux tunnel edit` or `dux tunnel edit -m <manifest_path>` . Refer to `dux tunnel edit -h` for details
error="Manifest version is not same as current version. Upgrade needed"

The backup of the original manifest is saved with the timestamp so that any changes can be verified/reverted if needed.
Once the manifest is upgraded, it is recommended to check the updated manifest manually, or test if the updated manifest works fine with either a dux deploy -d command or dux status command. Please update the new manifest as needed for using a newer Tunnel container image, or use the new features supported etc.

1.c. Interactive TUI Editor (GUI mode)

Dux 4.0 introduces an interactive TUI (Text User Interface) editor for creating and editing manifests. This provides a guided form-based interface to fill in manifest fields without manually editing YAML files.

Creating a new manifest with TUI editor

Use the -g flag with init to launch the interactive editor:

$ dux tunnel init -g

The TUI editor will guide you through all required and optional manifest fields, then save the manifest to the specified path.
alt text

Navigating the TUI Editor

The TUI editor is organized into tabbed sections (e.g. Container, UEM, Hosts). A hint bar at the bottom of the screen shows the available key bindings at all times.

Key	Action
`Tab`	Move to the next field within the current section
`Shift+Tab`	Move to the previous field within the current section
`Ctrl+F`	Move to the next section (tab)
`Ctrl+B`	Move to the previous section (tab)
`Tab` on the last field of a section	Automatically advances to the next section
`Shift+Tab` on the first field of a section	Automatically moves back to the previous section
`Ctrl+S`	Save the manifest file and exit the editor
`Ctrl+D`	Dry-run: validate all fields and show warnings without saving
`Ctrl+P`	Open the Preferences page (Tunnel container only)
`Esc`	Quit the editor (prompts for confirmation if unsaved changes exist)

Saving the Manifest

Press Ctrl+S at any time to save the manifest and exit the editor. The file is written to the default path or to the path specified with -m.

If the manifest was auto-upgraded from an older version, a backup of the original file is created automatically (e.g. ts_manifest.yml.bak_<timestamp>) before saving.

Dry-Run (Validate Without Saving)

Press Ctrl+D to perform a dry-run. The editor collects the current form values, generates a temporary manifest, and validates all required fields without writing anything to disk. The result is shown in the status bar at the bottom:

Green: All required fields are populated and the manifest is valid.
Yellow: One or more warnings (e.g. missing required fields). Review and correct before saving.

Use dry-run to catch errors early before committing to a save.

Preferences Page (Tunnel container only)

Press Ctrl+P from the main editor to open the Global Preferences overlay. The Preferences page is available only when editing or creating a Tunnel container manifest.

Preferences control which optional sections and fields are shown in the TUI editor. The following options are available:

Preference	Description	Default
Use same Dux base directory on all hosts	When enabled, a single `global_base_dir` field is shown instead of a per-host field	Enabled
Device IP assignment	Enables L3 VPN and unique IP fields for device IP assignment scenarios	Disabled
Use outbound proxy to download initial configuration	Shows outbound proxy fields	Disabled
Use same SSH credential for SSH login for hosts	Shows a shared SSH credential section instead of per-host credentials	Enabled
Add extra label/tag field for each host	Shows an optional label field for each host entry	Disabled
Show comments in YML file	Includes descriptive comments in the generated manifest YAML	Disabled
Enable non-sudo mode for Dux operations	Switches Dux to non-sudo operation mode on remote hosts	Disabled

Key bindings inside the Preferences page:

Key	Action
`Tab` / `Shift+Tab`	Move between preference checkboxes
`Space`	Toggle a checkbox
`Ctrl+P`	Save preferences and return to the editor
`Esc`	Close without saving (prompts for confirmation)

When preferences are saved, the editor immediately rebuilds the form to reflect the new settings — including repopulating any fields that were previously hidden due to a preference mismatch with the original manifest data. This is why it is important to open the Preferences page and align settings before saving the manifest.

The `.preferences.yml` File

Preferences are persisted to a hidden file named .preferences.yml in the dux working directory:

Platform	Path
Linux	`/opt/omnissa/dux/.preferences.yml`
Mac OS (Intel/AMD64)	`/usr/local/var/opt/omnissa/dux/.preferences.yml`
Mac OS (Apple Silicon/ARM64)	`/opt/homebrew/var/opt/omnissa/dux/.preferences.yml`

This file is created automatically the first time a manifest is saved (if it does not already exist). The file is shared across all Tunnel container manifests on the same machine. Preferences set here apply as defaults every time the TUI editor is launched for a Tunnel container.

To reset preferences to defaults, delete the .preferences.yml file. The defaults will be applied on the next editor launch.

Editing an existing manifest with TUI editor

Use the edit command to modify an existing manifest in the TUI editor:

$ dux tunnel edit --help
Edit an existing Tunnel container deployment manifest using the interactive TUI editor

Usage:
  dux tunnel edit [flags]

Examples:
	dux tunnel edit                             # edit the default manifest
	dux tunnel edit -m /path/to/manifest.yml    # edit a specific manifest file

Flags:
  -m, --manifest-file string   Path to the manifest file to edit

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

⚠ Warning: Verify preferences before editing an existing manifest

When dux tunnel edit opens an existing manifest, it applies the current .preferences.yml settings — or built-in defaults if no preferences file exists yet — to control which fields are displayed in the form. If those preferences do not match the structure of the original manifest, the fields controlled by the mismatched preferences will be hidden, and their values will be silently dropped when the manifest is saved.

The following data is at risk if preferences do not match the manifest:

Preference setting Data lost when preference does not match the manifest

"Use same SSH credential for SSH login for hosts" is enabled Per-host ssh_user, ssh_key_path, and ssh_port values are hidden and not written on save

"Use same Dux base directory on all hosts" is enabled Per-host host_base_dir values are hidden and not written on save

"Device IP assignment" is disabled L3 VPN and unique IP fields are hidden and not written on save

"Add extra label/tag field for each host" is disabled Per-host label values are hidden and not written on save

Corrective action: Immediately after opening the editor — before making any changes or pressing Ctrl+S — press Ctrl+P to open the Preferences page. Verify that the settings reflect the structure of the manifest being edited (e.g. whether it uses per-host or global SSH credentials). Correct any mismatches, then save the preferences with Ctrl+P inside the overlay. The editor will rebuild the form and all fields will be correctly repopulated from the original manifest data.

If data is accidentally lost by saving with mismatched preferences, the original manifest is preserved in a timestamped backup file (.bak_<timestamp>) that is created automatically each time a manifest is overwritten.

Preference setting	Data lost when preference does not match the manifest
"Use same SSH credential for SSH login for hosts" is enabled	Per-host `ssh_user`, `ssh_key_path`, and `ssh_port` values are hidden and not written on save
"Use same Dux base directory on all hosts" is enabled	Per-host `host_base_dir` values are hidden and not written on save
"Device IP assignment" is disabled	L3 VPN and unique IP fields are hidden and not written on save
"Add extra label/tag field for each host" is disabled	Per-host label values are hidden and not written on save

2. Edit ts_manifest.yml

Use the TUI Editor with dux tunnel edit to view and edit the fields. You can also edit the manifest file with editor of your choice.
Please refer to the section "Points to be noted while editing ts_manifest.yml" under Troubleshooting section.

The fields in the manifest file are explained below:

image_name : Input details of tunnel container image to deploy

  # Enter the filename of the image to deploy below. 
  # This must match against the Tunnel container image filename from the default directory (refer to the note below) or the absolute path.
  # example: 29-2023.06.14-22e04910.tar.gz or /home/admin/29-2023.06.14-22e04910.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>/tunnel-server:<tag>

#Copy the bundle to the working directory
# eg. in Linux: cp ~/Downloads/23.12.14-2023.12.12-95068395.tar.gz /opt/omnissa/dux/images/
$ ls -ltr /opt/omnissa/dux/images 
total 735112
-rw-r--r--@ 1 abc  xyz  376374902 Feb 16 18:12 23.12.14-2023.12.12-95068395.tar.gz
#image_name in manifest
    image_name: 23.12.14-2023.12.12-95068395.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

container_logging: Configure logging behavior for Tunnel container

This section controls the logging behavior of the Tunnel 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"

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 Tunnel container deployment will be created for all hosts. If not specified, the default value is the home directory of the ssh user. 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 of dux for Tunnel container deployment will be created for all hosts.
  # Default is $HOME directory

  global_base_dir: $HOME

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

Fill in the IP address / host name of the host where Tunnel container needs to be deployed and the server_role (Basic/cascade-FE or cascade-BE).
If Tunnel container has to be deployed in Basic mode, the value of server_role is 0.
If Tunnel container has to be deployed as FrontEnd server, the value of server_role is 1.
If Tunnel container has to be deployed as Backend server, the value of server_role is 2.

For example:

  hosts:
   # Enter IP address of the host below
    - address: 1.2.3.4

      # The deployment role for the server. 
      # 0 - basic mode
      # 1 - cascade mode - frontend
      # 2 - cascade mode - backend
      server_role: 1

      #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:

      ## Example: subnet_range: 192.168.4.0/23
      #subnet_range:

      # Default is $HOME directory. If all hosts have common base directory, you may use the global parameter - 'global_base_dir'
      #host_base_dir: $HOME

      # Optional host label for grouping/filtering with command options like --label
      #label:

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:

subnet_range: Define Subnet range for Unique IP per device connection

To use the Unique IP per device connection feature supported from Tunnel container version 24.10 onwards, the subnet_range parameter can be defined per host. Note that this parameter should to be added only if the deployment role of the Tunnel container is basic or backend.
For example:

      ## If the deployment role for the server is basic/backend, please enter the CIDR for the IP range for devices corresponding to this Tunnel container deployment
      ##
      ## Example: subnet_range: 192.168.4.0/23

      subnet_range: 192.168.8.0/23

multi_nic_external_ip: If Multiple NICs are configured, specify the IP of the external NIC

If the customer needs to use a 2 NIC configuration - where one NIC is needed for unauthenticated traffic (External NIC) and another NIC for authenticated back-end traffic (Internal IP/host address), the provisioning needs to be done on the VM where tunnel container is to be deployed.
Dux will be running on a host in the Internal network, hence would be using the Internal IP for communication. The external IP can be given in the manifest using the parameter multi_nic_external_ip.
From Dux, the following security assessments would be done during deploy dry-run / deploy command to ensure security is not compromised if external IP is configured:

Verify SSH is Not Listening on External IP - To ensure SSH is not accessible via the external IP on your machine, SSH should be configured to only listen on specific interfaces (internal IP, or 127.0.0.1 or any IPs explicitly configured) and not on all interfaces - 0.0.0.0 or external IP
Port Scan for External IP : Ensure port 22 (the default SSH Port) is not open in the External IP

To specify the external IP, uncomment the multi_nic_external_ip parameter:

      # If external NIC is configured in the host machine where Tunnel container is deployed,
      # please specify the details of external IP of NIC2
      multi_nic_external_ip:

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 Tunnel 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 Tunnel container deployment on this specific host will be created under /home/admin/dux/.

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

perf_tune: Tune performance parameters/system configuration in remote host to support larger number of connections

If remote host has to be tuned with performance parameters, the value of perf_tune is 1 which is by default. This will execute perf_tune.sh in remote host.
If the user does not want to modify the system configuration in remote host, the value of perf_tune is 0.
For example:

# Tune performance parameters/system configuration in remote host to support larger number of connections
  # 1  - execute perf_tune.sh in the remote host
  # 0  - do not modify system configuration in remote host
  perf_tune: 1

Note about perf_tune.sh script
Note that the perf_tune.sh script is designed to optimize the network and file system parameters of a Tunnel container deployment host machine, enabling it to handle a larger number of connections and improve overall performance.
The changes made by the script are applied immediately and made persistent across reboots by saving the updated kernel parameters to a configuration file (/etc/sysctl.d/tunnel.conf).
The script requires sudo permissions to run. If the user prefers not to have the CLI automatically execute this script, they can manually run it on the remote host and set the perf_tune parameter to 0 in the configuration to disable automatic execution.

enable_l3_vpn: Enable Layer 3 IP-based VPN

To enable Layer 3 (L3) VPN in the Tunnel container, set the enable_l3_vpn parameter to 1 in the ts_manifest.yml file. This feature is supported only on the Windows platform with Tunnel Client version 25.11 or later.

When this parameter is enabled, Dux will execute the enable_l3_vpn.sh script on the remote host to configure IP forwarding at the interface level and update the firewall settings.

Important Notes:

This setting applies only to hosts with server_role configured as 0 (Basic mode) or 2 (Backend).
If the kernel module for TUN is not enabled, the script will automatically enable it at the kernel level and make the changes persistent. A system reboot is required for these changes to take effect, and you will be prompted accordingly.

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.

# Make vpnserver container persistent across reboots
sudo podman generate systemd --name vpnserver --files --new
sudo cp container-vpnserver.service /etc/systemd/system/
sudo chown root:root /etc/systemd/system/container-vpnserver.service
sudo chmod 644 /etc/systemd/system/container-vpnserver.service
sudo restorecon -v /etc/systemd/system/container-vpnserver.service
sudo systemctl daemon-reload
sudo systemctl enable container-vpnserver.service
sudo systemctl start container-vpnserver.service
sudo systemctl status container-vpnserver.service

If the perf_tune parameter is not enabled in the manifest, the enable_l3_vpn option will not take effect, as it indicates that the user does not wish to modify system settings through Dux. In such cases, the user can manually execute the commands from the enable_l3_vpn.sh script on the remote host.

  # Enable Layer 3 IP based VPN (currently supported only on Windows platform with Tunnel Client 25.11 or later versions)
  enable_l3_vpn: 0

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 if outbound proxy is not in DNS in remote network ) 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, Group Id/ tunnel configuration id, user name of the OG needs to be input in this section.
If tunnel_config_id is left blank, the organization Group ID is used to fetch the configuration.
Note that the tunnel_config_id parameter is supported only if UEM console supports multi-tunnel configuration feature which is from UEM Console version-23.06 onwards. If you are using an older UEM console version, please user group_id field.
Dux 3.0 supports specifying parameters to connect to Workspace ONE UEM API Server using OAuth.
Dux 3.0 supports specifying parameters to reach to UEM through Outbound proxy. Note that this is only used for the initial config download from UEM, the device traffic uses the Outbound proxy settings in Server traffic rules of UEM Console.

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: https://wns-1.ssdevrd.com

  # Omnissa Tunnel Configuration ID configured in the Workspace ONE UEM Console.
  # This field is supported only if the UEM console supports multi-tunnel configuration feature (from UEM Console version 23.06 onwards).
  # If left blank, default configuration from the specified organization group will be fetched.
  tunnel_config_id: 27bff2e3-4c81-4c1a-a955-7de6b44c75be

  # The organization group ID in Workspace ONE UEM Console where Tunnel is configured.
  group_id:

  admin:
    # Starting with Tunnel container version 25.03, OAuth is the recommended authentication method
    # for securely connecting to the Workspace ONE UEM API server. This authentication method
    # provides improved security and scalability.
    #
    # Important: Older versions of the Tunnel container do not support OAuth. To maintain compatibility
    # ensure you use a version of DUX that support OAuth deployment. 
    oauth:
      # Client ID to download config from the Workspace ONE UEM API server.
      client_id: 41cbcadbe64e48d3b0be792cc2cd238d

      # Client Secret to download config from the Workspace ONE UEM API server.
      client_secret: 28C18ACFDAC1D0ED39E497D7C2BDD822

      # Oauth token Service endpoint url to download bearer token using Client ID and Client Secret.
      token_service_url:

    # Basic authentication is planned for deprecation in a future version due
    # to security concerns. It is recommended to use OAuth for authentication instead.
    #basic_auth:
      # The username to authenticate with the Workspace ONE UEM API server.
      #username:


  # Add details if Outbound Proxy needs to be configured to reach to UEM.
  outbound_proxy:
    # Format:
    # proxy_host - <http/https>://<hostname/ip>
    # If protocol is not specified, default value is http
    proxy_host: 
    # proxy_port - proxy port number. If not specified, default value is 80 for http and 443 for https
    proxy_port:
    # Outbound Proxy user name for proxy authorization; This optional field can be enabled by uncommenting the `proxy_user` parameter below.
    #proxy_user:

permissions: Command Permissions Configuration

The permissions section in the ts_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 ts_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 Tunnel 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 ts_manifest.yml present in the default directory to deploy and manage Tunnel containers. Hence the commands are in format : dux <command> <args> format

3. Execute deploy command

Once the manifest is updated, deploy command can be run to deploy the Tunnel container in the hosts specified.

deploy help

$ dux deploy -h
Deploy Tunnel containers

Usage:
  dux tunnel 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
  -l, --label string                     Filter hosts by label
  -m, --manifest-file string             Custom manifest file path (default "/opt/omnissa/dux/ts_manifest.yml")
  -n, --node-number stringArray          Node number as listed in manifest to deploy on a single host
  -o, --outbound-proxy-password string   Password to authenticate with the Outbound Proxy 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. ts_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. Reachability check to API and AWCM endpoints

$ dux deploy -d
Manifest file syntax validation is successful
⚠️  Non-sudo operations enabled for: File operations, System commands, Network commands
Host 192.14.84.166: using base dir /home/user1. Ensure user 'user1' has appropriate permissions for the directory (/home/user1)
Verifying Tunnel container image location given in manifest: 24.10.457-2024.11.22-15ba0f7.tar.gz

Verifying deployment prerequisites on 192.14.84.166
Verifying docker is installed and running on 192.14.84.166

Checking open SSH connections to confirm SSH is configured securely
Warning: SSH is listening on all interfaces (0.0.0.0)
Warning: SSH is listening on all interfaces (::)
Please act on the warning messages to ensure security is not compromised

Checking for host working directory: /home/user1

Checking for availability of sufficient free disk space in the host working directory: /home/user1

Checking if IPV6 module is loaded/enabled in host: 192.14.84.166
IPV6 module is enabled in host: 192.14.84.166
Host 192.14.84.166 is good to deploy
Manifest file and hosts are good to deploy!

#In case of error in the manifest, for example, if tunnel_config_id was not filled up, you may get an error like below:
$ dux deploy -d
Manifest verification failed error="Incorrect data in manifest: the group_id field is required if tunnel_config_id is not 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 Tunnel containers in the hosts in the order as listed in manifest, and as per the UEM configuration defined. 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 Tunnel 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      
Enter UEM password: 
Warning: Using password-based authentication for fetching configuration from UEM. Consider switching to OAuth for improved security.
The perf_tune option has been enabled in the manifest. The perf_tune script will modify the Tunnel container host machines to provide recommended performance settings. Do you want to run the perf_tune script? (y/n): y

Checking open SSH connections to confirm SSH is configured securely
Warning: SSH is listening on all interfaces (0.0.0.0)
Warning: SSH is listening on all interfaces (::)

There are some warnings in the security assessment. Do you wish to continue with deployment (y/n): y

Preparing for Tunnel container deployment on 192.14.84.166
Copying Tunnel container image to remote. Please wait..
Progress 100% |██████████████████████████████████████████████████████████████████████████████████████| (376/376 MB, 7.5 MB/s)         
Deploying new Tunnel container on 192.14.84.166....                                                                              
5a3cfd0f45741379e0a61e8c4847eebeb75043e94d2b74d5c1cf97015cfa0fdf

Checking if Tunnel container is running on 192.14.84.166....
Fetching the deployment status. Please wait. This may take some time... \
Node number(n): 1        Version: 25.06.el9.992          CPU:   8.02%    Memory:  1221.984 MB   Devices: 0      Cascade: back-end       Status: Running
Deployment is up!

Deploy command has completed on 192.14.84.166

——

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


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


#### To deploy Tunnel container in specific/few remote hosts 
To deploy Tunnel containers in few remote hosts specified by ip, node-number or label.


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

#### To give UEM password as command line option:
$ dux deploy -u <uem_password>

Perform operations on deployed Tunnel containers

Once the deployment of containers is successful, other commands can be used to check status of deployment, fetch logs, run vpnreport on container, 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 Tunnel containers deployed

Usage:
  dux tunnel status [flags]

Flags:
  -p, --ip stringArray            Hostname or IP as specified in the manifest for filtering
  -j, --json                      Get status of Tunnel containers in json format
  -l, --label string              Filter hosts by label
  -m, --manifest-file string      Custom manifest file path (default "/opt/omnissa/dux/ts_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. In this case, one of the deployments is not in Running state, hence shows Down as status
$ dux status 

Status of Tunnel containers deployed

1. Host: 192.14.84.166  Node number(n): 1        Version: 23.12.ph4.14   CPU:   6.97%    Memory:  1137.129 MB   Devices: 0 Cascade: off             Status: Running
2. Host: 192.168.99.180 Status: Not Deployed

#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 192.14.132.110 

Status of Tunnel containers deployed

1. Host: 192.14.84.166  Node number(n): 1         Version: 23.12.ph4.14   CPU:   0.00%    Memory:  1157.281 MB   Devices: 0      Cascade: off            Status: Running


#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             

Status of Tunnel containers deployed

1. Host: 192.14.84.166  Node number(n): 1         Version: 23.12.ph4.14   CPU:   0.00%    Memory:  1157.281 MB   Devices: 0      Cascade: off            Status: Running

#Get status in a json string format for processing 
$ dux status -j               
{
    "command": "status",
    "values": [
        {
            "CPU": "0",
            "Cascade": "off",
            "Devices": "0",
            "Host": "192.14.84.166",
            "Memory": "1157.2812",
            "Node number": "1",
            "Status": "Running",
            "Version": "23.12.ph4.14"
        },
        {
            "CPU": "Unknown",
            "Cascade": "Unknown",
            "Devices": "Unknown",
            "Host": "192.168.99.180",
            "Memory": "Unknown",
            "Node number": "2",
            "Status": "Not Deployed",
            "Version": "Unknown"
        }
    ]
}

2.Run vpnreport on deployed container(s)

Vpnreport can be fetched from the deployed container(s) using dux show report.

#show report help
$ dux show report -h
Fetch vpnreport of a Tunnel container

Usage:
  dux tunnel show report [flags]

Flags:
  -j, --json          Get vpnreport in json format
  -r, --rows string   Range of rows from vpnreport to be printed for the nodes: e.g if rows 10-20 need to be printed, specify option as -r 10-20

Global Flags:
  -h, --help                      Print help information
  -p, --ip stringArray            Hostname or IP as specified in the manifest for filtering
  -l, --label string              Filter hosts by label
  -m, --manifest-file string      Custom manifest file path (default "/usr/local/var/opt/omnissa/dux/ts_manifest.yml")
  -n, --node-number stringArray   Node number as listed in manifest for filtering
  -q, --quiet                     Quiet mode: interactive ssh password prompts are disabled
  -v, --verbose                   Show verbose logs


#To get vpnreports of all containers, give the command "dux show report" 
# Sample run
$ dux show report

Vpnreport of Tunnel containers deployed

1. Host: 192.14.84.166
Tunnel Version:      23.12.ph4.14                                     
Console Version:     23.10.0.0                                     
Operating System:    Omnissa Photon OS/Linux                                     
MultiTunnel Config:  Tunnel Config                         
# of Devices:        0         Peak:      2                     
A: 0  iOS: 0  Mac: 0  Win: 0  Lnx: 0  Others: 0  SDK: 0    
# of Connections:    0         Peak:      0                     
# of Traffic Rules:  1         Enabled:   Yes                   
# of Proxies:        0         Up:        0         Down: 0      
API Connectivity:    Up        Last Resp: 200 OK                 
AWCM Connectivity:   Up        Last Resp: 200 OK                 
API via Traf Rules:  No                                    
Cascade Mode:        Off       Reverse Connect:     No             
KCD Proxy Support:   No        Config Locked:       No          
TLS Port Sharing:    No        Deployment Mode:     QA          
FIPS Mode:           No        NSX Mode:            No          
ZTNA DTR:            Yes       ZTNA PDTR:           No           
# of ZTNA DTR:       0         # of ZTNA PDTR:      0            
Appliance Mode:      No        Container Mode:      Yes          
MFA:                 Off       JWT:                 No                         
Service Status:      Up                                         
Log Lvl:             Debug                                 
SOCKS Downstream:       0.000 Kbps                         
SOCKS Upstream:         0.000 Kbps                         
NAT Downstream:         0.000 Kbps                         
NAT Upstream:           0.000 Kbps                         
Total Downstream:       0.000 Kbps                         
Total Upstream:         0.000 Kbps                         
CPU 1:  0.00%% CPU 2:  2.97%%                              
Average CPU:             1.06 %%                           
Memory Virtual:      1157.281 MB                           
Memory Resident:       77.879 MB                           
Memory Share:          15.461 MB                           
Certificate Expiry Info                                    
Server cert:        Sep 25,2025                            
API cert:           Sep 20,2042                            
Client cert:        Sep 20,2042                            
API Last Sync:        2024-02-19 12:50:04                    
AWCM Last Sync:       2024-02-19 12:56:55                    
Up Time:              3d 0h 8m 22s                         
# of Allowlisted Devices:          1                       
# of Devices Since Start:          0                       
  Using DTLS:                      0                       
# of Device Failures                                       
  Closed Handshake:                0                       
  Failed Handshake:                104                     
  Rejected due to DDoS Protection: 0                       
  Blocked due to ZTNA Policy:      0                       
  Blocked by Admin:                0                       
  Unable to Connect to BackEnd:    0                       
  Device Not in Allowlist:         0                       
  Device Non-Compliant:            0                       
  Device Non-Managed:              0                       
Outbound Traffic Since Start                               
  # of Successful Connections:     0                       
  # of Failed Connections:         0                       
  # of Blocked by ZTNA:            0                       
  # Using Proxy:                   0                       
  # Not Using Proxy:               0                       
# of Flows by Device Type                                  
  iOS:         0                                           
  Android:     0                                           
  Windows:     0                                           
  MacOS:       0                                           
  Linux:       0                                           
  Others:      0                                           
# of Flows from SDK Bundled App:  0                        
# of Flows by Protocol                                     
  TCP:                             0                       
  UDP:                             0                       
    Connected UDP:                 0                       
    Connectionless UDP:            0                       
    Per Device UDP Limit:          1321                    
Popular Apps                             TCP   UDP   PKT   
  1.                                     0     0     0     
  2.                                     0     0     0     
  3.                                     0     0     0     
  4.                                     0     0     0     
  5.                                     0     0     0     
  6.                                     0     0     0     
  7.                                     0     0     0     
  8.                                     0     0     0     
Devices with Most Traffic                TCP   UDP   PKT   
  1.                                     0     0     0     
  2.                                     0     0     0     
  3.                                     0     0     0     
  4.                                     0     0     0     
  5.                                     0     0     0     
  6.                                     0     0     0     
  7.                                     0     0     0     
  8.                                     0     0     0     
Top Destinations                         TCP   UDP   PKT   
  1.                                     0     0     0     
  2.                                     0     0     0     
  3.                                     0     0     0     
  4.                                     0     0     0     
  5.                                     0     0     0     
  6.                                     0     0     0     
  7.                                     0     0     0     
  8.                                     0     0     0     

2. Host: 192.168.99.180 Status: Not Deployed

# To filter few row numbers from the output give -r/--rows option
$ dux show report -r 6-10 
Displaying rows:6 7 8 9 10 
Vpnreport of Tunnel containers deployed

1. Host: 192.14.84.166
A: 0  iOS: 0  Mac: 0  Win: 0  Lnx: 0  Others: 0  SDK: 0    
# of Connections:    0         Peak:      0                     
# of Traffic Rules:  1         Enabled:   Yes                   
# of Proxies:        0         Up:        0         Down: 0      
API Connectivity:    Up        Last Resp: 200 OK                 
2. Host: 192.168.99.180 Status: Not Deployed

# To fetch row numbers 1,6, and 10 from all hosts
$ dux show report -r 1,6,10
Displaying rows:1 6 10 
Vpnreport of Tunnel containers deployed

1. Host: 192.14.84.166
Tunnel Version:      23.12.ph4.14                                     
A: 0  iOS: 0  Mac: 0  Win: 0  Lnx: 0  Others: 0  SDK: 0    
API Connectivity:    Up        Last Resp: 200 OK                 
2. Host: 192.168.99.180
Tunnel Version:      23.12.ph4.14                                     
A: 0  iOS: 0  Mac: 0  Win: 0  Lnx: 0  Others: 0  SDK: 0    
API Connectivity:    Up        Last Resp: 204 No Content     

## To get vpnreport output as json format for processing use -j option
# For example:
$ dux show report -j

## To get vpnreport of a node-number or ip use -n or -p option as the other commands
# For example
$ dux show report -n 1
$ dux show report -p 192.14.142.143

3.Fetch logs from the deployed containers

Fetch tunnel_snap 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 Tunnel container deployed till Ctrl-C is given.

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

Usage:
  dux tunnel logs [flags]

Flags:
  -f, --follow                    Follow/View logs of a Tunnel container specified by node-number (-n) or ip (-p) option
  -p, --ip stringArray            Hostname or IP as specified in the manifest for filtering
  -l, --label string              Filter hosts by label
  -m, --manifest-file string      Custom manifest file path (default "/opt/omnissa/dux/ts_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 
Retrieve vpnserv logs from 192.14.84.166
Copy log bundle from Remote to Local machine..
Logs from 192.14.84.166 downloaded at: /opt/omnissa/dux/logs/tunnel_snap.192.14.84.166_20240219184004.tar.gz

Retrieve vpnserv logs from 192.168.99.180
Copy log bundle from Remote to Local machine..
Logs from 192.168.99.180 downloaded at: /opt/omnissa/dux/logs/tunnel_snap.192.168.99.180_20240219184036.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

4.Stop deployed containers

In case a Tunnel container needs to be stopped for some reason, dux stop command can be given.

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

Usage:
  dux tunnel stop [flags]

Flags:
  -p, --ip stringArray            Hostname or IP as specified in the manifest for filtering
  -l, --label string              Filter hosts by label
  -m, --manifest-file string      Custom manifest file path (default "/opt/omnissa/dux/ts_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 Tunnel containers deployed in all the hosts given in the manifest? 
ip : 192.14.84.166 node-number : 1
ip : 192.14.132.197 node-number : 2 
Please confirm (y/n): y
Tunnel container was successfully stopped on 192.14.84.166
Tunnel container was successfully stopped on 192.14.132.197


#Deployment of Tunnel 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

5.Restart deployed containers

Stopped containers can be restarted by dux restart command

#restart help
$ dux restart -h
Restart the Tunnel container on given hosts

Usage:
  dux tunnel restart [flags]

Flags:
  -p, --ip stringArray            Hostname or IP as specified in the manifest for filtering
  -l, --label string              Filter hosts by label
  -m, --manifest-file string      Custom manifest file path (default "/opt/omnissa/dux/ts_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 Tunnel containers deployed in all the hosts given in the manifest? 
ip : 192.14.84.166 node-number : 1
ip : 192.14.132.197 node-number : 2 
Please confirm (y/n): y
Tunnel container was successfully restarted on 192.14.84.166
Tunnel container was successfully restarted on 192.14.132.197

#Deployment of Tunnel 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

6.Destroy deployed containers

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

#destroy command help
$ dux destroy -h
Destroy the Tunnel containers on the given hosts

Usage:
  dux tunnel destroy [flags]

Flags:
  -p, --ip stringArray            Hostname or IP as specified in the manifest for filtering
  -l, --label string              Filter hosts by label
  -m, --manifest-file string      Custom manifest file path (default "/opt/omnissa/dux/ts_manifest.yml")
  -n, --node-number stringArray   Node number as listed in manifest for filtering
  -q, --quiet                     Quiet mode: interactive ssh password prompts are disabled
  -t, --stop-timeout int          Seconds to wait for graceful shutdown before SIGKILL (docker stop -t) (default 10)
  -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 Tunnel containers deployed in all the hosts given in the manifest? 
ip : 192.14.84.166 node-number : 1
ip : 192.14.132.197 node-number : 2 
Please confirm (y/n): y
Tunnel container was successfully destroyed on 192.14.84.166
Tunnel container was successfully destroyed on 192.14.132.197


#Deployment of Tunnel  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

7. Log-override in Tunnel container

To change the log level in Tunnel container, use the log-override command.
Note that this feature to change log-level from the one set in UEM console is supported in Tunnel container from 23.12 onwards.

$ dux log-override  -h
Override log level in one or more Tunnel containers deployed

Usage:
  dux tunnel log-override [flags]

Flags:
  -c, --clear                     Restore log level to default value set by UEM Console
  -d, --duration int              Duration in minutes for the log level override; -1 to set log level indefinitely (default 30)
  -p, --ip stringArray            Hostname or IP as specified in the manifest for filtering
  -l, --log-level int             Desired log level to be set (1-Error, 2-Warn, 3-Info, 4-Debug)
  -m, --manifest-file string      Custom manifest file path (default "/opt/omnissa/dux/ts_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

  # Some examples below
  # To set log-level to Debug (4) for 10 mins
  $ dux log-override -n 1 -l 4 -d 10

  Are you sure you want to set log level in the Tunnel containers deployed in the following hosts to "Debug" for 10 mins? 
  ip : 192.14.84.166 node-number : 1 
  Please confirm (y/n): y
  Log-level was succesfully set to "Debug" in Tunnel container on 192.14.84.166

  # To set log-level to Debug (4) (default 30 mins)
  $ dux log-override -n 1 -l 4      

  Are you sure you want to set log level in the Tunnel containers deployed in the following hosts to "Debug" for 30 mins? 
  ip : 192.14.84.166 node-number : 1 
  Please confirm (y/n): y
  Log-level was succesfully set to "Debug" in Tunnel container on 192.14.84.166

  # To set log-level to Info (3) for indefinite time with auto-accept 
  $ dux log-override -n 1 -l 4 -d -1 -y
  Log-level was succesfully set to "Debug" in Tunnel container on 192.14.84.166
  # To clear log-level set / restore to default value set by UEM Console - for all hosts
  $ dux log-override -c

  Are you sure you want to clear log override on all the Tunnel containers deployed? (y/n): y
  Restored log level to default value set by UEM Console on 192.14.84.166
  Restored log level to default value set by UEM Console on 192.14.132.197

8. Get verbose logs

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

$ dux deploy -v

9. Open interactive shell with tunnel container

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

$ dux exec-shell -h
Open interactive shell with Tunnel container

Usage:
  dux tunnel 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/ts_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

$ dux exec-shell -n 1

Starting the interactive shell with container 192.14.84.166 vpnserver
[root@centos81 vpnd]# pwd
pwd
/opt/omnissa/tunnel/vpnd
[root@centos81 vpnd]# ls
ls
awcm.ca
awcm.crt
awcm.key
ca.pem
client_config.conf
dh2048.pem
entrypoint
gmon.out
ipv6_history.json
report.conf
server.conf
traffic_rules.xml
tunnel_snap.tar.gz
unique_ip_history.json
vpn.crt
vpn.key
vpnreport
vpnserv

10. Show system and container diagnostics

The dux show command provides various diagnostic sub-commands for inspecting the state of Tunnel hosts and containers. This is useful for debugging deployment issues.

$ dux show --help
Show system and container diagnostics for Tunnel hosts

Usage:
  dux tunnel show [command]

Available Commands:
  cert         Show TLS certificate status for the Tunnel container
  disk         Show root filesystem disk usage of Tunnel hosts
  dns          Show DNS configuration or resolve a hostname from the Tunnel container
  docker       Show Docker statistics for the Tunnel container
  network      Show network interface statistics for Tunnel hosts
  process      Show host load average and top CPU processes
  reachability Check reachability of the Tunnel container to API, Backend, and DNS servers
  report       Fetch vpnreport of a Tunnel container

Flags:
  -p, --ip stringArray            Hostname or IP as specified in the manifest for filtering
  -l, --label string              Filter hosts by label
  -m, --manifest-file string      Custom manifest file path (default "/opt/omnissa/dux/ts_manifest.yml")
  -n, --node-number stringArray   Node number as listed in manifest for filtering

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

# Examples:
$ dux show disk -n 1
$ dux show cert -p 192.14.84.166
$ dux show reachability
$ dux show docker -l prod

11. Enhanced supportability to search and list records from Tunnel container logs

The dux list command is used to search and list sessions, flows, alerts, or allowlist records from Tunnel server container logs. It provides various filtering options to narrow down the results based on user, destination, time range, and more.

$ dux list --help
List/search sessions, flows, alerts or allowlist from Tunnel container logs

Usage:
  dux tunnel list [flags]

Flags:
  -l, --alert                     List alerts from Tunnel container logs
  -a, --all                       List alerts, sessions and flows from Tunnel container logs
  -c, --allowlist-cache           List allowlist cache from Tunnel container
  -d, --dest string               List records matching a destination from Tunnel container logs
  -e, --end string                End time range for searching records from Tunnel container logs. Use RFC-3339 UTC time format e.g. 2023-12-31T15:00:00Z
  -f, --flow                      List flows from Tunnel container logs
  -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/ts_manifest.yml")
  -o, --no-space-footer           List records without adding whitespaces
  -n, --node-number stringArray   Node number as listed in manifest for filtering
  -q, --quiet                     Quiet mode: interactive ssh password prompts are disabled
      --sbac                      Search SBAC log records; optionally filter by --user using a username or UDID
  -s, --session                   List sessions from Tunnel container logs
  -t, --start string              Start time range for searching records from Tunnel container logs. Use RFC-3339 UTC time format e.g. 2023-12-31T15:00:00Z
  -u, --user string               List records matching a user from Tunnel container logs

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

Examples

List all records (alerts, sessions, and flows):
```
dux list --all
```
List allowlist cache along with all records only for node number 1:
```
dux list --allowlist-cache -n 1
```
Filter records by destination:
```
dux list --dest www.example.com
```
Filter records by user:
```
dux list --user john
```

Search SBAC records for a username or UDID:

dux tunnel list --sbac --user john
dux tunnel list --sbac --user 3E546123AB13094FA7856DABDD16F448

Filter SBAC records within a specific time range:

dux tunnel list --sbac --user john --start 2025-03-20T04:00:00Z --end 2025-03-20T05:00:29Z

Filter alerts within a specific time range:

dux list --alert --start 2025-03-20T04:00:00Z --end 2025-03-20T05:00:29Z

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. The CRUD logs for dux (i.e container operations related commands like deploy, destroy, stop, restart) can be found in the file dux-audit.log under logs directory as per the platform - for e.g /opt/omnissa/dux/logs/dux-audit.log in Linux.
If docker is installed with snap in the Linux system, you may encounter permission issues during deployment of Tunnel containers.
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 deploying with Basic Auth for UEM API authentication/ Outbound proxy authentication, always wrap your password in single quotes when using command-line options. 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 and the -o parameter for Outbound Proxy 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 ts_manifest.yml, please refer to the following guide:

Points to be noted while editing ts_manifest.yml file

Open the YAML File
- Right-click on the ts_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.
- The edit command is an easier option to view and edit the manifest file.
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: TunnelContainer_23.12.1.7.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 ts_manifest.yml file for reference

# Version number for the Tunnel container deployment manifest. This is auto generated and should not be altered.
version: "4.0.0.1162"


# 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
  

  # Omnissa Tunnel Configuration ID configured in the Workspace ONE UEM Console.
  # This field is supported only if the UEM console supports multi-tunnel configuration feature (from UEM Console version 23.06 onwards).
  # If left blank, default configuration from the specified organization group will be fetched. 
  tunnel_config_id: cafa5265-2e0f-4506-920e-f07f4b9esdsd

  # The organization group ID in Workspace ONE UEM Console where Tunnel is configured.
  group_id: 

  admin:
    # Starting with Tunnel container version 25.03, OAuth is the recommended authentication method
    # for securely connecting to the Workspace ONE UEM API server. This authentication method
    # provides improved security and scalability.
    #
    # Important: Older versions of the Tunnel container do not support OAuth. To maintain compatibility
    # ensure you use a version of Tunnel container that support OAuth deployment.
    oauth:
      # Client ID to download config from the Workspace ONE UEM API server.
      client_id: 41cbcadbe64e48d3b0be792cc2cd23dd

      # Client Secret to download config from the Workspace ONE UEM API server. 
      client_secret: 28C18ACFDAC1D0ED39E497D7C2BDD8AA
      
      # Oauth token Service endpoint url to download bearer token using Client ID and Client Secret.
      token_service_url: 

    # Basic authentication is planned for deprecation in a future version due
    # to security concerns. It is recommended to use OAuth for authentication instead. 
    #basic_auth:
      # The username to authenticate with the Workspace ONE UEM API server. 
      #username:


  # Add details if Outbound Proxy needs to be configured to reach to UEM. 
  outbound_proxy:
    # Format: 
    # proxy_host - <http/https>://<hostname/ip>
    # If protocol is not specified, default value is http 
    proxy_host: 
    # proxy_port - proxy port number. If not specified, default value is 80 for http and 443 for https 
    proxy_port: 
    # Outbound Proxy user name for proxy authorization; This optional field can be enabled by uncommenting the `proxy_user` parameter below. 
    #proxy_user:


#Tunnel container Image Information 
tunnel_server:
  # Enter the filename of the image or the repo path to deploy below.
  # File: This must match against the Tunnel container image filename from the default directory (refer to the note below) or the absolute path.
  # example: 29-2023.06.14-22e04910.tar.gz or /home/admin/29-2023.06.14-22e04910.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>/tunnel-server:<tag> 
  image_name: TunnelContainer_25.06.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: 
    # Input the path of ssh key - e.g /home/admin/id_rsa 
    ssh_key_path: 
    ## 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

  # Enable Layer 3 IP based VPN (currently supported only on Windows platform with Tunnel Client 25.11 or later versions) 
  enable_l3_vpn: 0

  # Container Logging Configuration
  # These parameters control how Docker will maintain the container logs to limit its disk usage on the host machine. 
  # 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"

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

      # The deployment role for the server. 
      # 0 - basic mode
      # 1 - cascade mode - frontend
      # 2 - cascade mode - backend 
      server_role: 0

      ######################################################################
      ## THE FOLLOWING ARE OPTIONAL PARAMETERS FOR TUNNEL 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.
      ## If all hosts have common ssh credential info/ssh port info, you may use the global parameter: 'ssh_login_credentials'  
      ## If both 'host_info' and 'ssh_login_credentials' are given, the credentials under 'host_info' are preferred.
      
      ## 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: user1
        ## Input the path of ssh key - e.g /home/admin/id_rsa
        ssh_key_path: /home/user1/.ssh/id_rsa
        ## For security reasons, the ssh_password is not recommended. 
        #ssh_password: 
        ## Input the ssh port. Default value - 22
        #ssh_port:

      ## Define Subnet range for Unique IP per device connection (Please note this feature is supported from Tunnel container version 24.10 onwards)
      ## If the deployment role for the server is basic/backend, please enter the CIDR for the IP range for devices corresponding to this Tunnel container deployment
      ##
      ## Example: subnet_range: 192.168.4.0/23
      
      #subnet_range:

      # Base directory for dux under which all directories of dux for Tunnel container deployment will be created.
      # Default is $HOME directory of the ssh user. If all hosts have common working directory, you may use the global parameter - 'global_base_dir'
      #host_base_dir: $HOME

      # Optional host label for grouping/filtering with command options like --label
      #label:


  # Tune performance parameters/system configuration in remote host to support larger number of connections
  # 1  - execute perf_tune.sh in the remote host
  # 0  - do not modify system configuration in remote host 
  perf_tune: 1


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

  # 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
    

# 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: 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

dux (Omnissa CLI)

Table of Contents

Installation

Installing dux for Linux

Installing rpm package for Linux

Installing dux for Ubuntu (and Debian-based systems)

Option 1 — Install from the Omnissa APT repository (recommended)

Option 2 — Install directly from a downloaded .deb

Installing dux for Mac OS

Installing dux for Windows

Installation Steps

Post-Installation Notes

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 Tunnel container

1.a. Execute init command

1.b Upgrade the manifest for Tunnel container

1.c. Interactive TUI Editor (GUI mode)

Creating a new manifest with TUI editor

Navigating the TUI Editor

Saving the Manifest

Dry-Run (Validate Without Saving)

Preferences Page (Tunnel container only)

The .preferences.yml File

Editing an existing manifest with TUI editor

2. Edit ts_manifest.yml

image_name : Input details of tunnel container image to deploy

ssh_login_credentials

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

container_logging: Configure logging behavior for Tunnel container

global_base_dir: Specify the global working directory for dux

hosts: Input docker host information for Tunnel 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.

subnet_range: Define Subnet range for Unique IP per device connection

multi_nic_external_ip: If Multiple NICs are configured, specify the IP of the external NIC

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

perf_tune: Tune performance parameters/system configuration in remote host to support larger number of connections

enable_l3_vpn: Enable Layer 3 IP-based VPN

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

Perform operations on deployed Tunnel containers

1.Check status of deployment

2.Run vpnreport on deployed container(s)

3.Fetch logs from the deployed containers

4.Stop deployed containers

5.Restart deployed containers

6.Destroy deployed containers

7. Log-override in Tunnel container

8. Get verbose logs

9. Open interactive shell with tunnel container

10. Show system and container diagnostics

11. Enhanced supportability to search and list records from Tunnel container logs

Examples

Troubleshooting

Passwords with Special Characters

Resolving ANSI Characters Display Issue in Windows PowerShell

Points to be noted while editing ts_manifest.yml file

Option 2 — Install directly from a downloaded `.deb`

The `.preferences.yml` File