...
These are used by all Opmantek products (exception: NMIS does not use the addresses property). Only the first two, name and hostname,are absolute absolutely necessary properties.
The properties shown in italic are not directly interpreted by the applications and are completely optional.
| Property Name | Description |
|---|---|
| name | The internal name of the node. This is used for identifying and displaying the node, not for communication with the node! |
| host | The DNS name, unqualified host name or main IP address for this node. Using a fully qualified DNS host name is recommended. |
| addresses | A list containing any secondary IP addresses that should also be associated with this node. |
| group | The (single) group that this node belongs to, which is used to control what nodes nodes a user is allowed to see. |
| notes | Free-form notes for a node, which are shown on the relevant context pages. (optional) |
| comments | A list of originator- and time-tagged comments for this node. (optional, supported in opEvents 2.0 and newer) |
| location | The location of the node. (optional) |
| businessService | The service the node provides. (optional) |
...
For the new product generation, opEvents and opConfig use the same collection where NMIS 9 saves this data.
The properties shown in italic are not directly interpreted by the applications and are completely optional.
| Property Name | Description | ||
|---|---|---|---|
| uuid | A unique identifier | of the nodename | The internal name of the node. This is used for identifying and displaying the node, not for communication with the node! |
| cluster_id | The identifier for the server. Indicates that this is a local node when it is the same as the cluster_id specified in the NMIS 9 config file. | ||
| configuration.host | The DNS name, unqualified host name or main IP address for this node. Using a fully qualified DNS host name is recommended. | ||
| configuration.addresses | A list containing any secondary IP addresses that should also be associated with this node. | ||
| configuration.group | The (single) group that this node belongs to, which is used to control what nodes a user is allowed to see. | ||
| configuration.notes | Free-form notes for a node, which are shown on the relevant context pages. (optional) | ||
| configuration.comments | A list of originator- and time-tagged comments for this node. (optional, supported in opEvents 2.0 and newer) | ||
| configuration.location | The location of the node. (optional) | ||
| configuration.businessService | The 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. (NMIS doesn't use any of these.)
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 except opConfig. Nodes are disabled if and only if they are explicitly marked as set to disabled.
| Property Name | Description |
|---|---|
| activated.opConfig | If set to 0, the node is disabled for opConfig. If unset or set to any non-zero value, the node is considered active. |
| activated.opEvents | If set to 0, the node is disabled for opEvents. If unset or set to any non-zero value, the node is considered active. |
| activated. |
| NMIS | If set to 0, the node is disabled for |
| NMIS. If unset or set to any non-zero value, the node is considered active. All nodes that are activated for NMIS are activated and licensed for opCharts. |
Note: The activation properties are within a subhash/subdocument, and the listing above used uses MongoDB dot-notation to indicate that (just like you would access such properties in an opEvents policy rule or an opConfig compliance rule).
...