Pandora: Documentation en: Policy

Go back to Pandora FMS documentation index

We are working on the translation of the Pandora FMS documentation. Sorry for any inconvenience.

1 Policies

1.1 Introduction

The policy system is conceived to make large monitoring environment management easier. It allows to propagate modules, alerts, external alerts, plugins, remote inventories and collections to the agents in a centralized and homogeneous way, by modifying its configuration files through the remote edition feature called Agent Configuration.

Policy available operations are the following:

• Create/delete/duplicate a policy
• Add/delete one or several existing policy agents
• Create/edit/delete a module
• Create/edit/delete an alert
• Create/edit/delete an external alert
• Create/delete an already existing collection
• Create/delete an already existing inventory module
• Link the policy to one or several adopted modules
• Apply policy changes

For policy changes to become effective, apply the policy to the corresponding section (queue).

Policy management can be performed by clicking on Configuration > Manage Policies on the left side of the Pandora FMS web console as shown below.

1.2 Adding a Policy

Click on Configuration > Manage Policies and all available policies will be shown.

To create a new policy, click on 'Create' to create a new policy. Then the policy creation form will be displayed, where you must enter the name, the group it belongs to, and an optional description.

1.3 Deleting a Policy

If you intend to delete any policy, make sure it does not have any agents associated.

If a policy contains agents, the delete button is disabled and a button to delete all its agents is shown. This button will add the delete process to the queue. Once it has been processed, the policy delete button will be enabled again.

1.4 Duplicating a Policy

There is also a button to duplicate a policy.

The created policy copy will appear as "not applied", regardless of the original policy's state.

1.5 Configuring a Policy

In order to configure the policy, use the policy name under Configuration > Manage Policies. Once inside, access the different setup sections through the upper right menu. You may also edit elements directly by clicking on the direct accesses provided when hovering the mouse over the policy you intend to configure.

Policy configuration contains the following tabs in addition to the setup:

• Agents
• Modules
• Inventory modules
• Alerts
• External alerts
• Collections
• Linking
• Queue
• Agent plugins
• Agent wizards

The different executable actions are not applied until the policy is applied. For instance, if you add an agent to the policy, you may create several modules and alerts, but they do not go into effect until the policy is applied.

Likewise, if you have a policy applied and you modify or delete elements, the changes do not take effect until it is applied again.

All changes are displayed within the Queue window, where changes may be applied.

1.5.1 Policy queue management

The policy operations queue contains a summary of the elements changed since their last application:

This list contains the elements yet to be updated and the ones yet to be deleted:

• Pending to be updated
  • Agents
  • Groups
  • Adopted modules pending to be linked
  • Adopted modules pending to be unlinked
• Pending to be deleted
  • Agents
  • Groups
  • Modules
  • Inventory modules
  • Alerts
  • External alerts
  • Plugins

This summary shows whether the policy should be applied or not. Sometimes, a button will be shown to apply them next to the icon of agents pending to be applied.

If the pending changes only affect the database, e.g. changes in alerts, this button will apply the changes just at that level, so the application will be faster.

However, if the configuration that affects configuration files has been changed, e.g. if collections or local modules have been modified, the application is complete.

Under summary, there is a button called 'Apply All' at the right side, to apply everything regardless of the pending modifications.

When selecting "apply", the policy agents are added to the application queue. The Pandora FMS Server will be in charge of applying the pending policies to the queue. You may see in the same screen the application's progress, and when it is finished, it will appear as complete in the queue together with the time passed since it finished.

1.5.2 Agents and Groups

This window was designed to add or to delete both agents and groups from the policy. Use the selector located at the top to select agents and groups.

1.5.2.1 Agents

At the top there are filtering options to select the desired agents in bulk using Control or Shift keys.

At the bottom, there is a list with all agents associated to the policy and even those that are yet to be deleted from the policy.

The list of agents has the possibility to filter by group, substring or state. List of items displayed:

• Agent Name
• Remote Configuration
• Policy agent status
• Number of unlinked modules in the agent
• Button to add the agent to the policy
• Icon group in order to find out whether that agent was applied by a policy group
• Timestamp of the last time that the policy was applied
• Delete/Undo buttom

When an agent is deleted, its name will appear crossed out and the delete button will be replaced by a button to undo the deletion and link the agent to the policy again.

Of course, adding or deleting policy agents will take effect when the policy is applied on the Queue page.

1.5.2.2 Groups

At the top there is the group recursion option. If it is checked, all child groups will be also added to the policy. The desired groups can be selected through the Control or Shift keys.

At the bottom, there is a list containing all the groups linked to the policy, including those yet to be deleted.

The group list shows the following information:

• Group Name
• Policy group status
• Button to add that group to the queue in order to be applied
• Number of agents belonging to that group that have that policy applied, over the total number of group agents
• Timestamp of the last time that the policy was applied
• Delete/Undo button.

When a group is deleted, its name will appear crossed out and the delete button will be replaced by a button to undo the deletion and link the group to the policy again. The agents belonging to that group will also appear crossed out.

Of course, adding of deleting policy groups will not take affect until this one is applied.

1.5.3 Modules

The modules menu allows to configure the modules to be added to the policy.

In order to add modules, choose the type of module in the drop-down menu. Select one of the available ones,(data server, network, plugin, WMI, Web) and click on the "Create" button. It is the same procedure as creating a module within an agent.

1.5.3.1 Creating a Data Server module

Data Server modules are modules added to software agents. In order to work with these modules, the agents must have remote configuration enabled.

Select the option "Create a new data server module" and click on the "Create" button in order to create a new data server module.

Later, configure all module fields. The field called "Data Configuration" is the one that allows to enter the module's code which is applied to the agents subscribed to this policy. This change will be displayed in this particular agent's "pandora_agent.conf" file.

Go to advanced options by clicking on the "Advanced Options" button.

Check the description of these particular features in the Templates and Components section. There are two options: filling out the fields or having previously defined a local. See Local components

1.5.3.2 Creating a Network Server Module

To create a Network Server module, choose the option 'Create a new Network Server Module' and click on "Create".

Then configure all module fields.

Click on "Advanced Options" to access advanced options.

Check the description of these fields and screens in the Templates and Components section.

Click on 'Create' once all fields have been filled out.

Keeping in mind that modules are repeated most of the time. Instead of filling out the fields any time a module is added, the best option is to preliminarily define it as a component and to use it as such.

To use a component, fill out the combo located under "Using module component" where it is possible to choose between the different component groups.

Once the group has been selected, another combo pops up where to choose the desired component.

In this example, the component called "Catalyst CPU Usage" from the Cisco MIBs Group has been chosen.

Once the component is selected, any of its fields may be modified. Click on "Create" once all fields have been filled out appropriately.

1.5.3.3 Creating a Plug-in Server module

Plug-in server modules are created by choosing the option "Create a new Plug-In Server Module" and clicking on "Create".

Then configure all module fields.

You may access advanced options by clicking on "Advanced Options".

Check the description of the above mentioned features and options within the Templates and Components section.

Once you have filled out all the fields appropriately, click on "Create".

Keep in mind that the modules are repeated most of the time. Instead of always filling out the fields any time a module is added, the best option is to preliminarily define it as a component and to use it as such. The use of components is thoroughly explained in the section called templates and components.

Use macros to configure dynamic parameters, like the IP address of an agent. To see the list of available macros, click on the help(?) button on Plugin(?)

1.5.3.4 Creating a WMI Server module

To create a WMI Server module, click on "Create a new WMI Server Module" and click on "Create".

Then define all module fields.

By clicking on "Advanced Options", access advanced options.

Check the description of the fields of these screens in the Templates and Components section.

Once all the fields have been filled out appropriately, click on "Create".

Keeping in mind that the modules are repeated most of the time. Instead of always filling out the fields any time a module is added, the best option is to preliminarily define it as a component and to use it as such. Component use is further explained in the section named "create a network module". For more information, check Windows remote monitoring through WMI.

1.5.3.5 Creating a Web Server module

To create a Web Server module, select the option called "Create a new Web Server module" and click on the "Create" button.

Then configure all the module's fields.

Access advanced options by clicking on "Advanced Options".

Check the description of the fields in the Templates and Components section.

Once all the fields have been filled out appropriately, click on "Create".

In the particular case of Web modules, there are no components.

For more information about Web module creation check Web monitoring.

1.5.3.6 Modifying a previously created module

It is possible to modify all modules assigned to a policy.

In order to do so, click on the module's name so the module configuration options are shown.

Once they have been modified appropriately, click on "Update".

If the policy module is renamed, the name will be updated like any other field when the policy is applied.

If a policy module is renamed but a module with the new name already exists in one of the agents, this module will be adopted while the module with the old name is deleted.

1.5.3.7 Deleting an already created Module

In order to delete the module from the policy and remove it from agent configuration, click on the trash button to the right of the module's name. Once done, the module will still appear but crossed out. The "Delete" button will have been replaced by the "Undo" button.

If you wish to delete several modules, select the check box to the right of the trash icon and click "Delete".

1.5.4 Inventory modules

It is also possible to create inventory modules within a policy by picking one from the list of the available ones in the system, thereby picking an interval and the credentials.

Like the rest of the policy elements, if you remove an inventory module, it will appear crossed out. The "Undo" button will replace the delete one to undo the action.

For more information about adding remote inventory modules check Inventory modules.

1.5.5 Alerts

The Alert menu allows to configure the alerts of the modules that belong to the policy.

1.5.5.1 Adding Alerts

In order to add an alert, link it to one of the predefined templates or to a module that belongs to the policy and click on "Add".

1.5.5.2 Modifying Alerts

It is possible to add actions to alerts, set them on stand-by mode or disable them.

If you intend to change any module or template, delete it and create a new one.

1.5.5.3 Deleting Alerts

In order to delete an alert from the policy and remove it from the agents that have it installed, click on the trash button at the right of the module's name. Once done, the alert will still be visible but crossed out. Then, the "Delete" button will be replaced by an "Undo" button.

1.5.6 External Alerts

External alerts allow to link alerts to agent modules not included in the policy module's main list. It is sometimes very useful to assign alerts to some agent modules but not to all of them.

1.5.6.1 Adding External Alerts

In order to create an external alert, fill out this form. The first field is intended to select the agent's modules. Only those not contained in the policy. The second field is intended to select the appropriate alert template. This feature is available both in the Metaconsole and the nodes.

1.5.6.2 Modifying External Alerts

Considering how easy it is to create new external alerts and their few variables, the possibility of modifying external alerts does not exist. In order to modify an external alert, delete it and create a new one.

1.5.6.3 Deleting External Alerts

In order to delete an external alert from the policy and remove it from the agents that have it installed, click on the trash button on the right of the external alert.

The deletion system is the same as the one of the regular alerts. The deletion does not take effect until the policy is applied. Until that very moment, the policy will still appear but crossed out and the "Delete" button will be replaced by an "Undo" button to undo the action.

1.5.7 Agent plugins

The process to add policy plugins is the same as that of the agent. Check the section Plugins in software agents.

In order for the agent plugin to be applied by a policy, the plugin must exist in the path specified by the agent.

For more information about the development of these plugins go to Agent plugin development.

1.5.8 Policy module states

When a module is created based on a policy is applied, it is referenced through the policy icon. These policy modules may have several states:

• Linked
• Unlinked
• Adopted
• Linked adopted

1.5.8.1 Linked Modules

These modules are created in the policy and once the policy is applied, they are also created within the agent. These are the average modules created within policies.

You may link and unlink modules from the module setup page by clicking on this button.

1.5.8.2 Unlinked Modules

Unlinked modules are modules that belong to a policy but which are not affected by policy changes. They can be useful because the enable establishing individual exceptions to modules that belong to a certain policy. That way you may "customize" a specific agent module within a policy without taking it out from said policy.

Policy changes are only applied if the module is linked again.

1.5.8.3 Adopted Modules

These modules were created within the policy with the same name of an already existing module within the agent. When applying the policy, Pandora FMS uses the existing module's data instead of creating a new module and it will keep on being managed from the agent.

A este tipo de módulos no les afectan los cambios que se realicen en las políticas

If you delete a policy, adopted modules are not deleted from the agents, they use the local definition again.

1.5.8.4 Linked adopted modules

An adopted module can be linked to use the definition set in the policy instead of the local one. That way, when managing the module from the policy, when there is some change the module changes too.

When a policy is deleted, linked adopted modules go back to using the local definition.

When an agent is deleted from a policy, linked modules are deleted and just the linked and linked adopted modules are kept (with their local definition prior to the policy.)

1.5.9 File Collections

They are normally used to mass deploy scripts or plugins, which will be later on executed by the very policy agents.

The first point to discuss is how to use file collections in the agent's view, how to use manual mode, agent by agent, without using collections, and how to do the same thing by using policies.

The first task is to arrange a life compilation. In order to do it, go to the agent's administrator. There you will see a "sub-option" called "Collections". Click on it so that you may create a new collection as seen on the picture below.

Once you have created the file collection, upload any appropriate file. These files can be binaries, scripts or data files. All files are moved to the same base directory. It is extremely important that each file collection has its own base directory. In the console, file collections are stored under a directory called /pandora_console/attachment/collection, bearing a name like fc_XXX, where "XXX" is the collection's numerical ID. File collections may also contain subdirectories. File collections are transferred as ZIP files to the agent through Tentacle.

File collections are only supported by the Tentacle transference mode.

On the picture below, you may see how the created example collection (fc_1383033439) has two files downloaded:

If we go back to the main collection screen, you can see both collections as a triangular icon, which indicates that there is a problem. This happens because collections are not synchronized. It is recommended to synchronize them by clicking on that same triangular icon.

When a file collection is synchronized, a green arrow-shaped icon is displayed as shown on the screenshot below.

Once the collection is synchronized, it will be applied onto the agent - this time without using any policies. Go to the agent administrator mode and look for the collection's tabulator (it is a disk-shaped icon). The available collections are displayed there in order to pick one of them and apply it to the agent, as you can see in the windows utilities example on the picture below.

Now it has been applied. Next time the agent contacts the server, you will obtain the file and a little modification in the '.conf' file, which will look like this:

file_collection fc_1383033439

1.5.9.1 File collections and policies

This works in a similar way as the single agent collections. Instead of applying a collection on a specific agent, it is applied to a policy, as seen here.

It is very easy to use a module which works with a file included in the collection: only refer to the directory that contains the collection by using its fixed ID. This is an example that employs a plug-in module:

1.5.9.2 Collection centralized management

From Pandora FMS OUM729 onwards, you can centralize the collection management from the Metaconsole.

For more information, click here.

1.5.9.3 Agent file collections location

Each file collection has a "short name". In this example, it is called "fc_1383033439", which means the features, scripts or executables contained in the collection are located at "%Archivos de programa%\pandora_agent\collections\fc_1383033439". It is important to keep in mind that the collection is sent in a compressed format to the agent, so this file collection should contain the unzip tool to be able to unzip the file. Since the agent version 3.2, this feature is installed under "%Archivos de programa%\pandora_agent\utils".

This information is important in order to use modules that work by using these files and to be able to specify the complete "real" path.

This is another example:

If the collection's short name is "fc_18", the location will be "%ProgramFiles%\pandora_agent\collections\fc_18" in case the English language is used on this particular computer.

Each file collection is stored in a different location in order to prevent file collections from overwriting each other or having conflicts among them.

Collection control system is based on md5 hashes, similarly to agent configuration file management. When creating the collection in Pandora FMS console, a md5 hash is created that is later sent to the agent. This md5 will only be updated when changes in the collection next to the Pandora FMS console are made and not in the agent. Therefore, local collection changes will stay within the console while the collection is not modified in the console. If you make some change in the collection next to the console the md5 will be recalculated and if it does not match that of the agents, the last collection configuration will be applied, overwriting what was written before and deleting possible loca modifications on the collections.

This is an example of a plugin used by the "df_percent.vbs" file, contained in a collection called "fc_1383033439" for a windows-based agent:

module_plugin cscript //B "%ProgramFiles%\pandora_agent\collections\fc_1383033439\df_percent.vbs"

Go back to Pandora FMS Documentation Index

1.6 Policy search

It is possible to perform policy searches from the Pandora FMS search header both in the Metaconsole and the node.

In the section of policy result, there is a table with the following fields:

• Name.
• Description.
• Group.
• Status.

There are 2 types of results in the Metaconsole:

• Centralized search: The policies shown are those from the Metaconsole itself. In the table, there is the Server field that is filled out with the symbol "-" to indicate that the data are obtained from the Metaconsole itself.

• Non-centralized search: The policies shown are obtained directly from each node. In the table, there is the Server field that is filled out with the name of each node.

1.7 Policy management from the Metaconsole

It is possible to manage policies from the Metaconsole. The process consists of distributing the information to all the nodes for each of the servers in charge of applying them. This distribution of information is complex because it is important that all nodes have the same data as the Metaconsole.

1.7.1 Configuration. Centralized management mode

The Metaconsole has a centralized management mode. This means that, as far as policies are concerned, management is done from the Metaconsole and not from the node. In the Metaconsole, the selection of this mode is made from the general configuration.

For the configured nodes to know that the mode is centralized, just go to the license screen and synchronize. That way, all policy management pages will be informative only, that is, available in read-only mode. The new nodes that are added will be automatically configured in this mode.

Finding out if a node is in centralized mode or not. If so, a warning message will appear in the policy view.

1.7.2 Policy queue in Metaconsole

The policy queue in the Metaconsole is different from that of the nodes. While in the latter, you can see the status of the implementation of the incomplete policies and a history of those already completed, in the Metaconsole this second part has been deleted. Only those that have not been applied or are in progress are shown indicating the node they belong to.

However, if you want to check the history, it is available at the node. In fact, it is the only thing that can be managed from the node since all other pages are in read-only mode.

1.7.3 Data integrity

Node and Metaconsole data of each policy must match. Modules, alerts, inventory module, collections... have to be consistent. Therefore, when applying a policy from the Metaconsole, all this data is copied to the involved nodes.

It is very diverse and very sensitive information. There may be an error when copying the data. In this case, the console will display an error and the node will be rolled back with the previous data. In clean installations there should be no problem, but it is recommended to delete the previous policy configurations made manually in the nodes, transferring them to the metaconsole to later synchronize them from there.