Version: 10.2.9

Check readiness for installation

After you prepare the prerequisites for the installation according to the System Requirements section, you can use the dedicated checking script to verify that the environment is ready and set up Work.AI without problems.

Running the check

To check the installation readiness:

$ ssh -i <path-to-private-key.pem> <username>@<hostname.example.com>
$ sudo mkdir -p /opt/workfusion/CHECKER_DIR
$ sudo chmod 0755 /opt/workfusion/CHECKER_DIR

Here, <USERNAME> is the application user.

Download the provided checker package with any file retrieving tool, for example, wget or curl:

$ curl 'https://LINK_TO_CHECKER' --output INSTALL_DIR/workfusion-precheck-package-<version>.tar.gz

Extract the downloaded package to the directory:

$ tar -xzvf INSTALL_DIR/workfusion-precheck-package-<VERSION>.tar.gz --strip 1 -C INSTALL_DIR/CHECKER_DIR

The package contains the following files:

drwxrwxr-x@ 17 ec2-user  groupname    544 Feb 19 10:57 .
drwx------@ 26 ec2-user  groupname    832 Feb 21 14:49 ..
-rw-rw-r--@  1 ec2-user  groupname   1813 Feb 19 10:52 README
drwxrwxr-x@  3 ec2-user  groupname     96 Feb 19 10:52 callback_plugins
drwxrwxr-x@  2 ec2-user  groupname     64 Feb 19 10:52 certificates
-rw-rw-r--@  1 ec2-user  groupname  12551 Feb 19 10:52 config.yml
drwxrwxr-x@ 44 ec2-user  groupname   1408 Feb 19 10:52 group_vars
-rw-rw-r--@  1 ec2-user  groupname   1635 Feb 19 10:52 hosts.yml
-rwxrwxr-x@  1 ec2-user  groupname   9822 Feb 19 10:52 install.sh
drwxrwxr-x@  3 ec2-user  groupname     96 Feb 19 10:52 inventories
-rwxrwxr-x@  1 ec2-user  groupname   9972 Feb 19 10:52 inventory.py
-rw-rw-r--@  1 ec2-user  groupname  13513 Feb 19 10:52 manifest.yml
drwxrwxr-x@ 66 ec2-user  groupname   2112 Feb 19 10:52 playbooks
-rw-rw-r--@  1 ec2-user  groupname   9858 Feb 19 10:52 ports.yml
drwxrwxr-x@ 84 ec2-user  groupname   2688 Feb 19 10:52 roles
-rw-rw-r--@  1 ec2-user  groupname   1208 Feb 19 10:52 rpa.yml
drwxrwxr-x@  5 ec2-user  groupname    160 Feb 19 10:59 sources

Note: if you have already downloaded and extracted the installation package, completed the configuration files (hosts.yml, config.yml, ports.yml, rpa.yml), and prepared certificates in the certificates directory, copy and replace them from PACKAGE_DIR to CHECKER_DIR. After that, skip steps 4-9 and proceed to step 10 at once.

Go to CHECKER_DIR, open the hosts.yml file in the editing mode, and specify the domain names that you have prepared earlier.

$ cd CHECKER_DIR
$ vi hosts.yml

# Press 'i' to enter the editing mode.
# Add the required DNS name.
# After you add the values, press <Esc>, then type ":wq" and press <Return> to save the changes and quit the editing mode.

For more information on how to complete the file, see Specify DNS names.

Open the ports.yml file in the editing mode, and specify the ports that you have prepared earlier:
```
$ vi ports.yml
```
For more information on how to complete the file, see Specify ports.
Open the rpa.yml file in the editing mode, and specify the rpa users and hosts that you have prepared earlier:
```
$ vi rpa.yml
```
For more information on how to complete the file, see Specify RPA users.
Open the config.yml file in the editing mode, and specify the users' credentials and other settings that you have prepared earlier:
```
$ vi config.yml
```
For more information on how to complete the file, see Specify installation parameters.
Run the following command to encrypt both the config.yml and rpa.yml files.
Note: skip this step if you use the configuration files that you have copied from PACKAGE_DIR (see step 3).
```
$ ./install.sh encrypt config
```
Optional. If you don't have prepared certificates, generate the self-signed ones in the certificates directory:
```
$ ./install.sh certs generate
```

Export the variables:

$ export ANSIBLE_PRIVATE_KEY_FILE="</path_to_ssh_key>"   # Path to SSH key for connection to all Linux servers as WFUSER
$ export ANSIBLE_REMOTE_USER="WFUSER" # WFUSER provided in config.yml
$ export ANSIBLE_VAULT_PASS="<ansible_vault_password>"   # Password for decryption of config.yml. If you don't set this variable, you'll be prompted for the password during setup.

Run the preinstall command.
```
$ ./install.sh preinstall full
```
If you don't have permission for that, you can perform these steps manually. For the guide, see Run additional steps that require root.
Note: if you skip this step, the report will show the "failed" status for the root checks. The other checks will be shown as usual.
After you prepare the configuration files, run the following commands.
The first command checks that the environment meets the system requirements. The second one verifies that the settings of the MS SQL Server are correct, and the server has been set up properly.
```
$ ./install.sh report full
$ ./install.sh report mssql
```
If you are planning to install Work.AI in the Standard way, repeat steps 1-12 on all Linux servers.

Note that the script can verify settings on Windows servers in the automatic mode only if you can connect from the Master server to Windows servers via WinRM. If the WinRM connection is restricted, you can verify users and ports on Windows hosts manually. For that run the following command in PowerShell on each Windows Server, from which you want to test connection to a port on another host.

function Test-TcpPort {
  Param([String]$hostAddress, [int]$port)
  $tcpClient = New-Object Net.Sockets.TcpClient
  try {
    $connection = $tcpClient.BeginConnect($hostAddress, $port,$null,$null)
    $wait = $connection.AsyncWaitHandle.WaitOne(2000, $false)
    if($wait) {
      $tcpclient.EndConnect($connection)
    } else {
      Write-Error "Timeout"
    }
  } finally {
    $tcpClient.Close()
    if($Error.Count -ne 0) {
      #exit 1
    }
  }
}
Test-TcpPort -host {specify-host-to-check} -port {specify-port-to-check}

Here, in the -host parameter, specify the host, where the port must be checked, and in the -port parameter, specify the port itself. For example, Test-TcpPort -host example-ct1.workfusion.com -port 44446. For the list of ports to be opened and verified, see the ports page.

If you don't see any output, it means that the check passes successfully, and there are no ports blocked by a firewall. In case when a firewall blocks a destination port, you will see "Timeout" in the output.

Report

After the check finishes, you can find the report with the results in INSTALL_DIR/CHECKER_DIR/logs/reports/.

Each check has the following status:

OK. The check of a component passed successfully.
FAILED. The check hasn't passed, and you must make the necessary amends.

info

In some cases, the report displays a verification step, which is followed by the empty line. Such a situation is normal and means that a particular check has been skipped because it does not apply to the current configuration.

For example, such records may appear if you are not installing RPA or Analytics components and thus have never prepared the infrastructure for them. Or if you are installing the product in the Basic mode, then the high-availability related steps will be skipped, and the checks will not be reflected in the final report.

Checking ports

Besides other environment settings, the checker verifies that the required ports are open among the servers. The script uses different types of validations for Linux and Windows servers:

From Linux servers: /dev/tcp/{{ host }}/{{ port }}
From Windows servers: the Net.Sockets.TcpClient class is used.

After the checker verifies the open ports, you will receive the following messages:

SUCCESS. The server returns "Connection refused," that means that the port is open and the firewall doesn't block communication for that port.
FAILED. The firewall blocks the connection to the port and returns a "Timeout" message.
OK | [WARNING: PORT IS BUSY]. The firewall doesn't block connection for that port, but another service occupies it.
This situation is normal if you have already installed a Work.AI component. If a service or an application is already listening to this port, free the port or use another one for installation.
Note that when verifying RPA and Analytics servers' ports from any other Linux server, you will receive the WARNING message. If the firewall on your RPA and Analytics Windows server is enabled by default, this behavior is normal and must not be considered as a failed check. Otherwise, check the settings of your network firewall.

For correct installation, all ports checks must have the SUCCESS status.

info

The script works correctly only if, by default, your firewall drops packets (that leads to timeout on the source server-side), and servers return the "refused" message in case any service does not listen to their available ports. If you have different behavior of the servers and the firewall, the ports check will work incorrectly.

Checking users

The checker prints the user-id and group-id on all servers, but it is necessary to review the report and make sure that UID and GID are the same on all servers. For example, for the quick installation, when the report file is generated in the logs directory, run the following commands on the main installation server:

$ cat full_precheck_200605143427 | grep UID
$ cat full_precheck_200605143427 | grep GID

For the Standard installation, to check the report files, run the above commands on all servers.

Running the check​

Report​

Checking ports​

Checking users​

Running the check

Report

Checking ports

Checking users