Page History

...

Command sets are stored in the single file conf/command_sets.nmis in opConfig before 2.2.4, and since .

Since 2.2.4 opConfig supports this and individual command set files in conf/command_sets.d/ and the files are now .json rather than .nmis.

It is recommended that you use individual files (as that makes things easier to maintain and more robust, e.g. should one file have syntactical problems). For backwards compatibility the old single file is consulted first, then any individual ones. opConfig loads a command set when it's seen for the first time, and any subsequent occurrences of a clashing config set (i.e. same name) will be ignored but logged.

...

Here is an excerpt from the default command set that  that ships with opConfig :(in .nmis, pre 2.2.4 format).

  'IOS_HOURLY' => {
    'os_info' => {
      'version' => '/12.2|12.4|15.\d+/',
      'os' => 'IOS'
    },
        'purging_policy' => {
            'keep_last' => 1000,
            'purge_older_than' => 2592000, # 30 days
            'autoprotect_first_revision' => 'true', 
        },    
        
        'scheduling_info' => {
      'run_commands_on_separate_connection' => 'false',
    },    
    'commands' => [
      {
        'multipage' => 'true',
        'privileged' => 'false',
        'command' => 'show interfaces',
        'tags' => [ 'HOURLY', 'performance', 'interfaces' ],
      },
      {
        'multipage' => 'true',
        'privileged' => 'false',',
        'command' => 'show ip interface',
        'tags' => [ 'HOURLY', 'detect-change', 'configuration' ],
      },
... and lots more

Below is much the same, but in the post 2.2.4, json format.

   "IOS_HOURLY" : {
      "scheduling_info" : {
         "run_commands_on_separate_connection" : "false",
         "attempt_timeout_recovery" : 1
      },
      "purging_policy" : {
         "purge_older_than" : 2592000,
         "keep_last" : 1000,
         "autoprotect_first_revision" : "true"
      },
      "commands" : [
         {
            "command" : "show interfaces",
            "privileged" : "false",
            "tags" : [
               "HOURLY",
               "performance",
               "interfaces"
        'command' => 'show ip interface'],
        'tags' => [ 'HOURLY', 'detect-change', 'configuration' ], "multipage" : "true"
      },
... and lots more},

Defining which nodes a command set applies to

This is normally done by filtering by OS info, but not necssarily necessarily limited to OS info only:

#filter# Filter using both regular expression and string equality checks:
'os_info' => {
 'version' => '/12.2|12.4|15.0/',
 'os' => 'IOS'
},
# orOr just the specific os family/type and that's all:
'os_info' => { 
 'os' => '/(Linux|CentOS|Ubuntu)/'
},

The examples above specify that the node in question must have an os_info property set, with sub-properties  properties os and version in the first example and just os in the second.

Plain string values indicate string comparison, but regular expressions can be given too. A node is only considered for this particular command set if all filtering expressions match. You can filter on any node property, not just properties from os_info (but the default command sets only use os_info).

...

For externally stored data the visible 'command output' in the GUI is made up from the size and the SHA256 checksum of the contents, and change detection (and the GUI) uses this data instead of the (possibly binary or huge) file contents. This produces much more coarse change detection, but works with binary files. In the GUI you'll see the made up 'command output', and a button to download the actua actual contents.

All other opConfig capabilities work normally for externally stored data; e.g. scheduling, tags, purging of old revisions, revision creation itself and so on.

...

opConfig 2.2 and newer can raise an event with NMIS if a change was detected for a node and a particular command. To . The event name is "Node Configuration Change Detected" and includes details of the change which has been detected.  To activate this feature you have to  give the command in question both the tags detect-change and report-change. You may also give a fixed event severity (values as defined in NMIS), like in this example:

...

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",

...