Metaconsole in versions prior to NG 756

If you already knew Pandora FMS before version 5.0, then you know that the Metaconsole concept already existed.

This section discusses the differences between the current Metaconsole and the old one, and also the solved failures and the developments proposed.

Before version 5.0, a normal Pandora FMS installation (Console+Server) could also work as Metaconsole.

The communication between the Metaconsole and the instances was unidirectional. The Metaconsole was connected to the instance databases and managed all memory data.

It did not store almost nothing in its own database.

Synchronization is done one-way between instances: from Metaconsole to instances.

Let us suppose that you wish to configure some alert templates so that they have several or all the instances.

Without logging out of the Metaconsole, templates can be configured and synchronized with the desired instances.

The Metaconsole was very inefficient due to its non-centralized architecture. A lot of connections to different databases were established and user experience was poor.

The available options were insufficient to get the intended control of instance environments without logging out of the Metaconsole.

Summarizing, the Metaconsole was slow when it was a little bit loaded and the user was very limited by its options.

The Metaconsole from version 5.0 is an special environment completely independent and incompatible with the console.

The communication between the Metaconsole and the instances is bi-directional. The Metaconsole connect with the instance database and the instances replicate part of their data to the Metaconsole database.

Other data, such as groups, alert templates, tags… are stored in the Metaconsole.

The synchronization is done in a one way: From the Metaconsole to the instances.

For example:

Lets suppose that we want to configure some alert templates for the ones that have several or all instances. Without exit from the metaconsole we could configure the templates and synchronize them with the instances that we want.

From version 5.0 onwards, the Metaconsole is a much more centralized, quick, and flexible tool than the previous version. It also includes many more views and features, as well as developments in the existing ones. It does not manage all data in memory, storing part of the information, which improves user experience.

This table summarizes the differences between the old Metaconsole features and the new ones.

	Before version 5.0	From version 5.0
The metaconsole can work as an instance
Synchronization	Decentralization	Centralized
Communication	Unidirectional	Bidirectional
Instance configuration
User panel
Tactical view	Through instances	General and 15 last events
Agent browser
Group view
Event visor	(Data in Instances)	(Data in the Metaconsole)
Tree view
Alert view
Module view
Network map
Traffic monitoring (Netflow)
Synchronization tools	Users/Profiles Components Policies Alerts	Users/Profiles Groups Components Alerts Tags
Move agents between instances
Report templates
Editors	Reports Visual console	Users/Profiles Groups Components Reports Visual console Alerts Tags Categories
Apply/Policy queue
Monitor view
Custom field view
Wizard
Visual console viewer
Cronjob setup

The Metaconsole has tools for element synchronization, such as the synchronization of users and groups, which is essential for instance correct management. Synchronization is based on passing all the information created in the Metaconsole to the different instances in order to manage all the information from each and everyone of them from the Metaconsole.

For example, a user created in an instance, but not in the Metaconsole, cannot be managed from the Metaconsole. On the other hand, if there is a created user in the Metaconsole, and users are synchronized, this user will be in Instances and it will be possible to manage it from the Metaconsole.

The Metaconsole has tools for element propagation, such component propagation or moving agents between instances (or nodes). Unlike synchronization, it is not a fundamental tool for the optimal functioning of the Metaconsole. It only provides data availability in instances, something that is necessary if, for example, policies that are applied in different instances (or nodes) are used.

For example, you may want to move an agent from Instance A to Instance B to balance instance load, through this set of tools it can be easily achieved.

There are several permission systems that restrict what an user can see or manage.

The ACL system controls which elements an user can see or manage depending on the group they belong to.

For example:

• A user may have reading permissions on the alert templates of the Application group and those of Administration on the Server group.
• You will be able to see and assign templates to both groups, but you only have the option to edit or delete those of the Server group.

To find out more about the ACLs, click on this link.

One tag is a label that you may assign to a module.

An user could have the ACLs of some specific group restricted by Tags. If so, only these ACLs will be applied to the modules that contain those Tags.

For example:

• An user may have reading or administration permissions on the Server group restricted to the Systems Tag.
• It will only have these permissions on the modules, that even belonging to an agent of the Server group, will have the System Tag assigned.

To learn more about the tags, click on this link.

Users have an access level assigned regarding the Metaconsole Wizard. This level may be Basic or Advanced.

Besides, alert templates and module components (local and network) will also have this access level.

Basic access users will only see in the Wizard the alerts corresponding to the alert templates with Basic level and the modules created from Basic level components.

Advanced access level users will see in the Wizard the alerts and modules from both Basic and Advanced levels.

Apart from visibility, the access level also affects module configuration and its alerts.

The section Operation (Monitoring Wizard) explains in detail the differences between Basic and Advanced monitor configuration.

The Advanced section contains the Metaconsole administration options, between them:

• The data synchronization between the Metaconsole and the Instances
• The data management of the Metaconsole
• The licence management of the Metaconsole
• The Metasetup where there are:
  • The Instances configuration
  • The Metaconsole configuration options

In this chapter we are going to talk about the Metasetup and the licence management, in the next chapter we will describe in detail the synchronization and data management of the Metaconsole.

In the Metasetup section, besides all the options of the console configuration, there is a tab for the console Setup.

In this tab, we will select the instances. All the configuration process is available at the manual section Install and Configure

In the Metasetup section we find tabs with the Metaconsole configuration different options:

In this section we find general data of the Metaconsole, such as the language, the date/hour configuration or customization about some sections, among others.

It is possible to customize if we want that the Netflow section would be enabled or disabled, the tree view classified by tags, the visual console and the possibility of web checks creation from the Wizard.

The parameters that require explanation are:

• Centralized Management: This option allows us to centrally manage policies and events from Metaconsole, without being able to manage them from the nodes.
• Enable update manager: This option allows us to activate both the “Offline update manager” and the “Online update manager”, which allow us to update the Metaconsole in this configuration.

It is possible to set a password policy with limitations in the password number of characters, expiration, temporary blocking of one user. To know more about the password policy go to the manual section Password policy

To know more about the authentication go to the manual section Authentication.

All configuration related to the data representation. Colors and graph resolution, number of items in the view pagination,etc.You can see more information about the visual configuration in this link.

Visualization options, historic, event purging and maximum size of blocks in the data migration.

File manager where it is possible to upload and delete the files from the images folder from the Metaconsole installation.

With the string translation feature it is possible to customize translations.

We do a search of the string in the language that we want to customize. The original string will be shown, the translation to that language and a third column to writte the customized translation.

Con la utilidad de mail podemos personalizar el envio de mails desde la metaconsola, donde deberemos de configurar la cuenta de mail con la que queremos enviar, por ejemplo, los informes generados.

En esta sección podemos modificar las opciones que se van a usar para el Update Manager. Por defecto viene ya configurado para poder realizar la actualización online. Esta sección solo será visible si tenemos activado el “Enable update manager”.

En esta sección podremos actualizar la metaconsola sin necesidad de conectarnos a ningún otro lugar. Solo tendremos que subir los ficheros “rpm” en orden hasta la versión que queremos actualizar, dado que no son versiones acumulativas. Esta sección solo será visible si tenemos activado el “Enable update manager”.

En esta sección podremos actualizar la metaconsola de manera automática, solo tendremos que poseer una licencia válida de metaconsola y acceso a internet. Esta sección solo será visible si tenemos activado el “Enable update manager”.