This document contains commands to deploy and manage SEG (Secure Email Gateway) containers using dux CLI.
Dux can be installed on Linux, Mac OS and Windows. For instructions on installing Dux, please refer to the README.html - https://packages.omnissa.com/ws1-tunnel/dux/3.1.0.886/README.html
Get the version of Dux cli deployed
$ dux version
Omnissa CLI - dux
3.1.0.886
$ 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.
$ 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.
In the host/VM from where dux is to be installed and run:
a. AlmaLinux, CentOS/RHEL, macOS or Windows
b. SSH (Secure Shell) should be installed and running on your local Mac/Linux/Windows machine. You can verify this by opening a terminal and typing ssh followed by pressing Enter. If SSH is installed, you will see a list of available options. If not, please install SSH using the appropriate package manager for your system.
c. SSH keys need to be set up for users to log in to the remote VMs (where SEG 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 seg_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. SEG docker container image bundle (tar.gz) has to be downloaded and should be placed in the images directory under dux home directory. The dux tool will use the container image from the dux home directory by default.
In the Linux VMs/hosts where SEG container needs to be deployed:
a. SSH has to be enabled in the remote host/VM and SSH server daemon sshd has to be running in the remote host.
For example, in AlmaLinux check if sshd is running with the command: systemctl status sshd.
b. Docker/Podman/Podman-docker has to be installed and running in the Linux host/VM. Currently Snap docker (if ubuntu) is not supported.
Please ensure to install Docker CE/Podman/Podman-docker.
i. Dux commands perform docker operations using the 'docker' command. If Podman is installed on the VM, a symbolic link from podman to /usr/bin/docker is required to ensure compatibility.
The dry-run command (dux deploy -d) automatically creates this symlink if needed. Alternatively, the user can manually create it using the following command: `sudo ln -sf $(which podman) /usr/bin/docker`
c. If Dux can be allowed to use sudo for the execution of commands (no_sudo: true in the manifest files): Ensure that the user can do sudo without password in the remote VM/host where SEG container needs to be deployed
i.e In the sudoers file in the remote host, add an entry to grant passwordless access to your desired user.
To allow users to execute commands with sudo privileges without entering a password on the remote VM, follow these steps:
i. SSH to the remote VM as a user with administrative privileges.
ii. Edit the sudoers file using the command: sudo visudo.
iii. Add the following line to the end of the file to grant sudo privileges without password prompt: Replace username with the actual username of the user.
username ALL=(ALL) NOPASSWD: ALL
iv. Save and exit the sudoers file.
d. 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:
```bash sudo usermod -aG docker <username> ```
```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.
e. Connectivity to UEM Console API.
f. Connectivity to Email Server (exchange).
Deployment of SEG container in Dux VM
To deploy SEG container in the same Linux VM as Dux, and to use dux commands locally without the need to use ssh:
The dux CLI tool supports deploying and managing multiple types of containers, including Tunnel container, PAC (Proxy Auto Configuration) Reader, SEG (Secure Email Gateway), and EIC (EIC policy engine).
This section explains how to use dux to deploy and manage different containers based on the container type.
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.
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.
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 seg_manifest.yml was present in the default directory):
$ dux status
Status of SEG containers deployed
1. Host: 192.10.132.166 Status: Not Deployed
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: 3
Status of SEG containers deployed
1. Host: 192.10.132.166 Version: 2.32.0 Mail Server Connectivity: UP REST API Connectivity: UP Requests since startup: 0 Device Policy Size in Active Cache: 32
To avoid prompts, you can explicitly specify the container type in the command using the format: dux <container_type> <dux_command> <args>
For commands to deploy/manage SEG containers, you can use : dux seg <dux_command> <args>
Example:
$ dux seg status
Status of SEG containers deployed
1. Host: 192.10.132.166 Version: 2.32.0 Mail Server Connectivity: UP REST API Connectivity: UP Requests since startup: 0 Device Policy Size in Active Cache: 32
This command creates a sample manifest file for configuring SEG 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 seg_manifest.yml of older version (3.0.0.641) please refer to the next sub-section 1.b
This command creates a sample manifest (seg_manifest.yml) under the directory dux based on the platform (by default). If you wish to use a different path where the seg_manifest.yml file need to be created the command "dux init <some_path>" can be given. Please ensure to specify the path of manifest with -m option in the other commands.
For example, in Linux VM where dux is installed:
$ dux init --help
Select a container type to initialize:
1. Tunnel
2. EIC
3. PAC Reader
4. SEG
Enter the number of the container type: 4
Enter the number of the container type: 4
Create a manifest file for configuring SEG details for deployment and management
Usage:
dux seg init [path] [flags]
Examples:
dux seg init # initialize manifest under default path (/opt/omnissa/dux/)
dux seg init /some/path # initialize manifest under the specified path
dux seg init -u -m /path/to/manifest.yml # update the specified manifest file
dux seg init -u -n # hide the comments in the manifest file (-m for custom manifest file)
dux seg init -u # update the default manifest file
Flags:
-m, --manifest-file string Custom manifest file path to update (default "/opt/omnissa/dux/seg_manifest.yml")
-n, --no-comments Hide comments in the manifest file. If not given, comments will be shown in the manifest file
-u, --update Update the manifest file as per the latest version of dux
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: 4
Directory: /opt/omnissa/dux/scripts already exists
setup_host_for_seg.sh created at /opt/omnissa/dux/scripts/setup_host_for_seg.sh
Directory: /opt/omnissa/dux/certs already exists
SEG manifest file successfully created at: /opt/omnissa/dux/seg_manifest.yml
$cd /opt/omnissa/dux
abc@abc dux $ ls -ltr
total 16
[root@centos81 dux]# ls -ltr
total 28
drwxr-xr-x. 2 abc abc 6 Jun 17 04:12 images
drwxr-xr-x. 2 abc abc 42 Jun 17 06:10 logs
drwxr-xr-x 3 abc abc 96 Jun 17 13:05 certs
drwxr-xr-x 3 abc abc 96 Jun 17 13:05 scripts
-rw-r--r--. 1 abc abc 3720 Jun 18 08:06 seg_manifest.yml
If previous Dux version (3.0.0.641) is already installed and the SEG manifest file has the configuration details, the manifest can be upgraded with the following command:
$ dux init -u
1. Tunnel
2. EIC
3. PAC Reader
4. SEG
Enter the number of the container type: 4
Warning: Manifest version 3.0.0.641 is outdated.
Do you want to upgrade the manifest to the latest dux version ? (y/n) : y
Upgrading manifest from version 3.0.0.641 to version 3.1.0.886
Manifest file backed up to: /opt/omnissa/dux/seg_manifest.yml.bak_2025-12-11_18-09-08
Manifest file updated successfully at /opt/omnissa/dux/seg_manifest.yml
Directory: /opt/omnissa/dux/scripts already exists
Directory: /opt/omnissa/dux/certs already exists
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 ./seg_3.0.yml
Warning: Manifest version 3.0.0.641 is outdated. Current Dux version is 3.1.0.886
Please update the manifest with the command: `dux init -u` or `dux seg init -u` . Refer to `dux init -h` or `dux seg init -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 SEG container image, or use the new features supported etc.
Edit seg_manifest.yml generated in an editor of your choice.
Please refer to the section "Points to be noted while editing seg_manifest.yml" under Troubleshooting section.
Here are a few parameters:
# Enter the filename of the image or the repo path to deploy below.
# File: This must match against the SEG container image filename from the default directory (refer to the note below) or the absolute path.
# example: seg_image.tar.gz or /home/admin/seg_image.tar.gz
# Note: The default directory where the images are recommended to be present is:
# - for linux: /opt/omnissa/dux/images
# - for Mac OS on Intel/AMD64: /usr/local/var/opt/omnissa/dux/images/
# - for Mac OS on Apple Silicon/ARM64: /opt/homebrew/var/opt/omnissa/dux/images/
# - for Windows: <path of dux installation directory>/images
# Repository: Repository path of the image with the tag can be given as well:
# For example: your-local-repo.com/<path>/seg:<tag>
#Copy the bundle to the working directory
# eg. in Linux: cp ~/Downloads/seg_image.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 seg_image.tar.gz
#image_name in manifest
image_name: seg_image.tar.gz
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 (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
This parameter defines the global working directory under which all directories for dux related to SEG container deployment will be created for all hosts. If not specified, the default value is the home directory of the ssh user ($HOME). Use the parameter host_base_dir if the hosts have different working directories based on permission requirements for each host.
For example:
# Global value for base directory for dux under which all directories for SEG container deployment will be created for all hosts.
# Default is $HOME directory of the ssh user
global_base_dir: $HOME
This section controls the logging behavior of the SEG 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"
Fill in the IP address / host name of the host where SEG container needs to be deployed.
For example:
# SEG container Host(s) Information
# Input docker host information for SEG container deployment. Add an entry for each host.
hosts:
# Enter IP address of the host below
- address:
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:
The host_base_dir parameter specifies the working directory on the host under which all directories for the SEG 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 SEG container deployment on this specific host will be created under /home/admin/dux/.
## Host base directory for dux under which all directories of dux for SEG container deployment will be created for this host.
## If all hosts have common base directory, you may use the global parameter - 'global_base_dir'. Default is $HOME directory.
host_base_dir: /home/admin/dux
The details of UEM profile such as UEM url, UEM API Server port, Unique identifier of MEM configuration, user name to authenticate with Workspace ONE UEM API Server need to be given in this section.
Example of configuration parameters related to UEM:
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:
# The Workspace ONE UEM API server port as configured in the UEM console in Mobile Email Management (MEM) configuration
api_port:
# Unique ID of your Mobile Email Management (MEM) configuration. This is shown on the MEM Configuration page on the UEM console.
mem_guid:
admin:
# The username to authenticate with the Workspace ONE UEM API server.
username:
The permissions section in the seg_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 ca_cert_files field in the cg_manifest.yml file allows you to specify additional CA certificates to be added to the container's certificate store. These certificates are essential for enabling secure communication between the SEG 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 seg_manifest.yml present in the default directory to deploy and manage SEG containers. Hence the commands are in format : dux <command> <args> format
Once the manifest is updated with the required configuration details, deploy command can be run to deploy the SEG container in the hosts specified.
$ dux deploy -h
Deploy SEG containers
Usage:
dux seg deploy [flags]
Flags:
-d, --dry-run Check if manifest is good to deploy
-p, --ip stringArray Hostname or IP as specified in the manifest to deploy on a single host
-m, --manifest-file string Custom manifest file path (default "/opt/omnissa/dux/seg_manifest.yml")
-n, --node-number stringArray Node number as listed in manifest to deploy on a single host
-q, --quiet Quiet mode: interactive ssh password prompts are disabled
-u, --uem-password string Password to authenticate with the Workspace ONE UEM API server
-y, --yes Auto accept all prompts
Global Flags:
-h, --help Print help information
-v, --verbose Show verbose logs
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:
$ dux deploy -d
Manifest file syntax validation is successful
Verifying SEG container image location given in manifest: seg_image.tar.gz
Verifying remote host deployment prerequisites
Verifying deployment prerequisites on 192.10.132.166
Checking ssh connectivity to host: 192.10.84.186
Verifying docker is installed and running on 192.10.132.166
Checking for host working directory: /home/user1
Checking for availability of sufficient free disk space in the host working directory: /home/user1
Host 192.10.132.166 is good to deploy
Manifest file and hosts are good to deploy!
#In case of error in the manifest, for example, if image_name was not filled up, you may get an error like below:
$ dux deploy -d
Manifest verification failed error="Incorrect data in manifest: the image_name field must be populated"
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):
This command deploys the SEG containers in the hosts in the order as listed in manifest. The image is copied to remote host which will take few minutes depending on the network connectivity.
Note:
#Sample run
$ dux deploy
Enter UEM password:
Preparing for SEG container deployment on 192.10.132.166
SEG container image is already present on the host. Will not need to copy the image for deployment
Deploying new SEG container on 192.10.132.166
SEG container ID: a2a1a3cfd74ed077b4d2169ea00d5b5da5832f400d6f25ef0d257223fb59cc84
Fetching the deployment status. Please wait. This may take some time
Version: 2.32.0 Mail Server Connectivity: UP REST API Connectivity: UP Requests since startup: 0 Device Policy Size in Active Cache: 32
Deploy command has completed on 192.10.132.166
SEG container deployment requires specific users and groups to be created, and permissions of directories to be set. This requires sudo permissions.
The script setup_host_for_seg.sh is created by dux init command under /opt/omnissa/dux/scripts directory for linux ( note: the path will vary for different platforms)
This script needs to be executed manually in the host before the execution of dux deploy command. This will be prompted to user during deployment.
$ dux deploy
Enter UEM password:
Preparing for SEG container deployment on 192.10.84.186
Setup script prepared at /tmp/script/setup_host_for_seg_prepared.sh for manual execution
⚠️ Host 192.10.84.186 requires manual setup (NoSudo file operations):
Run setup script: sudo /tmp/script/setup_host_for_seg_prepared.sh
Continue deployment (y/N): y
SEG container image is already present on the host. Will not need to copy the image for deployment
Deploying new SEG container on 192.10.84.186....
c3dc0ae7a43e1cc9f4056c0cf749910508260cbdd58c3adabab47b120de0e6a3
Checking if SEG container is running on 192.10.84.186....
Fetching the deployment status. Please wait. This may take some time... \Version: 2.32.0 Mail Server Connectivity: DOWN REST API Connectivity: UP Requests since startup: 0 Device Policy Size in Active Cache: 55
Deploy command has completed on 192.10.84.186
To use a manifest from a different path -m flag can be used. If not specified, seg_manifest.yml from the directory where dux is run from is used by default.
#For eg.
$ dux deploy -m ~/Downloads/seg_manifest_xyz.yml
To deploy SEG containers in few remote hosts specified by ip or node-number (as per the order in manifest).
#For eg.
dux deploy -p 1.2.3.4
$ dux deploy -u <uem_password>
Once the deployment of containers is successful, other commands can be used to check status of deployment, fetch logs, and perform operations like stop, restart, and even destroy the deployments.
#status help
$ dux status -h
Get the status of the SEG containers deployed
Usage:
dux seg status [flags]
Flags:
-p, --ip stringArray Hostname or IP as specified in the manifest for filtering
-m, --manifest-file string Custom manifest file path (default "/opt/omnissa/dux/seg_manifest.yml")
-n, --node-number stringArray Node number as listed in manifest for filtering
-q, --quiet Quiet mode: interactive ssh password prompts are disabled
Global Flags:
-h, --help Print help information
-v, --verbose Show verbose logs
#To get status of all deployments - sample run.
$ dux status
Status of SEG containers deployed
1. Host: 192.10.132.166 Version: 2.32.0 Mail Server Connectivity: UP REST API Connectivity: UP Requests since startup: 0 Device Policy Size in Active Cache: 32
#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.10.132.110
#Get status of a specific host with node-number as listed in the manifest file
#Multiple node numbers can be given too: eg. dux status -n 1 -n 3
$ dux status -n 1
Fetch SEG log bundle from the deployed containers. If the container deployment is down, the docker logs of the container are fetched.
Note that the logs are stored in the logs directory based on the platform.
For linux: /opt/omnissa/dux/logs/
For Mac OS on Intel (AMD64): /usr/local/var/opt/omnissa/dux/logs
For Mac OS on Apple Silicon (ARM64): /opt/homebrew/var/opt/omnissa/dux/logs
For Windows: <INSTALL_DIR>\logs
The option -f can be used to continously view the docker logs output of a SEG container deployed till Ctrl-C is given.
# logs help
$ dux logs -h
Get logs from the SEG containers deployed
Usage:
dux seg logs [flags]
Flags:
-f, --follow Follow/View logs of a SEG container specified by node-number (-n) or ip (-p) option
-p, --ip stringArray Hostname or IP as specified in the manifest for filtering
-m, --manifest-file string Custom manifest file path (default "/opt/omnissa/dux/seg_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 SEG container logs from 192.10.132.166
Copy log bundle from Remote to Local machine..
Logs from 192.10.132.166 downloaded at: /opt/omnissa/dux/logs/seg_logs_dir.192.10.132.166_20250619141935.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
In case an SEG container needs to be stopped for some reason, dux stop command can be given.
# stop help
$ dux stop -h
Stop SEG containers on the given host(s) from the manifest file. To restart the containers again, you may use `dux restart` command.
Usage:
dux seg stop [flags]
Flags:
-p, --ip stringArray Hostname or IP as specified in the manifest for filtering
-m, --manifest-file string Custom manifest file path (default "/opt/omnissa/dux/seg_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 SEG containers deployed in all the hosts given in the manifest?
ip : 192.10.132.166 node-number : 1
Please confirm (y/n): y
SEG container was successfully stopped on 192.10.132.166
#Deployment of SEG 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
Stopped containers can be restarted by dux restart command
#restart help
$ dux restart -h
Restart the SEG containers on given hosts
Usage:
dux seg restart [flags]
Flags:
-p, --ip stringArray Hostname or IP as specified in the manifest for filtering
-m, --manifest-file string Custom manifest file path (default "/opt/omnissa/dux/seg_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 SEG containers deployed in all the hosts given in the manifest?
ip : 192.10.132.166 node-number : 1
Please confirm (y/n): y
SEG container was successfully restarted on 192.10.132.166
#Deployment of SEG 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
To stop and remove the deployed container from the remote SEG container host, dux destroy command can be used.
$ dux destroy -h
Destroy the SEG containers on the given hosts
Usage:
dux seg destroy [flags]
Flags:
-p, --ip stringArray Hostname or IP as specified in the manifest for filtering
-m, --manifest-file string Custom manifest file path (default "/opt/omnissa/dux/seg_manifest.yml")
-n, --node-number stringArray Node number as listed in manifest for filtering
-q, --quiet Quiet mode: interactive ssh password prompts are disabled
-y, --yes Auto accept all prompts
Global Flags:
-h, --help Print help information
-v, --verbose Show verbose logs
#Destroy all deployments
#Sample run
$ dux destroy
Are you sure you want to destroy the SEG containers deployed in all the hosts given in the manifest?
ip : 192.10.132.166 node-number : 1
Please confirm (y/n): y
SEG container was successfully destroyed on 192.10.132.166
#Deployment of SEG 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
If you wish to get verbose logs for any command, use the -v or --verbose option.
For example:
$ dux deploy -v
If you wish to start a shell with SEG container you can use the command 'exec-shell'
$ dux exec-shell -h
Open interactive shell with SEG container
Usage:
dux seg 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/seg_manifest.yml")
-n, --node-number stringArray Node number as listed in manifest for filtering
-q, --q Quiet mode: interactive ssh password prompts are disabled
Global Flags:
-h, --help Print help information
-v, --verbose Show verbose logs
$ dux exec-shell -n 1
Starting the interactive shell with SEG container in host: 192.10.132.166
[usrseg@localhost seg]$ pwd
/opt/omnissa/seg
[usrseg@localhost seg]$ ls
config launcher logs scripts seg-installer-tools.jar seg.jar tmp tools
[usrseg@localhost seg]$ exit
exit
For any installation issues please refer to the package manager instructions (yum/dnf/brew) for the specific error.
For example, if you are using dnf and encounter issues with installing dux, check if the cache is updated. Try "dnf makecache" to update metadata cache.
Ensure "dux init" command is run the first time.
Do a dry-run before deploying to ensure there are no issues with the manifest, and to ensure that the deployment pre-requisites are met.
dux deploy -d
For any issues, please check the file dux.log under logs directory as per the platform - for e.g /opt/omnissa/dux/logs/dux.log in Linux.
If docker is installed with snap in the Linux system, you may encounter permission issues during deployment of SEG containers with dux.
Ubuntu commonly uses snap to install packages.
If snap docker is used it is recommended to uninstall snap docker, and install docker as mentioned in https://docs.docker.com/engine/install/ubuntu/ .
sudo snap remove docker --purge
sudo reboot
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin
Note: Please check if there are other containers running in your VM with snap docker. While technically possible, running both Snap Docker and Docker CE on the same Ubuntu system is generally not recommended due to the potential for conflicts and complexity - wrt port usage, networking, system resources usage etc.
Please ensure the conditions in the Prerequisites section are met.
In Windows, if dux is installed under system directories like C:\Program Files, Windows Powershell/Command Prompt should be run as administrator for dux commands to work. Please check for errors related to access issues.
When using command line option (-u) to input password to authenticate with the UEM API server, always wrap your password. This prevents issues with special characters being misinterpreted by the shell during deployment.
Example: If the password is Secret123!, input it as 'Secret123!'.
This recommendation applies only to the -u parameter for UEM Password in the deploy command. Passwords entered via prompts (e.g., Enter UEM password:) do not require wrapping in single quotes and will work as is.
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:
reg add HKCU\Console /v VirtualTerminalLevel /t REG_DWORD /d 1
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.
Open the YAML File
Understand YAML Syntax
: and then the corresponding value.image_name: seg_image.tar.gzMake Changes
#) in the YAML file as they provide context or explanations about specific entries.Save Changes
Ctrl + S (Linux) or Cmd + S (Mac)..yml extension to maintain its YAML format.Validate Changes (Optional)
Backup (Optional but Recommended)
Sample seg_manifest.yml file for reference
# Version number for the SEG Container deployment manifest. This is auto generated and should not be altered.
version: "3.1.0.886"
# Configuration parameters needed to deploy SEG container
seg:
# Enter the filename of the image or the repo path to deploy below.
# File: This must match against the SEG container image filename from the default directory (refer to the note below) or the absolute path.
# example: seg_image.tar.gz or /home/admin/seg_image.tar.gz
# Note: The default directory where the images are recommended to be present is:
# - for linux: /opt/omnissa/dux/images
# - for Mac OS on Intel/AMD64: /usr/local/var/opt/omnissa/dux/images/
# - for Mac OS on Apple Silicon/ARM64: /opt/homebrew/var/opt/omnissa/dux/images/
# - for Windows: <path of dux installation directory>/images
# Repository: Repository path of the image with the tag can be given as well:
# For example: your-local-repo.com/<path>/seg:<tag>
image_name: seg_image.tar.gz
# Container Host(s) Authentication Information
# If all hosts have common authentication credentials, you may want to use the parameter - 'ssh_login_credentials'
# For authentication, provide the ssh user name and ssh key path below
# If all hosts use a different SSH port other than 22, uncomment the `ssh_port` parameter and enter the port number.
# If not provided, default value of 22 will be used.
ssh_login_credentials:
ssh_user: user1
# Input the path of ssh key - e.g /home/admin/id_rsa
ssh_key_path: /home/user1/.ssh/id_rsa
## Optional: Input the ssh port. Default value - 22
ssh_port:
# SSH Host key check - verify the identity of the remote host
# By default this is enabled and the user will be prompted to confirm the fingerprint of the public key of the remote host.
# If disabled, dux will connect similar to the ssh option StrictHostKeyChecking=no and UserKnownHostsFile=/dev/null
# 1 - enable host key checking
# 0 - disable host key checking
ssh_host_key_check: 1
# 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"
# Global value for base directory for dux under which all directories of dux for SEG container deployment will be created for all hosts.
# Default is $HOME directory
global_base_dir: $HOME
# SEG container Host(s) Information
# Input docker host information for SEG container deployment. Add an entry for each host.
hosts:
# Enter IP address of the host below
- address: 10.232.18.132
######################################################################
## THE FOLLOWING ARE OPTIONAL PARAMETERS FOR SEG 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.
## SSH Port information
## If the host uses a different SSH port other than 22, uncomment the `ssh_port` parameter and enter the port number.
## If not provided, default value of 22 will be used.
#host_info:
#ssh_user:
## Input the path of ssh key - e.g /home/admin/id_rsa
#ssh_key_path:
## For security reasons, the ssh_password is not recommended.
#ssh_password:
## Input the ssh port. Default value - 22
#ssh_port:
## Base directory for dux under which all directories of dux for SEG container deployment will be created for this host.
## Default is $HOME directory. If all hosts have common base directory, you may use the global parameter - 'global_base_dir'
#host_base_dir: $HOME
# 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
# The Workspace ONE UEM API server port as configured in the UEM console in Mobile Email Management (MEM) configuration
api_port: 8443
# Unique ID of your Mobile Email Management (MEM) configuration. This is shown on the MEM Configuration page on the UEM console.
mem_guid: 93ae0bb8-9dc4-494e-a0c8-e243f8110439
admin:
# The username to authenticate with the Workspace ONE UEM API server
username: uemuser
# Additional CA certificates to be added to the container cert store
# Give file names of the cert to be added. Multiple filenames can be given separated by comma - e.g., cert1.crt, cert2.crt
# The default directory where the certs are recommended to be present is:
# - for linux: /opt/omnissa/dux/certs
# - for Mac OS on Intel/AMD64: /usr/local/var/opt/omnissa/dux/certs/
# - for Mac OS on Apple Silicon/ARM64: /opt/homebrew/var/opt/omnissa/dux/certs/
# - for Windows: <path of dux installation directory>/certs/
# Absolute path of the cert can be given as well - /home/admin/proxy.crt
ca_cert_files:
# Permissions configuration for command execution
# Controls whether sudo is used for different types of operations
# All fields default to false (use sudo) for backward compatibility and security
permissions:
# Docker operations: pull, run, stop, remove containers and images
docker:
no_sudo: false
# File operations: create directories, copy files, change ownership
file_operations:
no_sudo: false
# System operations: iptables, systemctl, package management
system:
no_sudo: false
# Network operations: firewall rules, port configuration
network:
no_sudo: false