This document contains commands to deploy and manage EIC (Endpoint Integrity Check) policy engine 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
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 EIC 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 eic_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. EIC docker container image bundle (tar.gz) has to be downloaded and placed in images directory under dux home directory. The dux tool will use the container image from the dux home directory by default.
f. The configuration files needed to deploy EIC container - policies.json, logback.xml, application.yaml need to be uploaded to eic-config directory under the default dux directory (based on the platform). Note that this directory will be created by dux init command, if it does not exist already.
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:
```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.
In the Linux VMs/hosts where EIC 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 EIC container needs to be deployed.
i.e In the sudoers file in the remote host, add an entry to grant passwordless access to your desired user.
To allow users to execute commands with sudo privileges without entering a password on the remote VM, follow these steps:
i. SSH to the remote VM as a user with administrative privileges.
ii. Edit the sudoers file using the command: sudo visudo.
iii. Add the following line to the end of the file to grant sudo privileges without password prompt: Replace username with the actual username of the user.
username ALL=(ALL) NOPASSWD: ALL
iv. Save and exit the sudoers file.
d. Connectivity to the Tunnel container (either on same VM or different one)
Deployment of EIC container in Dux VM
To deploy EIC 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), Content 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 ts_manifest.yml was present in the default directory):
$ dux status
Status of Tunnel 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: 2
Status of EIC containers deployed
1. Host: 192.10.132.166
Health check: 200 OK Version: 1.5 State: RUNNING Policy: READY ALLOW: BLOCK: 0
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.10.132.166
Health check: 200 OK Version: 1.5 State: RUNNING Policy: READY BLOCK: ALLOW: 0
For commands to deploy/manage EIC containers, you can use : dux eic <dux_command> <args>
This command creates a sample manifest file for configuring EIC 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 eic_manifest.yml of older version (3.0.0.641) please refer to the next sub-section 1.b
This command creates a sample manifest (eic_manifest.yml) and the eic-config under the directory dux based on the platform (by default). If you wish to use a different path where the eic_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. Note that the directory eic-config will still be created under the default dux path.
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: 2
Create a manifest file for configuring EIC details for deployment and management
Usage:
dux eic init [path] [flags]
Examples:
dux eic init # initialize manifest under default path (/opt/omnissa/dux/)
dux eic init /some/path # initialize manifest under the specified path
dux eic init -u -m /path/to/manifest.yml # update the specified manifest file
dux eic init -u -n # hide the comments in the manifest file (-m for custom manifest file)
dux eic init -u # update the default manifest file
Flags:
-m, --manifest-file string Custom manifest file path to update (default "/opt/omnissa/dux/eic_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
5. Content Gateway
Enter the number of the container type: 2
EIC manifest file successfully created at: /opt/omnissa/dux/eic_manifest.yml
Please upload the config files for EIC under: /opt/omnissa/dux/eic-config
Directory: /opt/omnissa/dux/scripts already exists
Directory: /opt/omnissa/dux/certs already exists
$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. 2 abc abc 6 Jun 18 15:05 eic-config
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 15:05 eic_manifest.yml
If previous Dux version (3.0.0.641) is already installed and the EIC 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: 2
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/eic_manifest.yml.bak_2025-12-11_18-09-08
Manifest file updated successfully at /opt/omnissa/dux/eic_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 ./eic_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 eic init -u` . Refer to `dux init -h` or `dux eic 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 EIC container image, or use the new features supported etc.
Edit eic_manifest.yml generated in an editor of your choice.
Please refer to the section "Points to be noted while editing eic_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 eic container image filename from the default directory (refer to the note below) or the absolute path.
# example: eic_engine.tar.gz or /home/admin/eic_engine.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>/eic-policy-engine:<tag>
#Copy the bundle to the working directory
# eg. in Linux: cp ~/Downloads/eic_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 eic_image.tar.gz
#image_name in manifest
image_name: eic_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 section controls the logging behavior of the EIC 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"
This parameter defines the global working directory under which all directories for dux related to EIC 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 EIC container deployment will be created for all hosts.
# Default is $HOME directory
global_base_dir: $HOME
Fill in the IP address / host name of the host where EIC container needs to be deployed along with the API Port number where EIC container listens for api calls related to healthcheck. Default value for the same is 9099.
For example:
hosts:
# Enter IP address of the host below
- address:
# API Port number. Default value - 9099
api_port: 9099
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 EIC 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 EIC container deployment on this specific host will be created under /home/admin/dux/.
# Base directory for dux under which all directories of dux for EIC 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
The parameters under jave_heap_size refer to the inital heap size and the maximum heap size allocated to JVM.
# The parameters under java_heap_size are optional. Uncomment and edit the values if the java heap size needs to be changed.
#java_heap_size:
#xms: "256m" # Initial heap size (minimum memory allocated to JVM)
#xmx: "2g" # Maximum heap size (maximum memory JVM can use)
The permissions section in the eic_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 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 Content Gateway container and external systems.
# Additional CA certificates to be added to the container cert store
# Give file names of the cert to be added. Multiple filenames can be given separated by comma - e.g., cert1.crt, cert2.crt
# The default directory where the certs are recommended to be present is:
# - for linux: /opt/omnissa/dux/certs
# - for Mac OS on Intel/AMD64: /usr/local/var/opt/omnissa/dux/certs/
# - for Mac OS on Apple Silicon/ARM64: /opt/homebrew/var/opt/omnissa/dux/certs/
# - for Windows: <path of dux installation directory>/certs/
# Absolute path of the cert can be given as well - /home/admin/proxy.crt
ca_cert_files:
Note: The following sections assume that there is only eic_manifest.yml present in the default directory to deploy and manage EIC 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 EIC container in the hosts specified.
$ dux deploy -h
Deploy EIC containers
Usage:
dux eic 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/eic_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
-y, --yes Auto accept all prompts
Global Flags:
-h, --help Print help information
-v, --verbose Show verbose logs
To catch if 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 EIC container image location given in manifest: eic_image.tar.gz
Verifying remote host deployment prerequisites
Verifying deployment prerequisites on 192.10.132.166
Checking ssh connectivity to host: 192.10.132.166
Verifying docker is installed and running on 192.10.132.166
Checking for host working directory: /home/user1
Checking for availablility of sufficient free disk space in the host working directory: /home/user1
Host 192.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 EIC 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
Preparing for EIC container deployment on 192.10.132.166
EIC container image is already present on the host. Will not need to copy the image for deployment
Stopping and removing existing EIC container on 192.10.132.166
Deploying new EIC container on 192.10.132.166
EIC container ID: f5c2e406c8c28135ab675a624bc36a225f6bb80299eb511318978f5350357f81
Fetching the deployment status. Please wait. This may take some time
Health check: 200 OK Version: 1.8 State: RUNNING Policy: READY Reauth: 0 BLOCK: 0 RESTRICT:$ITAR-demo: 0 block: 0 ALLOW: 0 Allow: 0
Deployment is up!
Deploy command has completed on 192.10.132.166
——
#### To use a different manifest
To use a manifest from a different path -m flag can be used. If not specified, eic_manifest.yml from the directory where dux is run from is used by default.
#For eg.
$ dux deploy -m ~/Downloads/eic_manifest_xyz.yml
#### To deploy EIC container in specific/few remote hosts
To deploy EIC 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
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 EIC containers deployed
Usage:
dux eic 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 "/usr/local/var/opt/omnissa/dux/eic_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 EIC containers deployed
1. Host: 192.10.132.166
Health check: 200 OK Version: 1.8 State: RUNNING Policy: READY Allow: 0 Reauth: 0 BLOCK: 0 RESTRICT:$ITAR-demo: 0 block: 0 ALLOW: 0
#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 EIC 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 EIC container deployed till Ctrl-C is given.
# logs help
$ dux logs -h
Get logs from the EIC containers deployed
Usage:
dux eic logs [flags]
Flags:
-f, --follow Follow/View logs of a EIC 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/eic_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 EIC container logs from 192.10.132.166
Extracted filename: eic_logarchive_20250618100327.zip
Copy log bundle from Remote to Local machine..
Logs from 192.10.132.166 downloaded at: /usr/local/var/opt/omnissa/dux/logs/eic_logarchive_20250618100327.192.10.132.166.zip
#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 EIC container needs to be stopped for some reason, dux stop command can be given.
# stop help
$ dux stop -h
Stop EIC containers on the given host(s) from the manifest file. To restart the containers again, you may use `dux restart` command.
Usage:
dux eic 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/eic_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 EIC containers deployed in all the hosts given in the manifest?
ip : 192.10.132.166 node-number : 1
Please confirm (y/n): y
EIC container was successfully stopped on 192.10.132.166
#Deployment of EIC 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 EIC container on given hosts
Usage:
dux eic 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/eic_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 EIC containers deployed in all the hosts given in the manifest?
ip : 192.10.132.166 node-number : 1
Please confirm (y/n): y
EIC container was successfully restarted on 192.10.132.166
#Deployment of EIC 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 EIC container host, dux destroy command can be used.
#destroy command help
$ dux destroy -h
Destroy the EIC containers on the given hosts
Usage:
dux eic 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/eic_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 EIC containers deployed in all the hosts given in the manifest?
ip : 192.10.132.166 node-number : 1
Please confirm (y/n): y
EIC container was successfully destroyed on 192.10.132.166
#Deployment of EIC 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 EIC container you can use the command 'exec-shell'
$ dux exec-shell -h
Open interactive shell with EIC container
Usage:
dux eic 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/eic_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 EIC container in host: 192.10.132.166
bash-5.1$ pwd
/opt/omnissa/eic
bash-5.1$ ls
config default-config drl eic-policy-engine-1.0-SNAPSHOT.jar logs scripts
bash-5.1$ 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 EIC 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.
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: eic_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 eic_manifest.yml file for reference
# Version number for the EIC Container deployment manifest. This is auto generated and should not be altered.
version: "3.1.0.886"
# EIC Policy Engine information needed to deploy
eic_policy_engine:
# Enter the filename of the image or the repo path to deploy below.
# File: This must match against the EIC container image filename from the default directory (refer to the note below) or the absolute path.
# example: eic_engine.tar.gz or /home/admin/eic_engine.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>/eic-policy-engine:<tag>
image_name: eic_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/id_rsa
## Optional: Input the ssh port. Default value - 22
ssh_port:
# SSH Host key check - verify the identity of the remote host
# By default this is enabled and the user will be prompted to confirm the fingerprint of the public key of the remote host.
# If disabled, dux will connect similar to the ssh option StrictHostKeyChecking=no and UserKnownHostsFile=/dev/null
# 1 - enable host key checking
# 0 - disable host key checking
ssh_host_key_check: 1
# Global value for base directory for dux under which all directories of dux for EIC container deployment will be created for all hosts.
# Default is $HOME directory
global_base_dir: $HOME
# 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"
# The parameters under java_heap_size are optional. Uncomment and edit the values if the Java heap size of EIC Policy Engine needs to be changed.
#java_heap_size:
#xms: "256m" # Initial heap size (minimum memory allocated to JVM)
#xmx: "2g" # Maximum heap size (maximum memory JVM can use)
# EIC Policy Engine container Host(s) Information
# Input docker host information for EIC policy engine container deployment. Add an entry for each host.
hosts:
# Enter IP address of the host below
- address: 192.10.128.132
# API Port number. Default value - 9099
api_port: 9099
####################################################################################
## THE FOLLOWING ARE OPTIONAL PARAMETERS FOR EIC POLICY ENGINE 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 EIC 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
# 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