Why You Should Care About Your Release Notes

When you’re someone like me, who has operated and maintained software for yourself or others, the Release Notes are pretty important. Pure software developers or stakeholders often overlook the importance of this topic, as they simply have to deal with Release Notes when building or generating them. They are often an afterthought and just another box to check on a release procedure list. Here are some reasons why spending some time on your Release Note is worth it.

macOS with Apple Silicon and x86-64-v3 support

I’m maintaining container images in the OpenNMS ecosystem. My local machine is a Mac with Apple Silicon. While I was upgrading some base images using RHEL UBI 10 / CentOS 10 images, I noticed the following error message.

0.112 Fatal glibc error: CPU does not support x86-64-v3

That happens if you try to run on an emulated x86 architecture running on ARM. After some investigation, I’ve found an article in the Red Hat developer forum talking about upgrading the Microarchitecture level from v2 to v3. The problem introduced is that v3 isn’t supported. I’m using Orbstack and you can reproduce this problem simply running the following docker command.

Streaming telemetry with gNMI

This document describes how you can set up a lab environment for testing gNMI using a virtual HPE Juniper router running Junos 24.2 R1-S2.5. It shows how you can collect metrics for interfaces and CPU utilization collected with OpenNMS. This isn’t something I do every day, so I just preserve this here for my future self and the ones who want to get up to speed a bit quicker.

What you will learn

• Enable gNMI over gRPC with sensors on a HPE Juniper router
• Verify the gRPC connections and configuration
• Enable OpenNMS Horizon to subscribe to gRPC streams for sensor data
• Set up TLS on gRPC using a self-signed certificate authority
• Visualize the collected data in Grafana

Limitations

• Streaming telemetry can only be configured from the OpenNMS Core instance, see enhancement NMS-18064
• Metric labels for network interfaces are right now just resource id strings

Before you begin

You need the following environment to get a lab running:

SNMP Proxy ... wait what?

Working with SNMP in 2025 is still a thing. Most hate it, but it’s sometimes the only thing you can use to get insights into the box you are working with. I want to shed some light on the SNMP proxy capability in Net-SNMP, it might be possible some people haven’t heard of it and might find it useful. In a nutshell, you can use Net-SNMP as a proxy to query information from another SNMP agent over an IP connection you can’t or do not want to query directly.

Building container images for OpenNMS

The previous article described how you can build and compile OpenNMS Horizon from source. This section explains how you build container images (OCI) from the source artifacts.

Deploy base image as foundation

Running OpenNMS Horizon core, Minion, or Sentinels in a container requires shared components. Some of them are a) the JDK base image, b) some useful tools, and c) JICMP, and JICMP6.

The JDK is shared with Core, Minion, and Sentinel. JICMP, and JICMP6 are required for Core and Minion. To manage these dependencies, we have a deploy-base image created which covers the main requirements running the Core, Minion, and Sentinel server processes. Getting an efficient size was a goal and a multi-stage build approach was chosen to address it. The fist

Dealing with secrets in OpenNMS Horizon

Dealing with secrets in a monitoring platform is a tedious task. The nature of monitoring systems is providing integrations in as many systems. Here is my mental model looking at the various ways for integrating OpenNMS. Especially having a 20 year old platform gives you some very own challenges. Talking about integration of monitoring systems, In OpenNMS Horizon/Meridian (OpenNMS for short), are some places where you have just one option, and some with various options. This article should help you to get an idea where you need to deal with secrets and credentials. The north/south areas serve monitoring purpose whereas the west/east directions address scaling topics in the context of volume, geographic or feature sets.

OpenNMS Horizon with RRDtool

As described in the previous article we have built and installed an OpenNMS Horizon Core component from the source. It comes with a Java implementation of RRDTool called JRobin. The portability of Java applications allowed users to run OpenNMS platforms where RRDTool wasn’t easily available. It was threadsafe and allowed more threads writing data. RRDTool implemented that functionality and surpassed JRobin performance and feature wise.

💁‍♀️ If you just don’t care in a dev or testing environment, you can use JRobin for simplicity, because it’s just there and works out of the box. For any production environment, I highly recommend to use RRDTool. It gives you much better support for tools, performance and features. Migrating later is doable but painful.

Demystifying iplike in OpenNMS Horizon

As described in the previous article we have built and installed an OpenNMS Horizon Core component from the source.

With setting up the database schema with ${OPENNMS_HOME}/bin/install -dis a function IPLIKE is created for the OpenNMS database.

It allows us to get IP address matches for IPv4 and IPv6 addresses with filters used in all IP filters in the tool, e.g. IPADDR IPLIKE 192.168.0-3.0-255.

By default, the function is implemented in a SQL procedural language (PL/pgSQL). As OpenNMS had to deal with larger IP address inventories, an optimized version in C was created which is available as the IPLIKE package. The C version of this stored procedure has to be built against header files from specific PostgreSQL major versions. This is the reason you see iplike-pgsql{12,13,14,15} packages in the OpenNMS repositories.

JniPing vs. JnaPing

As described in the previous article we have build an OpenNMS Horizon Core component from source. If you don’t do anything else, it will uses an ICMP implementation using Java Native Access (JNA). The big benefit here, it’s all Java and supports IPv4 and IPv6. You also don’t need additional permissions on your Linux system such as net.ipv4.ping_group_range and SELinux. It makes it perfect for local development and also if you want to run OpenNMS on exotic architectures where you can’t easily compile or build the JNI equivalent written in C from the source code. The downside it comes with some overhead for each ICMP service test. You can see the effect on the latency measurements, especially on very fast responding IP addresses, such as the local loopack interface.

OpenNMS - Auf die harte Tour

I asked many questions in 2004 on IRC when I tried to get my first OpenNMS instance up and running. People in the community held my hand when I was struggling. They helped me to get to my personal “Aha!” moments. If you have time and patience, this is great, because this is a great learning opportunity. In the world of User Experience Design, this is called “friction”. How can you determine friction? My background is that of someone who cut his hands on sharp metal changing network equipment and operating IT gear for others – I have empathy for people running OpenNMS. I like to run user empathy sessions with someone in your target group and figure out where and how they struggle. If you have no one, the next best option is to put yourself in the shoes and get your hands dirty.