Versions Compared

Old Version 41

changes.mady.by.user Nancy Smith

Saved on

compared with

New Version 42

changes.mady.by.user Mark Unwin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents
maxLevel3
Ï


Excerpt

opConfig Concepts

The main concepts to bear in mind are nodes, credential sets, commands, changes and revisions:

  • NODES:

    • Nodes are devices/computers that opConfig knows about, and which it is configured to run commands for.

    • As opConfig needs to connect to the node in question and execute commands on that node, the node needs to be configured with access credentials. In opConfig these are stored independent from the nodes in what opConfig calls credential sets.

  • CREDENTIAL SETS:

    • Credential sets are a combination of usernames, passwords, privileged passwords etc. allowing access to the devices CLI.
    • Once the credential set has been used to create a working CLI access then "commands" can be issued and the results recorded.

  • COMMAND SETS

    • Commands are normally command line constructs which will be executed on the node in question. 

      • (Some are "passive commands" like "audit-import" which are not actually run on the node but the result is associated with node.

      • Commands can be grouped and collected into what opConfig calls a "command set". Command sets are configured to apply only to particular OS and maybe versions or platforms.

    • The command output is captured and stored by opConfig.

    •  Command outputs are compared against the previous revision, and if different it's saved as a new revision in opConfig.  It could also be a one-shot command which is not analyzed in great detail (e.g. a process listing or some other diagnostic command)

    • A command can be marked for change detection in which case more detailed analysis occurs for changes.

  • CHANGES / REVISIONS:

    • Revisions are the command outputs as collected over time.
    • opConfig lets you distinguish between "very dynamic" and "mostly static" commands in an efficient flexible fashion:
      • Static commands should be marked for detailed change detection.
        In this case, a new revision is created if and only if there are (relevant) differences between the most recent state and the new  command output.
      • Dynamic commands should not be marked for change detection.
        Every time such a command is run, the output will be saved as a new revision - regardless of whether there were any differences between historic and current state.

...

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).

Code Block
languageperl
  '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

Defining which nodes a command set applies to

This is normally done by filtering by OS info, but not necessarily limited to OS info only:Below is much the same, but in the post 2.2.4, json format.

Code Block
languageperljs
#filter using both "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"
            ],
            "multipage" : "true"
         },


Defining which nodes a command set applies to

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

Code Block
languageperl
# Filter using both regular 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).

...

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:

Code Block
'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",

...