Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
en:documentation:06_metaconsole:04_command [2021/08/18 09:58]
laura.cano [Stage 1 elements]
en:documentation:06_metaconsole:04_command [2021/11/05 12:05] (current)
Line 1: Line 1:
-====== COMMAND CENTER ======+====== Command Center ======
  
 {{indexmenu_n>3}} {{indexmenu_n>3}}
  
 [[:en:documentation:start|Go back to Pandora FMS documentation index]] [[:en:documentation:start|Go back to Pandora FMS documentation index]]
 +
  
 ===== Command Center ===== ===== Command Center =====
Line 53: Line 54:
 The following elements are those centralized from the new Command Center: The following elements are those centralized from the new Command Center:
  
-  * **Users**: It is only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same ID**  will be considered the **same user**  (following the priority rules described previously). +  * **Users**: It is only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same ID**  will be considered the **same user**  (following the priority rules described previously). 
-  * **User profiles**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same name**  will be considered as the **same user **  (following the priority rules described previously).+  * **User profiles**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same name**  will be considered as the **same user **  (following the priority rules described previously).
   * **Agent groups**: They are only managed from the Metaconsole. Node management is disabled.   * **Agent groups**: They are only managed from the Metaconsole. Node management is disabled.
-  * By unifying from the Command Center those users with the **same name**  will be considered to be from the **same group **  (following the priority rules described previously).+  * By unifying from the Command Center those with the **same name**  will be considered to be from the **same group **  (following the priority rules described previously).
  
 <WRAP center round info 60%>Make sure you adjust the parameter ''autocreate_group''  from the server configuration files ''pandora_server.conf''  by a valid group ID after unifying from the Command Center. <WRAP center round info 60%>Make sure you adjust the parameter ''autocreate_group''  from the server configuration files ''pandora_server.conf''  by a valid group ID after unifying from the Command Center.
Line 62: Line 63:
 </WRAP> </WRAP>
  
-  * **File collections**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same short name**  will be considered to be from the **same collection **  (following the priority rules described previously). +  * **File collections**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same short name**  will be considered to be from the **same collection **  (following the priority rules described previously). 
-  * **Alert template**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same name**  will be considered as the **same template **  (following the priority rules described previously). +  * **Alert template**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same name**  will be considered as the **same template **  (following the priority rules described previously). 
-  * **Alert commands**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same name**  will be considered as the **same command **  (following the priority rules described previously). +  * **Alert commands**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same name**  will be considered as the **same command **  (following the priority rules described previously). 
-  * **Alert actions**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same name**  will be considered as the **same action **  (following the priority rules described previously). +  * **Alert actions**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same name**  will be considered as the **same action **  (following the priority rules described previously). 
-  * **//Server plugins//**  : They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same name and execution**  will be considered as the **same plugin **  (following the priority rules described previously). +  * **//Server plugins//**  : They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same name and execution**  will be considered as the **same plugin **  (following the priority rules described previously). 
-  * **OS**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same name **will be considered as the **same OS **  (following the priority rules described previously). +  * **OS**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same name **will be considered as the **same OS **  (following the priority rules described previously). 
-  * **Module tags**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same name**  will be considered as the **same tag **  (following the priority rules described previously). +  * **Module tags**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same name**  will be considered as the **same tag **  (following the priority rules described previously). 
-  * **Module categories**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same name**  will be considered as the **same category **  (following the priority rules described previously). +  * **Module categories**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same name**  will be considered as the **same category **  (following the priority rules described previously). 
-  * **Module groups**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same name**  will be considered as the **same group **  (following the priority rules described previously). +  * **Module groups**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same name**  will be considered as the **same group **  (following the priority rules described previously). 
-  * **Component group**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same name**  will be considered as the **same group **  (following the priority rules described previously). +  * **Component group**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same name**  will be considered as the **same group **  (following the priority rules described previously). 
-  * **Network components**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same name and OS**  will be considered as the **same component **  (following the priority rules described previously). +  * **Network components**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same name and OS**  will be considered as the **same component **  (following the priority rules described previously). 
-  * **Local components**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same name and OS**  will be considered as the **same component **  (following the priority rules described previously). +  * **Local components**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same name and OS**  will be considered as the **same component **  (following the priority rules described previously). 
-  * **Component Template**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same name**  will be considered as the **same template **  (following the priority rules described previously). +  * **Component Template**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same name**  will be considered as the **same template **  (following the priority rules described previously). 
-  * **Inventory module**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same name and OS**  will be considered as the **same module **  (following the priority rules described previously). +  * **Inventory module**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same name and OS**  will be considered as the **same module **  (following the priority rules described previously). 
-  * **Monitoring policies**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same name**  will be considered as the **same policy **  (following the priority rules described previously). +  * **Monitoring policies**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same name**  will be considered as the **same policy **  (following the priority rules described previously). 
-  * **Policy modules**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same name within a policy with the same name**  will be considered as the **same module **  (following the priority rules described previously). +  * **Policy modules**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same name within a policy with the same name**  will be considered as the **same module **  (following the priority rules described previously). 
-  * **Policy inventory modules**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same name and OS within a policy with the same name**  will be considered as the **same module **  (following the priority rules described previously). +  * **Policy inventory modules**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same name and OS within a policy with the same name**  will be considered as the **same module **  (following the priority rules described previously). 
-  * **//Policy plugins//**  : They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same execution within a policy with the same name**  will be considered as the **same plugin **  (following the priority rules described previously). +  * **//Policy plugins//**  : They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same execution within a policy with the same name**  will be considered as the **same plugin **  (following the priority rules described previously). 
-  * **Policy collections**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same short name within a policy with the same name**  will be considered as the **same collection **  (following the priority rules described previously). +  * **Policy collections**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same short name within a policy with the same name**  will be considered as the **same collection **  (following the priority rules described previously). 
-  * **Alerts and policy external alerts**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same template on the same module name within a policy with the same name**  will be considered as the **same alert **  (following the priority rules described previously). +  * **Alerts and policy external alerts**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same template on the same module name within a policy with the same name**  will be considered as the **same alert **  (following the priority rules described previously). 
-  * **Actions on alerts and policy external alerts**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those users with the **same name on the same template on the same module name within a policy with the same name**  will be considered as the **same action **  (following the priority rules described previously).+  * **Actions on alerts and policy external alerts**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the **same name on the same template on the same module name within a policy with the same name**  will be considered as the **same action **  (following the priority rules described previously).
   * **Agents within policies**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those within policies with the same name will be considered as the **agents within the same policy**. Agent logs within Metaconsole policies will be discarded and noly node logs will be taken into account (which is where application becomes effective).   * **Agents within policies**: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those within policies with the same name will be considered as the **agents within the same policy**. Agent logs within Metaconsole policies will be discarded and noly node logs will be taken into account (which is where application becomes effective).
   * **Agents**: Agent management in node is allowed, except for their deletion which should be done from the Metaconsola.   * **Agents**: Agent management in node is allowed, except for their deletion which should be done from the Metaconsola.
Line 88: Line 89:
  
 {{  :wiki:07_policies_centralised.png  }} {{  :wiki:07_policies_centralised.png  }}
 +
  
 ==== Prerequisites for launching the Command Center database merge ==== ==== Prerequisites for launching the Command Center database merge ====
Line 148: Line 150:
  
  
-==== Ejecución del proceso de mezcla ====+==== Merging process execution ==== 
 + 
 +The merging proces has **2 stages, **a first sitage to **synchronyze the different elements **that can be managed from the Metaconsole and a second stage to **update the references in the events to those centralized elements. **This process is performed that way to allow the console to be accesible again as soon as possible, since event updating is part of the process that can take the longest since it usually entails more information. Both stages are in turn divided into other 2 sub-stages differentiated in 2 progress bars. 
  
-El proceso de mezcla tiene **2 fases** diferenciadas, una primera fase para **sincronizar los distintos elementos** gestionables desde la Metaconsola y una segunda fase para **actualizar las referencias que haya en los eventos a esos elementos** centralizados. Este proceso se hace de esta forma para permitir que la consola sea accesible de nuevo lo antes posible, dado que la actualización de los eventos es la parte del proceso que más tiempo puede tomar al tratarse por lo general del mayor volumen de información. Ambas fases se encuentran a su vez divididas en otras 2 subfases diferenciadas en 2 barras de progreso. 
 === Stage 1 elements === === Stage 1 elements ===
  
-  * **Initialize:**  It checks all the previous requirements, generates the corresponding backups (if the requirements are met) in case any part of the process fails, and generates the result of the database merging within the memory. If this process fails for any reason, the databases will not have been modified yet, so it will not be necessary to restore backups. Backups are stored in each node/Metaconsole in the directory: ''pandora_console/attachment/merge_backups'' +In this stage **elements are synchronized **found in the databases from all nodes that can be managed from the Metaconsole. It is the merging process as such and it is sub-divided in other 2 stageseach one with its own progress bar:
-  * **Apply:**  If the previous initialization stage was successful, the result of the unification will begin to be applied to all nodes and the Metaconsole. This process is sequential in order of priorityso when one is finished, the next one will start. If there is an error during this process (for example, connection loss with a database), the process itself will try to restore the generated backups (a third red progress bar will be seen that will mark the restoration progress). If the reason for the failure prevents the backups from being recovered, the recovery must be done manually. +
-{{  :wiki:pfms-metaconsole-command_center_06.png  }}+
  
 +  * **Initialize:**  It checks all the previous requirements, generates the corresponding backups (if the requirements are met) in case any part of the process fails, and generates the result of the database merging within the memory. If this process fails for any reason, the databases will not have been modified yet, so it will not be necessary to restore backups. Backups are stored in each node/Metaconsole in the directory: ''/attachment/merge_backups''
 +  * **Apply:**  If the previous initialization stage was successful, it will be applied to all nodes and the Metaconsole. This process is sequential in order of priority, so when one is finished, the next one will start.
 +{{  :wiki:18_merge_success.png  }}
  
-=== Stage 2 events ===+If there is an error during this process (for example, connection loss with a database), the process itself will try to restore the generated backups (a third red progress bar will be seen that will mark the restoration progress). If the reason for the failure prevents the backups from being recovered, the recovery must be done manually.
  
-  * **Main database:**  CAs events are a large volume of information that is also affected, this update process takes place in parallel with the normal operation of the already merged environment. At this point, the server and **pandora_db**  can be started again normallyand standard users are able to access the console again. Of course, you will see in the event view the update process bar for all the events, so that for that part there might still be inconsistencies (regarding filters for example) only for the events that were there before the merge. //New events would be generated normally//This stage and process is launched by each of the nodes, through a specific task in the console's **cron**Due to the volume of information it can be a heavy and time-consuming task, so as far as possible the less load the environment has at that time the better (try to launch it outside of the busiest hours on Pandora FMS). +<WRAP center round important 60%> \\ If the source of the failure prevents the backups from being recovered, the recovering shall be performed manually\\ </WRAP>{{  :wiki:17_initialize_error.png  }} \\ {{  :wiki:19_merge_error.png  }}
-=== Historical database ===+
  
-  * It would be the continuation of the previous pointupdating the events in the historical database under the same characteristics already indicated.+<WRAP center round important 60%> \\ Sometimes there might be unexpected failures, for example connection lost for a while between the Metaconsole and a node's database or the impossibility of creating a backup due to not having aenough disk spaceso it is possible the error message shown will be generic. If that'the case and you need it, contact Pandora FMS support team to receive assistance\\ </WRAP>
  
-{{  :wiki:pfms-metaconsole-command_center_07.png  }}{{  :wiki:pfms-metaconsole-command_center_08.png  }} 
  
-Once stage 1 is finished, the environment will be considered centralized, and from there you will be able to manage everything from the Metaconsole. Element synchronization has also been changed, now the **pandora_ha**  process of each node is in charge of synchronizing its database with that of the Metaconsole (this process is executed together with the server as of version 755).+=== Stage 2: Event updating ===
  
-When we make a change in the Metaconsole (for example, create a userthis queues the necessary queries to the database for the nodes (''INSERTS'', ''UPDATES'', etc.) which **pandora_ha**  reads in an orderly manner and executes in each **server_threshold**. This ensures that if a server is down for a while, when it is started again it can catch up correctly.+In this stage **the existing references to the different synchronized elements in events will be updated ** (for example by groups). The stage is subdivided in the update of the main database events and the history database event update and will only affect those events that existed before launching the merging processThe new generated events after centralizing the nevironment will have all the correct references and won't need to be updated.
  
-This list of pending queries can be seen from the Metaconsole in the **Consoles setup**. If for some reason any query fails, the node will not continue with the rest, you will see an error in **Consoles setup**  and it will be necessary to treat it manually by an administratorIn most cases you should be able to fix it by launching the merging process again in the Command Center.+   * **Main database:**  As events are a large volume of information that is also affected, this update process takes place in parallel with the normal operation of the already merged environmentAt this point, the server and ''pandora_db''  can be started again normally, and standard users are able to access the console again. Of course, you will see in the event view the update process bar for all the events, so that for that part there might still be inconsistencies (regarding filters for example) only for the events that were there before the merge. //New events would be generated normally//. This stage and process is launched by each of the nodes, through a specific task in the console'**cron**. Due to the volume of information, it can be a heavy and time-consuming task, so as far as possible the less load the environment has at that time the better (try to launch it outside of the busiest hours on Pandora FMS). 
 +  * **History database**: It would be the continuation of the previous point, updating the events in the historical database under the same characteristics already indicated. 
 +{{  :wiki:20_events_success.png  }}
  
-{{  :wiki:pfms-metaconsole-command_center_09.png  }} 
  
-=== Including new nodes ===+==== Environment already centralized through Command Center ====
  
-If in an already centralized environment you add a new nodeedit one, or re-enable an existing one that has been left out of the mergeit will be necessary to go through the **Command Center**  again.+Once stage 1 is finished, the environment will be considered centralizedand from there you will be able to manage everything from the Metaconsole. Element synchronization has also been changed, now the ''pandora_ha'' process of each node is in charge of synchronizing its database with that of the Metaconsole.
  
-A message will be displayed advising the administrator to do this taskwhile the node will remain locked and inaccessible, in a //pending-to-merge state//.+When you make a change in the Metaconsole (for examplecreate a user) this queues the necessary queries to the database for the nodes (''INSERTS'', ''UPDATES''etc.) which ''pandora_ha'' reads in an orderly manner and executes in each server_threshold. This ensures that if server is down for a while, when it is started again it can catch up correctly.
  
-{{  :wiki:pfms-metaconsole-command_center_10.png  }}+This list of pending queries can be seen from the Metaconsole in the **Consoles setup**. If for some reason any query fails, the node will not continue with the rest, you will see an error in **Consoles setup** and it will be necessary to treat it manually by an administrator. In most cases you should be able to fix it by launching the merging process again in the Command Center.
  
-{{  :wiki:pfms-metaconsole-command_center_11.png  }}+{{  :wiki:21_metaconsoles_setup_sync_queue.png  }}
  
-The changes made will not be assigned and you will not have access to the console until the merging process finishes.+{{  :wiki:22_sync_queue.png  }}
  
-{{  :wiki:pfms-metaconsole-command_center_12.png  }} 
  
-<WRAP center round tip 60%> \\ If you need to make a change in the console to fix a bug in the merging process (such as applying an OUM), you can delete the item from the node list to temporarily unlock it. \\ </WRAP>+=== Including new nodes ===
  
-==== Items included in the synchronization ====+If in an already centralized environment you **add** a new node, **edit** one, or **re-enable** an existing one that has been left out of the merge, **it will be necessary to go through the** **Command Center** **again**.
  
-  * **Users**: It is managed only from the MetaconsoleNode management is disabled. +A message will be displayed warning the administrator to do this taskWhile it is not performed, the node will remain **locked and inaccessible**, in //pending-to-merge //statusThe changes made will not be assigned to it aor will it have access to the console until it goes through the merging process
-  * **Profiles**: It is managed only from the Metaconsole. Node management is disabled. + 
-  * **Groups**: It is managed only from the MetaconsoleNode management is disabled. +{{  :wiki:23_new_node.png  }} 
-  * **Policies**: It is managed only from the Metaconsole. Node management is disabled. In the node, you will be allowed to apply the policies previously managed by the Metaconsole+ 
-  * **Agents**Agent management is allowed in node, except its elimination that must be done from the Metaconsole. +<WRAP center round tip 60%>\\ 
-  * **Collections**: It is managed only from the Metaconsole. Node management is disabled. +If you need to make a change in the console to fix a bug in the merging process (such as applying an OUM)you may delete the item from the node list to temporarily unlock it.\\ 
-  * **Tags**: It is managed only from the Metaconsole. Node management is disabled. +</WRAP
-  * **Alerts (templatesactions and commands)**: It is managed only from the Metaconsole. Node management is disabled. + 
-  * **OS**: It is managed only from the Metaconsole. Node management is disabled+[[:en:documentation:start|Go back to Pandora FMS index]]
-  * **>Server plugins**: It is managed only from the Metaconsole. Node management is disabled. +
-  * **Local and remote components**: It is managed only from the Metaconsole. Node management is disabled. +
-  * **Module groups and categories**It is managed only from the Metaconsole. Node management is disabled. +
-  * **Inventory modules**It is managed only from the Metaconsole. Node management is disabled. +
-  * **Autoconfiguration rules**It is managed only from the Metaconsole. Node management is disabled. +
-The sections indicated with centralized management can only be configured from the Metaconsole. In case of accessing these elements from the nodes, you will only be able to list the elements, disappearing the editing options, and you will see a warning that will indicate that you are in centralized mode with a link that will take the administrator to the section of the corresponding Metaconsole for the configuration of these items.+
  
-{{  :wiki:pfms-metaconsole-command_center_13.png  }} 
  
-[[:en:documentation:start|Go back to Pandora FMS documentation index]] 
  
  
ºº