Difference between revisions of "Pandora: Metaconsole: Documentation en: Installation"

From Pandora FMS Wiki
Jump to: navigation, search
(Report scheduler)
 
(60 intermediate revisions by 9 users not shown)
Line 5: Line 5:
  
  
In this section will be included all the aspects needed in order to install and configure a Metaconsole and their Instances.
+
This section includes all the requirements to install and configure a Metaconsole and its instances(nodes).
  
  
 
== Installation  ==
 
== Installation  ==
  
The installations of the  Instances and the Metaconsole requires to be '''hosted in servers that are communicated''' in both ways.
+
Instance and Metaconsole installation must be '''hosted in servers connected''' both ways.
  
In order to do these we should verify that:
+
So, make sure that:
  
* The Metaconsole can contact with the Instances  
+
* The Metaconsole can contact the Instances  
* The Instances can contact with the Metaconsole  
+
* The instances can contact the Metaconsole  
  
{{Tip|The Instances don't need to be communicated between them at any moment}}
+
{{Tip|Instances do not need to communicate with each other.}}
  
To understand better this requirement you can take a look to [[Pandora:Metaconsole:Documentation_en:Arquitecture|Metaconsole architecture]].
+
To better understand this requirement, take a look at [[Pandora:Metaconsole:Documentation_en:Arquitecture|Metaconsole architecture]].
  
The '''timezone setting''' should see the same. The more synchronized would be the Instances and Metaconsole would be, more exact will be the visualized data.  
+
The '''timezone setting''' should be the same. The more synchronized instance and Metaconsole times are, the more accurate the displayed data will be.  
  
For example: If an Instance has 5 minutes of difference with the Metaconsole, the visualization of the time that have passed since their events were generated when these data are shown in the Metaconsole they will be false.
+
For example, if an instance has a 5-minute difference regarding the Metaconsole, when these data are shown in the Metaconsole, the display of the time lapse since the events were generated will be false.
  
 
=== Instances===
 
=== Instances===
  
One Instance is a Pandora FMS Enterprise typical installation: '''One instance is composed of one Server and one Web Console'''. All details about how to install the Instances will be found in the documentation section [[Pandora:Documentation_en:Installing|Pandora FMS Installation]].
+
An instance or node is a common Pandora FMS Enterprise installation made up by its own '''server''' and '''web console'''.
 +
 
 +
To learn more about how to install an instance, visit the following [[Pandora:Documentation_en:Installing|link.]]
  
 
=== Metaconsole ===
 
=== Metaconsole ===
  
A Metaconsole is a Pandora FMS Enterprise installation with a metaconsole license.
+
A Metaconsole is a Pandora FMS Enterprise installation with a Metaconsole license.
 +
 
 +
 
 +
{{Tip|It is not possible to use the Pandora FMS console and Metaconsole at the same time.}}
 +
 
 +
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, etc.
  
 +
=== License Activation ===
  
{{Tip|It is not possible to use at the same license the Pandora FMS console and the Metaconsole}}
+
After installing Pandora FMS Enterprise console, regardless of the installation method, access the Pandora FMS console (<nowiki>http://IP/pandora_console/</nowiki>) and a welcome screen will appear to activate the license. To find out more about how the license is activated, visit the following [[https://wiki.pandorafms.com/index.php?title=Pandora:QuickGuides_EN:General_Quick_Guide#Enterprise_license_activation|link.]]
  
''' The Metaconsole is only the Web Console''' It doesn't use server so it will not host agent neither monitors'''
+
{{Tip|In order to activate the Metaconsole, you need a Metaconsole license. If you activate the node license, the normal console will appear.}}
  
In some cases it could be necessary the server libraries to execute the database maintenance script in the Metaconsole. To simplify it, this is done installing the server but without firing it.
+
== Metalicence ==
  
=== Metaconsole Additional Configuration ===
+
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 Metaconsole validating its metalicence. Once validated, register each and every one of the desired instances (explained in the following sections), later synchronizing the metalicence so that you may work on all of them.
 +
 
 +
Apart from 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 long time periods, contact Ártica ST at [mailto:[email protected] [email protected]].
 +
 
 +
== 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:
+
In order for instances to communicate with the Metaconsole and the other way around, configure both sides correctly.
  
/etc/pandora/pandora_meta.conf
+
=== Metaconsole ===
 +
 
 +
==== Instance registration and configuration ====
  
Create an script at  /etc/cron.daily/pandora_meta_db  with the following content:
+
In the Metasetup section, you may register and configure the Instances to which the Metaconsole will be linked.
  
/usr/share/pandora_server/util/pandora_db.pl /etc/pandora/pandora_meta.conf
+
To register a new instance, it is required to know a series of parameters referring to the instance to be handled. If it is the registration of an instance that has not yet been registered through a license, the default data are:
  
And modify the permissions of it through chmod:
+
* '''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
  
chmod 755 /etc/cron.daily/pandora_meta_db
+
<b>Advance Field</b>
  
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.
+
To ensure connectivity between node and Metaconsole, configure the connection data manually.
  
Execute it manually to check that it works and it doesn't report errors:
+
* '''Metaconsole DB host''': database IP
 +
* '''Metaconsole DB name''': pandora
 +
* '''Metaconsole DB user''': pandora
 +
* '''Metaconsole DB password''': pandora
 +
* '''Metaconsole DB port''': 3306
  
/etc/cron.daily/pandora_meta_db
 
  
=== Metaconsole License Activation ===
+
These fields indicate the configuration of the connection that the ''node'' will establish against the ''Metaconsole''.
  
After installing the Enterprise version's Pandora FMS Console by any installation method, you're required to access the Pandora Console (http://IP/pandora_console/). Subsequently, the following welcome screen to accept the license is going to appear:
 
  
<br>
 
 
<center>
 
<center>
[[Image:license_accept.png]]
+
[[image:Configure_Instances_editor.png]]
 
</center>
 
</center>
<br>
 
  
After accepting the license, the Pandora FMS Database schema is going to change, adding required new tables for the use of the Enterprise Version. In this moment, a new screen to register the license key, which Artica has sent to you, is going to appear:
+
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.
  
<br>
 
 
<center>
 
<center>
[[Image:license_setup.png]]
+
[[image:Configure_Instances_list_new.png]]
 
</center>
 
</center>
<br>
 
  
In order to activate the metaconsole you need a valid metaconsole license. If you use a standart pandora fms license then the standard console would appear after activating the license.  
+
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 checks 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 indicator 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.
 +
 
 +
{{Tip|An Instance can be well configured, but without replicating its events.}}
  
== Metalicencia ==
+
{{Tip|Once you have chosen to replicate the events, all their management will be done from the Metaconsole, keeping instance events as merely informative.}}
  
A partir de la versión 7.0NG de PandoraFMS disponemos de una licencia única para el entorno de Metaconsola. Esta licencia se aplica únicamente en la Metaconsola y se sincroniza con el resto de instancias permitiendo una centralización del número de agentes que hay desplegado en todo el entorno, pudiendo realizar de forma dinámica la asignación de agentes entre las diferentes instancias de Pandora FMS siempre y cuando no se sobrepase el número de agentes total dentro de la Metaconsola.
+
{{Warning|If database encription is enabled, <b>the nodes and the metaconsole must use the same encryption_passphrase configuration</b>.}}
  
De esta forma en una instalación desde cero de Metaconsola e instancia, el primer elemento que hay que instalar es la Metaconsola y una vez registrada la misma se van añadiendo las diferentes instancias.
+
==== Index Scaling ====
  
=== Dar de alta una nueva instancia perteneciente a un entorno de Metaconsola ===
+
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.
  
Para ello realizamos  el proceso de [[Pandora:Documentation_es:Instalacion|instalación]] habitual de cualquier instancia. Una vez que se haya creado correctamente la base de datos y estemos en la pantalla que nos pide la introducción de la licencia:
+
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 provide a leeway in the event that elements are created in the instances for reasons beyond the Metaconsole.  
  
<br>
+
Thus, execute in the Metaconsole's database the following query:
<center>
 
[[Image:license_setup.png]]
 
</center>
 
<br>
 
  
Procedemos a dar de [[Pandora:Metaconsole:Documentation_es:InstallAndConfigure#Configuraci.C3.B3n_de_las_Instancias|alta la instancia]] en la Metaconsola. Para que se pueda dar de alta correctamente debemos realizar los "grants" necesarios en la base de datos de Metaconsola y nodos. Una vez estén todas las bases de datos con acceso, procedemos a registrar la instancia en la Metaconsola.
+
ALTER TABLE tgrupo AUTO_INCREMENT <nowiki>=</nowiki> 3000;
 +
ALTER TABLE ttag AUTO_INCREMENT <nowiki>=</nowiki> 3000;
 +
ALTER TABLE talert_templates AUTO_INCREMENT <nowiki>=</nowiki> 3000;
 +
ALTER TABLE talert_actions AUTO_INCREMENT <nowiki>=</nowiki> 3000;
 +
ALTER TABLE talert_commands AUTO_INCREMENT <nowiki>=</nowiki> 3000;
 +
ALTER TABLE tconfig_os AUTO_INCREMENT <nowiki>=</nowiki> 3000;
 +
ALTER TABLE tmodule_group AUTO_INCREMENT <nowiki>=</nowiki> 3000;
  
En el apartado de Metasetup, se podrá configurar las Instancias con las que se enlazará la Metaconsola.
+
{{Tip|If you suspect that the number of elements of an instance created outside the Metaconsole may exceed 3000, a higher value can be set.}}
  
La configuración de una instancia tiene una serie de parámetros que debemos [[Pandora:Metaconsole:Documentation_es:InstallAndConfigure#Instancias_2|configurar y obtener]] de las Instancias:
+
{{Warning|To improve Metaconsole event performance in large environments, it is recommended to add the following indexes to the database:
  
<center><br><br>
+
<b>ALTER TABLE</b> tmetaconsole_agent_secondary_group <b>ADD INDEX</b> id_tagente (id_tagente);
[[image:Configure_Instances_editor.png|1600px]]
+
<br>
</center><br><br>
+
<b>ALTER TABLE</b> tmetaconsole_event <b>ADD INDEX</b> server_id (server_id);}}
  
Una vez creada la instancia, se configuraran todos los elementos automáticamente en la instancia y se habrá registrado correctamente la instancia pudiendo a partir de ahora levantar el servicio del servidor de Pandora en la instancia y empezar a desplegar la monitorización.
+
==== Report scheduler ====
  
<center><br><br>
+
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 [[Pandora:Documentation_en:Managing_and_Administration#Cron_Job|link.]]).
[[image:Instancia_correcta.png|1600px]]
 
</center><br><br>
 
  
En el caso de tratarse de una actualización de licencia de Pandora FMS, se deberá actualizar la licencia dentro de la Metaconsola y pulsar sobre Validar y Sincronizar. Automáticamente se sincronizará la licencia en todas las instancias instaladas dentro de la Metaconsola.  
+
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, adjusting the corresponding local paths:
  
<center><br><br>
+
  */5 * * * * <user> wget -q -O - <nowiki>http://x.x.x.x/pandora_console/enterprise/extensions/cron/cron.php</nowiki> >> /var/www/pandora_console/log/console.log
[[image:Sync_license.png|1600px]]
 
</center><br><br>
 
  
Si alguna de las instancias no ha sincronizado correctamente su licencia, habra que forzar su sincronización en el apartado licencia de la metaconsola o en su defecto volver a registrar la instancia de nuevo en la Metaconsola.
+
{{Warning|For versions prior to 747 the path will be <b>/var/www/pandora_console/padora_console.log</b>.}}
  
== Configuration ==
+
Finally, to configure SMTP to send emails, edit the corresponding parameters in the mail configuration section, which have the following values by default:
  
In order that Instances could communicate with the Metaconsole and vice versa, you should configure both sides correctly.
+
<center>
 +
[[image:Mail_metaconsola.png]]
 +
</center>
  
 
=== Instances ===
 
=== Instances ===
  
In Instances, there are a serial of parameters to ensure the access of your data with the Metaconsole.
+
In instances, there are a series of parameters to ensure the access of your data with the Metaconsole.
  
 
==== Giving access to the Metaconsole ====
 
==== Giving access to the Metaconsole ====
  
The Metaconsole could have access to one Instance in two different ways:
+
The Metaconsole accesses an instance in two different ways:
  
* Remote access to the '''Data Base''' to see and edit the data stored in the instances.
+
* Remote access to the '''Database''' to see and edit the data stored in the instances.
* Access to the to the '''API''' for some actions like the edition of configuration files or the NetFlow monitoring
+
* 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.
+
The instance should be configured to '''guarantee both accesses''' to the Metaconsole.
  
 
===== Database=====
 
===== Database=====
  
It will be necessary to know the database '''credentials''' to configure later the Instance in the Metaconsole (Host, Database, Users and Password). Other important thing is to ''' give permissions''' to the user so he could have remote access to the database. It is done with the MySQL GRANT command:
+
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 ''' grantig 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>;
 +
 
 +
For example:
  
  GRANT ALL PRIVILEGES on <MetaconsoleDatabaseName>.* to <UserName>@<HostAddress> IDENTIFIED BY '<UserPass>';
+
  GRANT ALL PRIVILEGES on PandoraMetaBase.* to adminmeta@localhost IDENTIFIED BY pandora;
  
 
===== API =====
 
===== API =====
  
The access to the Instance API will be guaranteed with the following parameters:
+
The access to the API instance will be guaranteed with the following parameters:
  
* '''User and password''': It should be necessary to know a valid user and password in the Instance.
+
* '''User and password''': It is necessary to know a valid user and password in the instance.
* '''API password''': It should be necessary to know the access password to the API that is configured in the Instance.
+
* '''API password''': It is necessary to know the access password to the API that is configured in the instance.
* '''IPs List with access to the API''': In the Instance configuration, there is an IPs list that could have access to the API. It is possible to use <nowiki>'*'</nowiki> as wildcart to give access to all IPs or to one subnet
+
* '''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 <nowiki>'*'</nowiki> as wildcard to give access to all IPs or to one subnet
 +
 
 +
<center>
 +
[[File:Imagen setup2.png]]
 +
</center>
  
 
==== Auto-authentication ====
 
==== Auto-authentication ====
  
In some parts of the metaconsole there are accesses to the Instance Web Console.
+
In some parts of the Metaconsole, there are accesses to the instance Web Console. 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 it belongs to. 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.
  
For example, in the event visor, when you click on the Agent that is associated to one event (if there is one) it will take us to the view of this agent in the console of the Instance to which it belongs to.
+
<center>
 +
[[image:autologin hash.png]]
 +
</center>
  
For this access the Auto-authentication is used.
+
{{Tip|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.}}
  
This authentication is done with a ''hash'' for which is necessary one string that is configured in the Instance:'' The autoidentification  password''.
+
==== Event replication ====
  
This configuration is not necessary to configure the Instance in the Metaconsole, but without it, if you click on one of the links that take us to the Instance, we should have to authenticate
+
In order for instance events to be seen in the Metaconsole, these should have access to the Metaconsole database.
  
==== Event Replication ====
+
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.
  
In order that in the Metaconsole could be seen the Instance events, these should have access to the Metaconsole database.
+
Besides event replication, they will make Metaconsole autovalidation effective. This is for events that are associated to a module, when they replicate the event to the Metaconsole, they will validate all the previous events that were assigned to the same module.
  
The Instances will replicate from time to time their events saving the date and hour of the last replicated to continue from there the next time
+
To configure event replication, activate in the Instance Enterprise Configuration section ''Event Replication''.
 
 
Besides the event replication, they will do effective the Metaconsole autovalidation. This is, for the 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 the event replication, in the Instance Enterprise Configuration section be should activate the ''Event Replication''.
 
  
 
This will be configured:  
 
This will be configured:  
  
* '''Intervale''': Every how many seconds the server will replicate the events generated from the last replication to the Metaconsole database.
+
* '''Interval''': How often (seconds) the server will replicate the events generated from the last replication to the Metaconsole database.
  
{{Tip|If is configured, for example 60 seconds, the first replication will happen 60 seconds after the server has been started.}}
+
{{Tip|If it is 60 seconds, the first replication will happen 60 seconds after the server was started.}}
  
* '''Replication Mode''': If all events will be replicated or only the ones that are validated.
+
* '''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 the event replication is activated, the 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 view of events in only reading mode.
+
* '''Show list of events in the local console (only reading)''': When event replication is activated, event management is done in the Metaconsole and there is not access to them in the instance. With this option you will have access to a read-only event view.
  
* '''Metaconsole Database Credentials ''': Host, Database, Users,Password and Port (Is the port is not indicted the port by default will be used).
+
* '''Metaconsole database credentials ''': Host, database, user, password and port (if the port is not indicated, the port by default will be used).
  
 
+
<center>
<center><br><br>
 
 
[[image:Replication_events_setup.png]]
 
[[image:Replication_events_setup.png]]
</center><br><br>
+
</center>
  
The event replication is done by the server. In the configuration file should be an enabled token:
+
Event replication is done by the server. In the configuration file there should be the following enabled token: ''event_replication 1''
  
<center><br><br>
+
<center>
 
[[image:Replication_events_conf_token.png]]
 
[[image:Replication_events_conf_token.png]]
</center><br><br>
+
</center>
  
{{Warning|To do effective any configuration change in the event replication it will be necessary to restart the server.}}
+
{{Warning|Restart the server to apply any event replication configuration changes.}}
  
{{Warning|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}}
+
{{Warning|If you add in a Metaconsole a new node which already contains lots of events, it could take a lot of time to copy all the events to the Metaconsole}}
  
If you want to alter the date since node is going to synchronize events with the target metaconsola (for example, to force event replication from the current date), you need to execute this SQL sentence in the node database for versions of Pandora older than 5.1SP3:
+
If you want to modify 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"
 
  UPDATE tconfig SET `value` = UNIX_TIMESTAMP() WHERE `token` = "replication_copy_last_utimestamp"
  
For versions newer than 5.1SP3 execute the following query:
+
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";
 
  UPDATE tconfig SET `value` = (SELECT MAX(id_evento) FROM tevento) WHERE `token` = "replication_copy_last_id";
  
{{Warning|If you have activated the child nodes SELinux security, the event replication may not work. Please disable it.}}
+
{{Warning|If you have activated the child nodes SELinux security, event replication may not work. Disable it.}}
  
=== Metaconsole ===
+
==== Autoprovisioning from the Metaconsole ====
  
==== Giving access to the Instances ====
+
From Pandora version 7 onwards, you may find in the Metaconsole configuration setup, the option to register the node in the Metaconsole.
  
Same way as the Instances give [[Pandora:Metaconsole:Documentation_en:Installation#Giving_access_to_the_Metaconsole|access to the Metaconsole]] to have a remote access to the database, the Metaconsole should do the same, so the Instances could replicate their events.
+
You can also check whether 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.
  
==== Instances Configuration ====
+
{{Tip|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.}}
  
In the Metasetup section, it will be possible to configure the Instances with which the Metaconsole will be linked.
+
Advanced options configuration is the one sent to the node to connect to the database.
  
The configuration of one instance has a serial of parameters that we should [[Pandora:Metaconsole:Documentation_en:Installation#Instances_2|configure and retrieve]] from the Instances:
+
<br>
 +
<center>
 +
[[Image:Autoprovision nodo formuario.png |850px]]
 +
</center>
 +
<br>
  
<center><br><br>
+
=== Metaconsole Additional Configuration ===
[[image:Configure_Instances_editor.png|800px]]
 
</center><br><br>
 
  
In the view of the configured Instances, we will see that the Instances can be edited, disabled and deleted.
+
If the node event replication has been activated, the Metaconsole stores event data in its own database. For their maintenance these data can be deleted and/or moved to the Metaconsole history event database. This is done, as in a Pandora FMS instance, through the execution of the database maintenance script that is at''/usr/share/pandora_server/util/pandora_db.pl''. Usually, to launch it the server file is used. But since it is a Metaconsole there is no need for a server. To do this, copy fhe file /etc/pandora/pandora_server.conf from one of the nodes, edit it, and modify the data related to the database (hostname, DDBB name, user and password) and save the file, for example as:
  
Besides, there are some indicators that checks some information of the configuration of each Instance. These checks are done when loading this view, but the can also be done individually clicking on them.
+
/etc/pandora/pandora_meta.conf
  
<center><br><br>
+
Create an script at  /etc/cron.daily/pandora_meta_db  with the following content:
[[image:Configure_Instances_list.png|800px]]
 
</center><br><br>
 
  
The indicators are these:
+
/usr/share/pandora_server/util/pandora_db.pl /etc/pandora/pandora_meta.conf
  
* '''Database''':If we haven't configured right the Instance database we won't have the necessary permission, the indicator will be red and it will give us information about the problem.
+
And modify the its permissions through chmod:
* '''API''': This indicator will do a test to the Instance API. If it fails it will report information about the failure to us
 
* '''Compatibility''':This indicator will do a check of some requirements that should be between the Instance and the Metaconsole. The Instance server name, for example, should match with the name that we give to it in its configuration in the metaconsola.
 
* '''Event Replication''': This indicator shows if the Instance has activated the event replication and if the events from the Instance have been alredy received and how long ago was the last replication.
 
  
The three first indicators should be in green color so the Instance should be correctly linked and we start viewing their data.However, the event Replication events will give us only information about this feature.
+
chmod 755 /etc/cron.daily/pandora_meta_db
  
{{Tip| One Instance could be configured correctly but with their events not replicated}}
+
In order to execute it, it is necessary for you to have installed the necessary packages to execute (even if it does not) the Pandora FMS server and its Enterprise section.
  
==== Index Scaling ====
+
Execute it manually to check that it works and it does not report errors:
  
Most of the synching between the metaconsole and instances is performed according to name, independent from the elements' internal IDs.  
+
/etc/cron.daily/pandora_meta_db
  
As exceptions to this, there are groups, tags and alerts, that should have synchronized IDs as something important.
+
== Metalicence Synchronization==
  
In order to '''make sure that the group, tag, alert, operating system and module group IDs that synchronize from the metaconsole don't exist on instances''', we'll raise the AUTO_INCREMENT value significantly in the tgroup, ttag, talert_templates, talert_actions, talert_commands, tconfig_os and tmodule_group. This way we'll give a larger margin in case elements are created on instances by causes external to the metaconsole.
+
Next, there is an example of how to synchronize the Metalicence between a Metaconsole and an Instance.
  
For this, we'll run the following query on the metaconsole database:
+
First, there is an instance with its own generated and correctly validated key.
  
ALTER TABLE tgrupo AUTO_INCREMENT <nowiki>=</nowiki> 3000;
+
<center>
ALTER TABLE ttag AUTO_INCREMENT <nowiki>=</nowiki> 3000;
+
[[image:Nodo_licenciasuya.png]]
ALTER TABLE talert_templates AUTO_INCREMENT <nowiki>=</nowiki> 3000;
+
</center>
ALTER TABLE talert_actions AUTO_INCREMENT <nowiki>=</nowiki> 3000;
 
ALTER TABLE talert_commands AUTO_INCREMENT <nowiki>=</nowiki> 3000;
 
ALTER TABLE tconfig_os AUTO_INCREMENT <nowiki>=</nowiki> 3000;
 
ALTER TABLE tmodule_group AUTO_INCREMENT <nowiki>=</nowiki> 3000;
 
{{Tip|If we are suspicious that the number of elements from an instance created with independence to the metaconsole can go over 3000, we can give it a larger value.}}
 
  
==== Report scheduler / Pandora_DB maintance script  ====
+
Once the node is generated and properly validated, it is configurd in the Metaconsole to later synchronize the license:
  
Metaconsola doesnt have a "server", but you need to install packages (open & enterprise) in the system where metaconsole is executed because you need to launch each hour the ''pandora_db'' maintance script. Please be sure you scheduled it in cron, it's the piece of server which execute the metaconsole event purge and who moves the events not validated to the event history table.  
+
<center>
 +
[[image:Sincronodo_meta2.png]]
 +
</center>
  
If you also want to use on-demand reports sent by email, you need to setup the periodic execution of cron extension, in the same way you setup in a regular Enteprise console. Create a file called ''/etc/cron.d/pandora_cron_extension'' with following contents (adapt paths and IP address to the paths in your system).
+
Once these steps are finished, the Metaconsole license is "Validated" to synchronize the Metalicence with the Instance.
  
  */5 * * * * <user> wget -q -O - http://x.x.x.x/pandora_console/enterprise/extensions/cron/cron.php >> /var/www/pandora_console/pandora_console.log
+
<center>
 
+
[[image:Meta_sincrolicencia.png]]
Remember also to setup the cron SMTP settings, by editing the file '/enterprise/extensions/cron/email_config.php':
+
</center>
  
<pre>
+
The result will be the Metalicence in the Instance.
  //Please setup your config to send emails in cron job
 
  $cron_email_from = array('[email protected].org' => 'Pandora FMS');
 
  $cron_email_smtpServer = 'mail.artica.es';
 
  $cron_email_smtpPort = 25;
 
  $cron_email_username = '';
 
  $cron_email_password = ;
 
</pre>
 
  
  

Latest revision as of 14:29, 10 June 2020

Go back to Pandora FMS documentation index


1 Installation and Configuration

This section includes all the requirements to install and configure a Metaconsole and its instances(nodes).


1.1 Installation

Instance and Metaconsole installation must be hosted in servers connected both ways.

So, make sure that:

  • The Metaconsole can contact the Instances
  • The instances can contact the Metaconsole

Info.png

Instances do not need to communicate with each other.

 


To better understand this requirement, take a look at Metaconsole architecture.

The timezone setting should be the same. The more synchronized instance and Metaconsole times are, the more accurate the displayed data will be.

For example, if an instance has a 5-minute difference regarding the Metaconsole, when these data are shown in the Metaconsole, the display of the time lapse since the events were generated will be false.

1.1.1 Instances

An instance or node is a common Pandora FMS Enterprise installation made up by its own server and web console.

To learn more about how to install an instance, visit the following link.

1.1.2 Metaconsole

A Metaconsole is a Pandora FMS Enterprise installation with a Metaconsole license.


Info.png

It is not possible to use the Pandora FMS console and Metaconsole at the same time.

 


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, etc.

1.1.3 License Activation

After installing Pandora FMS Enterprise console, regardless of the installation method, access the Pandora FMS console (http://IP/pandora_console/) and a welcome screen will appear to activate the license. To find out more about how the license is activated, visit the following [[1]]

Info.png

In order to activate the Metaconsole, you need a Metaconsole license. If you activate the node license, the normal console will appear.

 


1.2 Metalicence

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 Metaconsole validating its metalicence. Once validated, register each and every one of the desired instances (explained in the following sections), later synchronizing the metalicence so that you may work on all of them.

Apart from 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 long time periods, contact Ártica ST at [email protected].

1.3 Configuration

In order for instances to communicate with the Metaconsole and the other way around, configure both sides correctly.

1.3.1 Metaconsole

1.3.1.1 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 the registration of an instance that has not yet been registered through 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

Advance Field

To ensure connectivity between node and Metaconsole, configure the connection data manually.

  • 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.


Configure Instances editor.png

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.

Configure Instances list new.png

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 checks 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 indicator 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.

Info.png

An Instance can be well configured, but without replicating its events.

 


Info.png

Once you have chosen to replicate the events, all their management will be done from the Metaconsole, keeping instance events as merely informative.

 


Template warning.png

If database encription is enabled, the nodes and the metaconsole must use the same encryption_passphrase configuration.

 


1.3.1.2 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 provide a leeway in the event that elements are created in the instances for reasons beyond 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;

Info.png

If you suspect that the number of elements of an instance created outside the Metaconsole may exceed 3000, a higher value can be set.

 


Template warning.png

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);
ALTER TABLE tmetaconsole_event ADD INDEX server_id (server_id);

 


1.3.1.3 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, 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/log/console.log

Template warning.png

For versions prior to 747 the path will be /var/www/pandora_console/padora_console.log.

 


Finally, to configure SMTP to send emails, edit the corresponding parameters in the mail configuration section, which have the following values by default:

Mail metaconsola.png

1.3.2 Instances

In instances, there are a series of parameters to ensure the access of your data with the Metaconsole.

1.3.2.1 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.

1.3.2.1.1 Database

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 grantig 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>;

For example:

GRANT ALL PRIVILEGES on PandoraMetaBase.* to [email protected] IDENTIFIED BY pandora;
1.3.2.1.2 API

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 wildcard to give access to all IPs or to one subnet

Imagen setup2.png

1.3.2.2 Auto-authentication

In some parts of the Metaconsole, there are accesses to the instance Web Console. 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 it belongs to. 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.

Autologin hash.png

Info.png

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.

 


1.3.2.3 Event replication

In order for instance events to 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 Metaconsole autovalidation effective. This is for events that are associated to a module, when they replicate the event to the Metaconsole, they will validate all the previous events that were 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.

Info.png

If it is 60 seconds, the first replication will happen 60 seconds after the server was started.

 


  • 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 is done in the Metaconsole and there is not access to them in the instance. With this option you will have access to a read-only event view.
  • Metaconsole database credentials : Host, database, user, password and port (if the port is not indicated, the port by default will be used).

Replication events setup.png

Event replication is done by the server. In the configuration file there should be the following enabled token: event_replication 1

Replication events conf token.png

Template warning.png

Restart the server to apply any event replication configuration changes.

 


Template warning.png

If you add in a Metaconsole a new node which already contains lots of events, it could take a lot of time to copy all the events to the Metaconsole

 


If you want to modify 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";

Template warning.png

If you have activated the child nodes SELinux security, event replication may not work. Disable it.

 


1.3.2.4 Autoprovisioning from the Metaconsole

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 whether 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.

Info.png

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.


Autoprovision nodo formuario.png


1.3.3 Metaconsole Additional Configuration

If the node event replication has been activated, the Metaconsole stores event data in its own database. For their maintenance these data can be deleted and/or moved to the Metaconsole history event database. This is done, as in a Pandora FMS instance, through the execution of the database maintenance script that is at/usr/share/pandora_server/util/pandora_db.pl. Usually, to launch it the server file is used. But since it is a Metaconsole there is no need for a server. To do this, copy fhe file /etc/pandora/pandora_server.conf from one of the nodes, edit it, and modify the data related to the database (hostname, DDBB name, user and password) and save the file, for example as:

/etc/pandora/pandora_meta.conf

Create an script at /etc/cron.daily/pandora_meta_db with the following content:

/usr/share/pandora_server/util/pandora_db.pl /etc/pandora/pandora_meta.conf

And modify the its permissions through chmod:

chmod 755 /etc/cron.daily/pandora_meta_db

In order to execute it, it is necessary for you to have installed the necessary packages to execute (even if it does not) the Pandora FMS server and its Enterprise section.

Execute it manually to check that it works and it does not report errors:

/etc/cron.daily/pandora_meta_db

1.4 Metalicence Synchronization

Next, there is an example of how to synchronize the Metalicence between a Metaconsole and an Instance.

First, there is an instance with its own generated and correctly validated key.

Nodo licenciasuya.png

Once the node is generated and properly validated, it is configurd in the Metaconsole to later synchronize the license:

Sincronodo meta2.png

Once these steps are finished, the Metaconsole license is "Validated" to synchronize the Metalicence with the Instance.

Meta sincrolicencia.png

The result will be the Metalicence in the Instance.


Go back to Pandora FMS documentation index