opConfig 4 is the NMIS 9 compatible version. In this guide, you will learn all you need to start using opConfig.
We recommend you:
Once opConfig has been installed, we can access the GUI:
http://<yourserver>/en/omk/opConfig |
The first step will be to introduce the license, if we haven't done that yet:
Once we introduce the license we will see the first screen of opConfig, the dashboard, that will be empty for the moment:
Once opConfig has been installed, we need to set up the nodes. For this, we go to System > Edit Nodes.
All the local and remote nodes (Remote nodes are seen since version 4.1.1) are listed here:
Click in the button "Refresh OS Info all Nodes" to update the OS Info for all the local nodes. In this case, it would not take into account if the node is active for opConfig or not for a node to be selected.
This button will update the OS information for a node based on the file OS_Rules.nmis, located in the configuration directory by default. These rules are based, mostly, on the sysDescr configuration attribute. For this to be set, the community string must be correct and the device should have been successfully polled from NMIS at least once. We can check this information, among others, in the node information, by clicking in the node name.
In case we only want to set the OS Information for only the new nodes - The ones that don't have OS Info set, we can click in "Discover OS Info New Nodes".
We can review all the Node information if we click on a node. The information shown for a node is the following:
Once these details are set up, we can test the connection using the button "Test Connection".
We can also set up this configuration using the cli tool.
Note that, for remote nodes (Since version 4.1.1):
If a node has been added, these are the steps to perform for this node to be ready to work with opConfig:
If you need further debugging information for each step, you can use the cli tool with the debug option.
In the views menu we have the following views:
From this menu, we can schedule a configuration set to run once, by selecting a date, a node or node set, and a Configuration set. It is also possible to notify introducing an email.
When we create a new Schedule, we can see the following errors:
No nodes match your selections and the config set filters! A config set has a set of filters that has to mach with the selected node properties. For example, the selected Config set has the following filter:
"filter" : { "activated.opConfig" : 1, "connection_info.transport" : "SSH", "name" : [ "node1", "node2", "node3" ] }, |
So, the schedule only will be possible if we select node1, node2, or/and node3, and each one is active for opConfig and has SSH as transport.
The Virtual Operator is used to help create jobs comprised of commands sets to be run on various nodes, reporting to see job results and troubleshooting to diagnoses nodes which raise conditions. You can find a complete Virtual Operator guide in this link.
From the System > Edit Nodes menu we can see all nodes, a node details and Edit or add a new node. From the node details, we can Test the connection to a Node, or Discover the Node.
From opConfig 4.0.0, nodes information is shared between NMIS and opConfig, so the "Import Nodes from NMIS" option is not available anymore.
Credentials for all connections made by opConfig are configurable from the opConfig GUI ONLY. Before anything else you need to create sets of credentials to access you devices. At this point in time, opConfig supports only Telnet and SSH, and for SSH password-based authentication and RSA with no passphrase is supported.
Steps to set up your first automated job:
# opConfig: hourly command set running 1 * * * * root /usr/local/omk/bin/opconfig-cli.pl quiet=1 act=run_command_sets tags=HOURLY # and the daily ones 7 7 * * * * root /usr/local/omk/bin/opconfig-cli.pl quiet=1 act=run_command_sets tags=DAILY # and a daily import from open-audit enterprise 21 4 * * * root /usr/local/omk/bin/opconfig-cli.pl quiet=1 act=import_audit # and a daily purge of old revisions 40 3 * * * root /usr/local/omk/bin/opconfig-cli.pl act=purge_revisions quiet=1 |
The schedule maintains a queue of jobs and the opconfig daemon, opconfigd, is the responsible of running this jobs on time.
It is also important to review and set accordingly the purging policies.
The opConfig daemon, opconfigd process, will run in a loop performing the following operations:
Only "command" type jobs will be saved in the queue, to better keep track of the operations run.
See the documentation for What constitutes a change, and when should opConfig create new revisions
This configuration items will affect some running daemon aspects (Please, make sure you have restarted daemon once a configuration item - <omk_dir>/conf/opCommon.nmis - is changed):