Frequent errors

The following are typical problems that arise when performing an installation:

• La instalación finaliza exitosamente, sin embargo al ingresar a la URL tenemos un error o directamente no aparece la pantalla de login

Verify that you have disabled SELinux and Firewald (Pre-requisitos).

• When executing the deploy script the lecture of the inventory variables fails.

Verify that the variables (TZ, postgres_user, postgres_password, admin_pass, ami_user, ami_pass and TZ) are uncommented and with an assigned value. Although the default values are used (not recommended in production), the line corresponding to each variable must be uncommented.

• When executing the deploy script the parameter iface fails.

Remember that iface refers to the host’s network interface (eth0, eth1, ens18, ens0s3, etc.).

• The server does NOT have access to the internet / The server does not solve domains
• Timeout failure of some package or repository temporarily unavailable.

In these cases, the deploy must be run again. When using web packages, the temporary unavailability of a repository or web connection can affect the installation.

• Making a mistake when executing an installation method and architecture type regarding the inventory file section.

When executing a Self-Hosted or Deployer-Nodes installation of a classic architecture (AIO) or based on containers, one has to pay special attention to work with the appropriate sections for each combination: [prodenv-aio], [prodenv- docker] and its lines.

• Failure in the Task associated with RTPengine

This happens when the kernel-devel package has not been installed or the package does not match the kernel version (Pre-requisitos).

Errors in the Deployer-nodes installation method

• Lack of permissions when executing the deploy script.

Remember that in the deployer the script must be executed with sudo. Remember that packages like sudo, openssh-server or python-minimal must be installed before running the deploy.sh script.

• The ssh access of the installation target host was not configured correctly.

Check firewall status. Check remote access by ssh with the ** root** user.

Architecture based on docker containers

1. How do I change passwords of docker containers?

There are three important password services:

• OMniLeads web GUI: change the $DJANGO_PASS variable in .env file and restart the omniapp container: docker restart oml-omniapp-prodenv
• Postgresql y MySQL: see the section Changes of network parameters (Hostname and/or IP Address) and changes of passwords of services.

2. The LAN network segment where OML must be deployed is *192.168.15.0/24* or falls within a segment that encompasses it.

By default the docker environment is raised with the internal subnet within the mentioned range. Change the SUBNET variable and use another network segment that does not collide with that of your LAN. This is done in the .env file. Then restart the omnileads-prodenv service.

3. The environment doesn’t start due to docker-compose tells that there is an used port, what should I do?

There are three of Docker Host used to map ports inside containers, these are:

• WD_EXT_PORT=442 –> mapea con el puerto 8080/tcp del contenedor que aloja el componente Wombat Dialer. Esto permite acceder a la GUI de WD.
• NGINX_EXT_PORT=444 –> mapea con el puerto 443/tcp en Omniapp para acceder a la GUI de OMniLeads.