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.0.0.641/README.html
Get the version of Dux cli deployed
$ dux version
Omnissa CLI - dux
3.0.0.641
$ dux help
CLI to deploy and manage containers based on the manifest file
Usage:
dux [command]
Available Commands:
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.
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. 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.
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
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: 10.87.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: 10.87.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: 10.87.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.
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
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
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
-rw-r--r--. 1 abc abc 3720 Jun 18 08:06 seg_manifest.yml
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
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 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:
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 syntanctically 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 deployment prerequisites on 10.87.132.166
Verifying docker is installed and running on 10.87.132.166
Host 10.87.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 10.87.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 10.87.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
Deployment is up!
Deploy command has completed on 10.87.132.166
——
#### To use a different manifest
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 container in specific/few remote hosts
To deploy SEG containers in few remote hosts specified by ip or node-number (as per the order in manifest).
#For eg.
$ dux deploy -n 1 -n 3
$ dux deploy -p 1.2.3.4
#### To give UEM password as command line option:
$ dux deploy -u <uem_password>
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: 10.87.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 10.87.132.110
#Get status of a specific host with node-number as listed in the manifest file
#Multiple node numbers can be given too: eg. dux status -n 1 -n 3
$ dux status -n 1
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 10.87.132.166
Copy log bundle from Remote to Local machine..
Logs from 10.87.132.166 downloaded at: /opt/omnissa/dux/logs/seg_logs_dir.10.87.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 : 10.87.132.166 node-number : 1
Please confirm (y/n): y
SEG container was successfully stopped on 10.87.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 : 10.87.132.166 node-number : 1
Please confirm (y/n): y
SEG container was successfully restarted on 10.87.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 : 10.87.132.166 node-number : 1
Please confirm (y/n): y
SEG container was successfully destroyed on 10.87.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: 10.87.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.
To avoid errors while editing the seg_manifest.yml, please refer to the following guide:
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.0.0.641"
#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:
# Application
# 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
# 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.
## The values can also be passed as environment variables
## SSH Port information
## If the host uses a different SSH port other than 22, uncomment the `ssh_port` parameter and enter the port number.
## If not provided, default value of 22 will be used.
host_info:
ssh_user:
## Input the path of ssh key - e.g /home/admin/id_rsa
ssh_key_path:
## For security reasons, the ssh_password is not recommended.
ssh_password:
## Input the ssh port. Default value - 22
#ssh_port:
#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