1. CORS Support
1.1. Why do I need CORS support?
By default, many browsers implement a same origin policy which prevents making requests to a resource, on an origin that’s different from the source origin.
For example, a request originating from a page served from http://www.opennms.org to a resource on http://www.adventuresinoss.com would be considered a cross origin request.
CORS (Cross Origin Resource Sharing) is a standard mechanism used to enable cross origin requests.
For further details, see:
1.2. How can I enable CORS support?
CORS support for the REST interface (or any other part of the Web UI) can be enabled as follows:
-
Open '$OPENNMS_HOME/jetty-webapps/opennms/WEB-INF/web.xml' for editing.
-
Apply the CORS filter to the '/rest/' path by removing the comments around the <filter-mapping> definition. The result should look like:
<!-- Uncomment this to enable CORS support --> <filter-mapping> <filter-name>CORS Filter</filter-name> <url-pattern>/rest/*</url-pattern> </filter-mapping>
-
Restart OpenNMS
1.3. How can I configure CORS support?
CORS support is provided by the org.ebaysf.web.cors.CORSFilter servlet filter.
Parameters can be configured by modifying the filter definition in the 'web.xml' file referenced above.
By default, the allowed origins parameter is set to '*'.
The complete list of parameters supported are available from:
2. ReST API
A RESTful interface is a web service conforming to the REST architectural style as described in the book RESTful Web Services. This page is describes the RESTful interface for OpenNMS.
2.1. ReST URL
The base URL for Rest Calls is: http://opennmsserver:8980/opennms/rest/
For instance, http://localhost:8980/opennms/rest/alarms/ will give you the current alarms in the system.
2.2. Authentication
Use HTTP Basic authentication to provide a valid username and password. By default you will not receive a challenge, so you must configure your ReST client library to send basic authentication proactively.
2.3. Data format
Jersey allows ReST calls to be made using either XML or JSON.
By default a request to the API is returned in XML.
To get JSON encoded responses one has to send the following header with the request: Accept: application/json
.
2.4. Standard Parameters
The following are standard params which are available on most resources (noted below)
Parameter | Description |
---|---|
|
integer, limiting the number of results. This is particularly handy on events and notifications, where an accidental call with no limit could result in many thousands of results being returned, killing either the client or the server. If set to 0, then no limit applied |
|
integer, being the numeric offset into the result set from which results should start being returned. E.g., if there are 100 result entries, offset is 15, and limit is 10, then entries 15-24 will be returned. Used for pagination |
Filtering: All properties of the entity being accessed can be specified as parameters in either the URL (for GET) or the form value (for PUT and POST). If so, the value will be used to add a filter to the result. By default, the operation is equality, unless the |
|
|
Checks for equality |
|
Checks for non-equality |
|
Case-insensitive wildcarding ( |
|
Case-sensitive wildcarding ( |
|
Greater than |
|
Less than |
|
Greater than or equal |
|
Less than or equal |
If the value null
is passed for a given property, then the obvious operation will occur (comparator will be ignored for that property).
notnull
is handled similarly.
-
Ordering: If the parameter
orderBy
is specified, results will be ordered by the named property. Default is ascending, unless theorder
parameter is set todesc
(any other value will default to ascending) -
Raw where clause: If there is a
query
parameter, it will be used as a raw where clause (SQL, not HQL), and added to any other filters created by other parameters
2.5. Standard filter examples
Take /events
as an example.
Resource | Description |
---|---|
|
would return the first 10 events with the rtc subscribe UEI, (10 being the default limit for events) |
|
would return all the rtc subscribe events (potentially quite a few) |
|
would return the first 10 events with an id greater than 100 |
|
would return the first 10 events that have a non-null Ack time (i.e. those that have been acknowledged) |
|
would return the first 20 events that have a non-null Ack time and an id greater than 100. Note that the notnull value causes the comparator to be ignored for eventAckTime |
|
would return the first 20 events that have were acknowledged after 28th July 2008 at 4:41am (+12:00), and an id greater than 100. Note that the same comparator applies to both property comparisons. Also note that you must URL encode the plus sign when using GET. |
|
would return the 10 latest events inserted (probably, unless you’ve been messing with the id’s) |
2.6. Currently Implemented Interfaces
2.6.1. Acknowledgements
the default offset is 0, the default limit is 10 results.
To get all results, use limit=0 as a parameter on the URL (ie, GET /acks?limit=0 ).
|
GETs (Reading Data)
Resource | Description |
---|---|
|
Get a list of acknowledgements. |
|
Get the number of acknowledgements. (Returns plaintext, rather than XML or JSON.) |
|
Get the acknowledgement specified by the given ID. |
POSTs (Setting Data)
Resource | Description |
---|---|
|
Creates or modifies an acknowledgement for the given alarm ID or notification ID. To affect an alarm, set an |
Usage examples with curl
curl -u 'admin:admin' -X POST -d notifId=3 -d action=ack http://localhost:8980/opennms/rest/acks
curl -u 'admin:admin' -X POST -d alarmId=42 -d action=esc http://localhost:8980/opennms/rest/acks
2.6.2. Alarm Statistics
It is possible to get some basic statistics on alarms, including the number of acknowledged alarms, total alarms, and the newest and oldest of acknowledged and unacknowledged alarms.
GETs (Reading Data)
Resource | Description |
---|---|
|
Returns statistics related to alarms. Accepts the same Hibernate parameters that you can pass to the |
|
Returns the statistics related to alarms, one per severity. You can optionally pass a list of severities to the |
2.6.3. Alarms
the default offset is 0, the default limit is 10 results. To get all results, use limit=0 as a parameter on the URL (ie, GET /events?limit=0 ).
|
GETs (Reading Data)
Resource | Description |
---|---|
|
Get a list of alarms. |
|
Get the number of alarms. (Returns plaintext, rather than XML or JSON.) |
|
Get the alarms specified by the given ID. |
Note that you can also query by severity, like so:
Resource | Description |
---|---|
|
Get the alarms with a severity greater than or equal to MINOR. |
PUTs (Modifying Data)
PUT requires form data using application/x-www-form-urlencoded as a Content-Type.
Resource | Description |
---|---|
|
Acknowledges (or unacknowledges) an alarm. |
|
Acknowledges (or unacknowledges) alarms matching the additional query parameters. eg, |
New in OpenNMS 1.11.0
In OpenNMS 1.11.0, some additional features are supported in the alarm ack API:
Resource | Description |
---|---|
|
Clears an alarm. |
|
Escalates an alarm. eg, NORMAL → MINOR, MAJOR → CRITICAL, etc. |
|
Clears alarms matching the additional query parameters. |
|
Escalates alarms matching the additional query parameters. |
Additionally, when acknowledging alarms (ack=true) you can now specify an ackUser
parameter.
You will only be allowed to ack
as a different user IF you are PUTting as an authenticated user who is in the admin role.
Queries
As noted above, it is possible to pass a raw query
parameter when doing ReST queries.
In the case of alarms, it is possible to pass severity names when querying by severity, rather than having to know the number that the severity enum maps to.
For example:
/alarms?query=lastEventTime%20%3E%20'2011-08-19T11%3A11%3A11.000-07%3A00'%20AND%20severity%20%3E%20MAJOR%20AND%20alarmAckUser%20IS%20NULL
This will get any alarms where the last event associated with the alarm is newer than August 19th, 2011 11:11:11, the severity is greater than MAJOR, and the alarm is not acknowledged (alarmAckUser
is null).
You should be able to use any column in the alarm, event, node, ipinterface, or snmpinterface tables.
2.6.4. Events
GETs (Reading Data)
Resource | Description |
---|---|
|
Get a list of events. The default for offset is 0, and the default for limit is 10. To get all results, use limit=0 as a parameter on the URL (ie, |
|
Get the number of events. (Returns plaintext, rather than XML or JSON.) |
|
Get the event specified by the given ID. |
PUTs (Modifying Data)
PUT requires form data using application/x-www-form-urlencoded
as a Content-Type.
Resource | Description |
---|---|
|
Acknowledges (or unacknowledges) an event. |
|
Acknowledges (or unacknowledges) the matching events. |
2.6.5. Foreign Sources
ReSTful service to the OpenNMS Provisioning Foreign Source definitions. Foreign source definitions are used to control the scanning (service detection) of services for SLA monitoring as well as the data collection settings for physical interfaces (resources).
This API supports CRUD operations for managing the Provisioner’s foreign source definitions. Foreign source definitions are POSTed and will be deployed when the corresponding requisition gets imported/synchronized by Provisiond.
If a request says that it gets the "active" foreign source, that means it returns the pending foreign source (being edited for deployment) if there is one, otherwise it returns the deployed foreign source.
GETs (Reading Data)
Resource | Description |
---|---|
|
Get all active foreign sources. |
|
Get the active default foreign source. |
|
Get the list of all deployed (active) foreign sources. |
|
Get the number of deployed foreign sources. (Returns plaintext, rather than XML or JSON.) |
|
Get the active foreign source named {name}. |
|
Get the configured detectors for the foreign source named {name}. |
|
Get the specified detector for the foreign source named {name}. |
|
Get the configured policies for the foreign source named {name}. |
|
Get the specified policy for the foreign source named {name}. |
POSTs (Adding Data)
POST requires XML using application/xml as its Content-Type.
Resource | Description |
---|---|
|
Add a foreign source. |
|
Add a detector to the named foreign source. |
|
Add a policy to the named foreign source. |
PUTs (Modifying Data)
PUT requires form data using application/x-www-form-urlencoded as a Content-Type.
Resource | Description |
---|---|
|
Modify a foreign source with the given name. |
DELETEs (Removing Data)
Resource | Description |
---|---|
|
Delete the named foreign source. |
|
Delete the specified detector from the named foreign source. |
|
Delete the specified policy from the named foreign source. |
2.6.6. Groups
Like users, groups have a simplified interface as well.
GETs (Reading Data)
Resource | Description |
---|---|
|
Get a list of groups. |
|
Get a specific group, given a group name. |
|
Get the users for a group, given a group name. (new in OpenNMS 14) |
|
Get the categories associated with a group, given a group name. (new in OpenNMS 14) |
POSTs (Adding Data)
Resource | Description |
---|---|
|
Add a new group. |
PUTs (Modifying Data)
Resource | Description |
---|---|
|
Update the metadata of a group (eg, change the |
|
Add a user to the group, given a group name and username. (new in OpenNMS 14) |
|
Associate a category with the group, given a group name and category name. (new in OpenNMS 14) |
DELETEs (Removing Data)
Resource | Description |
---|---|
|
Delete a group. |
|
Remove a user from the group. (new in OpenNMS 14) |
|
Disassociate a category from a group, given a group name and category name. (new in OpenNMS 14) |
2.6.7. Heatmap
GETs (Reading Data)
Resource | Description |
---|---|
|
Sizes and color codes based on outages for nodes grouped by Surveillance Categories |
|
Sizes and color codes based on outages for nodes grouped by Foreign Source |
|
Sizes and color codes based on outages for nodes grouped by monitored services |
|
Sizes and color codes based on outages for nodes associated with a specific Surveillance Category |
|
Sizes and color codes based on outages for nodes associated with a specific Foreign Source |
|
Sizes and color codes based on outages for nodes providing a specific monitored service |
Resource | Description |
---|---|
|
Sizes and color codes based on alarms for nodes grouped by Surveillance Categories |
|
Sizes and color codes based on alarms for nodes grouped by Foreign Source |
|
Sizes and color codes based on alarms for nodes grouped by monitored services |
|
Sizes and color codes based on alarms for nodes associated with a specific Surveillance Category |
|
Sizes and color codes based on alarms for nodes associated with a specific Foreign Source |
|
Sizes and color codes based on alarms for nodes providing a specific monitored service |
2.6.8. KSC Reports
GETs (Reading Data)
Resource | Description |
---|---|
|
Get a list of all KSC reports, this includes ID and label. |
|
Get a specific KSC report, by ID. |
|
Get a count of all KSC reports. |
PUTs (Modifying Data)
Resource | Description |
---|---|
|
Modify a report with the given ID. |
POSTs (Creating Data)
Documentation incomplete see issue: NMS-7162
DELETEs (Removing Data)
Documentation incomplete see issue: NMS-7162
2.6.9. Maps
The SVG maps use ReST to populate their data. This is the interface for doing that.
GETs (Reading Data)
Resource | Description |
---|---|
|
Get the list of maps. |
|
Get the map with the given ID. |
|
Get the elements (nodes, links, etc.) for the map with the given ID. |
POSTs (Adding Data)
Resource | Description |
---|---|
|
Add a map. |
PUTs (Modifying Data)
Resource | Description |
---|---|
|
Update the properties of the map with the given ID. |
DELETEs (Removing Data)
Resource | Description |
---|---|
|
Delete the map with the given ID. |
2.6.10. Measurements API
The Measurements API can be used to retrieve collected values stored in RRD (or JRB) files. Note that all units of time are expressed in milliseconds.
GETs (Reading Data)
Resource | Description |
---|---|
|
Retrieve the measurements for a single attribute |
The following table shows all supported query string parameters and their default values.
name | default | comment |
---|---|---|
start |
-14400000 |
Timestamp in milliseconds. If < 0, the effective value will be (end + start). |
end |
0 |
Timestamp in milliseconds. If ⇐ 0, the effective value will be the current timestamp. |
step |
300000 |
Requested time interval between rows. Actual step may differ. Set to 1 for maximum accuracy. |
maxrows |
0 |
When using the measurements to render a graph, this should be set to the graph’s pixel width. |
interval |
null |
Duration in milliseconds, used by strategies that implement late aggregation. |
heartbeat |
null |
Duration in milliseconds, used by strategies that implement late aggregation. |
aggregation |
AVERAGE |
Consolidation function used. Can typically be |
fallback-attribute |
Secondary attribute that will be queried in the case the primary attribute does not exist. |
Usage examples with curl
curl -u admin:admin "http://127.0.0.1:8980/opennms/rest/measurements/node%5B1%5D.nodeSnmp%5B%5D/CpuRawUser?start=-7200000&maxrows=30&aggregation=AVERAGE"
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<query-response end="1425588138256" start="1425580938256" step="300000">
<columns>
<values>159.5957271523179</values>
<values>158.08531037527592</values>
<values>158.45835584842285</values>
...
</columns>
<labels>CpuRawUser</labels>
<timestamps>1425581100000</timestamps>
<timestamps>1425581400000</timestamps>
<timestamps>1425581700000</timestamps>
...
</query-response>
POSTs (Reading Data)
Resource | Description |
---|---|
|
Retrieve the measurements for one or more attributes, possibly spanning multiple resources, with support for JEXL expressions. |
Here we use a POST instead of a GET to retrieve the measurements, which allows us to perform complex queries which are difficult to express in a query string. These requests cannot be used to update or create new metrics.
An example of the POST body is available bellow.
Usage examples with curl
curl -X POST -H "Accept: application/json" -H "Content-Type: application/json" -u admin:admin -d @report.json http://127.0.0.1:8980/opennms/rest/measurements
{
"start": 1425563626316,
"end": 1425585226316,
"step": 10000,
"maxrows": 1600,
"source": [
{
"aggregation": "AVERAGE",
"attribute": "ifHCInOctets",
"label": "ifHCInOctets",
"resourceId": "nodeSource[NODES:1424038123222].interfaceSnmp[eth0-04013f75f101]",
"transient": "false"
},
{
"aggregation": "AVERAGE",
"attribute": "ifHCOutOctets",
"label": "ifHCOutOctets",
"resourceId": "nodeSource[NODES:1424038123222].interfaceSnmp[eth0-04013f75f101]",
"transient": "true"
}
],
"expression": [
{
"label": "ifHCOutOctetsNeg",
"value": "-1.0 * ifHCOutOctets",
"transient": "false"
}
]
}
{
"step": 300000,
"start": 1425563626316,
"end": 1425585226316,
"timestamps": [
1425563700000,
1425564000000,
1425564300000,
...
],
"labels": [
"ifHCInOctets",
"ifHCOutOctetsNeg"
],
"columns": [
{
"values": [
139.94817275747508,
199.0062569213732,
162.6264894795127,
...
]
},
{
"values": [
-151.66179401993355,
-214.7415503875969,
-184.9012624584718,
...
]
}
]
}
2.6.11. Nodes
Note: the default offset is 0, the default limit is 10 results. To get all results, use limit=0 as a parameter on the URL (ie, GET /nodes?limit=0).
Additionally, anywhere you use "id" in the queries below, you can use the foreign source and foreign ID separated by a colon instead (ie, GET /nodes/fs:fid).
GETs (Reading Data)
Resource | Description |
---|---|
|
Get a list of nodes. This includes the ID and node label. |
|
Get a specific node, by ID. |
|
Get the list of IP interfaces associated with the given node. |
|
Get the IP interface for the given node and IP address. |
|
Get the list of services associated with the given node and IP interface. |
|
Get the requested service associated with the given node, IP interface, and service name. |
|
Get the list of SNMP interfaces associated with the given node. |
|
Get the specific interface associated with the given node and ifIndex. |
|
Get the list of categories associated with the given node. |
|
Get the category associated with the given node and category name. |
|
Get the asset record associated with the given node. |
POSTs (Adding Data)
POST requires XML using application/xml as its Content-Type.
Resource | Description |
---|---|
|
Add a node. |
|
Add an IP interface to the node. |
|
Add a service to the interface for the given node. |
|
Add an SNMP interface to the node. |
|
Add a category association to the node. |
PUTs (Modifying Data)
PUT requires form data using application/x-www-form-urlencoded as a Content-Type.
Resource | Description |
---|---|
|
Modify a node with the given ID. |
|
Modify the IP interface with the given node ID and IP address. |
|
Modify the service with the given node ID, IP address, and service name. |
|
Modify the SNMP interface with the given node ID and ifIndex. |
|
Modify the category with the given node ID and name. |
DELETEs (Removing Data)
Perform a DELETE to the singleton URLs specified in PUT above to delete that object.
2.6.12. Notifications
Note: the default offset is 0, the default limit is 10 results.
To get all results, use limit=0
as a parameter on the URL (ie, GET /events?limit=0
).
GETs (Reading Data)
Resource | Description |
---|---|
|
Get a list of notifications. |
|
Get the number of notifications. (Returns plaintext, rather than XML or JSON.) |
|
Get the notification specified by the given ID. |
To acknowledge or unacknowledge a notification, use the acks
endpoint — see Acknowledgements.
2.6.13. Outage Timelines
GETs (Reading Data)
Resource | Description |
---|---|
|
Generate the timeline header |
|
Generate the timeline image |
|
Generate an empty timeline for non-monitored services |
|
Generate the raw HTML for the image |
2.6.14. Outages
GETs (Reading Data)
Resource | Description |
---|---|
|
Get a list of outages. |
|
Get the number of outages. (Returns plaintext, rather than XML or JSON.) |
|
Get the outage specified by the given ID. |
|
Get the outages that match the given node ID. |
2.6.15. Requisitions
RESTful service to the OpenNMS Provisioning Requisitions. In this API, these "groups" of nodes are aptly named and treated as requisitions.
This current implementation supports CRUD operations for managing provisioning requisitions. Requisitions are first POSTed and no provisioning (import/synchronize) operations are taken. This is done so that a) the XML can be verified and b) so that the operations can happen at a later time. They are moved to the deployed state (put in the active requisition repository) when an import is run.
If a request says that it gets the active requisition, that means it returns the pending requisition (being edited for deployment) if there is one, otherwise it returns the deployed requisition. Note that anything that says it adds/deletes/modifies a node, interface, etc. in these instructions is referring to modifying that element from the requisition not from the database itself. That will happen upon import/synchronization.
You may write requisition data if the authenticated user is in the provision, rest, or admin roles.
GETs (Reading Data)
Resource | Description |
---|---|
|
Get all active requisitions. |
|
Get the number of active requisitions. (Returns plaintext, rather than XML or JSON.) |
|
Get the list of all deployed (active) requisitions. |
|
Get the number of deployed requisitions. (Returns plaintext, rather than XML or JSON.) |
|
Get the active requisition for the given foreign source name. |
|
Get the list of nodes being requisitioned for the given foreign source name. |
|
Get the node with the given foreign ID for the given foreign source name. |
|
Get the interfaces for the node with the given foreign ID and foreign source name. |
|
Get the interface with the given IP for the node with the specified foreign ID and foreign source name. |
|
Get the services for the interface with the specified IP address, foreign ID, and foreign source name. |
|
Get the given service with the specified IP address, foreign ID, and foreign source name. |
|
Get the categories for the node with the given foreign ID and foreign source name. |
|
Get the category with the given name for the node with the specified foreign ID and foreign source name. |
|
Get the assets for the node with the given foreign ID and foreign source name. |
|
Get the value of the asset for the given assetName for the node with the given foreign ID and foreign source name. |
POSTs (Adding Data)
Resource | Description |
---|---|
|
Adds (or replaces) a requisition. |
|
Adds (or replaces) a node in the specified requisition. This operation can be very helpful when working with [[Large Requisitions]]. |
|
Adds (or replaces) an interface for the given node in the specified requisition. |
|
Adds (or replaces) a service on the given interface in the specified requisition. |
|
Adds (or replaces) a category for the given node in the specified requisition. |
|
Adds (or replaces) an asset for the given node in the specified requisition. |
PUTs (Modifying Data)
Resource | Description |
---|---|
|
Performs an import/synchronize on the specified foreign source. This turns the "active" requisition into the "deployed" requisition. |
|
Performs an import/synchronize on the specified foreign source. This turns the "active" requisition into the "deployed" requisition. Existing nodes will not be scanned until the next rescan interval, only newly-added nodes will be. Useful if you’re planning on making a series of changes. |
|
Update the specified foreign source. |
|
Update the specified node for the given foreign source. |
|
Update the specified IP address for the given node and foreign source. |
DELETEs (Removing Data)
Resource | Description |
---|---|
|
Delete the pending requisition for the named foreign source. |
|
Delete the active requisition for the named foreign source. |
|
Delete the node with the given foreign ID from the given requisition. |
|
Delete the IP address from the requisitioned node with the given foreign ID and foreign source. |
|
Delete the service from the requisitioned interface with the given IP address, foreign ID and foreign source. |
|
Delete the category from the node with the given foreign ID and foreign source. |
|
Delete the field from the requisition’s nodes asset with the given foreign ID and foreign source. |
2.6.16. Realtime Console data
The Realtime Console (RTC) calculates the availability for monitored services. Data provided from the RTC is available to the ReST API.
GETs (Reading Data)
Resource | Description |
---|---|
|
Get all nodes and availability data from a given SLA category filter, i.e. Web Servers (Web+Servers) |
|
Get node availability data for each node of a given SLA category filter |
|
Get detailed service availability for a given node in a given SLA category filter |
|
Get detailed availability for all services on a given node |
Example
curl -u demo:demo http://demo.opennms.org/opennms/rest/availability/categories/Web+Servers
curl -u demo:demo http://demo.opennms.org/opennms/rest/availability/categories/nodes
curl -u demo:demo http://demo.opennms.org/opennms/rest/availability/categories/nodes/31
curl -u demo:demo http://demo.opennms.org/opennms/rest/availability/nodes/31
2.6.17. Scheduled Outages
GETs (Reading Data)
Parameter | Description |
---|---|
|
to get a list of configured scheduled outages. |
|
to get the details of a specific outage. |
POSTs (Setting Data)
Parameter | Description |
---|---|
|
to add a new outage (or update an existing one). |
PUTs (Modifying Data)
Parameter | Description |
---|---|
|
to add a specific outage to a collectd’s package. |
|
to add a specific outage to a pollerd’s package. |
|
to add a specific outage to a threshd’s package. |
|
to add a specific outage to the notifications. |
DELETEs (Removing Data)
Parameter | Description |
---|---|
|
to delete a specific outage. |
|
to remove a specific outage from a collectd’s package. |
|
to remove a specific outage from a pollerd’s package. |
|
to remove a specific outage from a threshd’s package. |
|
to remove a specific outage from the notifications. |
2.6.18. SNMP Configuration
You can edit the community string, SNMP version, etc. for an IP address using this interface. If you make a change that would overlap with an existing snmp-config.xml, it will automatically create groups of <definition /> entries as necessary. If no <definition /> entry is created it matches the defaults.
There are different versions of the interface (see below). The following operations are supported:
GETs (Reading Data)
Parameter | Description |
---|---|
|
Get the SNMP configuration for a given IP address. |
PUTs (Modifying Data)
Parameter | Description |
---|---|
|
Add or update the SNMP configuration for a given IP address. |
Determine API version
To determine the version of the API running in your OpenNMS type http://localhost:8980/opennms/rest/snmpConfig/1.1.1.1 in your browser and have a look at the output:
-
Version 1: If the output only have attributes
community
,port
,retries
,timeout
andversion
-
Version 2: If there are more attributes than described before (e.g. max Repetitions)
API Version 1
In version 1 only a few attributes defined in snmp-config.xsd
are supported.
These are defined in snmp-info.xsd
:
<xs:schema
xmlns:tns="http://xmlns.opennms.org/xsd/config/snmp-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
version="1.0"
targetNamespace="http://xmlns.opennms.org/xsd/config/snmp-info">
<xs:element name="snmp-info" type="tns:snmpInfo"/>
<xs:complexType name="snmpInfo">
<xs:sequence>
<xs:element name="community" type="xs:string" minOccurs="0"/>
<xs:element name="port" type="xs:int"/>
<xs:element name="retries" type="xs:int"/>
<xs:element name="timeout" type="xs:int"/>
<xs:element name="version" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
The following table shows all supported attributes, optional restrictions and the mapping between snmp-info.xsd
and snmp-config.xsd
.
All parameters can be set regardless the version.
attribute snmp-info.xml | attribute snmp-config.xml | default | restricted to version | restriction |
---|---|---|---|---|
version |
version |
v1 |
- |
"v1", "v2c" or "v3" are valid arguments. If an invalid or empty argument is provided "v1" is used. |
port |
port |
161 |
- |
Integer > 0 |
retries |
retry |
1 |
- |
Integer > 0 |
timeout |
timeout |
3000 |
- |
Integer > 0 |
community |
read-community |
public |
- |
any string with a length >= 1 |
curl -v -X PUT -H "Content-Type: application/xml" \
-H "Accept: application/xml" \
-d "<snmp-info>
<community>yRuSonoZ</community>
<port>161</port>
<retries>1</retries>
<timeout>2000</timeout>
<version>v2c</version>
</snmp-info>" \
-u admin:admin http://localhost:8980/opennms/rest/snmpConfig/10.1.1.1
Creates or updates a <definition/>
-entry for IP address 10.1.1.1 in snmp-config.xml
.
curl -v -X GET -u admin:admin http://localhost:8980/opennms/rest/snmpConfig/10.1.1.1
Returns the SNMP configuration for IP address 10.1.1.1 as defined in example 1.
API Version 2
Since Version 2 all attributes of a <definition />
entry defined in snmp-config.xsd
(http://xmlns.opennms.org/xsd/config/snmp) can be set or get via the interface - except it is only possible to set the configuration for one IP address and not for a range of IP addresses.
This may change in the future.
The interface uses SnmpInfo objects for communication.
Therefore it is possible to set for example v1 and v3 parameters in one request (e.g. readCommunity
String and privProtocol
String).
However OpenNMS does not allow this.
It is only allowed to set attributes which have no version restriction (e.g. timeout value) or the attributes which are limited to the version (e.g. readCommunity
String if version is v1/v2c).
The same is for getting data from the API, even if it is possible to store v1 and v3 parameters in one definition block in the snmp-config.xml
manually, the ReST API will only return the parameters which match the version.
If no version is defined, the default is assumed (both in PUT and GET requests).
The SnmpInfo schema is defined as follows:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<xs:schema
elementFormDefault="qualified"
version="1.0"
targetNamespace="http://xmlns.opennms.org/xsd/config/snmp-info"
xmlns:tns="http://xmlns.opennms.org/xsd/config/snmp-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="snmp-info" type="tns:snmpInfo"/>
<xs:complexType name="snmpInfo">
<xs:sequence>
<xs:element name="authPassPhrase" type="xs:string" minOccurs="0"/>
<xs:element name="authProtocol" type="xs:string" minOccurs="0"/>
<xs:element name="community" type="xs:string" minOccurs="0"/>
<xs:element name="contextEngineId" type="xs:string" minOccurs="0"/>
<xs:element name="contextName" type="xs:string" minOccurs="0"/>
<xs:element name="engineId" type="xs:string" minOccurs="0"/>
<xs:element name="enterpriseId" type="xs:string" minOccurs="0"/>
<xs:element name="maxRepetitions" type="xs:int" minOccurs="0"/>
<xs:element name="maxRequestSize" type="xs:int" minOccurs="0"/>
<xs:element name="maxVarsPerPdu" type="xs:int" minOccurs="0"/>
<xs:element name="port" type="xs:int" minOccurs="0"/>
<xs:element name="privPassPhrase" type="xs:string" minOccurs="0"/>
<xs:element name="privProtocol" type="xs:string" minOccurs="0"/>
<xs:element name="proxyHost" type="xs:string" minOccurs="0"/>
<xs:element name="readCommunity" type="xs:string" minOccurs="0"/>
<xs:element name="retries" type="xs:int" minOccurs="0"/>
<xs:element name="securityLevel" type="xs:int" minOccurs="0"/>
<xs:element name="securityName" type="xs:string" minOccurs="0"/>
<xs:element name="timeout" type="xs:int" minOccurs="0"/>
<xs:element name="version" type="xs:string" minOccurs="0"/>
<xs:element name="writeCommunity" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
The following table shows all supported attributes, the mapping between snmp-info.xsd
and snmp-config.xsd
.
It also shows the version limitations, default values and the restrictions - if any.
attribute snmp-info.xml | attribute snmp-config.xml |
---|---|
default |
restricted to version |
restriction |
version |
version |
v1 |
- |
"v1", "v2c" or "v3" are valid arguments. If an invalid or empty argument is provided "v1" is used. |
port |
port |
161 |
- |
Integer > 0 |
retries |
retry |
1 |
- |
Integer > 0 |
timeout |
timeout |
3000 |
- |
Integer > 0 |
maxVarsPerPdu |
max-vars-per-pdu |
10 |
- |
Integer > 0 |
maxRepetitions |
max-repetitions |
2 |
- |
Integer > 0 |
maxRequestSize |
max-request-size |
65535 |
- |
Integer > 0 |
proxyHost |
proxy-host |
- |
|
readCommunity |
|
read-community |
public |
v1, v2c |
|
writeCommunity |
write-community |
private |
v1, v2c |
securityName |
|
security-name |
opennmsUser |
v3 |
|
securityLevel |
security-level |
noAuthNoPriv |
v3 |
Integer value, which can be null, 1, 2, or 3. <ul><li>1 means noAuthNoPriv</li><li>2 means authNoPriv</li><li>3 means authPriv</li></ul> If you do not set the security level manually it is determined automatically: <ul><li>if no authPassPhrase set the securityLevel is 1</li><li>if a authPassPhrase and no privPassPhrase is set the security level is 2.</li><li>if a authPassPhrase and a privPassPhrase is set the security level is 3.</li></ul> |
authPassPhrase |
auth-passphrase |
0p3nNMSv3 |
v3 |
|
authProtocol |
auth-protocol |
MD5 |
v3 |
only MD5 or SHA are valid arguments |
privPassPhrase |
privacy-passphrase |
0p3nNMSv3 |
v3 |
|
privProtocol |
privacy-protocol |
DES |
v3 |
only DES, AES, AES192 or AES256 are valid arguments. |
engineId |
engine-id |
|
v3 |
|
contextEngineId |
context-engine-id |
v3 |
|
contextName |
|
context-name |
|
v3 |
|
enterpriseId |
enterprise-id |
v3 |
curl -v -X PUT -H "Content-Type: application/xml" \
-H "Accept: application/xml" \
-d "<snmp-info>
<readCommunity>yRuSonoZ</readCommunity>
<port>161</port>
<retries>1</retries>
<timeout>2000</timeout>
<version>v2c</version>
</snmp-info>" \
-u admin:admin http://localhost:8980/opennms/rest/snmpConfig/10.1.1.1
Creates or updates a <definition/>
-entry for IP address 10.1.1.1 in snmp-config.xml
.
curl -v -X GET -u admin:admin http://localhost:8980/opennms/rest/snmpConfig/10.1.1.1
Returns the SNMP configuration for IP address 10.1.1.1 as defined in example 1.
curl -v -X PUT -H "Content-Type: application/xml" \
-H "Accept: application/xml" \
-d "<snmp-info>
<readCommunity>yRuSonoZ</readCommunity>
<port>161</port>
<retries>1</retries>
<timeout>2000</timeout>
<version>v1</version>
<securityName>secret-stuff</securityName>
<engineId>engineId</engineId>
</snmp-info>" \
-u admin:admin http://localhost:8980/opennms/rest/snmpConfig/10.1.1.1
Creates or updates a <definition/>
-entry for IP address 10.1.1.1 in snmp-config.xml
ignoring attributes securityName
and engineId
.
curl -v -X PUT -H "Content-Type: application/xml" \
-H "Accept: application/xml" \
-d "<snmp-info>
<readCommunity>yRuSonoZ</readCommunity>
<port>161</port>
<retries>1</retries>
<timeout>2000</timeout>
<version>v3</version>
<securityName>secret-stuff</securityName>
<engineId>engineId</engineId>
</snmp-info>" \
-u admin:admin http://localhost:8980/opennms/rest/snmpConfig/10.1.1.1
Creates or updates a <definition/>
-entry for IP address 10.1.1.1 in snmp-config.xml
ignoring attribute readCommunity
.
2.6.19. Users
Since users are not currently stored in the database, the ReST interface for them is not as full-fledged as that of nodes, etc.
You cannot use hibernate criteria for filtering.
You may need to touch the $OPENNMS_HOME/etc/users.xml file on the filesystem for any addition or modification actions to take effect (see NMS-6469 for details).
|
GETs (Reading Data)
Parameter | Description |
---|---|
|
Get a list of users. |
|
Get a specific user, by username. |
POSTs (Adding Data)
Parameter | Description |
---|---|
|
Add a user. If supplying a password it is assumed to be hashed or encrypted already, at least as of 1.12.5.
To indicate that the supplied password uses the salted encryption algorithm rather than the older MD5 based algorithm, you need to pass an element named |
PUTs (Modifying Data)
Parameter | Description |
---|---|
|
Update an existing user’s full-name, user-comments, password, passwordSalt and duty-schedule values. |
2.7. ReST API Examples
2.7.1. Getting Graph data
While graphs aren’t technically available via ReST, you can parse some ReST variables to get enough data to pull a graph. This isn’t ideal because it requires multiple fetches, but depending on your use case, this may be adequate for you.
I’m in-lining some sample PHP code which should do this (not tested at all, cut & paste from old code I have that does not use the ReST- interface, and/or coded straight into the browser so YMMV). If you go to your NMS and click the resource graphs, then right click the graph you want and hit _View Image you will get the full URL that would need to be passed to pull that graph as a standalone image.
From that just take the URL and plug in the values you pulled from ReST to get a graph for whatever node you wanted.
function fetchit($thing, $user = "user", $pass = "pass") {
$url = "http://localhost:8980/opennms";
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url . $thing);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_USERAGENT, $useragent);
curl_setopt($ch, CURLOPT_USERPWD, $user.':'.$pass);
$data = curl_exec($ch);
curl_close($ch);
return $data;
}
// this assumes you already have found the nodeId via a previous REST call or some other means. Provided more as an example than what you might want.
function getNodeInterfaces($nodeId) {
$data = fetchit("/rest/nodes/$nodeId/snmpinterfaces");
return simplexml_load_string($data);
}
function fetchGraphs($nodeId) {
$ints = getNodeInterfaces($nodeId);
$chars = array('/','.',':','-',' ');
$endtime = time();
$starttime = (string)(time() - ($days * 24 * 60 * 60)) ;
// use bcmath or a better version of PHP if you don't want this hypocrisy here.
$endtime = $endtime . '000';
$starttime = $starttime . '000';
for($i=0; $i<count($ints->snmpInterfaces); $i++) {
$ifname = $ints->snmpInterfaces[$i]->snmpInterface->ifName;
$mac = $ints->snmpInterfaces[$i]->snmpInterface->physAddr;
$if = str_replace($chars, "_", $ifname);
if ( strlen(trim($mac)) < 12 ) { $mac_and_if = $if; } else { $mac_and_if = $if .'-'. $mac; };
$image = fetchit("$url/graph/graph.png?resource=node[$nodeId].interfaceSnmp[$mac_and_if]&report=report=mib2.HCbits&start=$starttime&end=$endtime");
// you can poop this to a file now, or set header('Content-type: image/png'); then print "$image";
}
}
2.7.2. provision.pl examples and notes
One way to test out the new ReST interface is to use provision.pl
.
If you run it you’ll get a summary of the output, but it’s not totally obvious how it all works.
Here is an example of adding a new node using the ReST interface:
# add a new foreign source called ubr
/usr/share/opennms/bin/provision.pl requisition add ubr
/usr/share/opennms/bin/provision.pl node add ubr 10341111 clownbox
/usr/share/opennms/bin/provision.pl node set ubr 10341111 city clownville
/usr/share/opennms/bin/provision.pl node set ubr 10341111 building clown-town-hall
/usr/share/opennms/bin/provision.pl node set ubr 10341111 parent-foreign-id 1122114
/usr/share/opennms/bin/provision.pl interface add ubr 10341111 10.1.3.4
# this is like a commit. No changes will take effect until you import a foreign source
/usr/share/opennms/bin/provision.pl requisition import ubr
You will probably need to specify the username/password of an admin. To do this add:
--username=admin --password=clownnms
to the command line.
2.7.3. Debian (Lenny) Notes
For Lenny, you’ll need to pull a package out of backports to make everything work right.
Read http://backports.org/dokuwiki/doku.php?id=instructions for instructions on adding it to sources.list
.
# install liburi-perl from backports
sudo apt-get -t lenny-backports install liburi-perl
2.7.4. Windows Powershell ReST
Example of using Windows Powershell to fill some asset fields with ReST.
# Installdate of Windows
$wmi = Get-WmiObject -Class Win32_OperatingSystem
$dateInstalled = $wmi.ConvertToDateTime($wmi.InstallDate)
# Serialnumber and manufacturer of server
Get-WmiObject win32_bios | select SerialNumber
$wmi = Get-WmiObject -Class win32_bios
$manufacturer = $wmi.Manufacturer
# Text file with a description of the server for the comments field
$comment = Get-Content "C:\Program Files\BGInfo\Info_Description.txt" | Out-String
$user ="admin"
$pass= "admin"
$secpasswd = ConvertTo-SecureString $user -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential ($pass, $secpasswd)
$nodeid = Invoke-RestMethod -Uri http://opennms.domain.nl:8980/opennms/rest/nodes?label=servername.domain.nl -Credential $cred
$nodeid = $nodeid.nodes.node.id
$uri="http://opennms.domain.nl:8980/opennms/rest/nodes/$nodeid/assetRecord"
Invoke-RestMethod -Uri "http://opennms.massxess.nl:8980/opennms/rest/nodes/$nodeid/assetRecord/?building=133" -Credential $cred -Method PUT
Invoke-RestMethod -Uri "$uri/?manufacturer=$manufacturer" -Credential $cred -Method PUT
Invoke-RestMethod -Uri "$uri/?dateInstalled=$dateInstalled" -Credential $cred -Method PUT
Invoke-RestMethod -Uri "$uri/?comment=$comment" -Credential $cred -Method PUT
3. Develop Documentation
This document is the guideline for people who wish to contribute to writing documentation for the OpenNMS project. The OpenNMS software is free and open source, contribution of any kind is welcome. We ask that you observe the rules and guidelines outlined here to maintain consistency across the project.
Each (sub)project is represented as a section of the documentation.
Each section will produce a HTML output in the file system that is generated in the target/generated
sources folder.
The chosen file format for documentation is AsciiDoc (Asciidoc Homepage).
Document files use the .adoc
file extension.
Note that there are different ways to contribute documentation, each suitable for the different use cases:
-
Tutorials and How To’s should be published on the OpenNMS Wiki. For example: you want to describe how to use the Net-SNMP agent and the SNMP monitor from OpenNMS to solve a special use case with OpenNMS.
-
The documentation in the source code should be formal technical documentation. The writing style should be accurate and concise. However, ensure that you explain concepts in detail and do not make omissions.
3.1. File Structure in opennms-doc
Directory | Contents |
---|---|
|
module with the guide for OpenNMS user e.g. NOC user who don’t change behavior of OpenNMS. |
|
module with the guide for administrators configuring, optimizing and running OpenNMS |
|
module with the guide for those who want to develop OpenNMS |
|
module with the guide of how to install OpenNMS on different operating systems |
|
module with the changelog and release notes |
3.2. Writing
The following rules will help you to commit correctly formatted and prepared documentation for inclusion in the OpenNMS project. It is important that we maintain a level of consistency across all of our committers and the documentation they produce.
When writing place a single sentence on each line. This makes it easy to move content around, and also easy to spot long, or fragmented, sentences. This will also allow us to assign comments on a sentence in GitHub which will facilitate easier merging.
Other than writing documentation, you can help out by providing comments on documentation, reviewing, suggesting improvements or reporting bugs. To do this head over to: issue tracker for documentation! |
3.2.1. Conventions for text formatting
The following conventions are used:
-
File names and path are written in `poller-configuration.xml` they will be rendered in:
poller-configuration.xml
; -
Names that indicate special attention, e.g. this configuration matches *any* entry: this is rendered as: this configuration matches any entry;
-
_Italics_ is rendered as Italics and used for emphasis and indicate internal names and abbreviations;
-
*Bold* is rendered as Bold and should be used sparingly, for strong emphasis only;
-
+methodName()+ is rendered as methodName() and is also used for literals, (note: the content between the
+
signs will be parsed); -
`command` is rendered as
command
(typically used for command-line or parts used in configuration files), (note: the content between the ` signs will not be parsed); -
`my/path/` is rendered as
my/path/
this is used for file names and paths; -
\``double quote'' (which is two grave accents to the left and two acute accents to the right) renders as ``double quote'';
-
\`single quote' (which is a single grave accent to the left and a single acute accent to the right) renders as `single quote'.
3.2.2. Gotchas
-
Always leave a blank line at the top of the documents section. It might be the title ends up in the last paragraph of the document;
-
Start in line 2 setting a relative path to the images directory to picture rendering on GitHub:
// Allow image rendering
:imagesdir: relative/path/to/images/dir
-
Always leave a blank line at the end of documents;
-
As {} are used for Asciidoc attributes, everything inside will be treated as an attribute. To avoid this you have to escape the opening brace: \\{. If you do not escape the opening brace, the braces and the text inside them will be removed without any warning being issued!;
-
Forcing line breaks can be achieved with ` +` at the end of the line followed by a line break.
This is the first line +
and this a forced 2nd line
This is the first line
and this a forced 2nd line
3.3. Headings and document structure
Each document starts over with headings from level zero (the document title). Each document should have an id. In some cases sections in the document need to have id’s as well, this depends on where they fit in the overall structure. If you wish to have a link to specific content that content has to have an id. A missing id in a mandatory place will cause the build to fail.
To start a document:
[[unique-id-verbose-is-ok]]
= The Document Title
If you are including the document inside another document and you need to push the headings down to the right level in the output, the leveloffset attribute is used.
Subsequent headings in a document should use the following syntax:
== Subheading
... content here ...
=== Subsubheading
content here ...
3.4. Links
When you need to link to other parts of the manual you use the target id. To use a target id you follow this syntax:
<<doc-guidelines-links>>
This will render as: [doc-guidelines-links]
To use the target id in you document simply write the target id in your text, for example: |
see <<target-id>>
this should suffice for most cases.
If you need to link to another document with your own link text, then follow this procedure:
<<target-id, link text that fits in the context>>
Having lots of linked text may work well in a web context but is a distracting in print. The documentation we are creating is intended for both mediums so be considerate of this in your usage. |
If you wish to use an external link, they are are added as:
http://www.opennms.org/[Link text here]
This will render in the output as: Link text here
For short links it may be beneficial not to use accompanying link text:
http://www.opennms.org/
Which renders as: http://www.opennms.org/
It is acceptable to have a period trailing after the URL, it will not render as a part of the link. |
3.5. Admonitions and useful notes
These are useful for defining specific sections, such as Notes, Tips and Important information. We encourage the use of them in the documentation as long as they are used appropriately. Choose from the following:
NOTE: This is my note.
This is how its rendered:
This is my note. |
TIP: This is my tip.
This is how its rendered:
This is my tip. |
IMPORTANT: This is my important hint.
This is how its rendered:
This is my important hint. |
CAUTION: This is my caution.
This is how its rendered:
This is my caution. |
WARNING: This is my warning.
This is how its rendered:
This is my warning. |
A multiline variation:
TIP: Tiptext. +
Line 2.
Which is rendered as:
Tiptext. Line 2. |
Remember to write these in full caps. There is no easy manner in which to add new admonitions, do not create your own. |
3.6. Attributes
Common attributes you can use in documents:
-
{opennms-version} - rendered as "17.0.0"
These can substitute part of URLs that point to, for example, APIdocs or source code. Note that opennms-git-tag also handles the case of snapshot/master.
Sample Asciidoc attributes which can be used:
-
{docdir} - root directory of the documents
-
{nbsp} - non-breaking space
3.7. Comments
There’s a separate build that includes comments.
When the comments are used they show up with a yellow background.
This build doesn’t run by default, but after a normal build, you can use make annotated
to create a build yourself.
You can use the resulting 'annotated' page to search for content as the full manual is a single page.
To write a comment:
// this is a comment
Comments are not visible in the standard build. Comment blocks won’t be included in the output of any build. The syntax for a comment block is:
////
Note that includes in here will still be processed, but not make it into the output.
That is, missing includes here will still break the build!
////
3.8. Tables
For representing structured information you can use tables. A table is constructed in the following manner:
[options="header, autowidth"]
|===
| Parameter | Description | Required | Default value
| `myFirstParm` | my first long description | required | `myDefault`
| `myScndParm` | my second long description | required | `myDefault`
|===
This is rendered as:
Parameter | Description | Required | Default value |
---|---|---|---|
|
my first long description |
required |
|
|
my second long description |
required |
|
Please align your columns in the AsciiDoc source in order to give better readability when editing in text view. If you have a very long description, break at 120 characters and align the text to improve source readability. |
this is rendered as:
Parameter | Description | Required | Default value |
---|---|---|---|
|
Authentication credentials to perform basic authentication.
Credentials should comply to RFC1945 section 11.1,
without the Base64 encoding part. That’s: be a string made of the concatenation of: |
optional |
|
|
Additional headers to be sent along with the request. Example of valid parameter’s names are
|
optional |
|
3.9. Include images
When visualizing complex problems you can help the explanation and provide greater information by using an image. We use in OpenNMS documentation modules two directories for images.
The image folder structure mirrors the text structure. In this case it is a little bit easier to locate the AsciiDoc text file where the image is included.
.
└── opennms-doc(1)
└── guide-doc(2)
├── README.adoc
├── pom.xml
├── src(3)
| └── asciidoc(4)
| ├── configs
| | └── poller-configuration.xml
| ├── images(5)
| | ├── 01_opennms-logo.png(6)
| | └── 02_pris-overview.png
| ├── images_src(7)
| | └── pris-overview.graphml(8)
| ├── index.adoc(9)
| └── text
| ├── images.adoc(10)
| ├── include-source.adoc
| ├── introduction.adoc
| └── writing.adoc
└── target(11)
1 | This folder contains all documentation modules; |
2 | The module for this documentation for target group of documentation contributors; |
3 | Indicates a source folder; |
4 | The documentation root folder; |
5 | Folder for images. Images should be *.png or *.jpg if included in the documentation; |
6 | The image used, the format is a leading <number>_ followed by a name using no spaces; |
7 | Some images are created from tools like yED, this folder should contain the editable version of the file with the same file name; |
8 | Editable version of the image source file, note no spaces in the name; |
9 | Main document file which includes all documentation parts and is rendered as index.html for the web; |
10 | AsciiDoc source file which can include images; |
11 | Target folder with generated HTML output after mvn clean package has been performed; |
All images in the entire manual share the same namespace, it is therefore best practice to use unique identifiers for images. |
To include an image file, make sure that it resides in the 'images/' directory relative to the document you’re including it within. Then use the following syntax for inclusion in the document:
.This is a caption of the image
image::docs/02_opennms-logo.png[]
Which is rendered as:
The image path for the images you include is relative to the *.adoc source file, where you use the image. |
3.10. Code Snippets
You can include code snippets, configuration- or source code files in the documentation. You can enable syntax highlighting by providing the given language parameter, this will work on source code or configuration.
3.10.1. Explicitly defined in the document
be careful to use this kind of code snippets as sparsely as possible. Code becomes obsolete very quickly, archaic usage practices are detrimental. |
if you do wish to include snippets use the following method:
<service name="DNS" interval="300000" user-defined="false" status="on">
<parameter key="retry" value="2" />
<parameter key="timeout" value="5000" />
<parameter key="port" value="53" />
<parameter key="lookup" value="localhost" />
<parameter key="fatal-response-codes" value="2,3,5" /><!-- ServFail, NXDomain, Refused -->
<parameter key="rrd-repository" value="/opt/opennms/share/rrd/response" />
<parameter key="rrd-base-name" value="dns" />
<parameter key="ds-name" value="dns" />
</service>
If there’s no suitable syntax highlighter for the code used just omit the language: [source].
Currently the following syntax highlighters are enabled:
-
Bash
-
Groovy
-
Java
-
JavaScript
-
Python
-
XML
For other highlighters that could be added see https://code.google.com/p/google-code-prettify/.
3.10.2. Included from an example file
You can include source or configuration from an external file. In this way you can provide a working example configuration maintaining doc and example at the same time. The procedure and rules are the same as with images, the path is relative to the *.adoc file where the file to be used is included.
[source,xml] ---- include::../configs/wmi-config.xml[] ----
This is how it’s rendered:
<?xml version="1.0"?>
<wmi-config retry="2" timeout="1500"
username="Administrator" domain="WORKGROUP" password="password">
</wmi-config>
3.10.3. Include parts of a file
If you want to include just a specific segment of a large configuration file, you can assign tags that indicate to AsciiDoc the section that is to be included. In this example just the service definition of the ICMP monitor should be included.
In the 'poller-configuration.xml' tag the section in the following manner:
...
<rrd step="300">
<rra>RRA:AVERAGE:0.5:1:2016</rra>
<rra>RRA:AVERAGE:0.5:12:1488</rra>
<rra>RRA:AVERAGE:0.5:288:366</rra>
<rra>RRA:MAX:0.5:288:366</rra>
<rra>RRA:MIN:0.5:288:366</rra>
</rrd>
<!-- # tag::IcmpServiceConfig[] -->
<service name="ICMP" interval="300000" user-defined="false" status="on">
<parameter key="retry" value="2" />
<parameter key="timeout" value="3000" />
<parameter key="rrd-repository" value="/opt/opennms/share/rrd/response" />
<parameter key="rrd-base-name" value="icmp" />
<parameter key="ds-name" value="icmp" />
</service>
<!-- # end::IcmpServiceConfig[] -->
<service name="DNS" interval="300000" user-defined="false" status="on">
<parameter key="retry" value="2" />
<parameter key="timeout" value="5000" />
<parameter key="port" value="53" />
...
[source,xml] ---- include::../configs/poller-configuration.xml[tags=IcmpServiceConfig] ----
<service name="ICMP" interval="300000" user-defined="false" status="on">
<parameter key="retry" value="2" />
<parameter key="timeout" value="3000" />
<parameter key="rrd-repository" value="/opt/opennms/share/rrd/response" />
<parameter key="rrd-base-name" value="icmp" />
<parameter key="ds-name" value="icmp" />
</service>
Spaces and tabs are taken from the original file. |
3.11. Cheat Sheets and additional hints
For instructions on how to build your own version of the manual:
The documentation uses the AsciiDoc format. There are a number of guides that will help you to get started with using AsciiDoc:
For other resources, to gain familiarity with AsciiDoc, you can visit: