...

Now you know how you logged in, create a credential set to match this. To do this navigate to menu -> System -> Edit Credential Sets. What is important to note here is that this device only required a single password and does not use a privileged mode (root in Linux, enable in Cisco). So the new setting (introduced in opConfig 3.0.2), is "Automatically Privileged" for this node this should be set to "Yes".

...

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 opConfigopConfig

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

Find the node and edit it in opConfig, you should see a screen like below, this indicates that the OS and personality have been set, you can see them by selecting "Connection" and "OS Info" on the left.  If they are not set, you can edit the OS rule and press the "Refresh Node from NMIS" until they are set.

Create a Phrasebook

More information about phrase books: opConfig custom phrasebook and personality

To tell opConfig how to talk to a device, you need a a phrasebook, this is helping the system to know what to do.  

...

prompt user
    match /Login:/
prompt pass
    match /[Pp]assword:/
prompt generic 
    match /] > /
macro paging
    send nothing
macro disconnect
    send quit
prompt connection_error
    match /Connection refused|Received disconnect/

More information on creating a Phrasebook can be found HERE: opConfig custom phrasebook and personality

Test the Work So Far

The best way to test everything is to run a discovery on the node, this will match credential set and test the phrasebook, to run that we would run the command:

...

%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,
	},

...