The enterprise nature of OpenNMS means that it must be highly configurable, and the sheer number of configuration options is often overwhelming to the new user. To try out OpenNMS, you need only to modify two files.
OpenNMS stores its configuration files in the $OPENNMS_HOME/etc directory, usually /opt/OpenNMS/etc or /etc/opennms. In that directory is a file called discovery-configuration.xml and another called snmp-config.xml.
The first file controls what OpenNMS will discover, and it looks like this:
<discovery-configuration threads="1" packets-per-second="1" initial-sleep-time="300000" restart-sleep-time="86400000" retries="3" timeout="800"> <include-range retries="2" timeout="3000"> <begin>192.168.0.1</begin> <end>192.168.0.254</end> </include-range> <include-url>/opt/OpenNMS/etc/include</include-url> </discovery-configuration>
This file shows some examples of what OpenNMS can use for discovery. An OpenNMS How-To guide covers all of the options. Basically, OpenNMS performs a ping sweep of the addresses and address ranges specified in this file. For each reply it receives, it will generate a newSuspect event to pass to the capabilities daemon for service scanning.
In this case, OpenNMS will scan from 192.168.0.1 to 192.168.0.254, as well as all of the IP addresses listed in the /opt/OpenNMS/etc/include file.
If you need to monitor two subnets, use multiple
include-range tags. The following configuration will scan the 192.168.1.0 subnet and 172.20.2.0 subnet:
<discovery-configuration threads="1" packets-per-second="1" initial-sleep-time="300000" restart-sleep-time="86400000" retries="3" timeout="800"> <include-range> <begin>192.168.1.1</begin> <end>192.168.1.254</end> </include-range> <include-range> <begin>172.20.2.1</begin> <end>172.20.2.254</end> </include-range> </discovery-configuration>
Note that once it discovers a machine, OpenNMS will perform a directed port scan on the device to discover what services it provides. If you have portsentry or other detection software installed, make sure to exempt the OpenNMS server from any blocks.
The second file to modify is snmp-config.xml. It controls the community string to use for SNMP queries.
<snmp-config retry="3" timeout="800" read-community="public" write-community="private"> <definition version="v1"> <specific>192.168.0.5</specific> </definition> <definition read-community="topsecret"> <range begin="192.168.1.1" end="192.168.1.254"/> <range begin="172.20.2.1" end="172.20.2.254"/> <specific>172.20.3.1</specific> </definition> </snmp-config>
The first line lists the default read community string as
public and the default write community string as
private. At the moment, OpenNMS does not support the SNMP SET command, so it does not use the write community string and you do not have to configure it.
Override the default values via
<definition> tags. The first tag forces OpenNMS to use SNMP version 1 for 192.168.0.5. (This is sometimes necessary when the device improperly supports SNMPv2c.) OpenNMS will use version 2c if available but will also work if your hardware supports only version 1.
The second definition overrides the default read community string of
topsecret for the 192.168.1.0 and 172.20.2.0 subnets and the specific device at 172.20.3.1.
If only one community name is in use on the network, placing it in the first line in place of
public is sufficient. You can also leave it as
public if you haven't changed it on your agents.
After you have modified these two files, start OpenNMS with the command:
$OPENNMS_HOME is usually /opt/OpenNMS. For Linux distributions that support
/sbin/service, use the command:
service opennms start
Similarly for Debian, use:
invoke-rc.d opennms start
Finally, ensure that the Tomcat servlet container is running, and then point a browser to:
http://[OpenNMS Server]:8180/opennmsfor Debian)
and log in with a username of
admin and a password of
admin. Within 5 minutes, OpenNMS should have started to discover the network.
Like many open source projects, OpenNMS is a little light on documentation. The OpenNMS How-To guides are a good place to start, and the OpenNMS Wiki provides additional information. There is a large community supporting the project, and the best way to contact it is via the OpenNMS mailing lists. Be sure to read the OpenNMS mailing list FAQ first.
The current development version of OpenNMS adds support for SNMP version 3, as well a new JMX data collector for gathering information from sources such as JBoss and Tomcat. It also introduces a new "alarms" subsystem, which improves event management by reducing duplicate events and adding some automated event manipulation (such as increasing severity over time). Also planned is support for the Nagios Remote Plug-ins Executor (NRPE) via a 100 percent Java-based NRPE client.
Tarus Balog has more than 15 years of network management experience in the telecom and datacom industries.
Return to the SysAdmin DevCenter