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

From Pandora FMS Wiki
Jump to: navigation, search
(Database)
(Registration and Configuration of Instances)
Line 77: Line 77:
 
* '''Control user''': admin
 
* '''Control user''': admin
 
* '''Console password''': pandora
 
* '''Console password''': pandora
 +
 +
<b>Campos avanzados</b>
 +
 +
Para garantizar la conectividad entre nodo y Metaconsola, podemos configurar manualmente los datos de conexión.
 +
 +
* '''Metaconsole DB host''': IP de la base de datos
 +
* '''Metaconsole DB name''': pandora
 +
* '''Metaconsole DB user''': pandora
 +
* '''Metaconsole DB password''': pandora
 +
* '''Metaconsole DB port''': 3306
 +
 +
 +
Estos campos indican la configuración de la conexión que establecerá el ''nodo'' contra la ''metaconsola''.
 +
  
 
<center>
 
<center>

Revision as of 15:05, 18 October 2018

Go back to Pandora FMS documentation index


1 Installation and Configuration

In this section will be included all the aspects needed in order to install and configure a Metaconsole and their Instances(nodes).


1.1 Installation

The installations of the Instances and the Metaconsole requires to be hosted in servers that are communicated in both ways.

In order to do these we should verify that:

  • The Metaconsole can contact with the Instances
  • The Instances can contact with the Metaconsole

Info.png

The Instances don't need to be communicated between them at any moment

 


To understand better this requirement you can take a look to 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.

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.

1.1.1 Instances

Una Instancia o nodo es una instalación típica de Pandora FMS Enterprise, compuesta por un servidor y una consola web

Para saber con detalle como instalar una instancia podemos visitar el siguiente enlace.

1.1.2 Metaconsole

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


Info.png

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

 


Es necesario tener activo un servidor para poder realizar distintas operaciones referentes a la metaconsola como la “migración”, “autoprovisionamiento”, ejecución de servicios…

1.1.3 Metaconsole License Activation

Tras instalar la versión Enterprise de la Consola de Pandora FMS, sea cual sea el método de instalación, se deberá acceder a la consola de Pandora (http://IP/pandora_console/) y le aparecerá la siguiente pantalla de bienvenida para aceptar la licencia. Para saber más de como se activa la licencia podemos visitar el siguiente enlace.

Info.png

Para poder activar la metaconsola necesita una licencia de metaconsola. Si activa la licencia de nodo le aparecerá la consola normal.

 


1.2 Metalicence

A partir de la versión 7.0NG de PandoraFMS disponemos de una licencia única para un entorno con Metaconsola. Se podrán crear tantas instancias como se quiera, siempre y cuando no se sobrepase el número de agentes total dentro de la Metaconsola.

Esta licencia se aplica en la Metaconsola y se puede sincronizar en tantas instancias como se quiera, permitiendo así la gestión centralizada de los distintos agentes que se desplegarán en dichas Instancias.

Con esta licencia, si empezamos una instalación desde cero, primero deberemos instalar la Metaconsola validando su metalicencia. Una vez validado, registraremos cada una de las instancias deseadas (explicado en los siguientes apartados), sincronizando posteriormente la metalicencia para que podamos trabajar sobre todas ellas.

1.3 Configuration

In order for instances to communicate with the Metaconsole and vice versa, you should configure both sides correctly.

1.3.1 Metaconsole

1.3.1.1 Registration and Configuration of Instances

In the Metasetup section, you can register and configure the Instances with which the Meta Console will be linked.

To register a new instance we must know a series of parameters referring to the instance we want to handle. 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

Campos avanzados

Para garantizar la conectividad entre nodo y Metaconsola, podemos configurar manualmente los datos de conexión.

  • Metaconsole DB host: IP de la base de datos
  • Metaconsole DB name: pandora
  • Metaconsole DB user: pandora
  • Metaconsole DB password: pandora
  • Metaconsole DB port: 3306


Estos campos indican la configuración de la conexión que establecerá el nodo contra la metaconsola.


Configure Instances editor.png

If the installation is a Pandora where we have already included a valid license in the instance, we will have to obtain these data from the setup of the instance and its database.

In the view of the configured Instances we will see that the instances can be modified, deactivated and deleted. There are some indicators that check certain information of the configuration 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 will be the following list:

  • Database: If we have misconfigured the Instance database or do not have the necessary permissions, the indicator will be red and will give us information about the problem.
  • API: This indicator will test the API of the Instance. If it fails it will give us information about the failure.
  • Compatibility: This indicator makes a check of some requirements that have to be between Instance and Metaconsole. The name of the Instance server, for example, must match the name given to it in its configuration in the Meta Console.
  • Event Replication: This indicator shows whether the Instance has event replication enabled and if events have already been received from the Instance, how long ago the last replication was.
  • Agent cache: This indicator states that the last status of the agents and modules of the node have been correctly saved in the Metaconsole database. When a change is generated, only that 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 us to begin to see its data. On the other hand, the Event Replication indicator only gives us 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, leaving the events of the instance as merely informative.

 


1.3.1.2 Index Scaling

Most of the synchronization between the Metaconsole and the Instances is done by name, independently of the internal ID of the elements, with the exception of groups, tags, alerts, operating systems and groups of modules, whose IDs it is important that they are 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, we will increase the AUTO_INCREMENT value of the tables tgrupo, ttag, talert_templates, talert_actions, talert_commands, tconfig_os and tmodule_group sensibly. In this way, we will give a wide margin in the event that elements are created in the instances for reasons beyond the control of the Metaconsole.

For that we will 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, you can set a higher value.

 


1.3.1.3 Report scheduler / Pandora_DB maintance script

It is necessary to install the packages (open and enterprise) of the server in the system where the Metaconsole is installed in order to launch the database maintenance script ('pandora_db). You must make sure that it is correctly programmed for execution in cron every hour (as detailed in the following Pandora:Documentation_en:Gestion_y_Administracion#Cron_Job |link.]]).

If you are going to use on-demand reports (sent by email), you need to program the execution of the cron extension as it is done in a normal Enterprise console. Usually this is done by putting 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, it is necessary to edit the corresponding parameters in the mail configuration section, which by default have the following values:

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 could have access to one Instance in two different ways:

  • Remote access to the Data Base 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 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 credentials of the database to configure the instance in the Meta Console. (Host, Database, User and Password).

Besides this, another important point is giving permission 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>;

Por ejemplo:

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.
  • 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 '*' as wildcart to give access to all IPs or to one subnet

Imagen setup.png

1.3.2.2 Auto-authentication

En algunas partes de la metaconsola hay accesos a la Consola Web de la Instancia como, por ejemplo, en el visor de eventos al pinchar en el agente asociado a un evento (si lo hay) nos llevará a la vista de ese agente en la consola de la Instancia a la que pertenece. Para este acceso se utiliza Auto-autenticación. Esta autenticación se realiza con un hash para el que se necesita una cadena configurada en la Instancia: La contraseña de auto identificación. Dicha contraseña la ponemos en el campo de “Auth token” de la configuración de la instancia en la metaconsola.

Autologin hash.png

Info.png

Esta configuración no es necesaria para configurar la instancia en la Metaconsola, pero sin ella, al pinchar en uno de los enlaces que nos llevan a la instancia, tendremos que autenticarnos.

 



1.3.2.3 Event Replication

In order that Instance events may be seen in the Metaconsole, these should have access to the Metaconsole database.

The Instances will replicate from time to time their events saving the date and hour of the last one to be replicated to continue from there the next time.

Besides the event replication, they will make the Metaconsole autovalidation effective. 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:

  • Intervale: Every how many seconds the server will replicate the events generated from the last replication to the Metaconsole database.

Info.png

If is configured, for example 60 seconds, the first replication will happen 60 seconds after the server has been started.

 


  • Replication Mode: If 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.
  • Metaconsole Database Credentials : Host, Database, Users,Password and Port (Is the port is not indicted the port by default will be used).

Replication events setup.png

The event replication is done by the server. In the configuration file should be an enabled token:

Replication events conf token.png

Template warning.png

To do effective any configuration change in the event replication it will be necessary to restart the server.

 


Template warning.png

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 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:

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, the event replication may not work. Please disable it.

 


1.3.2.4 Autoprovisión desde el nodo

A partir de Pandora 7 puedes encontrar en el setup de configuración enterprise, la opción de dar de alta el nodo en la metaconsola introduciendo menos datos que en el formulario de nodos en la metaconsola.

Ademas puedes chequear si esta llegas vía api a la metaconsola y chequear si esta dado de alta el nodo en la metaconsola.


Autoprovision nodo formuario.png



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:

/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 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:

/etc/cron.daily/pandora_meta_db

1.4 Sincronización de Metalicencia

A continuación vamos a ver un ejemplo de como sincronizar la metalicencia entre una metaconsola y una instancia.

En primer lugar, tenemos una instancia con su propia clave generada y correctamente validada.

Nodo licenciasuya.png

Una vez tenemos el nodo generado y correctamente validado, a continuación lo configuraremos en la metaconsola para posteriormente poder sincronizar la licencia:

Sincronodo meta2.png

Cuando ya tenemos estos pasos, nos iremos a la licencia de la metaconsola y daremos a "Validate and sync" para sincronizar la Metalicencia con la instancia.

Meta sincrolicencia.png

El resultado será que tendremos la metalicencia en la instancia como se puede ver a continuación:

File:Meta sincrolicenciaNodo.png


Go back to Pandora FMS documentation index