...

Create an OS Rule

So that opConfig knows what the OS and other things, you will need to decide a few things, and then of the device (the Command Sets that apply), the personality (phrasebook that applies) as well as other interesting properties, we create an OS rule which will set these.  OS .  OS rules enable opConfig to automatically discover what to do with a deviceset those properties based on devices properties discovered by NMIS.

The file to edit is /usr/local/omk/conf/OS_Rules.nmis, at the end of the base configuration is some documentation, included in the appendix below,    ( see appendix below for some example configurations).

A quick look at the MikroTik device in NMIS showed that the Description field which is the SNMP variable sysDescr was "RouterOS CHR", this will be the basis for our OS Rule for MikroTik devices.

So we will be adding setting two properties, the OS (used in command_sets) and the personality (it's phrasebook), the OS tells opConfig which Command Set to use and the phrasebook tells opConfig how to talk to the routerSet to use and the phrasebook tells opConfig how to talk to the router with the right phrasebook.    You can also atomatically set other Node properties here e.g. "connection_info.transport" => "SSH".

	240 =>  {
		'IF' => {
			'sysDescr' => qr/RouterOS/,
		},
		'SET' => {
			'os_info.os' => 'RouterOS',
			'connection_info.personality' => 'routeros',
			BREAK => 'true',
		}
	},

This rule is saying, if I see the regular expression /RouterOS/ match in the field sysDescr, then set the following properties of the node.

Import the node into opConfig

sysDescr, then set the following properties of the node.

Import the node into opConfig

Access the menu in opConfig and import the node, you can do this from the menu "System -> Edit Nodes", then look for the blue button "Import new Nodes from NMIS".

...

%hash = (
	'ROUTEROS_DAILY' => {
		
    'os_info' => {
			'os' => 'RouterOS',
    },
		
    'scheduling_info' => {
      'run_commands_on_separate_connection' => 'false',
    },
		
	commands => [
      {
        'tags' => [ 'DAILY', 'configuration','version',
										'troubleshooting', 'detect-change', 'routeros' ],
        'command' => '/export',
        'privileged'  => 'false',
        'multipage' => 'false',
        'run_command_on_separate_connection' => 'false'       
      },
      {
        'tags' => [ 'DAILY', 'configuration','version',
										'troubleshooting', 'detect-change', 'routeros' ],
        'command' => '/system license print',
        'privileged'  => 'false',
        'multipage' => 'false',
        'run_command_on_separate_connection' => 'false'       
      },
      {
        'tags' => [ 'DAILY', 'configuration','version',
										'troubleshooting', 'detect-change', 'routeros' ],
        'command' => '/system package print',
        'privileged'  => 'false',
        'multipage' => 'false',
        'run_command_on_separate_connection' => 'false'       
      },    			
	
    ],
  },
);

Appendix A: OS Rules Help Text

# here are some example rules and explanations
		
	1 => {
		# all IF clauses must match. propnames are in main nodes structure,
		# and subarea.propname will work, too.
		IF => { 'nodeVendor' => qr/.../, 
						'sysDescr' => 'some static choice',
						'someotherprop' => [ 'static option 1', 'other static option' ],
						'elsewhere.subprop.subsubprop' => qr/whatever/,
		},
		
		# propname => what to set it to, totally static
		# all props set that way are a/v to subsequent rules
		SET => { 'os_info.os' => 'setOS string to match fixedstringcommand_set',
						     'connection_info.personality' => 'some other fixed stringphrasebook filename' },
		
		# property to consume -> regex -> commasep prop list to fill with captures
		# props captured are also a/v to subsequent rules; use undef as target to skip a capture
		CAPTURE => [ 
			[ 'sysDescr' => qr/with (capture)(groups)/ => "os_info.platform,os_info.otherthing" ]
			[ 'location' => qr/...(single).../ => "weird.prop.to.set", ],
			# and where evaluation is REQUIRED, but only with a SINGLE target property:
			[ 'thingy' => qr/...(more)than(one).../ => "some.prop" => 'an expression with $1, $2 etc.' ],
		],
			
		# if set to 1 or 'true', don't consider any other rules 
		# if this one already matched. no effect if the rule isn't matching.
		# i don't think this stuff needs to be nested/recursive,
		# but a cheapie overlapping setup would be good and useful:
		# e.g. R1: 'figure out if cisco-ish, don't break', then
		# R20: 'if cisco-ish is true form before, figure out if iosxr and if so, break.'
		BREAK => false,
	},

...