Differences

This shows you the differences between two versions of the page.

--- en:documentation:06_metaconsole:11_metaconsole [2021/07/22 01:38]
jimmy.olano [Online Update Manager] Boleto GitLab # 7835 ticket retoques.
+++ en:documentation:06_metaconsole:11_metaconsole [2021/11/05 12:05]
@@ Line 1: / Line 1: @@
-====== Metaconsole in versions prior to NG 756 ======
-{{indexmenu_n>11}}
-===== Comparative =====
-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 ====
-Before version 5.0, a **normal Pandora FMS installation** (Console+Server) **could also work as Metaconsole**.
-=== Communication ===
-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.
-{{  :wiki:metaconsola_arquitecture_com_old.png?500  }}
-=== Synchronization ===
-**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.
-{{  :wiki:metaconsola_arquitecture_sync_old.png?500  }}
-=== Troubleshooting ===
-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.
-==== From Version 5.0 ====
-The **Metaconsole** from version 5.0 is an **special environment completely independent** and **incompatible with the console**.
-=== Communication ===
-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.
-{{  :wiki:metaconsola_arquitecture_com.png?500  }}
-=== Synchronization ===
-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.
-{{  :wiki:metaconsola_arquitecture_sync.png?500  }}
-=== Developments ===
-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.
-==== Summary table ====
-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** |{{  :wiki:yes_tick.png  }}  |{{  :wiki:no_tick.png  }}  |
-|**Synchronization**   |Decentralization  |Centralized  |
-|**Communication**   |Unidirectional  |Bidirectional  |
-|**Instance configuration**   |{{  :wiki:yes_tick.png  }}  |{{  :wiki:yes_tick.png  }}  |
-|**User panel**   |{{  :wiki:yes_tick.png  }}  |{{  :wiki:yes_tick.png  }}  |
-|**Tactical view**   |Through instances  |General and 15 last events  |
-|**Agent browser**   |{{  :wiki:yes_tick.png  }}  |{{  :wiki:yes_tick.png  }}  |
-|**Group view**   |{{  :wiki:yes_tick.png  }}  |{{  :wiki:yes_tick.png  }}  |
-|**Event visor**   |{{  :wiki:yes_tick.png  }}(Data in Instances)  |{{  :wiki:yes_tick.png  }}(Data in the Metaconsole)  |
-|**Tree view**   |{{  :wiki:no_tick.png  }}  |{{  :wiki:yes_tick.png  }}  |
-|**Alert view**   |{{  :wiki:no_tick.png  }}  |{{  :wiki:yes_tick.png  }}  |
-|**Module view**   |{{  :wiki:no_tick.png  }}  |{{  :wiki:yes_tick.png  }}  |
-|**Network map**   |{{  :wiki:no_tick.png  }}  |{{  :wiki:yes_tick.png  }}  |
-|**Traffic monitoring (Netflow)**   |{{  :wiki:no_tick.png  }}  |{{  :wiki:yes_tick.png  }}  |
-|**Synchronization tools**   |Users/Profiles \\ Components \\ Policies \\ Alerts|Users/Profiles \\ **Groups** \\ Components \\ Alerts \\ **Tags**   |
-|**Move agents between instances**   |{{  :wiki:yes_tick.png  }}  |{{  :wiki:yes_tick.png  }}  |
-|**Report templates**   |{{  :wiki:no_tick.png  }}  |{{  :wiki:yes_tick.png  }}  |
-|**Editors**   |Reports \\ Visual console  |**Users/Profiles** \\ **Groups** \\ **Components** \\ Reports \\ Visual console \\ **Alerts** \\ **Tags** \\ **Categories** |
-|**Apply/Policy queue**   |{{  :wiki:yes_tick.png  }}  |{{  :wiki:yes_tick.png  }}  |
-|**Monitor view**   |{{  :wiki:no_tick.png  }}  |{{  :wiki:yes_tick.png  }}  |
-|**Custom field view**   |{{  :wiki:no_tick.png  }}  |{{  :wiki:yes_tick.png  }}  |
-|**Wizard**   |{{  :wiki:no_tick.png  }}  |{{  :wiki:yes_tick.png  }}  |
-|**Visual console viewer**   |{{  :wiki:no_tick.png  }}  |{{  :wiki:yes_tick.png  }}  |
-|**Cronjob setup**   |{{  :wiki:no_tick.png  }}  |{{  :wiki:yes_tick.png  }}  |
-===== Synchronization =====
-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.
-{{  :wiki:metaconsola_users_sync.png?400  }}
-===== Propagation =====
-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.
-{{  :wiki:metaconsola_agents_prop.png?350  }}
-===== User Permissions =====
-There are several permission systems that restrict what an user can see or manage.
-==== ACLs ====
-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 [[:en:documentation:04_using:11_managing_and_administration#permission_assignment|link.]]
-==== Tags ====
-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 [[:en:documentation:04_using:11_managing_and_administration#permission_system_extended_by_tags|link.]]
-==== Wizard Access Control ====
-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.
-=== Visibility ===
-== Basic Access ==
-//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 ==
-//Advanced//  access level users will see in the Wizard the alerts and modules from both //Basic//  and //Advanced//  levels.
-=== Configuration ===
-Apart from visibility, the access level also affects module configuration and its alerts.
-The section **[[:en:documentation:06_metaconsole:06_operation|Operation (Monitoring Wizard)]]** explains in detail the differences between Basic and Advanced monitor configuration.
-===== Administration =====
-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.
-==== Instance Configuration ====
-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 [[:en:documentation:06_metaconsole:03_installation#instances_configuration|Install and Configure]]
-{{  :wiki:metasetup_nodosnew.png  }}
-==== Metaconsole Configuration ====
-In the Metasetup section we find tabs with the Metaconsole configuration different options:
-=== General Configuration ===
-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.
-{{  :wiki:metasetup_general_new1.png?direct&  }}{{  :wiki:metasetup_general_new2.png?direct&  }}
-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.
-=== Password Policy ===
-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 [[:en:documentation:04_using:12_console_setup#password_policy|Password policy]]
-{{  :wiki:metasetup_passwords_new.png?direct&  }}
-=== Authentication ===
-To know more about the authentication go to the manual section [[:en:documentation:04_using:12_console_setup#authentication|Authentication.]]
-{{  :wiki:metasetup_auth.png?direct&  }}
-=== Visual Configuration ===
-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 [[:en:documentation:04_using:12_console_setup#visual_styles|link.]]
-{{  :wiki:metasetup_visualnew.png?direct&  }}{{  :wiki:metasetup_visualnew2.png?direct&  }}{{  :wiki:metasetup_visualnew3.png?direct&  }}
-=== Performance ===
-Visualization options, historic, event purging and maximum size of blocks in the data migration.
-{{  :wiki:metasetup_performance_new.png?direct&  }}
-=== File Management ===
-File manager where it is possible to upload and delete the files from the images folder from the Metaconsole installation.
-<WRAP center round important 60%> The Metaconsole code re-uses some images from the normal console code. These images will be not accessible form this manager and it will be necessary to get to the installation manually to manage them. </WRAP>
-{{  :wiki:metasetup_file_manager_new.png  }}
-=== String Translation ===
-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.
-{{  :wiki:metasetup_string_translations_new.png  }}
-=== Email ===
-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.
-{{  :wiki:mail_metaconsola.png?direct&  }}
-=== Opciones Update Manager ===
-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".
-{{  :wiki:opciones_update.png?direct&  }}
-=== Offline 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".
-{{  :wiki:offline_update.png?direct&  }}
-=== Online 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".
-{{  :wiki:online_update.png  }}
-===== Synchronization tools =====
-The **Metaconsole** has **tools for the synchronization of elements**, which are fundamental for the correct management of the Instances. The synchronization is based on passing all the information created in the metaconsole to the different Instances to manage all possible information of each of them from the Metaconsole.
-For example, if we have 20 different instances(nodes) in our company, and we want the same user to have the same access permissions in those 20, we can create a user with the desired profiles and synchronize that user to have it in the 20 instances(nodes) and thus not have to create it individually in each instance.
-Another example, we have to monitor different clients that are distributed throughout our instances, so that some clients are also repeated in different instances. We will be able to create the different groups to which the agents of the different instances will belong, and then synchronize each corresponding group with its instance.
-Next, we are going to see in detail the different synchronizations that the Metaconsole allows us to make.
-==== User Synchronization ====
-This option allows the user to synchronize the users of the Metaconsole and their profiles in the instances.
-Within this synchronization we can find two different options:
-  * Copy the configured profiles to the user
-{{  :wiki:sync_usuarioscopia.png  }}
-  * Give new profiles to the created user
-{{  :wiki:sync_usuariosnuevos.png  }}
-In both cases we have the option to create the groups associated to the profiles in case they do not exist in the instance(node).
-Before using this synchronization, it is recommended to take into account the users that are going to create new ones in the instances, due to possible conflicts with the user ID. It is recommended not to have users created in the instances and to create them all from the meta console in order to have the same users both in there as in the instances.
-<WRAP center round tip 60%> In both cases, profiles that do not exist in the instance will be created. </WRAP>
-<WRAP center round important 60%> **When in doubt**  about which option is best to use, **user profiles must be copied**. </WRAP>
-==== Group Synchronization ====
-This option allows the user to synchronize the Metaconsole groups with the instances.
-{{  :wiki:sync_grupos.png  }}
-It is recommended not to have groups created in the instances and to create them all from the meta console in order to have the same groups both in there and in the instances.
-<WRAP center round important 60%> Once the groups have been synchronized, their names should not be modified either in the meta console or in the node. If it is done, it will be necessary to modify them in both places so that it does not give problems since the synchronization is based on the ID, but some operations use the name. The synchronization in the current version synchronizes the name the first time, but if there are later changes of names in the groups they will not be synchronized. </WRAP>
-==== Alert Synchronization ====
-This option allows the user to synchronize the Metaconsole alerts with the instances.
-{{  :wiki:sync_alertas.png  }}
-It is recommended not to have alerts created in the instances and to create them all from the console in order to have the same alerts both in there and in the instances.
-==== Component Synchronization ====
-This option allows the user to synchronize the components of the Metaconsole with the instances.
-{{  :wiki:sync_componentes.png  }}
-It is recommended not to have components created in the instances and to create them all from the Metaconsole in order to have the same components both in there and in the instances.
-==== Tag Synchronization ====
-This option allows the user to synchronize the tags of the Metaconsole with the instances.
-{{  :wiki:sync_tagsnew.png  }}
-It is recommended not to have tags created in the instances and to create them all from the Metaconsole in order to have the same tags both in there and in the instances.
-==== OS Synchronization ====
-This option allows the user to synchronize the OS of the Metaconsole with the instances.
-{{  :wiki:sync_os.png  }}
-It is recommended not to have OS created in the instances and to create them all from the Metaconsole in order to have the same OS both in there and in the instances.
-==== Module Groups Synchronization ====
-This option allows the user to synchronize the module groups operating in the Metaconsole with the instances.
-{{  :wiki:sync_modulegroups.png  }}
-It is recommended not to have the groups of modules created in the instances and to create them all from the Metaconsole in order to have the same groups of modules both in there and in the instances.
-===== Propagation tools =====
-The MetaConsole has tools for the propagation of elements. Unlike synchronization, it is not a fundamental tool for the optimal functioning of the Metaconsole, it only facilitates the availability of data in the Instances, something that is necessary if, for example, we use policies that are applied in different instances (or nodes).
-<WRAP center round tip 60%> It is recommended to synchronize the instances with the meta console after the creation of the different elements in the propagation tool. </WRAP>
-Next, we are going to see in detail the different propagations or data management that allows us to make the meta console.
-==== User Management ====
-The following actions can be performed in this section:
-  * User management
-  * Profile management
-  * Edit my user
-For example, we have 10 instances inside our meta console, where we want a user with special permissions to operate inside 3 of them. First, we would go to profile management where we would create a special profile with the permissions we want. Then we create the user we want to manage the three instances, assigning the permission we have created to it. Finally, we will synchronize this user and profiles with the instances to have it in all three. After a while the user has become obsolete, but instead of deleting the user we deactivate it in case we want to use it again in the future, we go to user management and use the bulb icon to deactivate it until further notice.
-=== User Management ===
-In this section we can see the list of users already created, modify their configuration, delete them, deactivate them or create new users.
-{{  :wiki:gestion_usuarios.png?direct&  }}
-== Create a new user ==
-To add a user click on the "Create User" button, where we will see the following form which must be filled:
-{{  :wiki:gestion_creacionusuarios.png?direct&  }}
-{{  :wiki:gestion_creacionusuarios2.2.png?direct&  }}
-The parameters that require explanation are:
-  * **Interactive charts**: It allows the user to choose if they prefer to see the interactive graphics, or on the contrary, to use the general configuration of the Metaconsole.
-  * **Metaconsole access**: It sets the user permissions to access the console. These permissions can be:
-      * *Basic**: With this access the user will be able to use in the Wizard only the components whose Wizard level is //Basic//, as long as the user has ACL permissions on the group they belong to. * *Advanced**: With this access the user will be able to use any of the components in the Wizard regardless of their Wizard level, as long as the user has ACL permissions on the group they belong to.
-  * **Search custom field view**: Seleccionamos el filtro por defecto para la vista de "Campos personalizados"
-  * **Not Login**: If this option os selected, the user will be able to access the API.
-  * **Enable agents management**: This option is used to enable the agent management in the Wizard. If it is deactivated, only the Wizards of modules and alerts will be available.
-  * **Enable node access**: This option is used to enable access to the instances. If it is activated, it will be possible to access the consoles of the instances through the name of agents and modules in many places; for example, from the network map or the events view.
-== Modify/Deactivate/Delete a user ==
-In the user list the following options are available:
-  * Activate/Deactivate the user
-  * Edit the user
-  * Delete the user form the Metaconsole
-  * Delete the user form the Metaconsole and all Instances
-{{  :wiki:gestion_modificacionusuarios.png  }}
-A user's editing form is the same as the creation form, but including the profile editor.
-{{  :wiki:gestion_modificacionusuarios2.png?direct&  }}
-In the profile editor the user can be assigned profiles in certain groups besides limiting those privileges to the selected Tags. If Tags are not selected, the user will have access to all modules, whether they have associated Tags or not.
-=== Profile Management ===
-In this section we can see the list of profiles already created, modify their configuration, delete them or create new profiles.
-{{  :wiki:gestion_perfiles.png  }}
-There are a series of ACL flags that will give access to the different Pandora FMS functionalities. To know which function enables each ACL flag of the profiles, visit section [[:es:documentation:04_using:11_managing_and_administration#perfiles_en_pandora_fms|Perfiles en Pandora FMS]] in the user manual.
-== Create a new profile ==
-To add a profile click on the "Create" button to see the following form, where we must fill in those permissions that we want to give with the new profile:
-{{  :wiki:gestion_creacionperfil.png?direct&  }}
-{{  :wiki:gestion_creacionperfil2.png?direct&  }}
-<WRAP center round tip 60%> Some of these bits don't make sense in the Metaconsole. However, we may want to use the Metaconsole to synchronize profiles to Instances, where they could be useful. </WRAP>
-== Modify/Delete a profile ==
-In the list of profiles you have options to:
-  * Edit the profile
-  * Delete a profile from Metaconsole
-{{  :wiki:dac2.1.png  }}
-=== Edit my user ===
-In this section we can configure the user who is authenticated in the Metaconsole. The profiles assigned to the user will be merely informative. If the authenticated user is not an administrator, this will be the only section you can see.
-{{  :wiki:gestion_editmyuser.png  }}
-<WRAP center round important 60%> We are working on the translation of the Pandora FMS documentation. Sorry for any inconvenience. </WRAP>
-==== Agent management ====
-The following actions can be performed in this section:
-  * Migration of agents between instances
-  * Self-provisioning of agents
-  * Group management
-For example, we are planning to manage 15 instances in the metaconsole, and we want the distribution of the agents to be organized according to the load of each instance, creating the agents so that they are always generated in the instance with the lowest load. To do this, we will go to auto-provisioning and activate the option indicated for it. Once done, if for example, we realize that certain agents should go together in the same instance, we will go to the migration of agents between instances, where we will choose which agents move to which other instances so that we don't have to delete and create the agents manually.
-=== Agent Migration ===
-<WRAP center round important 60%> This feature requires a running Metaconsole server to work. </WRAP>
-In this section we can migrate agents between the instances connected to our Metaconsole. {{  :wiki:gestion_migagentes.png?direct&  }}
-In order for the historical data of the agents to be transferred, the "Discard history data" checkbox must be activated. Once we have everything selected and we press the "move" button, it will start to perform the following checks to be able to perform the migration.
-**The agents do not exist in the destination server**
-There must not exist any agent to migrate with the same agent name in the target server.
-**The necessary collections are synchronized with the destination server**
-To prevent the agent from attempting to download non-existent collections once migrated, verify that the collections exist on both servers (source and destination).
-**The necessary alert definitions are synchronized with the target server**
-Verify that the templates, actions and commands defined on the source server are also defined on the target server. The relations are made through ID, so these values must also be identical.
-**The configuration files of the software agents associated to the agents do not exist in the target server**
-There must not be configuration files with the same name as those associated to the agents that we are going to migrate in the target server. If so, we must remove them from the destination server.
-**Both servers have the same version**
-Verify that Pandora FMS versions are identical in both servers.
-**The address of the destination server is configured**
-Verify that the IP address of your destination server (Dataserver) is configured, you can access the following screen through <i>Servers > Manage servers</i> of the instance to which we want to move the agents:
-{{  :wiki:configurar_serverip.png?direct&  }}
-{{  :wiki:configurar_serverip2.png?direct&  }}
-**The necessary policies are synchronized with the target server**
-Verify that the source server policies are available on the target server. All relations are made through ID, so these values must also be identical.
-**The groups are synchronized with the destination server**
-Verify that the groups of the source server are defined in the destination server. All relations are made through ID, so these values must also be identical.
-**The remote plugins are synchronized with the destination server**
-Verify that the server plugins are defined in the destination server. All relations are made through ID, so these values must also be identical.
-**Inventory plugins are synchronized with the target server**
-Verify that the inventory plugins are defined on the target server. All relations are made through ID, so these values must also be identical.
-Once all the checks are done, click on the "Next" button to continue with the migration, where a table with the status of the migration will appear.
-<WRAP center round tip 60%> In order to avoid blocking the work queue, the agent to be transferred will always be processed with lower priority, this avoids the system being blocked by transferring an agent with a lot of data, giving priority to the migration of the agent over the migration of the data. </WRAP>
-<WRAP center round tip 60%> In order to optimize the process the original agent will be deactivated and the automatic disable mode will be established. By default, this configuration will **eliminate **  the original agent in 30 days. </WRAP>
-<WRAP center round important 60%> Defined prediction modules may lose functionality once the agent is migrated. Review definitions after migration. </WRAP>
-=== Agent Autoprovisioning ===
-When we deploy Pandora in big and complex environments with many Pandora nodes and Metaconsole environment, we find the problem of deciding how to deploy the agents: which server is assigned to them? how to balance the workload?
-For this, the concept of agents auto-provisioning appears, which allows assigning an agent to one of the multiple Pandora servers that we have in our infrastructure.
-<WRAP center round important 60%> This feature requires a Metaconsole server with a Provisioning Server running in order to work. </WRAP>
-<WRAP center round important 60%> This functionality is used to manage the assignment **initial**  of the agents to a given server. When you install your agents for the first time, select the IP address of the Metaconsole as //server_ip//. </WRAP>
-To be able to use this feature we will have to configure the server and the Metaconsole.
-== Server Configuration ==
-For the autoprovisioning system to work we must enable the ProvisioningServer at /etc/pandora/pandora_server.conf:
-<code>
- # Enables auto provisioning service
- provisioningserver 1
-</code>
-<WRAP center round tip 60%> Verify that the IP address of your destination servers (Dataserver) is configured in each node. You can access the following screen through <i>Servers > Manage servers </i> </WRAP>
-{{  :wiki:configurar_serverip.png  }}
-{{  :wiki:configurar_serverip2.png  }}
-== Console Configuration ==
-In this section we can choose between three different types of autoprovisioning, activating the one we want by means of a switch:
-{{  :wiki:configurar_autorprovi.png  }}
-**Round Robin**
-It uses the Round-robin planning method to distribute, in an equitable way and in a rational order, all the new Pandora software agents that reach the Metaconsole. The distribution of the agents will be done in a circular way, assigning the corresponding server to each new agent.
-**Less Loaded**
-The new agents will be dynamically assigned to those servers with less load.
-**Custom**
-In the customized classification, we will be able to define our own classification rules, based on certain parameters retrieved from the information reported by the agent (name of the agent and its IP address).
-If we choose the Custom option, we will click on the "Create a custom entry" button where the following form will appear:
-{{  :wiki:configurar_autorprovicustom.png  }}
-In the configuration section we will have to put the content that will be added to the configuration file. It is a way of customization that will be used to classify the agents; an example would be:
-<code>
- # Text contained here will be validated and inserted in the agent configuration
- server_ip 192.168.80.164
-</code>
-Once created we will have to introduce the rules that we want the agents to comply with by hitting the "add" button.
-{{  :wiki:configurar_autorprovicustom2.png  }}
-We will be able to specify the matching conditions in the form of rules using the following fields:
-  * agent alias
-  * agent address
-We will be able to specify the operations using the following fields:
-  * OR
-  * AND
-=== Autoconfiguration ===
-In this section you can edit the autoconfigurations of the agents in a centralized way from the Metaconsole. In order to make this edition, we must have activated the "Centralized management".
-For more information, visit this [[:en:documentation:02_installation:04_configuration_agents#automatic_agent_configuration|link]].
-=== Group Management ===
-In this section we can manage, delete and create new groups in the Metaconsole.
-{{  :wiki:configurar_gestiongrupo.png  }}
-== Create a Group ==
-To create a new group, click on the "create group" button and the following form will appear:
-{{  :wiki:configurar_creargrupo.png?direct&  }}
-The parameters that require explanation are:
-  * **Parent**: combo where another group can be defined as the parent of the group being created.
-  * **Propagate ACL**: allows ACLs to be propagated to child subgroups..
-  * **Custom ID**:the groups have an ID in the Database. In this field it is possible to put another custom ID that can be used from an external program to perform an integration.
-== Modify/Delete a group ==
-In the list of groups there are options for:
-  * Editing the group
-  * Deleting the Metaconsole group
-{{  :wiki:dac2.1.png  }}
-=== Tree group ===
-In this section we can perform exactly the same actions as in the previous section, changing the display mode:
-{{  :wiki:tree_group_meta.png  }}
-=== Collections ===
-From Pandora FMS OUM729 you can centralize the management of collections from the Metaconsole.
-{{  :wiki:mc_col_menu.png  }}
-The first time you access collection management, with ** centralized management enabled **, an internal process of synchronization of the collections from the nodes to the Metaconsole will be performed:
-{{  :wiki:mc_col_message.png  }}
-From this moment on, you will have the collections in the Metaconsole. To avoid conflicts, you must manually copy the collection directories from the nodes to the Metaconsole:
-Source location (node):
-<code>
-/var/www/html/pandora_console/attachment/collection/
-</code>
-Destination location (Metaconsole):
-<code>
-/var/www/html/pandora_console/attachment/collection/
-</code>
-**Note:**  Remember to assign the correct permissions to the transferred files:
-<code>
-chmod apache. -R  /var/www/html/pandora_console/attachment/collection/*
-</code>
-Once the files are transferred, you can recreate the collection to force synchronization to nodes.
-For more information about the collections, please visit this [[:en:documentation:05_big_environments:02_policy#file_collections|link]].
-==== Module Management ====
-The following actions can be performed in this section:
-  * Component Group Management
-  * Local component management
-  * Network Component Management
-  * Plugin management
-Before we start, let's explain what a component is: it is a "generic module" that can be applied repeatedly on an agent, being a kind of "master copy" of a module. This is very useful to monitor new agents with the components stored in the database.
-For example, we have 12 instances where we want to create the same type of modules in each: we want to create 10 local modules, 5 network modules and 3 custom plugins. Thanks to the management in the Metaconsole we will be able to create these components, each one in its section, and then synchronize them to have them in the different instances without having to manually create them.
-=== Component Group Management ===
-In this section we can delete and create new groups of components.
-{{  :wiki:gestionar_grupocompo.png  }}
-{{  :wiki:gestionar_grupocompo2.png  }}
-{{  :wiki:gestionar_grupocompo3.png  }}
-== Group creation ==
-To create a new group click on the "Create" button.
-{{  :wiki:gestionar_crearcompogrupo.png  }}
-== Group deletion ==
-{{  :wiki:gestionar_borrarcompogrupo.png?direct&  }}
-=== Local component management ===
-In this section we can delete, duplicate and create new local components. A local component is the elaboration of a module defined in the configuration of software agents, structured as "pieces" of text that can be cut and pasted in the configuration of agents.
-{{  :wiki:gestionar_compolocal.png  }}
-== Local component creation ==
-In order to create a local component click on the "Create" button where the following form will appear:
-{{  :wiki:gestionar_compolocalcrear.png?direct&  }}
-{{  :wiki:gestionar_compolocalcrear2.png?direct&  }}
-{{  :wiki:gestionar_compolocalcrear3.png?direct&  }}
-In order to see in detail more information about the parameters for the creation of a new local component you can visit [[:en:documentation:04_using:03_templates_and_components#creating_new_network_components|Create user]].
-== Duplicate/Delete a local component ==
-In the list of local components you have options for:
-  * Duplicating a local component
-  * Deleting a local component of the Meta Console
-{{  :wiki:meta_net_component_op_col.png  }}
-=== Network Component Management ===
-In this section we can delete, duplicate and create new network components. A network component groups all remote modules (wmi, tcp, snmp, icmp, plugin, web, etc).
-{{  :wiki:gestionar_compored.png  }}
-== Creating Network Component ==
-There are three types of network components that can be created:
-  * Network
-  * Plugin
-  * WMI
-To create a new network component in the drop-down menu select a network component from the three possible (WMI, Network or Plugin): and click on the button //Create//. Next, we will see a screen to create a network component.
-{{  :wiki:gestionar_comporedcrear.png?direct&  }}
-{{  :wiki:gestionar_comporedcrear2.png?direct&  }}
-{{  :wiki:gestionar_comporedcrear3.png?direct&  }}
-To see in detail more information about the parameters of creation of a new network component you can visit the section [[:en:documentation:04_using:03_templates_and_components#creating_new_network_components|Network component]].
-== Duplicating/Deleting a Network Component ==
-In the list of network components you have options for:
-  * Duplicating a network component
-  * Deleting a network component from the Metaconsole
-{{  :wiki:meta_net_component_op_col.png  }}
-=== Plugin Management ===
-In this section we will be able to delete, modify and create new plugins that will use plugin type network components.
-{{  :wiki:gestionar_compoplugin.png  }}
-== Creating a Plugin ==
-To create a plugin click on the "Add" button and the following form will appear:
-{{  :wiki:gestionar_compoplugincrear.png?direct&  }}
-{{  :wiki:gestionar_compoplugincrear2.png?direct&  }}
-The parameters that require explanation are:
-  * **Plug-in command**: Where we will put the PATH to where the plugin is located
-  * **Plug-in parameters**: Where we will put the parameters that we must write so that the plugin works correctly.
-{{  :wiki:gestionar_compoplugincrear.png?direct&  }}
-== Modifying/Deleting a Plugin ==
-In the plugin list there are options for:
-  * Modifying a plugin
-  * Deleting a plugin from the Metaconsole
-Certain plugins have a padlock in front of the Modify option, because these plugins cannot be modified or deleted.
-{{  :wiki:gestionar_compopluginborrar.png  }}
-==== Alert Management ====
-The following actions can be performed in this section:
-  * Management of commands
-  * Management of shares
-  * Management of templates
-{{  :wiki:gestionar_alertasgeneral.png?direct&  }}
-For example, in our meta console we have 5 instances with different clients and in all of them we need to measure in each agent the temperature of its CPU. With this information, we need an alert to be triggered when the CPU exceeds a certain temperature, and what we want is to create a command that will make the CPU eliminate certain services so as not to be used in an excessive way, causing it to rise in temperature. We would generate an alert that carries out this command and then synchronize it with all our instances so that we don't have to do it manually one by one.
-In this section we will only talk about the management of templates, in particular, the differences with the management of alerts of the instances. To know more about its operation and configuration you can consult the [[:en:documentation:04_using:01_alerts|Alert System]] section inside the Pandora FMS manual.
-=== Template Management ===
-The only difference with regard to the management of alerts of the instances, is in the creation of a new template. When creating a template we have an option called "Wizard level".
-{{  :wiki:gestionar_alertas.png?direct&  }}
-This field will define which users will be able to use this template to create alerts from the Wizard.
-  * **No Wizard**: This template will not be available in the Wizard.
-  * **Basic**: Any user with access to the Wizard will be able to use this template to create alerts.
-  * **Advanced**: Only users with advanced level of access to Metaconsole will be bale to use this template (see section [[:en:documentation:06_metaconsole:08_synchronization_and_propagation#create_a_new_user|Create user]]).
-==== Event Alert Management ====
-The following actions can be performed in this section:
-  * Create event alert
-  * Modify/Delete/Disable/Silence event alerts
-{{  :wiki:gestionar_alertaseventos.png?direct&  }}
-For example, we have 4 instances where we have in one of the agents the monitoring of the apache server of each of the web pages located in the different instances. We will create an event alert that will warn us when this monitoring goes down to warn the administrator that the Apache service should be immediately fixed, so that it wouldn't be necessary to create one by one manually in the instances agents.
-To find out more about its operation and configuration, please consult the section [[:es:documentation:04_using:02_events#alertas_de_eventos_correlacic3b3n_de_eventos|Alert System]] of the Pandora FMS manual.
-==== Component Management ====
-The following actions can be performed in this section:
-  * Tag Management
-  * Module group management
-  * OS Management
-{{  :wiki:gestionar_componentes.png?direct&  }}
-=== Manage tags ===
-In this section we will be able to delete, modify, and create new tags.
-== Creating Tags ==
-To create a new tag we click on the button “create tag” and then we will get the following form to fill in:
-{{  :wiki:gestionar_tagscrear.png?direct&  }}
-== Modify/Delete tags ==
-In the list of tags we have options to:
-  * Edit the tag
-  * Delete the tag from the Metaconsole
-{{  :wiki:dac2.1.png  }}
-=== Module Groups Management ===
-In this section we can delete and create new groups of modules.
-{{  :wiki:gestionar_gruposmodulos.png?direct&  }}
-== Group Creation ==
-To be able to create a new module group we will click on the button “Create module group”:
-{{  :wiki:gestionar_gruposmoduloscrear.png?direct&  }}
-== Deletin a Module Group ==
-{{  :wiki:gestionar_borrarcompogrupo.png  }}
-=== OS Management ===
-In this section we can delete and create new OS.
-{{  :wiki:gestionar_os.png?direct&  }}
-{{  :wiki:gestionar_os2.png?direct&  }}
-== OS Creation ==
-To create a new OS we click on the button “create OS” and a form will appear for us to fill in:
-{{  :wiki:gestionar_oscrear.png?direct&  }}
-== OS Deletion ==
-{{  :wiki:gestionar_borrarcompogrupo.png  }}
-==== Policy Management ====
-From this section we can create, modify, and delete policies. {{  :wiki:meta_menu.png?direct&800  }}
-For example, we have 7 instances in which 2 of them are going to be monitored in the same way, with the same name of agents and modules. We would create a policy that creates the modules in the agents automatically, which we will later synchronize with the different instances without having to create it one by one.
-=== Policy Creation ===
-New policies can be created by clicking on the "Create" button, where the following form is displayed:
-{{  :wiki:meta_crear.png?direct&800  }}
-For a better understanding of how to configure policies, please refer to the section [[:en:documentation:05_big_environments:02_policy|Policy Management.]]
-=== Modify/Delete policies ===
-In the list of policies we have options to modify a policy and delete it. If a policy has agents, the "Delete" button will be disabled and a button to delete all its agents will appear next to it. This button will introduce the agent deletion into the queue, and as soon as it is processed, the policy deletion button will be active again.
-{{  :wiki:meta_borrar.png  }}
-==== Category Management ====
-In this section we can modify, delete and create new categories.
-{{  :wiki:gestionar_categorias.png?direct&  }}
-=== Creating Categories ===
-To create a new category click on the button “create category”:
-{{  :wiki:gestionar_categoriascrear.png?direct&  }}
-=== Modify/Delete categories ===
-In the list of categories we have options to:
-  * Edit the category
-  * Delete the category from the Metaconsole
-{{  :wiki:dac2.1.png  }}
-==== Server Management ====
-In this section we will be able to delete the servers installed in the Metaconsole. In order to be able to use all the features, the Auto-provisioning and Migration servers should be activated.
-{{  :wiki:gestionar_server.png?direct&  }}
-[[:en:documentation:start|Go back to Pandora FMS documentation index]]

ºº