🛠️IT administrator management
IT administrator managment
Environment variables
Through this section is going to be commented the procedures that needs the use of inventory file. As known the file is edited bofer installation and after that it becomes default. But the variables and their values stayes as environment variables.
To check this variables open the file /etc/profile.d/omnileads_envars.sh.
This way the administrator can see them when he/she wants
Important
Do not edit this file.
Configuration of the Predictive Dialer module
Note
First of all, we notify that if the OML instance deployed in the previous steps does not contemplate the use of campaigns with predictive outbound dialer, this step can be omitted.
OMniLeads needs a third-party tool to implement the campaigns with predictive outbound dialer. This tool is based on comercial software licenses that must be managed with the manufacturer.
In any case the system can be used with a test channel that grants as a demo. Therefore we can configure the component and run concept tests before acquiring licenses for a real operation.
If running predictive campaigns is desired, we must generate the following basic Wobal Dialer settings. To generate this configuration we must follow some steps that begin with the access to the corresponding URL.
http://omnileads.yourdomain:8080/wombat or http://XXX.XXX.XXX.OML:8080/wombat
Note
In case of running OMniLeads Dockerized the URL is:http://XXX.XXX.XXX.OML:442/wombat
Where XXX.XXX.XXX.OML is the IP of docker engine host
Creation of database
When enter for the first time, we must proceed with the creation of a MariaDB database that uses Wombat Dialer. Click on the highlighted button in figure 2.
Figure 1: DB create
Then is the moment to ingress root MySQL user password and then click on the button shown in figure 2.
Note
Since OMniLeads 1.6.0 version a MySQL root password is not set, so you can leave this field empty.
We proceed then with the creation of the MariaDB database that will use from now on the Wombat Dialer component.
Figure 2: MariaDB root password
First login
Once created the MariaDB database that Wombat Dialer uses, we proceed with the first login.
Figure 3: Login post db create
A login must be performed then in the Wombat Dialer administration interface to continue with the configuration of the necessary parameters for the OML interaction.
Upon entering a screen like the following is displayed, where we must access with the user and passwords generated within the installation.
Figure 4: Access to WD
Change of web credentials
By default Wombat Dialer comes with the web credentials demoadmin as user and demo as password. These credentials can be changed:
Firstly, the credentials must be defined in the inventory file, these are the variables dialer_user and dialer_password. See about_install_inventory_vars.
Go to Wombat Dialer web, and go to Administration -> Edit users.
Figure 5: WD change credentials
There you can see the user demoadmin, click on the pencil icon, change the user in Login field with the same user you ingressed in the variables dialer user, for password use the same password ingressed in dialer_password.
Finally click on Save button.
Figure 6: WD change credentials 2
Once finished, reload the page and ingress with the new credentials.
AMI credentials
Note
From release-1.8.0 take care of this
Wombat Dialer will use different AMI credentials that OMniLeads uses, for that reason, the AMI user wombatami is created inside the file oml_manager.conf. The password for this AMI user changes depending of what inserted the user in inventory file parameter ami_password. By default the user comes this way:
Basic parameters
Once inside the system, we proceed with the configuration of the two basic parameters to make the integration with OMniLeads ready. To do this we must access the “Basic configuration” menu as indicated in figure 7.
Figure 7: WD basic config
In this menu, first of all, a new conection instance must be generated inside the Asterisk Servers section as exposed in figure 8.
Figure 8: WD basic config - AMI Asterisk
In the next point, a Trunk is configured using an arbitrary “Trunk name”, but with the calling chain marked in figure 9. Local/${num}@from-oml/n
Figure 9: WD basic config - Asterisk Trunk
At last, remember to “play” the dialer service, as indicated in figure 10.
Figure 10: WD activate
Finally the platform is enabled to manage predictive calls. The default installation has a Wombat Dialer demo license for a channel.
Backup/restore of database
You can make a backup/restore of MariaDB dialer database, executing the following commands in the host where Wombat/MariaDB is running.
To perform a Backup:
Where $ubicacion_archivo_dump is the path where you are going to place the dump file
To make the restore, in a new MariaDB server:
You must have the backup file in the new server to restore the database
Change SSL certificates
If you want to change the SSL certificates you need to have yours in .pem format. Rename the files, they must be *cert.pem and key.pem. Then place them in these folders:
After that, restart the following services:
Reset admin web password
If you have forgotten the password for admin user you can reset the same to its default values (admin/admin), for that SSH into OMniLeads and execute this command:
Backup & Restore
OMniLeads has a script to perform the Backup/restore tasks.
Backup
To perform a Backup:
We must access the host where OMniLeads is running through ssh. Once inside the host we execute the following commands.
The execution of the script throws an output similar to the one on figure 11.
As it can be seen, the command output tells us how to do the restore procedure. Inside the path /opt/omnileads/backup, the files “.tar.gz” that contain the backups are generated.
If you dont want to make a database backup you can run script with the –no-database option
Restore
If the restore is performed in a new host, then the file generated in the Backup within the path /opt/omnileads/backup must be left available.
Important
In case of doing the restore in a new instance, it is necessary that the machine has a full OMniLeads running in the same version backup file has been generated from.
To perform a restore, we must execute:
It is no needed to add the full location path of the backup.
Note
If there is no database backup, the restore of database isn’t done
A copy of omnileads_envars-sh file will be placed in /opt/omnileads/bin/omnileads_envars.backup
If the backup includes addons, the restore is going to execute te reinstall of theses addons
Upgrades
OMniLeads create continuously releases, so it’s necessary that you upgrade de software periodically.
Important
Upgrade under release-1.3.1 to release-1.3.1 (including it)
Is ESSENTIAL to know the passwords for postgresql, mysql and django admin that were set during installation. You can see these passwords in my_inventory file and you will have to type them again in inventory file. If the same passwords are not used, the upgrade will set up the passwords you typed in inventory file
If you don’t use the same MySQL password you set during install, the upgrade will fail
Upgrade after release-1.3.1
If you don’t want to change variable values, just define the installation type.
If you want to change some variable, ingress it in inventory file and the upgrade process will change it for you.
**Upgrade from release-1.15.0 (or any previous version) to release-1.16.0 **
In this delivery, the components are extracted from the main repository: rtpengine, asterisk, redis, websocket, kamailio, postgres, and nginx.
They all reside in isolated and dedicated repositories, included as GIT submodules of the main repository of the App. Therefore the upgrade procedure should involve the submodules initialization as indicated below.
Below are the steps to follow in order to perform a new platform update. This task is also performed with the script “deploy.sh”.
Self-Hosted Upgrade
In order to proceed:
Access as root user in the machine with OMniLeads installed
Go over root directory ominicontacto and execute:
Note
Remember that the Tab key when pressing more than once, autocompletes the command displaying all releases.
Next we should position on the directory
Now we proceed with the edition of the inventory file, where only the variables should be adjusted:
Then the script is executed with the -u (update) parameter. This execution will take some minutes and implies applying all the updates downloaded with the “git pull origin master” on our OMniLeads instance.
If everything flows correctly, at the end of the task execution we will see a screen as shown in figure 13.
Figure 13: updates OK
Upgrades using Deployer-Nodes method
The cloned repository should be accessed on our Workstation machine, to run the update on the Linux OMniLeads host.
Remember that the Tab key when pressing more than once, autocompletes the command displaying all releases. Once the release is selected:
Uncomment the line for self-hosted installation in the inventory file
Then the script is executed with the -u (update) parameter. This execution will take some minutes and implies applying all the updates downloaded with the “git pull origin master” on our OMniLeads instance.
Finally, the platform is updated to the last stable version “master”
Figure 14: updates from ansible remote OK
Note
AIO installations will not be supoorted in future for Debian and Ubuntu so, is recommended to use CentOS.
Changes of network parameters (Hostname and/or IP Address) and changes of passwords of services
To do these tasks, you must execute again the deploy.sh script
If you want to change IP/hostname you must inside the server with root user, change the IP/hostname and be sure the system got the changes. A reboot of the system is recommended.
If you want to change passwords edit the password you wish, see about_install_inventory_vars to check the variables related to passwords.
You must execute the deploy.sh script, this way:
Important
You must be sure you run the deploy script in the same release installed in the system, otherwises an upgrade of software will be done.
Users unblock
OMniLeads count with a block users system, when someone enter the wrong password three times. This is the security measure implemented to avoid brute force attacks in the platform’s Login console. The administrator user has the possibility of unblocking any user who has been blocked by entering the wrong password unintentionally.
To unblock it you enter the following URL: https://omnileads-hostname/admin, this URL displays the Django Administrator Console.
Figure 15: Django admin console
There, enter the admin user credentials. Then click on the button Defend
Figure 16: Defender in django admin
This opens the Django Defender administrator (https://github.com/kencochrane/django-defend) which is the Django plugin used to manage this. Click on Blocked Users
Figure 17: Blocked users view
You will see the blocked user. Just click on Unblock to unblock it.
Figure 18: Unblock user view
Now the user can login without problem.
<<<<<<< HEAD Recover & Takeover nodo PostgreSQL HA ********************************** ======= .. _about_recovery_pgsql_ha:
Recovery & Takeover nodo PostgreSQL HA
>>>>>>> develop
Para realizar la recuperacion de un nodo principal que por algun tipo de falla quedo fuera de serivcio y por lo tanto el nodo de backup pasa a ser principal. Para volver a unir nuestro nodo al cluster, se deben ejecutar los siguientes comandos:
<<<<<<< HEADmain_pgsql: systemctl stop postgresql-11 main_pgsql: su postgres - main_pgsql: cd ~ main_pgsql: repmgr -h replica_pgsql -U repmgr -d repmgr -f repmgr.conf standby clone –dry-run main_pgsql: repmgr -h replica_pgsql -U repmgr -d repmgr -f repmgr.conf standby clone -F main_pgsql: systemctl start postgresql-11 main_pgsql: repmgr -f repmgr.conf standby register -F
main_pgsql: repmgr -h ip_backup_node -U repmgr -d repmgr -f repmgr.conf standby clone –dry-run main_pgsql: repmgr -h ip_backup_node -U repmgr -d repmgr -f repmgr.conf standby clone -F main_pgsql: systemctl start postgresql-11 main_pgsql: systemctl start repmgr11 main_pgsql: repmgr -f repmgr.conf standby register -F
>>>>>>> develop Ahora bien, para dejar nuestro cluster en el estado inicial, es decir en la coniguracion de main - backup explicidata en la instalacion, se deben ejecutar la siguiente lista de comandos:
<<<<<<< HEADreplica_pgsql: repmgr -h main_pgsql -U repmgr -d repmgr -f repmgr.conf standby clone –dry-run replica_pgsql: repmgr -h main_pgsql -U repmgr -d repmgr -f repmgr.conf standby clone -F
replica_pgsql: repmgr -h ip_main_node -U repmgr -d repmgr -f repmgr.conf standby clone –dry-run replica_pgsql: repmgr -h ip_main_node -U repmgr -d repmgr -f repmgr.conf standby clone -F
>>>>>>> developreplica_pgsql: systemctl start postgresql-11 replica_pgsql: repmgr -f repmgr.conf standby register -F
OMniLeads unistall
If by any reason you want to unistall OMniLeads from your machine or VM, there is a script for that. It is already incorportaed in the install process, just execute it:
This script:
Unistall the essential services of omnileads: asterisk, kamailio, rtpengine, mariadb, postgreSQL, wombat dialer, redis, nginx and omniapp.
Delete the file /opt/omnileads (including recordings)
Remove the databases
Note
The script does not unistall the dependency packages used to install the services.
Important
Be careful when executing it, once executed there is no way to recover the system.
Última actualización