Child pages
  • Common Node Properties
Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 3 Next »

A number of Opmantek products use a common node configuration infrastructure, which supports standard, product-specific and custom node attributes. This page describes both the core properties and outlines the product-specific ones.

Common Properties

These are used by all products. Only the first two, name and hostname are absolute necessary properties. The properties shown in italic are not interpreted by the applications and are completely optional.

Property NameDescription

The internal name of the node. This is used for identifying and displaying the node, not for communication with the node!


The DNS name, unqualified host name or main IP address for this  node. Using a fully qualified DNS host name is recommended.


A list containing any secondary IP addresses that should also be associated with this node. This list is often empty.


The (single) group that this node belongs to, which is used to control what nodes  a user is allowed to see.


Free-form notes for a node, which are shown on the relevant context pages. (optional)

locationThe location of the node. (optional)
businessServiceThe service the node provides. (optional)

Properties for Licensing And Activation

Both opConfig (2.1 and up) and opEvents (1.2.3 and up) support per-node activation and licensing, which is controlled by the properties described below.

If a node is disabled for a particular product, then it is completely ignored by this product: for opEvents that means no events are processed for this node, for opConfig no command sets would be run for the node and so on.

By default nodes are enabled for all products. Nodes are disabled if and only if they are explicitely marked as disabled.

Property NameDescription
activated.<productname>If set to 0, the node is disabled for <productname>.
If unset or set to any non-zero value, the node is considered active.

Note: The activation properties are within a subhash/subdocument, and the listing above used MongoDB dot-notation to indicate that (just like you would access such properties in an opEvents policy rule or an opConfig compliance rule).

opConfig Properties

opConfig requires two extra sets of properties for correct communication with a node, which are stored in the connection_info  and os_info subhash/subdocuments. The os_info information is primarily used in command set definitions, and customized command sets might not use any of these properties.

The properties given in italic are optional and only relevant for specific types of devices.

Property NameDescription


The type of OS or system 'personality', which is used for determining what command sets are applicable.


Which credential set to use when authenticating to  this node.


Which  transport mechanism to use for connecting to this node. Valid choices are "SSH" or "Telnet".


Whether setting up paging requires privileged mode. Only relevant on Cisco PIX/ASA.


What line separator character(s)  to send to the node. By default the patform's 'newline' character sequence is used.


The name of the phrasebook macro to use for line continuation.

connection_info.connect_optionsAny extra, non-standard options  for the connection. See the documentation for
Net::CLI::Interact for details. If present, this must be an Array in JSON format.
os_info.osThe general OS type. Required to determine what command sets are applicable.

The OS  Version identifier.


The Major Release Number extracted from the OS Version.


The Train of the OS version. Relevant for Cisco devices only.


The OS Platform as extracted from the Version.


The OS Image. Relevant mainly for Cisco devices.


The  enabled Feature Sets of this system. Relevant mainly for Cisco devices.

opEvents Properties

The current version of opEvents, 1.2.3, does not make use of product-specific properties.

Legacy Properties

When a node is refreshed or imported from NMIS, many of its properties in NMIS are also transferred. This includes certain SNMP-related identities, node active and collect flags and the like.

These properties are currently not used by opConfig or opEvents, but will show up when you export a node using opnode_admin. Your opEvents and opConfig policies can make use of these properties, you can edit them with opnode_admin (and, to some extent, via the GUI if you modify the configuration variables opevents_gui_node_summary_list and/or opconfig_gui_node_summary_list).

  • No labels