Skip to end of banner
Go to start of banner

opHA 3 - Centralised configuration

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Introduction

Managing and monitoring a large network of devices requires a scalable, high availability and easy to manage solution. opHA 3.0.5 brings a new feature that allows to centralise the configuration files from the master and send it to the pollers. The configuration files can be applied in NMIS and OMK. This partial configuration files would override the configuration that the poller has. 

Requirements

  • NMIS 9.0.6 is required
  • opHA version 3.0.5
  • The pollers also need to be updated with at least version 3.0.5 of opHA

How does it work

opHA 3.0.5 has the main key points:

  • The first step is create a file from a template (NMIS or OMK)
  • Validate and save the file
  • Create a group. By default, the following groups are created:
    • pollers: With contains all peers
    • master: With the local machine
  • Assign peers to a group
  • Assign group to a configuration file
  • Push the configuration file: The file will be send to the peers and restart the daemons when needed (You will see a message when it is necessary). 

Also, you can also map a role with a peer. By default, the following roles are available: 

  • 'Poller', 'Master', 'Portal', 'Local'

And this roles are assigned: 

  • Master: Server Local 
  • Poller: All existing peers available

View/Edit configuration files

Accessing from the menu Views > Configuration, we can see a list of the configured files.

Create a new configuration file

We can create a new configuration file clicking on the button "New Configuration File":


We would need to introduce:

  • The file name (Cannot be empty and had .nmis extension). 
  • The file type: If NMIS or OMK. It is very important to select the right type, as it is going to be applied on different products. 

Once we select a type, we would see a template loaded into the editor.

IMPORTANT considerations:

  • The file is edited in json format, but it is being saved as a perl hash. We can download the file as it is being saved from the Download button. 
  • We can remove/add sections when we have selected the Section "all". 
  • We can validate the file before being saved. If it is not valid, we will see the output on the console on the bottom. 
  • By default, once the file is saved, it is going to create a backup file, with a maximum of two.

Add a peer to a group

We can add a peer to a group on the button Peers Group from the Configuration menu. 

In this screen, we would see all the groups available and the peers added to the group. 

To edit the group members, we need to select the group, click Edit, and change the group members. Then, press Save. 

To edit the groups, we need to press the button Edit Groups. 

Create a new Group / Edit Groups

We can edit groups on the button Edit Groups from the Peers Groups menu. 

You can edit, add or remove existing groups. 

Please be aware that, if you remove a group, all group associations will be lost. 

Assign a Group to a Config file

Accessing from the menu Views > Configuration, we can see a list of the configured files. Pressing the Peer Group > Edit button,  we can add groups to a configuration file to be send that file.

Push a configuration file

Accessing from the menu Views > Configuration, we can see a list of the configured files. Pressing the Peer Group > Push button,  we can push a configuration file to the configured groups.

A note will be display when some daemons would need to be restarted. 

Once a configuration is Push, you will be able to see the Log as the result pressing on the status button:

Role Mapping

We can assign a peer to a role on the button Role Mapping from the Configuration menu:

We can add new mappings, edit or remove existing. Note that if a peer has a role assigned, it is not going to appear in the add button, you will need to edit. 

Changing NMIS default configuration

Please note that once we change NMIS or OMK configuration from the master, it is not intended to be edited from the own poller. 

When we update the configuration in NMIS from a master, we are going to see a message on the NMIS configuration screen, and we are not going to be able to update the configuration from NMIS. 

Restoring a Backup

By default, 2 backup files are saved in <omk/nmis>/backups. 

New configurations

These are new configuration values: 

  • opha_conf_templates_url: '/install/templates'
  • opha_backup_master_location: $self->{app_path}/conf/conf.d/backups
  • opha_master_config_location: $self->{app_path}/conf/conf.d
  • opha_conf_files_url: $self->{app_path}/conf/peers
  • opha_max_backup_files: 2
  • opha_restart_nmis_needed_sections: The sections for NMIS that require a daemon update.
  • opha_restart_omk_needed_sections: The sections of the configuration for OMK that require a daemon update. 
  • opha_role_list: ['Poller', 'Master', 'Portal', 'Local']
  • opha_config_file_types: ['NMIS', 'OMK']

Known issues

These are the know issues from this version (Will be solved in next releases): 

  • The configuration files pushed cannot be removed. But you can send the file again to override the necessary configuration. 
  • Backup files are saved, but it is not possible to rollback from the GUI. By default, configuration files have 2 backup files. 
  • Once you edit NMIS configuration, it is not possible to edit from the GUI. You will see a message when there are some configuration files overriding the local configuration. 
  • If the daemon is going to be restarted, it is not going to see the result on the log. 


  • No labels