Resolve migration prerequisite check issues

Message in CLI

Description

How to resolve

(log data about prerequisite checks are found in /var/log/algosec-software-upgrade.log)

Version incompatible between nodes

Verifies that all installed products are in the same version + build on both source and migration target.

Update the build files so source and migration target have the same build.

For details, see raw version data and valuesfor comparison in the log.

All ASMS services on source node ([source node IP]) must be OK prior to migration 
The following services are not OK:

Checks status of services on migration target.

First, try to restart the services. Run for each service:

algosec_test_service -n <SERVICE NAME> -f

for example, algosec_test_service -n postgresql -f

If services do not restart, contact AlgoSec support.

The following nodes are unreachable from 
migrated server

Checks if all remote nodes are reachable from migration target.

Open ports. See Required port connections.

For details, see Failed to check connectivity between migration IP {​​}​​ and dist node {​​} in the log.​​

Remote node must be a 
standalone machine

Verifies that migration target machine is standalone.

The target machine must be a clean machine deployed directly from AlgoSec image installation.

License prerequisite check failed with:
License file is not installed

Verifies license on migration target IP.

Install license on target machine. See and ASMS licensing

License prerequisite check failed with:
The target license includes fewer components 
than the source license in the following modules
Verifies license on migration target IP.

Contact AlgoSec to add missing components to the target license. Insufficient license may cause problems.

For details, Localhost license modules: and Migration [migration IP] license modules: see in the log.

Firewall(s) detected filtering traffic between source (x.x.x.x) and target (x.x.x.x) for the following ports: [ports]

Verifies that traffic on ports 443 (https), 5432 (postgresql), and 9595 (HA/DR) is not filtered between source & migration target.

Check with your IT department that firewall(s) allow traffic on these ports (bi-directional).

Tip: You can check if the filter has been removed by:

  1. From source to target: run this command in SSH on the source:

nmap -n -p <port> <ip target> 2>&1| grep -q filtered && echo "Traffic is blocked" || echo "Traffic is allowed"
  1. From target to source: run this command in SSH on the target:

nmap -n -p <port> <ip source> 2>&1| grep -q filtered && echo "Traffic is blocked" || echo "Traffic is allowed"

This only works when this prerequisite finds an issue with the port

Traffic from target (x.x.x.x) to source (x.x.x.x) is NATed (x.x.x.x) 
or
 Traffic from source (x.x.x.x) to target (x.x.x.x) is NATed (x.x.x.x) 

Checks for NATed traffic is between source and target.

Contact your IT department to disable any NAT configuration between source and target machines.

 

Low bandwidth speed found between local node and [machine IP]: (%s) Mbit/s.
Average speed: 160 Mbit/ss Mbit/s
Minimum required: 64Mbit/s Mbit/s:
Checks bandwidth between source and target.

We recommend bandwidth of at least 1Gbit/s (125MB/s). Minimum allowable is 64Mbit/s (8MB/s).

Contact your IT department to determine and adjust, if necessary, your bandwidth between the source and the target machines.

Tip:

Use the following commands to check bandwidth:

  1. Prepare the source machine, enter:

    dd if=/dev/zero of=/data/test-file‬ bs=157286400 count=1 2>&1
    IP=[IP of the target]
  1. Run the test command (then if prompted, type in the password and hit <Enter>):

    scp -o StrictHostKeyChecking=no /data/test-file‬ root@${​​IP}​​:/data/test-file‬

    An example of the output is:

    test-file‬                          100%  150MB 219.9MB/s   00:00

    The network bandwidth in the example is 219.9MB/s.

  1. Clean up the test files by entering:

    rm -f /data/test-file ; ssh root@${​​​​IP}​​​​ rm -f /data/test-file
Not all files in the /var/lib/pgsql/data/ directory are owned by user postgres. 
Checks PostgreSQL files.

Reassign owner of all files in the /var/lib/pgsql/data/ directory to user postgres. Run the following code:

algosec_test_service -n postgresql -k
chown -R postgres:postgres /var/lib/pgsql/data/
algosec_test_service -n postgresql -s
Target machine [IP] could not connect to NAS server [IP] on mount path [/data/...] via NFS4.
Check NAS server connectivity. Check connectivity and make sure NAS is accepting connections from the target machine.
Target machine [IP] has insufficient permission level to NAS server [IP] on mount path [/data/...] via NFS4. 
Checks target machine server permissions level to NAS server. Configure NAS server to allow write permissions for the target machine.
NAS server is defined on target but not on source node. 
Checks target machine connection to NAS when no NAS is defined for the source. Disconnect target node from NAS.
The mail server [IP] on port [PORT] is unreachable from the target node [IP]
 
Checks connectivity from target node to mail server.

Check with your IT department that traffic is allowed from the target machine to the defined mail server in ASMS.

Tip: To check the connectivity, run the following:

echo 'exit' | timeout --signal=9 5 telnet <IP> <PORT> 2>&1 | grep -q 'Connected' && echo "Traffic to mail server is allowed" || echo "Traffic to mail server is blocked"
Detected SSH rate limit through firewall(s) on connection betweensource (x.x.x.x) and target (x.x.x.x) 
Checks SSH traffic between source and target machine.

Ask your IT department to analyze event logs of firewall(s) to determine which encountered an SSH Brute Force Attack.

Disable SSH rate limit on these firewall(s) during the migration procedure.

Postgresql service is not running on source node [IP] 
Reports sync cannot continue.
Checks reports sync utility readiness.

Restart postgresql service on source and try syncing reports again.

Tip: To restart postgresql service, run:

systemctl restart postgresql.service