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

Compare with Current View Page History

« Previous Version 3 Next »

Configuration Options

Credential Sets

Credentials for all connections made by opConfig are stored encrypted in the database, and are configurable from the opConfig GUI: Menu System, Edit Credential Sets. Each credential sets has a name, and can be shared by any number of nodes.

Connections and OS Info

Connections define which devices/nodes opConfig should connect to, and which commands to run on that node. opConfig will connect to any node that has valid settings for personality, transport and credential set.

  • "Personality" identifies which set of prompts, strings, line-ending conventions etc. a node is subject to; for example, the 'ios' personality works only on Cisco IOS devices, while the 'bash' personality covers just about all Unix systems with the bash shell.
  • "Transport" is one of Telnet or SSH. At this point in time, only password-based authentication is supported for SSH.
  • "Credential Set" is the name of an existing credential  set that defines user name and password(s) for authenticating to a node.

To configure these settings go to the System Menu, Edit Nodes, select a node for edit/delete, then go to the Connections section. You'll see the relevant options shown with explanations in tooltips.

In addition to these fixed characteristics of a node, opConfig also makes use of the "OS Info" section: the entries in this section roughly define the node's Operating System, Platform and related characteristics. Generally all of opConfig's command sets are specific to OS or platform.

If you Import a Node from NMIS (or Refresh a Node from NMIS), then the OS information for this node is also imported from NMIS. You can, however, override those settings in the GUI.

Command Sets

Each command set defines two types of information:

  • information for filtering out which devices/nodes the commands will be run on,
  • and the actual commands to be run, and whether the commands should be run sequentiall in a single session/connection or be run separately on their own.

Here is an example command set, I will break it down in the sections that follow:

'IOS_DAILY' => {
 'os_info' => {
   'version' => '/12.2|12.4|15.0/',
   'os' => 'IOS'
 },
 'aging_info' => {
   'age' => 'forever'
 },
 'scheduling_info' => {
   'run_commands_on_separate_connection' => 'false'
 },
 commands => [
 {
   'tags' => [ 'config','version','troubleshooting', 'detect-change' ],
   'command' => 'show version',
   'privileged' => 'false',
   'multipage' => 'true',
   'run_command_on_separate_connection' => 'false',
   'command_filters' => [
     '/uptime is/'
   ]
 }
}}

Defining which nodes a command set applies to:

Filtering by OS info

#filter using a regular expression:
'os_info' => {
 'version' => '/12.2|12.4|15.0/',
 'os' => 'IOS'
},
# or just the specific os and that's all:
'os_info' => { 
 'os' => 'Linux'
},

A regular expression can be used in any filtering field.  Any hash or field can be defined in a connection and then filtered on in the command set (not just the ones that have been shown).

Making opConfig detect changes in a command output:

Not all output is worthy of change detection, configuration information generally is while performance information generally is not.  The configuration for a router, for example, is - but the usage counters on an interface is not.  Commands that have the tag detect-change will have change detection run on them by opConfig.  If the output is different from the previously stored output, a new revision is stored along with what the changes were.  If the tag is not defined, a new revision is stored (if the output is different) but no changes are tracked (and will not be reported in the GUI as a configuration change).

'tags' => ['detect-change'],

There is one more issue to resolve.  Not all changes found may be considered important or relavent.  To ignore unimportant changes a set of command filters can be added to a command:

'command_filters' => [
 '/uptime is/'
]

If the regular expression matches a change that change is considered unimportant and will not be tracked by the change management system (and so the GUI will not report it as a change)

Grouping commands into sessions:

By default all commands for a device will be run one after another within the same session/connection to that device.  This will generally save time as connecting to the device often takes longer than running all the commands on it.  This is not always the case and there will be certain commands that run for a longer period of time that should have their own connection, for example statistics gathering with iostat or vmstat.

If you would like to change the default behaviour and have opConfig run all commands in all command set in separate session/connection, modify opCommon.nmis like this:

# to run each command in it's own session, change this to true
 'opconfig_run_commands_on_separate_connection' => 'false',

It makes a lot more sense to tell opConfig to run a set of commands on their own or, in most cases, just a single command on it's own.  Running a command or set of commands on their own session/connection:

# to run all commands in one command set define this key to be true - note the S in run_commandS_...
'scheduling_info' => {
 'run_commands_on_separate_connection' => 'true'
},

# to run just a specific command on its own - no S in run_command_...
commands => [
 {
 'command' => 'show version',
 'run_command_on_separate_connection' => 'true',
 }]

 

Usage

opconfig-cli

Information on what commands are supported is printed when no options are specified.  All options support debug=true for debug output and debug=9 for extremely verbose output.  

Listed below are the possible options for the act=X argument:

import_from_nmis

Grabs one or more nodes from NMIS. Identical in function to "Refresh" or "Import Nodes from NMIS" in the GUI.

discover

Tests a single given node (argument node=nodeX) and attempts to determine its Transport and Credential Set configuration. The node must already have a Personality set.

test_connect

opconfig-cli can be used to test connections to help debug situations that don't make any sense. 

An example of how it can be used:

bin/opconfig-cli.pl act=test_connect host=192.168.88.254 transport=Telnet personality=ios username=testuser password=testpass

The options for transport and personality are given above.

It is also possible to test an existing connection from the connections.nmis file by specifying node=node_name , if any options are specified on the command line along with the node they will override the settings loaded from the connections.nmis file.

command="some command" can also be specified to test the output of a specific command.

run_command_sets, Running commands on devices

This command will run all command sets for all nodes (by default).  

Options:

  • nodes=node1,node2,etc -- only command sets for the specified nodes will be run.
  • command_set_names=command_set1,command_set2,etc – only run the specified command sets (and of course only for nodes matching the command sets' criteria)
  • tags=tag1,tag2,etc –  The matching nodes are filtered by the tags specified. If any given tag is present in the list of the node's tags, the node will be used.

get_command_output, Get the last output from a command for a node

Requries node=node_name command="command name" and returns output collected from the last run of this command

diff_command_outputs, Diff two revisions 

Shows the diff from the output of 2 revisions of stored output (does not run them, only queries).  The command line would look similar to get_command_output with the edition of revision_1= and revision_2=

eg. act=diff_command_outputs node=node1 command="show run" revision_1=10 revision_2=13

import_audit

This action imports audit information from Open-AudIT Enterprise, for all devices known to Open-AudIT.

This requires a licensed Version 1.4 of Open-AudIT Enterprise or newer. The audit information will show up in opConfig as command "audit", and the command output  will be the full audit data set in JSON format. Nodes will be consolidated as much as possible with your currently existing node definitions.


To enable this functionality, set the necessary options in conf/opCommon.nmis and run opconfig-cli.pl act=import_audit periodically or as a one-off. The required config settings are as follows:

'opconfig_audit_import' => 1, # to enable this altogether
'opconfig_audit_import_url_base' => "http://my.oae.system.com/omk/oae/",
'opconfig_audit_import_user' => "nmis",         # needs ro-access
'opconfig_audit_import_password' => "somepassword",

list_policies, import_policy, export_policy; update_config_status, export_config_status  and check_compliance

These operations are documented on the separate page about Compliance Management.

  • No labels