EnglishFrançaisDeutschEspañolItaliano日本語한국어NederlandsPortuguês (Brasil)中文 (简体)中文 (繁體, 台灣)
Skip to main content

Remove dux.repo

Introduction:

The Omnissa Workspace ONE team is updating the deployment options for Tunnel and replacing the standalone Linux Tunnel installer. This new deployment method provides significant orchestration and security improvements over the previous RPM artifact and installer, and leverages a secure container version of the Tunnel gateway software. There is no requirement for container or Kubernetes infrastructure or expertise to make use of the new tools.

The new deployment method provides the following benefits:

  • Deploy multiple servers at the same time

  • Increased support and flexibility for the host, beyond RHEL 7 or Unified Access Gateway.

    • Choose your Linux distribution of choice for the host OS

  • Simplified host prerequisites

  • Improved diagnostic tools for monitoring your deployment

There two artifacts required for initial deployment and management.

  • Tunnel server container image

  • Cross-platform CLI (dux) for lifecycle management of Tunnel server

Tunnel server container image:
This artifact is available as a tar bar file on the Workspace ONE Resources portal. The Tunnel service will run within a Docker container on any server running your choice of Linux distribution.
You are free to manage your infrastructure and dictate security posture per your company policy.
The container deployment will take care of all the Tunnel gateway features and in-software security.

This artifact is available here: Customer Connect Portal

The Tunnel CLI tool – dux
The CLI tool is your primary interface to deploy and manage your tunnel gateway container deployment.
You can either run this tool locally on the server where the Tunnel service will be deployed or manage multiple deployments through a central-management server.
This tool is currently available for macOS and Linux platforms. Support for Windows platform is on our roadmap.

  • dux for Linux can be installed using the package managers - yum or dnf.

  • dux for macOS can be installed using the package manager - brew

dux for Linux:

For AMD64/Intel: https://packages.omnissa.com/ws1-tunnel/dux/2.2.0.247/dux-2.2.0.247-1.x86_64.rpm

For ARM64/Apple Silicon: https://packages.omnissa.com/ws1-tunnel/dux/2.2.0.247/dux-2.2.0.247-1.aarch64.rpm

Prerequisites:

There are separate requirements for the server hosting-running the Tunnel gateway service and the server hosting the dux tool.
If dux is to be run locally on the server where the gateway service is deployed, please ensure that both dux and the Tunnel container gateway server pre-requisites are met.

Server(s) where the Tunnel gateway service will run:

  • Linux distribution of choice.

  • Docker has to be installed and running on this Linux host.

  • Administrator should be able to sudo without a password to this Linux host.

  • Connectivity to UEM Console API.

  • Connectivity to AWCM.

  • If running cascade mode, Front-end to Back-end connection (direct or load-balanced) is required.

Server where dux will run:

  • CentOS/ RHEL 7+ or macOS

  • The Tunnel container image in .gz format should be downloaded to the host where dux will be run from.

  • Ensure the image is available in the default path - This step is applicable only after dux is installed and the folder structure is created.

    • For dux on Linux:
      Use /opt/omnissa/dux/images/

    • For dux on macOS
      Use /usr/local/var/opt/omnissa/dux/images for macOS on Intel/AMD64
      Use /opt/homebrew/var/opt/omnissa/dux/images/ for macOS on Apple Silicon/ARM64

The dux tool will use the container image from the above folder path by default. A custom folder may be used. Ensure the complete full directory path is provided in the manifest file if using a custom folder.

Steps to Install dux:

dux is currently available for macOS and Linux platforms. Support for Windows platform is on our roadmap.

  • dux for Linux can be installed using the package managers - yum or dnf.

  • dux for macOS can be installed using the package manager - brew

Installing dux for Linux

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

Note:
If you have the older-beta version 2.0.0.3 installed, perform the following cleanup steps before proceeding with installation:

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

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

Create dux.repo and install

$ cat << EOF | sudo tee /etc/yum.repos.d/dux.repo
[dux]
name=Workspace ONE Tunnel CLI
baseurl=https://packages.omnissa.com/ws1-tunnel/dux
enabled=1
gpgcheck=0
EOF

#If using yum:
$ sudo yum install -y dux 

# If using dnf 
$ sudo dnf install -y dux

After installation the following directory structures will be created:

/opt/omnissa/dux/
/opt/omnissa/dux/images/
/opt/omnissa/dux/logs/

Execute the following commands after:

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

Installing rpm package for Linux

Download the dux rpm as per the architecture of the host from where dux would be executed (x86_64 for AMD/Intel or aarch64 for ARM/Apple M1).
For example, if OS is Linux with amd64 architecture, the rpm dux-.x86_64.rpm should to be downloaded.

dux for Linux:

For AMD64/Intel: https://packages.omnissa.com/ws1-tunnel/dux/2.2.0.247/dux-2.2.0.247-1.x86_64.rpm

For ARM64/Apple Silicon: https://packages.omnissa.com/ws1-tunnel/dux/2.2.0.247/dux-2.2.0.247-1.aarch64.rpm

# download and install manually 
$ wget <url to download> Or download manually

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

$ dux version
Workspace ONE Tunnel CLI (dux)
2.1.0.2

Installing dux for macOS

dux can be installed on macOS using the package manager - brew

$ brew tap wsonetunnel/tunnel
$ brew install dux

After installation the following directory structures will be created depending on the device type

For macOS on Intel/AMD64:
/usr/local/var/opt/omnissa/dux/
/usr/local/var/opt/omnissa/dux/images
/usr/local/var/opt/omnissa/dux/logs

For macOS on Apple Silicon/ARM64:
/opt/homebrew/var/opt/omnissa/dux/
/opt/homebrew/var/opt/omnissa/dux/images/
/opt/homebrew/var/opt/omnissa/dux/logs/

Example:

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

The default path where dux looks for Tunnel Server images is the directory images based on the device type.
Logs (dux.log, tunnel snap, vpnserver logs) are stored under the directory logs based on the device type.

You may update to the GA version of dux from the beta version with the brew update command:

brew update
brew upgrade dux

Post Install

  • Get the version of Dux cli deployed
$ dux version 
Workspace ONE Tunnel CLI (dux)
2.1.0.2
  • Get the list of supported commands:
$ dux -h
CLI to deploy and manage Tunnel server containers

Usage:
  dux [command]

Available Commands:
  deploy       Deploy Tunnel server containers
  destroy      Destroy the Tunnel server containers on the given hosts
  help         Help about any command
  init         Create a manifest file for configuring Tunnel server details for deployment and management
  log-override Temporarily override one or more Tunnel server containers log level
  logs         Get logs from the Tunnel server containers deployed
  report       Fetch vpnreport of a Tunnel server container
  restart      Restart the Tunnel server container on given hosts
  status       Get the status of the Tunnel server containers deployed
  stop         Stop the Tunnel server containers on given hosts
  version      Get the version of dux

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

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

Steps to deploy the Tunnel gateway container

Once dux has been successfully installed, next step is to deploy the Tunnel container.

Step 1: Execute init command

Note: This command needs to be run only the first time when you install dux.

This command creates a sample manifest (ts_manifest.yml) and the performance tuning script (perf_tune.sh) which are used as inputs for deployment.
These files are created under the directory dux based on the platform.
If you wish to use a different path where the files need to be created the command "dux init <custom_path>" can be used for this . Please ensure to specify the path of manifest with -f option in the other commands.
The script perf_tune.sh contains commands to configure remote host settings for enhanced performance.

$ dux init
Deployment manifest initialized successfully

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

Step 2: Edit the ts_manifest.yml file

You may edit the manifest file in the editor of your choice.

  • image_name
 Enter the filename of the image to deploy below. 
  # This must match against the tunnel server image filename from the default directory (refer to the note below) or the absolute path.
  # example: 29-2023.06.14-22e04910.tar.gz or /home/admin/29-2023.06.14-22e04910.tar.gz
  # Note: The default directory where the images are recommended to be present is:
  #   - for Linux: /opt/omnissa/dux/images
  #   - for macOS on Intel/AMD64: /usr/local/var/opt/omnissa/dux/images/
  #   - for macOS on Apple Silicon/ARM64: /opt/homebrew/var/opt/omnissa/dux/images/

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

  • ssh_login_credentials
    If all hosts have common authentication credentials, you may want to use the parameter - ssh_login_credentials.
    However if you want to use different set of credentials for a host, the parameter host_auth_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 Generate SSH Keys on Linux

    Example:

ssh_login_credentials:
ssh_user: root
  # Input the path of ssh key - e.g /home/admin/id_rsa
ssh_key_path: /home/admin/id_rsa

  • ssh_host_key_check
    Applicable if the identity of the remote host needs to be verified.

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

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

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

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

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

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

    Fill in the IP address of the host where tunnel server container needs to be deployed and the server_role

    • If Tunnel server has to be deployed in Basic mode, the value of server_role is 0.

    • If Tunnel server has to be deployed as FrontEnd server, the value of server_role is 1.

    • If Tunnel server has to be deployed as Backend server, the value of server_role is 2.

      Example

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

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

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

    If both ssh_key_path and ssh_password are provided, ssh_key_path is preferred. Note that for security reasons, providing password information in the manifest is not recommended, though 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_auth_info and ssh_login_credentials are given, the credentials under host_auth_info are preferred.

    Example:

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

  • perf_tune: Option to configure the remote host with recommended system configuration - Optional

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

    Example

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

  • host_entries: Add entries to the container hosts file to manually link FQDN to IP address
    If host entries need to be specified for the remote host, specify the host names and ip addresses in this section.

    Example

# Add entries to the container hosts file to manually link FQDN to IP address
# Format:
## - host_name:
##   ip_address:
host_entries:
 - host_name: example.com
   ip_address: 1.2.3.4
  • uem: Details of Tunnel configuation within setup within WS1 UEM
    Enter the details of the Tunnel configuration in UEM in this section such as UEM API url, Group ID or Tunnel Configuration ID and the admin username.
    If tunnel_config_id is left blank, the organization Group ID is used to retrieve the configuration.
Example:

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

Step 3: Execute deploy command

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

deploy help

$ dux deploy -h
Deploy Tunnel server containers

Usage:
  dux deploy [flags]

Flags:
  -d, --dry-run                   Check if manifest is good to deploy
  -p, --ip stringArray            IP of host where tunnel server needs to be deployed
  -m, --manifest-file string      The manifest file used to deploy (default "/opt/omnissa/dux/ts_manifest.yml")
  -n, --node-number stringArray   Number of the node as listed in manifest where tunnel server needs to be deployed
  -u, --uem-passwd string         The password to authenticate with the Workspace ONE UEM API server.
  -y, --y                         Auto accept all prompts

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

Check if manifest is good to run

Example:

$ dux deploy -d
Manifest is good to deploy!

#In case of error in the manifest, for example, if tunnel_config_id is not populated, you will get an error like below:
$ dux deploy -d
Manifest verification failed error="Incorrect data in manifest: the group_id field is required if tunnel_config_id is not populated"

Host Key Verification

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

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

Deploy

This command deploys the tunnel gateway containers to the hosts in the order as listed in the manifest, and configured to the specificied UEM tenant. The container image is copied to remote host which will take few minutes depending on the network connectivity.

Note:

  1. Ensure the image to be deployed is in the images directory or the absolute path specified in the image_name in manifest.

  2. If image to be deployed is already loaded in remote host, the step to copy tunnel server image will be skipped.

  3. The command given without options (-n or -p) will deploy containers in all hosts as listed in manifest.

  4. The max_parallel option is not supported at this time and the deployment will be sequential.

Example:

#Sample run
$ dux deploy      
Enter UEM password: 
The perf_tune option has been enabled in the manifest. The perf_tune script will modify the Tunnel server host machines to provide recommended performance settings. Do you want to run the perf_tune script? (y/n): y

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

Deploy command has completed on 10.87.132.186

——

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


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


#### To deploy tunnel server container in specific/few remote hosts 
To deploy tunnel server 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 given UEM password as command line option:
$ dux deploy -u <uem_password>

Step 4: Post Deployment

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

Check status of deployment

#status help
$ dux status -h
Get the status of the Tunnel server containers deployed

Usage:
  dux status [flags]

Flags:
  -p, --ip stringArray            IPs of tunnelservers whose status needs to be queried
  -j, --json                      Get status of Tunnel server containers in json format
  -m, --manifest-file string      The manifest file which has the hosts where tunnelserver is deployed (default "/opt/omnissa/dux/ts_manifest.yml")
  -n, --node-number stringArray   Number of the node as listed in manifest whose status needs to be queried

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

#To get status of all deployments - sample run. In this case, one of the deployments is not in Running state, hence shows Down as status
$ dux status 

Status of Tunnel Server containers deployed

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

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

Status of Tunnel Server containers deployed

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


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

Status of Tunnel Server containers deployed

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

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

Retrieve vpnreport from deployed container(s).

The VPN report can be retrieved through dux for all or select Tunnel containers.

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

Usage:
  dux report [flags]

Flags:
  -p, --ip stringArray            IP of tunnel server container host to fetch vpnreport from
  -j, --json                      Get vpnreport in json format
  -m, --manifest-file string      The manifest file which has the hosts where Tunnel server is deployed (default "/opt/omnissa/dux/ts_manifest.yml")
  -n, --node-number stringArray   Number of the node as listed in manifest to fetch vpnreport from
  -r, --rows string               Range of rows from vpnreport to be printed for the nodes: e.g if rows 10-20 need to be printed, specify option as -r 10-20

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


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

Example of vpn report not included in this document.

Fetch logs from the deployed containers

Fetch tunnel_snap bundle from the deployed containers. If the container deployment is down, the docker logs of that container are retrieved.
Note: 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

The option -v can be used to stream the docker logs output of a tunnel server container deployed till this action is cancelled.

Example:

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

Usage:
  dux logs [flags]

Flags:
  -f, --follow                    Follow/View logs of a TunnelServer specified by node-number (-n) or ip (-p) option
  -p, --ip stringArray            IPs of Tunnel Servers to download logs from
  -m, --manifest-file string      The manifest file which has the hosts where Tunnel server is deployed (default "/opt/omnissa/dux/ts_manifest.yml")
  -n, --node-number stringArray   Number of the node as listed in manifest to fetch logs from

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


#Get logs of all containers deployed as per manifest
#Sample run - Note if the deployment is not up, the container logs are fetched.
$ dux logs 
Retrieve vpnserv logs from 10.87.132.186
Copy log bundle from Remote to Local machine..
Logs from 10.87.132.186 downloaded at: /opt/omnissa/dux/logs/tunnel_snap.10.87.132.186_20240219184004.tar.gz

Retrieve vpnserv logs from 192.168.99.180
Copy log bundle from Remote to Local machine..
Logs from 192.168.99.180 downloaded at: /opt/omnissa/dux/logs/tunnel_snap.192.168.99.180_20240219184036.tar.gz

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

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

Log-override
To change the log level for an individual container, use the log-override command.

Example:

$ dux log-override  -h
Temporarily override one or more Tunnel server containers log level

Usage:
  dux log-override [flags]

Flags:
  -c, --clear                     Restore log level to default value set by UEM Console
  -d, --duration int              Duration in minutes for the log level override; -1 to set log level indefinitely (default 30)
  -p, --ip stringArray            IP of Tunnel server whose log level needs to be overridden.
  -l, --log-level int             Desired log level to be set (1-Error, 2-Warn, 3-Info, 4-Debug)
  -m, --manifest-file string      The manifest file which contains the hosts where Tunnel server is deployed (default "/opt/omnissa/dux/ts_manifest.yml")
  -n, --node-number stringArray   Index of the node as listed in manifest whose log level needs to be overridden.
  -y, --y                         Auto accept all prompts

Global Flags:
  -h, --help      Print help information
  -v, --verbose   Show verbose logs
  # Some examples below
  # To set log-level to Debug (4) for 10 mins
  $ dux log-override -n 1 -l 4 -d 10

  Are you sure you want to set log level in node: 1 / IP: 10.87.132.186 to "Debug" for 10 mins? (y/n): y
  Log-level was succesfully set to "Debug" in Tunnel server container on 10.87.132.186

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

  Are you sure you want to set log level in node: 1 / IP: 10.87.132.186 to "Debug" for 30 mins? (y/n): y
  Log-level was succesfully set to "Debug" in Tunnel server container on 10.87.132.186

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

  Are you sure you want to clear log override on all nodes? (y/n): y
  Restored log level to default value set by UEM Console on 10.87.132.186
  Tunnel server container was not running on 192.168.99.252

Stop deployed containers

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

Usage:
  dux stop [flags]

Flags:
  -p, --ip stringArray            IPs of hosts where Tunnel Server containers need to be stopped
  -m, --manifest-file string      The manifest file which has the hosts where tunnelserver is deployed (default "/opt/omnissa/dux/ts_manifest.yml")
  -n, --node-number stringArray   Number of the node as listed in manifest where deployment of containers need to be stopped
  -y, --y                         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 TunnelServer running in 10.87.132.186 (y/n)?: y
Tunnel server container was successfully stopped on 10.87.132.186

Are you sure you want to stop TunnelServer running in 192.168.99.180 (y/n)?: n

#Deployment of tunnel server 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

Restart deployed containers

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

Usage:
  dux restart [flags]

Flags:
  -p, --ip stringArray            IPs of Tunnel servers that will be restarted
  -m, --manifest-file string      The manifest file which contains the hosts where Tunnel server is deployed (default "/opt/omnissa/dux/ts_manifest.yml")
  -n, --node-number stringArray   Number of the node as listed in manifest which will be restarted
  -y, --y                         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 Tunnel server deployment on 10.87.132.186 (y/n)?: n

Are you sure you want to restart Tunnel server deployment on 192.168.99.185 (y/n)?: y
Tunnel server container was successfully restarted on 192.168.99.185

#Deployment of tunnel server 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

Destroy deployed containers

#destroy command help
Destroy the Tunnel server containers on the given hosts

Usage:
  dux destroy [flags]

Flags:
  -p, --ip stringArray            IPs of hosts where Tunnel Server deployments need to be destroyed
  -m, --manifest-file string      The manifest file which has the hosts where tunnelserver is deployed (default "/opt/omnissa/dux/ts_manifest.yml")
  -n, --node-number stringArray   Number of the node as listed in manifest where deployment of containers need to be destroyed
  -y, --y                         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 Tunnel server deployment in 10.87.132.186 (y/n)?: y
Tunnel server container was successfully destroyed on 10.87.132.186

Are you sure you want to destroy Tunnel server deployment in 192.168.99.185 (y/n)?: n

#Deployment of tunnel server 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

Additional information for any command

You can get verbose logs for any command by using the -v or --verbose option.

Example:

$ dux deploy -v

Tips and Tricks

#1

Do I use the tunnel_config_id field and/or group_id field within the TS Manifest file?

The tunnel_config_id field is optional and supported only on UEM console version 2306 and later.
For UEM console version 2302 and earlier, please use the group_id field.

For UEM console 2306 and later, if the tunnel_config_id field is empty, the default configuration from the specified organization group (group_id field) will be retrieved.

#2

You may receive the following error during deployment:

Deployment failed error="error while creating hostfilecallback".

This error is because of a missing known_hosts file. You can manually add the known_hosts file or trust the host via SSH.
You may SSH to any server and accept the connection. This will create the known_hosts file on this server.

¿Le resultó útil esta página?

Enviar comentarios sobre este tema

¿Le resultó útil este tema?

No incluya información personal ni confidencial.

Generando el enlace…