Server Management

To start or stop manually Pandora FMS server, run the following in a shell console:

• Stop the daemon:

/etc/init.d/pandora_server stop

• Start the daemon:

/etc/init.d/pandora_server start

• Restart the daemon:

/etc/init.d/pandora_server restart

You may monitor the status of pandora_ha through systemd with:

systemctl status pandora_ha.service

There is an essential tool for proper Pandora FMS performance, which is in charge of carrying out these tasks. Its location is:

/usr/bin/pandora_db

This tool, hereinafter pandora_db.pl is included in Pandora FMS server package, so it must be run from a system where there is a Pandora FMS server installed.

pandora_db is a key tool for Pandora FMS to work properly, and that is why its execution is programmed in system cron tasks with an hourly interval. Its execution is configured within file:

/etc/cron.hourly/pandora_db

This tool performs all database maintenance tasks automatically:

• It deletes old data.
• It compresses existing data.
• It checks the consistency of the database for non-existing modules or uninitialized modules.
• It deletes the daily agent contact information.
• It moves all old data to the standby history database.

As mentioned before, pandora_db execution is configured in system cron tasks and although this execution is automatically included in Pandora FMS server installation, it is convenient to check it. Therefore, /etc/cron.hourly/pandora_db must exist and contain the following:

"/usr/bin/pandora_db" "/etc/pandora/pandora_server.conf">/dev/null 2>&1

It is equally important to check permissions and the file's owner. The appropriate file permissions would be 755, which can be granted by running:

chmod 755 /etc/cron.hourly/pandora_db

Regarding the owner, it must be root both for the user and group, which is set executing:

chown root:root /etc/cron.hourly/pandora_db

If necessary, it is possible to launch pandora_db execution manually as it was exposed in the previous section. Execute from a shell the following:

/usr/bin/pandora_db /etc/pandora/pandora_server.conf

To execute manually the maintenance tool and leave it in the background, run:

nohup /usr/bin/pandora_db /etc/pandora/pandora_server.conf

The process will take some time until it loads completely in the background. Then, you may close the shell console window, while the process will still be executed.

The command mysqldump will do a complete database dump of the table structure as well as its contents. This is done by doing a full database dump, both of the table structure as well as their contents. This command has several options to do a backup, and its most basic usage is enough to dump from the same system where the database is hosted.

For instance, to backup pandora database ( root user and password pandora) and dump the result to a file, run the following:

mysqldump -u root -p pandora> /backup/pandoradb_backup.sql

From a backup done that way, you may fully restore the database. Login in MySQL, proceed to create the database that will be restored and then load the backup in that database. Following the previous example (replace mypassword with your password):

mysql -u root -p

CREATE DATABASE pandora;
USE pandora;
SOURCE /backup/pandoradb_backup.sql;
GRANT ALL privileges ON pandora.* TO pandora@localhost IDENTIFIED BY 'mypassword';
exit;

Finally, it is necessary to set configured user permissions again both in Pandora FMS Console and server so they have total access to the database (replace mypassword by your password):

GRANT ALL privileges ON pandora.* TO pandora@localhost IDENTIFIED BY 'mypassword';

There is a script in Pandora FMS server distribution that is used to make a backup and a complete restore of the whole Pandora FMS. This script is conceived to make copies and restoration in systems where the server and the console are located in the same machine.

It is designed to backup and restore the following components:

• Server configuration file(s).
• Files(s) pending execution, as well as remote configuration agent files.
• Database, complete.
• Web Console, complete.

This script needs to run as root. You are the only responsible for this key. It is located at:

/usr/share/pandora_server/util/pandora_backup.sh

In the code repository, there is a small script that is used as Watchdog. This script monitors Pandora FMS status.

Thus you may perform a recovery operation (trying to start Pandora FMS), and if that fails, a warning must be issued. This tool is at:

/usr/share/pandora_server/util/pandora_watchdog.sh

The pandora_watchdog.sh script looks for a file in /usr/bin/pandora_alert with the instructions to generate the alert. This file must be created defining the code to be executed when the watchdog cannot activate the Pandora FMS server. In this example, in addition to warning through a SMS, it stops the Tentacle server:

#!/bin/bash
sendsms +34458474843 "The Pandora FMS has suffered some issue and it cannot be started."
/etc/init.d/tentacle_serverd stop

Grant execution permissions to this script:

chmod 750 /usr/bin/pandora_alert

To launch the Watchdog and leave it workin in the background, execute the following:

nohup /usr/share/pandora_server/util/pandora_watchdog.sh &

A history database is a database where old module data are transferred to make the main Pandora FMS database more responsive for everyday operations. Those data will still be available for Pandora FMS console when viewing reports, module charts etc.

To configure a history database, it is necessary to have a new server where to host it (different from the one of the main database). Once you have that server where MySQL is installed, follow these steps:

In Pandora FMS console, go to Management → Setup → Setup → History database to access connection configuration (Configure connection target).

Fill in the following fields:

• Host: Host name (web link or IP address) of the history database.
• Port: Connection port of the history database. Stardard value: 3306.
• Database name: Name of the history database. Default value: pandora.
• Database user: History database user. Default value: pandora.
• Database password: Password of the history database. This will allow to connect to the history database.

The last fields of this form Data days old to keep in active database, Transference block size (Step) and Delay between transferences (seconds) will define the way in which the data will be sent to the history database, that is, the oldest data, those with more than n days (Data days), will be moved to the history database in blocks of n rows (Step) waiting n seconds (Delay) between one block and the next to avoid overloading.

In the same screen, it is also possible to decide whether to send events with more than n days to the history database (Events days old to keep in active database), although it must be taken into account that including the events will considerably increase the growth rate of the history database, and that these will only be checked when generating reports, not in the event view.

Go back to Pandora FMS documentation index