Difference between revisions of "Pandora: Metaconsole: Documentation en: Installation"
(→Installation and Configuration)
|Line 59:||Line 59:|
== Configuration ==
== Configuration ==
Revision as of 18:04, 5 January 2015
- 1 Installation and Configuration
- 1.1 Installation
- 1.2 Configuration
- 1.2.1 Instances
- 1.2.2 Metaconsole
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.
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
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.
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 FMS Installation.
A Metaconsole is a Pandora FMS Enterprise installation with a metaconsole license.
The Metaconsole is only the Web Console It doesn't use server so it will not host agent neither monitors
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.
1.1.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.1.4 Metaconsole License Activation
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:
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:
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.
In order that Instances could communicate with the Metaconsole and vice versa, you should configure both sides correctly.
In Instances, there are a serial of parameters to ensure the access of your data with the Metaconsole.
22.214.171.124 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 the NetFlow monitoring
The Instance should be configured to guarantee both accesses to the Metaconsole.
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:
GRANT ALL PRIVILEGES on <MetaconsoleDatabaseName>.* to <UserName>@<HostAddress> IDENTIFIED BY <UserPass>;
The access to the Instance API will be guaranteed with the following parameters:
- User and password: It should be 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.
- 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
In some parts of the metaconsole there are accesses to the Instance Web Console.
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.
For this access the Auto-authentication is used.
This authentication is done with a hash for which is necessary one string that is configured in the Instance: The autoidentification password.
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
126.96.36.199 Event Replication
In order that in the Metaconsole could be seen the Instance events, 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 replicated to continue from there the next time
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:
- Intervale: Every how many seconds the server will replicate the events generated from the last replication to the Metaconsole database.
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).
The event replication is done by the server. In the configuration file should be an enabled token:
To do effective any configuration change in the event replication it will be necessary to restart the server.
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:
UPDATE tconfig SET `value` = UNIX_TIMESTAMP() WHERE `token` = "replication_copy_last_utimestamp"
188.8.131.52 Giving access to the Instances
Same way as the Instances give 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.
184.108.40.206 Instances Configuration
In the Metasetup section, it will be possible to configure the Instances with which the Metaconsole will be linked.
The configuration of one instance has a serial of parameters that we should configure and retrieve from the Instances:
In the view of the configured Instances, we will see that the Instances can be edited, disabled and deleted.
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.
The indicators are these:
- 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.
- 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.
220.127.116.11 Index Scaling
Most part of the synchronization between the Metaconsole and Instances is done by name, regardless of the internal ID of the items.
Like exceptions to this, there are the groups, tags and alerts, whose IDs it's very important that are synchronized.
In order to make sure that the group, tag and alerts IDs that are synchronized from the Metaconsole don't exist in the instances, we significantly increase the value AUTO_INCREMENT from the tgrupo, ttag, talert_templates, talert_actions and talert_commands table.
To do this, we should execute in the Metaconsole 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;
If we suspect that the number of elements of one instance created in an external way to the Metaconsole could exceed the 3000, it is possible to configure a higher value.
18.104.22.168 Report scheduler / Pandora_DB maintance script
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.
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).
*/5 * * * * <user> wget -q -O - http://x.x.x.x/pandora_console/enterprise/extensions/cron/cron.php >> /var/www/pandora_console/pandora_console.log
Remember also to setup the cron SMTP settings, by editing the file '/enterprise/extensions/cron/email_config.php':
//Please setup your config to send emails in cron job $cron_email_from = array('[email protected]' => 'Pandora FMS'); $cron_email_smtpServer = 'mail.artica.es'; $cron_email_smtpPort = 25; $cron_email_username = ''; $cron_email_password = ;