Pandora: Metaconsole: Documentation en: Installation
- 1 Installation and Configuration
- 1.1 Installation
- 1.2 Metalicence
- 1.3 Configuration
- 1.3.1 Metaconsole
- 1.3.2 Instances
- 1.3.3 Metaconsole Additional Configuration
- 1.4 Metalicence Synchronization
1 Installation and Configuration
This section includes all the aspects needed in order to install and configure a Metaconsole and its instances(nodes).
Instance and Metaconsole installation requires to be hosted in servers that are connected both ways.
So make sure that:
- The Metaconsole can contact the Instances
- The instances can contact the Metaconsole
To better understand this requirement, take a look at the Metaconsole architecture.
The timezone setting should be the same. The more synchronized the instances and the Metaconsole are, the more exact the displayed data will be.
For example, if an instance has a 5 minute difference regarding the Metaconsole, the display of the time passed since their events were generated, when these data are shown in the Metaconsole, will be false.
An instance or node is a common Pandora FMS Enterprise installation, with its own server and web console.
To learn more about how to install an instance, visit the following link.
A Metaconsole is a Pandora FMS Enterprise installation with a Metaconsole license.
It is necessary to have an active server in order to perform different operations related to the Metaconsole, such as migration, auto-provisioning, service execution...
1.1.3 License Activation
After installing the Pandora FMS Enterprise version console, regardless of the installation method, access the Pandora FMS console (http://IP/pandora_console/) and a welcome screen will appear to accept the license. To find out more about how the license is activated, visit the following []
In order to activate the Metaconsole you need a Metaconsole license. If you activate the node license, the normal console will appear.
From Pandora FMS version 7.0NG, there is a unique license for an environment with Metaconsole. It is possible to create as many instances as needed, as long as the total number of agents inside the Metaconsole is not exceeded.
This license is applied in the Metaconsole and can be synchronized in as many instances as desired, allowing centralized management of different agents that will be deployed in those instances.
With this license, if an installation is started from scratch, first install the Meta Console validating its metalicence. Once validated, register each one of the desired instances (explained in the following sections), later synchronizing the metalicence so that it can work on all of them.
Other than occasional network failures, Pandora FMS nodes must be able to reach Pandora FMS Metaconsole at all times. If you need to support nodes that may go offline for arbitrarily large time periods, contact Ártica ST at [email protected].
In order for instances to communicate with the Metaconsole and the other way around, configure both sides correctly.
22.214.171.124 Instance registration and configuration
In the Metasetup section, you may register and configure the Instances to which the Metaconsole will be linked.
To register a new instance, it is required to know a series of parameters referring to the instance to be handled. If it is a registration of an instance that has not yet been registered with a license, the default data are:
- Server name: localhost.localdomain
- Auth token: empty
- Console URL: http://IP/pandora_console
- API password: empty
- DB host: database IP
- DB name: pandora
- DB user: pandora
- DB password: pandora
- DB port: 3306
- Control user: admin
- Console password: pandora
To ensure connectivity between node and Metaconsole, configure manually the connection data.
- Metaconsole DB host: database IP
- Metaconsole DB name: pandora
- Metaconsole DB user: pandora
- Metaconsole DB password: pandora
- Metaconsole DB port: 3306
These fields indicate the configuration of the connection that the node will establish against the Metaconsole.
If it is a Pandora FMS installation where a valid license has already been included in the instance, obtain these data from the setup of the instance and its database.
Instances can be modified, deactivated and deleted in configured instance view. There are some indicators that check certain information of the setup of each instance. These checks are done when loading this view, but they can also be done individually by clicking on them.
The indicators are the following:
- Database: If the instance database has been misconfigured or you do not have the necessary permissions, the indicator will be red and will give information about the problem.
- API: This indicator will test the instance API. If it fails, it will give information about the failure.
- Compatibility: This indicator makes a check of some requirements between instance and Metaconsole. The name of the instance server, for example, must match its given name in the Metaconsole configuration.
- Event Replication: This indicator shows whether the instance has event replication enabled, whether events have already been received from the instance and how long ago the last replication was.
- Agent cache: This indicator states that the last node agent and module status have been correctly saved in the Metaconsole database. When there is a change, only said change will be modified in the database.
- Synchronization: This indication refers to the possibility of being able to synchronize the different elements from the Metaconsole to the instances.
The first three indicators must be green in order for the instance to be properly linked and for its data to appear. On the other hand, the Event Replication indicator only gives information about this feature.
Once you have chosen to replicate the events, all their management will be done from the Metaconsole, leaving instance events as merely informative.
126.96.36.199 Index Scaling
Most of the synchronization between the Metaconsole and instances is done by name, regardless of the internal ID of the elements, with the exception of groups, tags, alerts, operating systems and module groups, whose IDs must be synchronized.
In order to 'ensure that the IDs of the groups, tags, alerts, operating systems and module groups that are synchronized from the Metaconsole do not exist in the instances, increase the AUTO_INCREMENT value of the tgrupo, ttag, talert_templates, talert_actions, talert_commands, tconfig_os and tmodule_group tables noticeably. That way, you will give a wide margin in the event that elements are created in the instances for reasons beyond the control of the Metaconsole.
Thus, execute in the Metaconsole's database the following query:
ALTER TABLE tgrupo AUTO_INCREMENT = 3000; ALTER TABLE ttag AUTO_INCREMENT = 3000; ALTER TABLE talert_templates AUTO_INCREMENT = 3000; ALTER TABLE talert_actions AUTO_INCREMENT = 3000; ALTER TABLE talert_commands AUTO_INCREMENT = 3000; ALTER TABLE tconfig_os AUTO_INCREMENT = 3000; ALTER TABLE tmodule_group AUTO_INCREMENT = 3000;
If you suspect that the number of elements of an instance created outside the Metaconsole may exceed 3000, a higher value can be set.
To improve Metaconsole event performance in large environments, it is recommended to add the following indexes to the database:
ALTER TABLE tmetaconsole_agent_secondary_group ADD INDEX id_tagente (id_tagente);
188.8.131.52 Report scheduler
It is necessary to install the server packages (open and enterprise) in the system where the Metaconsole is installed in order to launch the database maintenance script ('pandora_db). Make sure that it is correctly programmed for execution in cron every hour (as detailed in the following link.).
If you are going to use on-demand reports (sent by email), program the cron extension execution as it is done in a normal Enterprise console. Usually this is done by typing in the following line into the cron by adjusting the corresponding local paths:
*/5 * * * * <user> wget -q -O - http://x.x.x.x/pandora_console/enterprise/extensions/cron/cron.php >> /var/www/pandora_console/pandora_console.log
Finally, to configure the SMTP to send emails, edit the corresponding parameters in the mail configuration section, which have the following values by default:
In instances, there are a series of parameters to ensure the access of your data with the Metaconsole.
184.108.40.206 Giving access to the Metaconsole
The Metaconsole accesses an instance in two different ways:
- Remote access to the Database to see and edit the data stored in the instances.
- Access to the to the API for some actions such as configuration file edition or NetFlow monitoring
The instance should be configured to guarantee both accesses to the Metaconsole.
As we have said before, you must know the database credentials to configure the instance in the Metaconsole (host, database, user and password).
Besides this, another important point is giving permissions to the user to remotely access the database. It is done with MySQL's GRANT command:
GRANT ALL PRIVILEGES on <MetaconsoleDatabaseName>.* to <UserName>@<HostAddress> IDENTIFIED BY <UserPass>;
GRANT ALL PRIVILEGES on PandoraMetaBase.* to [email protected] IDENTIFIED BY pandora;
The access to the API instance will be guaranteed with the following parameters:
- User and password: It is necessary to know a valid user and password in the instance.
- API password: It is necessary to know the access password to the API that is configured in the instance.
- IP list with access to the API: In the Instance configuration, there is an IP list that could have access to the API. It is possible to use '*' as wildcart to give access to all IPs or to one subnet
In some parts of the Metaconsole, there are accesses to the instance Web Console like, for example, in the event viewer when clicking on the agent associated to an event (if there is one), it will take you to the view of that agent in the console of the instance to which it belongs. Auto-authentication is used for this access. This authentication is done with a hash for which you need a string configured in the instance: The auto-identification password. The password is entered in the "Auth token" field of the instance configuration in the Metaconsole.
This configuration is not necessary to configure the instance in the Metaconsole, but without it, when clicking on one of the links that lead to the instance, you must pass the authentication.
220.127.116.11 Event replication
In order that instance events may be seen in the Metaconsole, these should have access to the Metaconsole database.
The instances will be replicated from time to time, their events saving the date and time of the last replication to continue from there the next time.
Besides event replication, they will make the Metaconsole autovalidation effective. This is for events that are associated to one module, when they will replicate the event to the Metaconsole, they will validate all the previous events that are assigned to the same module.
To configure event replication, activate in the Instance Enterprise Configuration section Event Replication.
This will be configured:
- Interval: How often (seconds) the server will replicate the events generated from the last replication to the Metaconsole database.
- Replication Mode: Whether all events will be replicated or only the ones that are validated.
- Show list of events in the local console (only reading): When event replication is activated, event management will be done in the Metaconsole and in the instance there is not access to them. With this option you will have access to a read-only event view.
- Metaconsole database credentials : Host, database, user, password and oort (if the port is not indicated the port by default will be used).
Event replication is done by the server. In the configuration file there should be the following enabled token: event_replication 1
If you add in a Metaconsole a new node which already contains lots of events, it could take a long time to copy all the events to the Metaconsole
If you want to alter the date from which the node will synchronize events with the target Metaconsole (for example, to force event replication from the current date), execute this SQL query against the node database for Pandora FMS versions older than 5.1SP3:
UPDATE tconfig SET `value` = UNIX_TIMESTAMP() WHERE `token` = "replication_copy_last_utimestamp"
For versions newer than 5.1SP3, execute the following query:
UPDATE tconfig SET `value` = (SELECT MAX(id_evento) FROM tevento) WHERE `token` = "replication_copy_last_id";
18.104.22.168 Autoprovisioning from the node
From Pandora version 7 onwards, you may find in the Metaconsole configuration setup, the option to register the node in the Metaconsole.
You can also check if it arrives via api to the Metaconsole and whether the node is registered in the Metaconsole.
Indicate the correct credentials for connecting to the node, database and API.
The first time this configuration is carried out, it is possible to enter an API password. In case of update, the node password is established.
Advanced options configuration is the one sent to the node to connect to the database
1.3.3 Metaconsole Additional Configuration
The Metaconsole, if the node events replication has been activated, store event data in its own database. For their maintenance these data can be deleted and/or move to the metaconsole history event ddb. THis is done, as in a pandora instance, through the execution of the ddbb maintenance script that is at/usr/share/pandora_server/util/pandora_db.pl. Usually, to launch it the server file is used, only that as it is a metaconsole, there is no server. To do this, get a copy o fhe file /etc/pandora/pandora_server.conf from one of the nodes, edit it, and modify the data related to the DDBB (hostname, DDBB name, user and password) and save the file, for example as:
Create an script at /etc/cron.daily/pandora_meta_db with the following content:
And modify the permissions of it through chmod:
chmod 755 /etc/cron.daily/pandora_meta_db
In order to could execute it, it is necessary that you have installed the necessary packages to execute (even if it doesn't) the Pandora FMS server and its Enterprise part.
Execute it manually to check that it works and it doesn't report errors:
1.4 Metalicence Synchronization
Next, let's see an example of how to synchronize the Metalicence between a Metaconsole and an Instance.
First, we have an instance with its own key generated and correctly validated.
Once we have the node generated and properly validated, then configure it in the Metaconsole to later synchronize the license:
When we have these steps, we will go to the Metaconsole license and give "Validate and sync" to synchronize the Metalicence with the Instance.
The result will be that we will have the Metalicence in the Instance as can be seen below: