Planet OpenNMS

June 25, 2022

2022 Open Source Summit – Day 4

I always feel a little sad on the last day of any conference, and Open Source Summit was no different. It seems like the week went by too fast.

With the Sponsor Showcase closing on Thursday, attendance at the Friday keynotes was light, but those of us that showed up got to hear some pretty cool presentations.

Picture of Rachel Rose on stage

The first one was from Rachel Rose, who supervises R&D at Industrial Light and Magic. As a fanboy of ILM I was very eager to hear what she had to say, and she didn’t disappoint. (sorry about the unflattering picture but I took three and they were all bad)

In the past a lot of special effects that combine computer generated imagery (CGI) and live action are created separately. The live action actors perform in front of a green screen and the CGI backgrounds are added later. Technology has advanced to the point that the cutting edge now involves live action sets that are surrounded by an enormous, curved LED screens, and the backgrounds are projected as the actors perform.

This presents a number of challenges as the backgrounds may need to change as the camera moves, but it provides a much better experience for the actors and the audience.

The tie-in to open source is that a lot of the libraries used the creation of these effects are now open. In fact, the Academy of Motion Picture Arts and Sciences (the people responsible for the Oscars) along with the Linux Foundation have sponsored the Academy Software Foundation (ASWF) to act as a steward for the “content creation industry’s open source software base”. The projects under the ASWF fall into one of two tiers: Adopted and Incubation. Currently there are four projects that are mature enough to be adopted and several more in the incubation stage.

A lot of this was so specific to the industry that it went over my head, but I could understand the OpenEXR project, which provides a reference implementation of the EXR file format for storing high quality images.

A slide showing the ILM Stagecraft volume setup

She then went on to talk about Stagecraft, which is the name of the ILM platform for producing content. I would love to be able to visit one day. It would be so cool to see a feature being made with the CGI, sets and actors all integrated.

Picture of Vini Jaiswal on stage

The next speaker was Vini Jaiswal, Developer Advocate for Databricks. I had seen a cool Databricks presentation back on Day 2 and the first part was similar, but Jaiswal skipped the in-depth technical details and focused more on features and adoption. A rather large number of companies are using the Delta Lake technology as a way to apply business intelligence to data lakes, and as the need to analyze normally unstructured data becomes more important, I expect to see even more organizations adopt it.

The third presentation was a video by Dmitry Vinnik of Meta on measuring open source project health.

Begin rant.

To be honest I was a little unhappy to see a video as a keynote. It was the only one for the entire week and I have to admit I kind of tuned it out. It wasn’t even novel, as he has given it at least twice before. The video we were shown is available on Youtube from a conference earlier in the month and he posted another one dated June 24th from the Python Web Conference (while it has a different splash screen it looks to be the same presentation).

A still picture of a part of the video sent in by Demetri Vinnik

Look, I’ve given the same talk multiple times at different conferences, so I get it. But to me keynotes are special and should be unique. I was insulted that I bothered to show up in person, wear a mask, get my temperature checked each day, and I expected something better than a video I could have watched at home.

Note: Rachel Rose played a video as part of her presentation and that’s totally cool, as she didn’t “phone in” the rest of it.

Okay, end rant.

The next two presenters were very inspiring young people, and it was nice to have them included as part of the program.

Picture of Alena Analeigh on stage

The first speaker was Alena Analeigh, an amazing young woman who, among other achievements, has been accepted to medical school at age 13 (note that in trying to find a reference for that I came up blank, except for her twitter bio, so if you have one please let me know and I can update this post).

Med school is just one of her achievements. She also founded The Brown STEM Girls as an organization to get more women of color interested in science, technology, engineering and math. She stated that while men make up 52% of the workforce, they represent 76% of people employed in STEM fields.

My love of such things was fostered at an early age, and programs like hers are a great step to encourage young women of color to get interested in and eventually pursue careers in STEM.

While she seemed a little nervous and tentative while presenting, the final speaker of the morning was the exact opposite. At 11 years old, I could listen to Orion Jean speak for hours.

Picture of Orion Jean on stage

Orion also has a number of accolades, including Time Magazine’s “Kid of the Year“. He got his start as the winner of a speech contest sponsored by Think Kindness, and since then has started the Race to Kindness (“a race where everybody wins”) to spread kindness around the world.

To help inspire acts of kindness he uses the acronym K.I.N.D.:

  • Keep Your Eyes Open: Look for opportunities to be kind to others. One example he used is one I actually practice. If you are in line to check out at the store, and you see a person with a lot less items than you, while not offer to let them check out first?
  • Include Others: No one can effect change alone. Get others involved.
  • Nothing Is Too Small: One thing that keeps us from spreading kindness is that we can try to think too big. Even small acts of kindness can have a huge impact.
  • Do Something About It: Take action. Nothing can change if we do nothing.

After the keynotes I had to focus on some work stuff that I had let languish for the week, so I didn’t make it to any of the presentations, but overall I was happy with my first conference in three years.

There were a few people that attended who tested positive for COVID, so I plan to take some precautions when I get home and hope that the steps the Linux Foundation took to mitigate infection worked. So far I’ve tested negative twice, and I’ll probably take another test on Monday.

My next conference will be SCaLE in Los Angeles at the end of July, and I plan to be in Dublin, Ireland for Open Source Summit – Europe. If you are comfortable getting out and about I hope to see you there.

by Tarus at June 25, 2022 07:04 PM

June 24, 2022

2022 Open Source Summit – Day 3

Thursday at the Open Source Summit started as usual at the keynotes.

Picture of Robin Bender Ginn on stage

Robin Bender Ginn opened today’s session with a brief introduction and then we jumped into the first session by Matt Butcher of Fermyon.

Picture of Matt Butcher on stage

I’ve enjoyed these keynotes so far, but to be honest nothing has made me go “wow!” as much as this presentation by Fermyon. I felt like I was witnessing a paradigm shift in the way we provide services over the network.

To digress quite a bit, I’ve never been happy with the term “cloud”. An anecdotal story is that the cloud got its name from the fact that the Visio icon for the Internet was a cloud (it’s not true) but I’ve always preferred the term “utility computing”. To me cloud services should be similar to other utilities such as electricity and water where you are billed based on how much you use.

Up until this point, however, instead of buying just electricity it has been more like you are borrowing someone else’s generator. You still have to pay for infrastructure.

Enter “serverless“. While there are many definitions of serverless, the idea is that when you are not using a resource your cost should be zero. I like this definition because, of course, there have to be servers somewhere, but under the utility model you shouldn’t be paying for them if you aren’t using them. This is even better than normal utilities because, for example, my electricity bill includes fees for things such as the meter and even if I don’t use a single watt I still have to pay for something.

Getting back to the topic at hand, the main challenge with serverless is how do you spin up a resource fast enough to be responsive to a request without having to expend resources when it is quiescent? Containers can take seconds to initialize and VMs much longer.

Fermyon hopes to address this by applying Webassembly to microservices. Webassembly (Wasm) was created to allow high performance applications, written in languages other than Javascript, to be served via web pages, although as Fermyon went on to demonstrate this is not its only use.

The presentation used a game called Finicky Whiskers to demonstrate the potential. Slats the cat is a very finicky eater. Sometimes she wants beef, sometimes chicken, sometimes fish and sometimes vegetables. When the game starts Slats will show you an icon representing the food they want, and you have to tap or click on the right icon in order to feed it. After a short time, Slats will change her choice and you have to switch icons. You have 30 seconds to feed as many correct treats as possible.

Slide showing infrastructure for Frisky Kittens: 7 microservices, Redis in a container, Nomad cluster on AWS, Fermyon

Okay, so I doubt it will have the same impact on game culture as Doom, but they were able to implement it using only seven microservices, all in Wasm. There is a detailed description on their blog, but I liked that fact that it was language agnostic. For example, the microservice that controls the session was written in Ruby, but the one that keeps track of the tally was written in Rust. The cool part is that these services can be spun up on the order of a millisecond or less and the whole demo runs on three t2.small AWS instances.

This is the first implementation I’ve seen that really delivers on the promise of serverless, and I’m excited to see where it will go. But don’t let me put words into their mouth, as they have a blog post on Fermyon and serverless that explains it better than I could.

Picture of Carl Meadows on stage

The next presentation was on OpenSearch by Carl Meadows, a Director at AWS.

Note: Full disclosure, I am an AWS employee and this post is a personal account that has not been endorsed or reviewed by my employer.

OpenSearch is an open source (Apache 2.0 licensed) set of technologies for storing large amounts of text that can then be searched and visualized in near real time. Its main use case is for making sense of streaming data that you might get from, say, log files or other types of telemetry. It uses the Apache Lucene search engine and latest version is based on Lucene 9.1.

One of the best ways to encourage adoption of an open source solution is by having it integrate with other applications. With OpenSearch this has traditionally been done using plugins, but there is a initiative underway to create an “extension” framework.

Plugins have a number of shortcomings, especially in that they tend to be tightly coupled to a particular version of OpenSearch, so if a new version comes out your existing plugins may not be compatible until they, too, are upgraded. I run into this with a number of applications I use such as Grafana and it can be annoying.

The idea behind extensions is to provide an SDK and API that are much more resistant to changes in OpenSearch so that important integrations are decoupled from the main OpenSearch application. This also provides an extra layer of security as these extensions will be more isolated from the main code.

I found this encouraging. It takes time to build a community around an open source project but one of the best ways to do it is to provide easy methods to get involved and extensions are a step in the right direction. In addition, OpenSearch has decided not to require a Contributor License Agreement (CLA) for contributions. While I have strong opinions on CLAs this should make contributing more welcome for developers who don’t like them.

Picture of Taylor Dolezal on stage

The next speaker was Taylor Dolezal from the Cloud Native Computing Foundation (CNCF). I liked him from the start, mainly because he posted a picture of his dog:

Slide of a white background with the head and sad eyes of a cute black dog

and it looks a lot like one of my dogs:

Picture of the head of my black Doberman named Kali

Outside of having a cool dog, Dolezal has a cool job and talked about building community within the CNCF. Just saying “hey, here’s some open source code” doesn’t mean that qualified people will give up nights and weekends to work on your project, and his experiences can be applied to other projects as well.

The final keynote was from Chris Wright of Red Hat and talked about open source in automobiles.

Picture of Chris Wright on stage

Awhile ago I actually applied for a job with Red Hat to build a community around their automotive vertical (I didn’t get it). I really like cars and I thought that combining that with open source would just be a dream job (plus I wanted the access). We are on the cusp of a sea change with automobiles as the internal combustion engine gives way to electric motors. Almost all manufacturers have announced the end of production for ICEs and electric cars are much more focused on software. Wright showed a quote predicting that automobile companies will need four times the amount of software-focused talent that the need now.

A slide with a quote stating that automobile companies will need more than four times of the software talent they have now

I think this is going to be a challenge, as the automobile industry is locked into 100+ years of “this is the way we’ve always done it”. For example, in many states it is still illegal to sell cars outside of a dealership. When it comes to technology, these companies have recently been focused on locking their customers into high-margin proprietary features (think navigation) and only recently have they realized that they need to be more open, such as supporting Android Auto or CarPlay. As open source has disrupted most other areas of technology, I expect it to do the same for the automobile industry. It is just going to take some time.

I actually found some time to explore a bit of Austin outside the conference venue. Well, to be honest, I went looking for a place to grab lunch and all the restaurants near the hotel were packed, so I decided to walk further out.

Picture of the wide Brazos river from under the Congress Avenue bridge

The Brazos River flows through Austin, and so I decided to take a walk on the paths beside it. The river plays a role in the latest Neal Stephenson novel called Termination Shock. I really enjoyed reading it and, spoiler alert, it does actually have an ending (fans of Stephenson’s work will know what I’m talking about).

I walked under the Congress Avenue bridge, which I learned was home to the largest urban bat colony in the world. I heard mention at the conference of “going to watch the bats” and now I had context.

A sign stating that drones were not permitted to fly near the bat colony under the Congress Avenue bridge

Back at the Sponsor Showcase I made my way over to the Fermyon booth where I spent a lot of time talking with Mikkel Mørk Hegnhøj. When I asked if they had any referenceable customers he laughed, as they have only been around for a very short amount of time. He did tell me that in addition to the cat game they had a project called Bartholomew that is a CMS built on Fermyon and Wasm, and that was what they were using for their own website.

Picture the Fermyon booth with people clustered around

If you think about it, it makes sense, as a web server is, at its heart, a fileserver, and those already run well as a microservice.

They had a couple of devices up so that people could play Finicky Whiskers, and if you got a score of 100 or more you could get a T-shirt. I am trying to simplify my life which includes minimizing the amount of stuff I have, but their T-shirts were so cool I just had to take one when Mikkel offered.

Note that when I got back to my room and actually played the game, I came up short.

A screenshot of my Finicky Whiskers score of 99

The Showcase closed around 4pm and a lot of the sponsors were eager to head out, but air travel disruptions affected a lot of them. I’m staying around until Saturday and so far so good on my flights. I’m happy to be traveling again but I can’t say I’m enjoying this travel anxiety.

[Note: I overcame by habit of sitting toward the back and off to the side so the quality of the speaker pictures has improved greatly.]

by Tarus at June 24, 2022 08:01 PM

June 23, 2022

2022 Open Source Summit – Day 2

The word for Day 2 of the Open Source Summit is SBOM.

When I first heard the term my thought was that someone had spoken a particular profanity at an inappropriate time, but SBOM in this context means “Software Bill of Materials”. Open source is so prevalent these days that it is probably included in a lot of the software you use and you may not be aware of it, so when an issue is discovered such as Log4shell it can be hard to determine what software is affected. The idea of asking all vendors (both software-only and software running on devices) to provide an SBOM is a first step to being able to audit this software.

It isn’t as easy as you might think. The OpenNMS project I was involved with used over a hundred different open source libraries. I know because I once did a license audit to make sure everything being used had compatible licenses. I also have used Black Duck Software (now Synopsys) to generate a list of included software, and it looks like they now offer SBOM support as well, but I get ahead of myself.

Note that Synopsys is here in the Sponsor Showcase but when I stopped by the booth no one was there.

Getting back to the conference, the second morning keynotes were more sparsely attended than yesterday, but the room was far from empty. The opening remarks were given by Mike Dolan, SVP and GM of Projects at the Linux Foundation, and he was a last minute replacement for Jim Zemlin, who was not feeling well.

Picture of Mike Dolan on stage

Included in the usual housekeeping announcements was a short “in memoriam” for Shubhra Kar, the Linux Foundation CTO who passed away unexpectedly this year.

Dolan also mentioned that the Software Package Data eXchange (SPDX) open standard used for creating SBOMs had turned 10 years old (and it looks like it will hit 11 in August). This was relevant because with applications of any complexity including hundreds if not thousands of open source software projects, there had to be some formal way of listing them for analysis in an SBOM, and most default to SPDX.

The next speaker was Hilary Carter who is in charge of research for the Linux Foundation.

Picture of Mike Dolan and Hilary Carter on stage

She spoke on the work the Linux Foundation is doing to measure the worldwide impact of open source. As part of that she mentioned that there is a huge demand for open source talent in the market place, but there are also policy barriers for employees of many companies to contribute to open source. She also brought up SBOMs as a way to determine how widespread open source use is in modern applications.

Stylized Mercator Map Projection

Since diversity has been a theme at this conference I wanted to address a pet peeve of mine. This is a slide from Carter’s presentation and it uses a stylized Mercator projection to show the world. I just think it is about time we stop using this projection, as the continent highlighted, Africa, is actually much, much larger in proportion to the other continents than is shown on this map. As an alternative I would suggest the Gall-Peters projection.

Gall-Peters projection of the world yoinked from Wikipedia

To further digress, I asked my friend Ben to run “stylized Gall-Peters projection” through Midjourney but I didn’t feel comfortable posting any of the results (grin).

Anyway, enough of that. The next presenter was Kevin Jakel, who founded Unified Patents.

Picture of Kevin Jakel on stage

The goal of Unified Patents is to protect open source from patent trolls. Patent trolls are usually “non-practicing entities” who own a lot of patents but exist to extract revenue from companies they believe are infringing upon them versus building products. Quite frequently it is cheaper to settle than pursue legal action against these entities and this just encourages more actions on the part of the trolls.

The strategy to combat this is described as “Detect, Disrupt and Deter”. For a troll, the most desired patents are ones that are broad, as this means more companies can be pursued. However, overly broad patents are also subject to review, and if the Patent and Trademark Office is convinced a patent isn’t specific enough it can invalidate it, destroying the revenue stream for the patent troll.

I’m on the fence over software patents in general. I mean, let’s say a company could create a piece of software that exactly modeled the human body and how a particular drug would interact with it, I think that deserves some protection. But I don’t think that anyone owns the idea of, say, “swipe left to unlock”. Also it seems like software rights could be protected by copyright, but then again IANAL (one source for more information on this is Patent Absurdity)

Picture of Amir Montezary on stage

The next person on stage was Amir Montazery, of the Open Source Technology Improvement Fund. The mission of the OSTIF is to help secure open source software. They do this through both audits and fundraising to provide the resources to open source projects to make sure their software is secure as possible.

Jennings Aske, of New York-Presbyterian Hospital spoke next. I have worked a bit with technology in healthcare and as he pointed out there are a lot of network connected devices used in medicine today, from the devices that dispense drugs to the hospital beds themselves. Many of those do not have robust security (and note that these are proprietary devices). Since a hack or other breach could literally be a life and death situation, steps are being taken to mitigate this.

Picture of Jennings Aske on stage

I enjoyed this talk mainly because it was from the point of view of a consumer of software. As customers are what drive software revenues, they stand the best chance in getting vendors to provide SBOMs, along with government entities such as the National Telecommunications and Information Administration (NTIA). The NTIA has launched an effort called Software Component Transparency to help with this, and Jennings introduced a project his organization sponsors called DaggerBoard that is designed to scan SBOMs to look for vulnerabilities.

Picture of Arun Gupta on stage

The next keynote was from Arun Gupta of Intel. His talk focused on building stronger communities and how Intel was working to build healthy, open ecosystems. He pointed out that open source is based largely on trust, which is an idea I’ve promoted since I got involved in FOSS. Trust is something that can’t be bought and must be earned, and it is cool to see large companies like Intel working toward it.

Picture of Melissa Smolensky on stage

The final presenter was Melissa Smolensky from Gitlab who based her presentation around a “love letter to open source”. It was cute. I too have a strong emotional connection to my involvement in free and open source software that I don’t get anywhere else in my professional life, at least to the same degree.

I did get to spend some time near the AWS booth today, and after chatting at length with the FreeRTOS folks I happened to be nearby when Chris Short did a presentation on GitOps.

Chris Short presenting GitOps

In much the same way that Apple inspired a whole generation of Internet-focused products to put an “i” in front of their name, DevOps has spawned all kinds of “Ops” such as AIOps and MLOps and now GitOps. The idea of DevOps was built around creating processes to more closely tie software development to software operation and deployment, and key to this was configuration management software such as Puppet and Ansible. Instead of having to manage configuration files per instance, one could store them centrally and use agents to deploy them into the environment. This central repository allows for a high degree of control and versioning.

It is hard to think of a better tool for versioning than git, and thus GitOps was born. Software developed using GitOps is controlled by configuration files (usually in YAML) and using git to make changes.

While I am not an expert on GitOps by any means, suppose your application used a configuration file to determine the various clusters to create. To generate a new cluster you would just edit the file in your local copy of the repo, git commit and git push.

You application would then use something like Flux (not to be confused with the Flux query language from InfluxData) to note that a change has occurred and then do a git pull which would then cause the change to be applied.

Pretty cool, huh? A lot of people are familiar with git so it makes the DevOps learning curve a lot less steep. It also allows for the configuration of multiple repositories so you can control, say, access to secrets differently than the main application configuration.

Spot Callaway and Brian Proffitt

Also while I was in the booth I got this picture of two Titans of Open Source, Spot Callaway and Brian Proffitt. Oh yeah.

My final session of the day was given by Kelly O’Malley of Databricks on Delta Lake.

Kelly O'Malley presenting on Delta Lake

Now as someone who has given a lot of talks, I try to be respectful of the presenter and with the exception of the occasional picture and taking notes I try to stay off my phone. I apologized to her afterward as I was spending a lot of time looking up terms with which I was unfamiliar, such as “ACID” and “parquet“.

Delta Lake is an open source project to create a “Lakehouse”. The term is derived from a combination of “Data Warehouse” and “Data Lake“.

Data warehouses have been around for a very long time (in one of my first jobs I worked for a VAR that built hardware solutions for storing large data warehouses) and the idea was to bring together large amounts of operational data into one place so that “business intelligence” (BI) could be applied to help make decisions concerning the particular organization. Typically this data has been very structured, such as numeric or text data.

But people started figuring out that a lot of data, such as images, needed to be stored in more of a raw format. This form of raw data didn’t lend itself well to the usual BI analysis techniques.

Enter Delta Lake. Based on Apache Spark, it attempts to make data lakes more manageable and to make them as useful as data warehouses. I’m eager to find the time to learn more about this. When I was at OpenNMS we did a proof of concept about using Apache Spark to perform anomaly detection and it worked really well, so I think it is perfectly matched to make data lakes more useful.

My day ended at an internal event sponsored by Nithya Ruff, who in addition to being the chairperson of the Linux Foundation is also the head of the AWS OSPO. I made a number of new friends (and also got to meet Amir Montazery from the morning keynotes in person) but ended up calling it an early night because I was just beat. Eager to be fresh for the next day of the conference.

by Tarus at June 23, 2022 05:48 PM

June 22, 2022

2022 Open Source Summit – Day 1

The main activities for the Open Source Summit kicked off on Tuesday with several keynote sessions. The common theme was community and security, including the Open Source Security Foundation (OpenSSF).

The focus on security doesn’t surprise me. I was reminded of this xkcd comic when the Log4shell exploit hit.

An xkcd comic showing how complex digital architecture depends on little known, small projects

At the time I was consulting for a bank and I called the SVP and said “hey, we really need to get ahead of this” and he was like “oh, yeah, I was invited to a security video call a short while ago” and I was like “take the call”.

I managed to squeeze into the ballroom just before the talks started, and I was happy to see the room was packed, and would end up with a number of people standing in the back and around the edges.

People in the hotel ballroom watching the keynote presentations

The conference was opened by Robin Bender Ginn, Executive Director of the OpenJS Foundation.

Picture of Robin Bender Ginn on stage

After going over the schedule and other housekeeping topics, she mentioned that in recognition of Pride Month the conference was matching donations to the Transgender Education Network of Texas (TENT) as well as Equality Texas, up to $10,000.

In that vein the first person to speak was Aeva Black, and they talked about how diversity can increase productivity in communities, specifically open source communities, by bringing in different viewpoints and experiences. It was very well received, with many people giving a standing ovation at its conclusion.

Picture of Aeva Black on stage

The next speaker was Eric Brewer from Google (a platinum sponsor) and his talk focused on how to improve the robustness and security of open source (and he joked about having to follow Black with such a change of topic). Free software is exactly that, free and “as is”. So when something like Log4shell happens that impacts a huge amount of infrastructure, there is really no one who has an implicit obligation to rectify the issue. That doesn’t prevent people from trying to force someone to fix things, as this infamous letter to Daniel Stenberg demonstrates.

Picture of Eric Brewer on stage

Brewer suggests that we work on creating open source “curators” who can provide commercial support for open source projects. In some cases they could be the maintainer, but it is not necessary. When I was at OpenNMS our support offerings provided some of this indemnification along with service levels for fixing issues, but of course that came at a cost. I think it is going to take some time for people to realize that free software does not mean a free solution, but this idea of curators is a good start.

I got the feeling that the next presentation was one reason the hall was so packed as Linus Torvalds and Dirk Hohndel took the stage. Linus will be the first to admit that he doesn’t like public speaking, but I found that this format, where Dirk asked him questions and he responded, worked well. Linus, who is, well, not known for suffering fools gladly, admitted and apologized for his penchant for being rather sharp in his criticism, and when Dirk asked if he was going to be nicer in the future Linus said, no, he probably wouldn’t so he wanted to proactively apologize. That made me chuckle.

Picture of Linus Torvalds and Dirk Hohndel on stage

This was followed by a security-focused presentation by Todd Moore from IBM, another platinum sponsor. He also addressed trying to improve open source security but took an angle more aimed at government involvement. Digital infrastructure is infrastructure, much like bridges, roads, clean water, etc., and there should be some way for governments to fund and sponsor open source development.

Picture of Todd Moore on stage

The final keynote for today was a discussion with Amy Gilliland who is the President of General Dynamics Information Technology (GDIT). In a past life I worked quite a bit with GDIT (and you have to admit, that can be a pretty appropriate acronym at times) and it is nice to see a company that is so associated with more secretive aspects of government contracting focusing on open source solutions.

Picture of Amy Gilliland on stage

After the keynotes I visited the Sponsor Hall to see the AWS booth. It was pretty cool. As a diamond sponsor it is right in front as you enter.

AWS Booth in the Sponsor Hall

There were people from a number of the open source teams at AWS available to do presentations, including FreeRTOS and OpenSearch.

People in the Sponsor Hall

I don’t have booth duty this conference so I decided to wander around. I thought it was laid out well and it was interesting to see the variety of companies with booths. I did take some time to chat with the folks at Mattermost.

Mattermost Booth in the Sponsor Hall

While I’m a user of both Discord and Slack, I really, really like Mattermost. It is open source and provides a lot of the same functionality as Slack, and you can also host it yourself which is what the OpenNMS Project does. If you don’t want to go to the trouble of installing and maintaining your own instance, you can get the cloud version from Mattermost, and I learned that as of version 7 there is a free tier available so there is nothing preventing you from checking it out.

A selfie featuring me and whurley

I did take a short break from the conference to grab lunch with my friend William Hurley (whurley). It had been at least three years since we’d seen each other face to face and, thinking back, I was surprised at the number of topics we managed to cover in our short time together. He is an amazing technologist currently working to disrupt, and in many ways found, commercial quantum computing through his company StrangeWorks. He also made me aware of Amazon Braket, which lets those of us who aren’t whurley to access quantum computing services. I’m eager to check it out as it is an area that really interests me.

After lunch I was eager to see a presentation on InfluxDB by Zoe Steinkamp.

A picture of Zoe Steinkamp presenting on InfluxDB

Time series data collection and storage was a focus of mine when I was involved in monitoring, and Influx is working to make flexible solutions using open source. Steinkamp’s presentation was on combining data collection at the edge with backend storage and processing in the cloud. Influx had a working example of a device that would monitor the conditions of a plant (she’s an avid gardener) such as temperature and moisture, and this data was collected locally and then forwarded to the cloud. They have a new technology called Edge Data Replication designed to make the whole process much more robust.

I was excited to learn about their query language. Many time series solutions focus so much on obtaining and storing the data and not enough on making that data useful, which to me seems to be the whole point. I’m eager to play with it as soon as I can.

One thing that bothered me was that the hotel decided to have the windows washed in the middle of the presentation.

A picture a window washer

Steinkamp did a great job of soldiering through the noise and not letting it phase her.

The evening event was held at Stubbs restaurant, which is also a music venue.

The Stubbs Restaurant sign feature a billboard welcoming the Open Source Summit

I’ve been a fan of Stubbs barbecue sauce for years so it was cool to go to the restaurant that bears his name, even though the Austin location was opened in 1996, a year after Christopher B. Stubblefield died.

It was a nice end to a busy day, and I look forward to Day 2.

by Tarus at June 22, 2022 06:08 PM

June 21, 2022

OpenNMS On the Horizon – June 21st, 2022

It's time once again for OpenNMS On the Horizon.

Since last time, we worked on documentation (Enlinkd topology layer, glossary, database reports, SNMP interface poller, OPAQUE data types), as well as encrypting PostgreSQL credentials, CircleCI refactoring, dependency updates, time-series updates (metric deduplication, cache generation), node scanning and detector support in Horizon Stream, node category events, blocked pom dependencies, JNA, LLDP, pristine configs, ALEC REST and UI, topology UI, state management for UI extensions, event/alarm search, outdated report logos, heatmap, device config backup UI and deletion, password/login screen, and other REST work in Horizon Stream.

Github Project Updates

Internals, APIs, and Documentation
  • Antonio worked on updated Enlinkd documentation for the new topology layer code.
  • Christian did more work on encrypting PostgreSQL credentials.
  • Morteza continued to rework the Horizon CircleCI code.
  • I updated a bunch of dependencies to newer versions.
  • Emily did more documentation work on the glossary.
  • Morteza and I worked on some optimizations to do less work during CircleCI builds.
  • Patrick did more work on deduplicating time-series metrics.
  • Mark Frazier worked on scheduling node scans in Horizon Stream.
  • Arthur did more work on supporting detectors in Stream.
  • Mark Mahacek worked on documentation for database reports and the SNMP Interface Poller.
  • Lars Schreiber contributed an enhancement to change the description of nodeCategoryMembershipChanged
  • I fixed up a number of our pom versions using 99.99.* for blocking bad dependencies to use the enforcer plugin instead.
  • I updated JNA to the latest version.
  • Freddy made an improvement to cache generation in the time-series API.
  • Jesse worked on an alternate way to handle/calculate ingress and egress with flows.
  • Dmitri worked on documentation for OPAQUE data type support.
  • Antonio worked on an issue relating to ifIndex storage when querying LLDP.
Web, ReST, UI, and Helm
  • Alex worked on creating a "pristine" dir for some files in WEB-INF like we do for etc.
  • Benjamin Janssens did more work on an ALEC REST endpoint for storing permissions for training data.
  • Yang Li worked on REST API docs and deployment in Horizon Stream.
  • Chinh Le continued their work on implementing topology in the new UI code.
  • Mike Rose refactored the UI extension code to have access to state management.
  • I fixed some old logos that never got cleaned out in reports and some other UI places.
  • Pushkar worked on wrapping up his event/alarm search fixes.
  • Christian merged his fixes for the heatmap.
  • Mike Rose fixed the backup config UI to disable manual backup trigger if a selected config doesn't have an associated service name.
  • Mike Rose did more work on password screen code.
  • Anya did more work on an ALEC UI.
  • Chandra updated the file editor to support DCB files.
  • Pushkar added support for deleting device config backups through REST.
  • Mark Frazier worked on the REST API for foreign sources in Stream.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Mark Frazier
  • Antonio Russo
  • Mike Rose
  • Yang Li
  • Arthur Naseef
  • Alexander Chadfield
  • Dmitri Herdt
  • Chinh Le
  • Benjamin Janssens
  • Jeffrey-David Kapp
  • Bonnie Robinson
  • Morteza Ershad-Manesh
  • Emily Marsh
  • Jesse White
  • Freddy Chu
  • Pushkar Suthar
  • Anya Rybalova
  • Alex May
  • Chandra Gorantla
  • Mark Mahacek
  • Lars Schreiber
  • James Hutchinson
  • Patrick Schweizer
  • Christian Pape
  • Dustin Frisch

Coming Soon: JIRA Migration

We will be migrating our JIRA issue-tracker from a self-hosted version to Atlassian's cloud version.
I don't have a timeline for this yet, but expect it in the coming months.

If you currently have an account at the OpenNMS issue tracker your account should already be migrated to JIRA Cloud, but you will need to perform a password reset with the "Can't log in?" link before you can log in.

Releases and Roadmap

Upcoming July Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is July 13th, 2022.

We currently expect updates to Horizon 30 and all supported Meridians.

Next Horizon: 31 (Q4 2022)

The next major Horizon release will be Horizon 31.

Since Horizon 30 was just released, there is nothing concrete on the roadmap for Horizon 31 yet.
Stay tuned for details when they come.

Next Meridian: 2023 (Q1 2023)

Meridian 2023 is early in its development cycle, but you can expect it to contain, at the very least, the work that's going into Horizon 30.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HS-52: Document interview results for the activity board
  • HS-53: Provide Summary of Findings
  • HS-101: Migrate the WEB detector for provisiong
  • HS-102: Migrate the JMS detector for provisioning
  • HS-103: Migrate the DATAGRAM detector for provisiong
  • HS-105: Migrate the DHCP detector for provisiong
  • HS-106: Migrate the JDBC detector for provisiong
  • HS-108: Migrate the SSH detector for provisioning
  • HS-130: Add swagger to REST API server
  • HS-139: Tag & Release Workflow
  • HS-141: Trigger the develop.yml workflow before merging feature into develop
  • HS-151: Migrate Scopes for provisioning detectors
  • HS-152: Refactor detectors: improve modularity of the OpenNMS GRPC Server
  • HS-155: Password Requirements
  • HS-156: Handle inventory management in provision service
  • HS-158: Generic non-Helm dependency support
  • NMS-11787: Provide CDP BRIDGE, LLDP, ISIS, OSPF topologies in REST
  • NMS-11793: Guide to monitor essential Microsoft Active Directory Services
  • NMS-11810: There should be documentation for the reports
  • NMS-11860: Enlinkd and Topology Refactoring
  • NMS-12355: Correct Grammar in Notices Box
  • NMS-14106: TEST: Provisiond configuration upgrade from release-29 to release-30
  • NMS-14119: Support for SSH Key Authentication
  • NMS-14161: Event/Alarm advanced search not passing search terms
  • NMS-14226: Test Environment preparation
  • NMS-14243: Heatmap drill down does not show any alarms/outages
  • NMS-14265: Test DCB UI
  • NMS-14300: DCB: UI : Configs without service name shouldn't have option for Backup
  • NMS-14325: Enlinkd Topology Map Layers Documentation
  • NMS-14335: Remove flaky tests from every merge and leave it for release only
  • NMS-14372: Replace old logo references in some files/reports with the new logo
  • NMS-14382: Add documentation for OPAQUE data type support
  • NMS-14388: UI Extensions should be able to tap into state management (Vuex, Pinia)
  • NMS-14411: DCB: Script files are not shown in File Editor UI
  • NMS-14417: upgrade JNA to 5

by RangerRick at June 21, 2022 08:32 PM

2022 Open Source Summit – Day 0

Monday was a travel day, but it was notable as it was the first time I have been in an airport since August. I fly out of RDU, and the biggest change was that they now have the “Star Trek” x-ray machines to scan carry-on luggage. While I was panicked for a second when I downloaded my boarding pass and didn’t see the TSA Precheck logo, I was able to get that sorted out so going through security was pretty easy.

The restrictions on masks for air travel have been lifted, but I wore mine along with about 10% of the other travelers. Even though I’ve had four shots and a breakthrough case of COVID I do interact with a lot of older people and since I’ll be around the most people in years at the Open Source Summit I figured I’d wear mine throughout the trip.

And while it isn’t N95, being a car nut I tried out these masks from K&N Engineering, who are known for high end air filtration for performance vehicles, and you almost don’t realize you are wearing a mask.

Anyway, I made my way to the Admiral’s Club and was pleasantly surprised to see it wasn’t very crowded. It was nice to have the membership (it comes with my credit card) as my flight to Charlotte was delayed over 90 minutes. I wasn’t too worried since I had a long layover before heading to Austin, so I was a lot less stressed than many of my fellow travelers.

The flight to Austin left on time and landed early, but we got hit with the curse in that our gate wasn’t available, so we ended up on the tarmac for 45 minutes, getting in 30 minutes late.

Not that I’m complaining. Seriously, according to my handy the trip from my home to Austin by car is 19 hours. From the moment I left my home until we landed was more like 8 hours, and most of that was enjoyable. I always have to remind myself of this wonderful clip by Louis CK which kind of sums up the amazing world in which we live where every time we fly we should be saying to ourselves “I’m in a chair in the sky!”

I checked in at the hotel and then we headed back out in our rented minivan to get the last member of our team, and then we drove about 45 minutes outside of Austin to this barbecue joint called Salt Lick in Driftwood Texas. It was wonderful and I was told we owed this experience to a recommendation years ago from Mark Hinkle, so thanks Mark!

A white van in the parking lot of the Salt Lick barbecue restaurant

You can’t really tell a good barbecue restaurant by its looks, although shabbier tends to be better, but more by the smell. When you get out of your vehicle your nose is so assaulted with the most wonderful smell you might be drawn to the entrance so quickly that you miss the TARDIS.

A British Police box that looks like the TARDIS from Doctor Who in the parking lot of the Salt Lick barbecue restaurant

We sat at a big picnic table and ordered family style, which was all you could eat meat, slaw, baked beans, bread, pickles and potato salad. I was in such a food coma by the end that I forgot to take a picture of the cobbler.

A table full of food at the Salt Lick barbecue restaurant

I tried not to fall asleep on the ride back to Austin (I wasn’t driving) but it was a great start to what I hope is a wonderful week.

by Tarus at June 21, 2022 01:15 PM

June 16, 2022

2022 Open Source Summit North America

Next week I’ll be attending my first conference in nearly three years. My last one turned out to be the very last OSCON back in 2019. Soon after that I was in a bad car accident that laid me up for many months and then COVID happened.

Open Source Summit Logo Showing Member Conferences

I am both eager and anxious. Even having four vaccine shots and one breakthrough case I still feel a little exposed around large groups of people, but the precautions outlined in the “Health and Safety” section of the conference website are pretty robust and I am eager to see folks face-to-face (or mask-to-mask) once again.

The Linux Foundation’s Open Source Summit used to be known as Linuxcon and now it is an umbrella title for a number of conferences around open source, all of which look cool. My new employer, AWS, is a platinum sponsor and will also have a booth (I am not on booth duty this trip but I’ll be around). I am looking forward to getting to meet in person many of my teammates who I’ve only seen via video, old friends I haven’t seen in years, and to making a bunch of new ones.

Of course, we would have to have a conference in Austin during a heat wave. I was thinking about never leaving the conference venue but then I remembered … barbecue.

If you are going and would like to say “hi” drop me a note on Twitter or LinkedIn or send an e-mail to tarus at tarus dot io.

by Tarus at June 16, 2022 04:41 PM

June 15, 2022

In Pursuit of Quality Interactions

Recently my friend Jonathan had a birthday, and I sent him a short note with best wishes for the day and to let him know I was thinking about him.

In his reply he included the following paragraph:

[I] was reminded of your comment about a sparsely attended OUCE conference at Southampton one year. You said something along the lines of that it didn’t matter, that you would try to make it the best experience you could for everyone there. That stuck with me. It’s been one of my mantras ever since then.

I can remember talking about that, although I also remember I was very ill during most of that conference and spent a lot of time curled up in my room.

Putting on conferences can be a challenge. You don’t know how many people will show up, but you have to plan months in advance in order to secure a venue. Frequently we could use information about the previous conference to approximate the next one, but quite often there were a number of new variables that were hard to measure. In this case moving the conference from Germany, near Frankfurt, to Southampton in the UK resulted in a lot less people coming than we expected.

It is easy to get discouraged when this happens. I have given presentations in full rooms where people were standing in the back and around the edges, and I have given presentations to three people in a large, otherwise empty room. In both cases I do my best to be engaging and to meet the expectations of those people who were kind enough to give me their attention.

I think this is important to remember, especially in our open source communities. I don’t think it is easy to predict which particular people will become future leaders on first impressions, so investing a little of your attention in as many people as possible can reap large results. I can remember when I started in open source I’d sometimes get long e-mails from people touting how great they were, which was inevitably followed up with a long list of things I needed to do to make my project successful. Other times I’d get a rather timid e-mail from someone wanting to contribute, along with some well written documentation or a nice little patch or feature, and I valued those much more.

I can remember at another OUCE we ended up staying at a hotel outside of Fulda because another convention (I think involving public service vehicles like fire trucks and ambulances) was in town at the same time. There was a van that would pick us up and take us into town each morning, and on one day a man named Ian joined me for the ride. He was complaining about how his boss made him come to the conference and he was very unhappy about being there. I took that as a challenge and spent some extra time with him, and by the end of the event he had become one of the project’s biggest cheerleaders.

Or maybe it was just the Jägermeister.

In the book Zen and the Art of Motorcycle Maintenance the author Robert Persig demonstrates a correlation between “attention” and “quality”. In today’s world I often find it hard to focus my attention on any one thing at a time, and it is something I should improve. But I do manage to put a lot of attention into person-to-person interactions, and that has been very valuable over the years.

In any case I was touched that Jonathan remembered that from our conversation, and it helps to be reminded. It also motivated me to write this blog post (grin).

by Tarus at June 15, 2022 01:25 PM

June 13, 2022

OpenNMS On the Horizon – June 13th, 2022

It's time once again for OpenNMS On the Horizon.

Since last time, we worked on documentation (database reports, external auth, the glossary, GraphML, Helm flows, installation, logging, performance data, OIA, poller threads, provisioning, SCV, and the SnmpCollector), CI/CD for Horizon and Horizon Stream, Lombok, Kafka alarm sync, stress-metrics, inventory management in Stream, SNMP OPAQUE types, GRPC, Docker multi-arch support, Topology, Flow Elasticsearch support, Stream persistence, bridge topology, PostgreSQL credential encryption, time-series metric deduplication, Keycloak login, requisition metadata editing, ALEC web UI and training API, heatmaps.

Github Project Updates

Internals, APIs, and Documentation
  • Jason continued to flesh out Horizon Stream CI/CD workflows.
  • Morteza worked on optimizing some Horizon CircleCI builds.
  • Mark Mahacek worked on documentation for external auth, GraphML, performance data, SCV, and the SnmpCollector.
  • Chandra worked on documentation for OIA and poller thread consumption.
  • I audited the current set of flaky tests in CircleCI and updated the code to match.
  • Morteza worked on dynamically generating CircleCI configs based on branch name and other metadata.
  • Mark Frazier worked on some Lombok-related changes in Horizon Stream.
  • Bonnie did more work on improvements to installation and provisioning documentation.
  • Alex fixed a bug where outstanding alarms may not re-sync to Kafka in some situations.
  • Freddy did some work on the stress-metrics command.
  • Marcel worked on a bunch of documentation relating to logging.
  • Freddy wrapped up his fixes to graceful shutdown of Telemetryd.
  • Mark Frazier worked on inventory-handling (provisioning) in Stream.
  • Dmitri did more work on OPAQUE SNMP data type handling.
  • Arthur worked on modularizing some GRPC-related code in Stream.
  • I fixed some issues in multi-arch Docker image generation.
  • Antonio worked on some fixes to topology smoke tests.
  • James fixed an error in error reporting in the flow Elasticsearch repository code.
  • Arthur worked on DAO/persistence in Stream.
  • Emily worked on adding new stuff to the glossary in the Horizon docs.
  • Antonio fixed an issue with bridge topology discovery.
  • Andrew worked on some updates to database report documentation.
  • Christian worked on encrypting stored PostgreSQL credentials.
  • Patrick worked on metric deduplication in the OIA time-series API.
Web, ReST, UI, and Helm
  • Alberto worked on updated Helm documentation for the Flow datasource.
  • Mike worked on Keycloak login stuff for Stream.
  • Yang Li did more work on user management REST endpoints in Stream.
  • Scott added support for multi-line text entry in requisition metadata in the web UI.
  • Chinh Le did more work on the new Vue-based topology UI.
  • Pushkar did more work on a fix for event and alarm search.
  • Anya worked on a web UI plugin for ALEC.
  • Benjamin worked on a REST endpoint for storing permissions for training submission.
  • Christian fixed an issue in the heatmap code.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Christian Pape
  • Patrick Schweizer
  • Pushkar Suthar
  • Mark Frazier
  • Jason Berry
  • Emily Marsh
  • Morteza Ershad-Manesh
  • Anya Rybalova
  • Andrew Konstantaras
  • Benjamin Janssens
  • Jeffrey-David Kapp
  • Benjamin Reed
  • Arthur Naseef
  • Jesse White
  • Dustin Frisch
  • Antonio Russo
  • Mike Rose
  • Chandra Gorantla
  • Mark Mahacek
  • Chinh Le
  • Yang Li
  • James Hutchinson
  • Dmitri Herdt
  • Lars Schreiber
  • Alberto Ramos
  • Alex May
  • Freddy Chu
  • Scott Theleman
  • Marcel Fuhrmann
  • Bonnie Robinson
  • Dino Yancey

Releases and Roadmap

Horizon 30 Released

Release 30.0.0 is the first in the Horizon 30 series, introducing a number of new features, most notably a preview of a new web UI, and the ability to back up infrastructure device configs.

The codename for Horizon 30.0.0 is Nutria.

Breaking Changes
OpenNMS Plugin/Integration API (OIA) Updated to 1.0.0

The OIA version required has been updated to 1.0.0, following its first stable release. Plugins intended to run in OpenNMS must implement version 1.0.0 (or higher).

New Configuration Management API

A new API has been introduced for accessing and manipulating configuration, including moving configuration from XML files into the database. The initial implementation proof-of-concept converts the provisiond-configuration.xml to the new API.

The OpenNMS installer will import your existing provisiond-configuration.xml file on upgrade.

This will happen automatically, but if you rely on programatically manipulating the Provisiond configuration you will need to convert your code to use the config management REST API instead.

Docker Images

The Horizon and Sentinel Docker images are now based on a minimal install of Ubuntu, rather than CentOS. Symlinks are provided to match the old paths in /opt but it’s possible you will run into subtle differences when transitioning.

Collectd Strict Interval

The org.opennms.netmgt.collectd.strictInterval setting now defaults to true.

Previously, Collectd would not reschedule collection for a device until after the previous collection completes. This means that if OpenNMS is collecting at a 5-minute interval, and it takes 1 minute to collect the data, then the next collection will start 6 minutes after the previous collection was launched.

The new default behavior is to always schedule collection as a predictable interval.

You can change to the previous behavior by creating a property file in $OPENNMS_HOME/etc/opennms.properties.d/ with the contents: org.opennms.netmgt.collectd.strictInterval=false.

New Features and Improvements
New UI (Early Access)

Work has begun on creating a new UI with an eye towards making more common workflows easier.

It uses Vue 3 and the Feather Design System. You can try it out by clicking "UI Preview" in the navigation bar of the web UI.

It is also now possible to write OIA plugins that extend the new UI.

Device Config Backup

Initial support has been added for performing configuration backups of infrastructure devices like routers and switches. Backups are performed as part of polling the device, and can be viewed (and triggered) in the web UI.

OIA Supported on Minion and Sentinel

The OpenNMS Plugin API can now be used to extend Minion and Sentinel. A subset of APIs are supported, as appropriate for each platform.

Secure Credentials Vault

You can now validate credentials stored in the SCV with the scv-validate Karaf command.

Additionally, support for encrypted credentials has been extended to more places inside OpenNMS, most notably in Metadata interpolation. Also, a REST API has been added for accessing and updating the SCV.

Flows and Nephron

It is now possible to configure thresholding on flow data.

Polling, Metadata, and Collection
  • The XML collector can now treat a collected value as an enumerated value, which lets you convert strings into integers to store as a gauge.
  • It is now possible to passively "collect" data from incoming events as time-series data, including those that come from traps or syslog. The eventconf has additional options to configure what data to collect
    from parameters including regular-expression matches.
  • The BgpSessionMonitor can now be configured to use a custom OID prefix for devices that publish peer tables in a non-standard location.

Additions or updates to graphs and collections have been made for:

  • F5 Devices
  • Flows
  • Node Exporter
  • Prometheus
  • Windows Exporter
REST API
  • Improvements have been made to the criteria querying API to support "Multi-And" and regexp restrictions, allowing for queries involving multiple event parameters, or complex string matching.
Documentation

An unspeakable amount of work has gone into documentation improvements and additions across the board.

Notable additions include:

  • Developer documentation for OSGi in OpenNMS, the OpenNMS Plugin API (OIA), the config management API, device config backup APIs, and the Health REST service.
  • Operation documentation updates relating to SNMP property extenders, performance data and collection, thresholding, the log file viewer, SCV, and the new UI preview.
  • Documentation improvements regarding "housekeeping" and other administrative tasks, alarms, Business Service Monitoring, Passive Status Monitoring, and more.
Important Internal Changes
  • Kafka components have been updated to version 3.0.0
  • Our embedded Karaf has been updated to version 4.3.6
OpenNMS Plugin API 1.0 Released

The first officially stable release of the OpenNMS Plugin API (a.k.a. OIA) came out last week.

From 1.0 forward, it will follow Semantic Versioning.

Since OIA 0.6, the following changes have occurred:

Improvements and Features
  • Guava has been updated to 30.1.1-jre
  • updated to be supported on Minion and Sentinel
  • extend the new Horizon Vue-based UI through OIA
  • key-value store support was added
  • Secure Credentials Vault support was added
  • event-sourced collection config support was added
Breaking
  • requires JDK 11 or higher
  • InterfaceToNodeCache API was changed to remove Stream<Integer> getNodeIds(String location, InetAddress ipAddr)
Helm 8 Released

Helm 8 contains updates to the core to use Grafana 8, the start of a move to
TypeScript, many optimizations, and a number of new features.

  • use an optimized bulk query when fetching string properties from OpenNMS
    versions that support it
  • convert much of the codebase to use native promises rather than angularJS
    wrappers
  • support converting NaN values to 0 when querying flow data
  • support swapping ingress and egress on flow data at query time
  • support for new filters for node, location, applications, hosts, and
    conversations
  • fixed an issue with missing flow data when ingress and egress are
    inconsistently available
  • many documentation improvements and additions
Alec 2.0 Released

ALEC (Architecture for Learning Enabled Correlation) version 2 contains a number of updates, most notably some new scoring strategies.

  • ALEC now requires JDK 11.
  • ALEC now users OIA 1.0.0, which means it requires Horizon 30 or higher, and future Meridian 2023 or higher.
  • In addition to the existing Set Intersection, Peer, and Matrix scoring strategies, ALEC now supports ARI and AMI strategies as well.
Upcoming July Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is July 13th, 2022.

We currently expect updates to Horizon 30 and all supported Meridians.

Next Horizon: 31 (Q4 2022)

The next major Horizon release will be Horizon 31.

Since Horizon 30 was just released, there is nothing concrete on the roadmap for Horizon 31 yet.
Stay tuned for details when they come.

Next Meridian: 2023 (Q1 2023)

Meridian 2023 is early in its development cycle, but you can expect it to contain, at the very least, the work that's going into Horizon 30.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-317: Grafana Datasource expressions - Flows
  • HELM-325: Document Grafana datasource expressions - Flows
  • HELM-327: Performnce DS Query type Attribute selector broken
  • HS-35: Add endpoints to REST API server for user management
  • HS-56: Create a service for pushing Requisition data to the provision module
  • HS-78: UX Writing - Password Reset Emails
  • HS-91: SCAN for inventory changes
  • HS-98: Tour through provisiond in Horizon
  • HS-99: Writing QA Check
  • HS-112: Interview identified users for the activity board
  • NMS-8861: Admin guide lacks a chapter on logging
  • NMS-13484: Document the Grafana Image Renderer plugin's dependencies
  • NMS-13574: Migrate External Auth into docs
  • NMS-13785: Error responses are not handled correctly when handling ElasticSearch responses
  • NMS-13918: Map Pins Missing Since Upgrade
  • NMS-14003: Telemetryd does not shut down gracefully
  • NMS-14018: SNMP MIB imports to handle OPAQUE data type implementation
  • NMS-14059: Add support for pre-authorization via HTTP header (to be used with pre-authentication)
  • NMS-14128: DCB: Error reporting needs love
  • NMS-14129: DCB: Debug script execution
  • NMS-14154: Documentation for OIA changes
  • NMS-14230: Create release notes content for H30
  • NMS-14231: Create release notes content for OIA, Alec, HELM to release along with H30
  • NMS-14255: DCB - Document impact of DCB on poller thread consumption
  • NMS-14282: Allow multi-line metadata
  • NMS-14299: DCB UI: Hover over Running Config in DCB takes longer
  • NMS-14321: Kafka-Producer Alarm Resync Failing Post Entire Kafka Cluster Outage
  • NMS-14322: Bridge Topology Discovery Mismatch
  • NMS-14326: fix smoke tests: GraphRestServiceIT
  • NMS-14343: features/topology: tooltip - PowerGrid (D3/Circle layout)
  • NMS-14359: Modify host, zone and requisition name field validation
  • NMS-14374: Fix Smoke Test for GraphMLTopologyIT
  • NMS-14377: features/topology: contextmenu - PowerGrid (D3/Circle layout)
  • NMS-14378: Snmp Link Up does not clear Snmp Link Down

by RangerRick at June 13, 2022 06:40 PM

June 08, 2022

AWS: Impressions So Far

When I announced that I had joined AWS, at least two of my three readers reached out with questions so I thought I’d post an update on my onboarding process and impressions so far.

One change you can expect is that when I talk about my job on this blog, I’m going to add the following disclaimer:

Note: Everything expressed here represents my own thoughts and opinions and I am not speaking for my employer Amazon Web Services.

Back when I owned the company I worked for I had more control about what I could share publicly. While I am very excited to be working for AWS and may, at some time in the future, speak on their behalf, this is not one of those times.

A number of people joked about me joining the “dark side”. My friend Talal even commented on my LinkedIn post with the complete “pitch speech” Darth Vader made to Luke Skywalker in Empire. While I got the joke I’d always had a pretty positive opinion of Amazon, gained mainly through being a retail customer.

I recently went and traced what I think to be my first interaction with Amazon back to a book purchase made in December of 1997. In the nearly 25 years I’ve been shopping there I can think of only two times that I was disappointed with their customer service (both involving returns) and numerous times when my expectations were exceeded by Amazon. For example, I once spent around $70 on two kits used to clean high performance automotive air filters. In shipment one of them leaked, and I asked if I could return it. They told me to keep both and refunded the whole $70, even after I protested that I’d be happy with half that.

It was this focus on customer service that attracted me to the possibility of working with Amazon. When I was at OpenNMS I crafted a mission statement that read “Help Customers. Have Fun. Make Money”. I thought I came up with it on my own but I may have gotten inspiration from a Dilbert cartoon, although I changed the order to put the focus on customers. I always put a high value on customer satisfaction.

I have also been a staunch, and I’ll admit, opinionated, proponent of free and open source software and nearly 20 years of those opinions are available on this blog. Despite that, AWS still wanted to talk to me, and as I went through the interview process I really warmed to the idea of working on open source at AWS.

Just before I started I received a note from the onboarding specialist with links to content related to Amazon’s “peculiar” culture. When I read the e-mail I was pretty certain they meant “particular”, as “particular” implies “specific” and “peculiar” implies “strange”. Nope, peculiar is the word they meant to use and I’m starting to understand why. They are so laser-focused on customer satisfaction that their methods can seem strange to people used to working in other companies.

As you can imagine with a company that has around 1.6 million employees, they have the onboarding process down to a science. My laptop and supporting equipment showed up before my start date, and with few problems I was able to get on the network and access Amazon resources. These last two weeks have been packed with meeting people, attending virtual classes with other new hires, and going through a lot of online training. One concept they introduce early on is the idea of “working backwards”. At Amazon, everything starts from the customer and you work backwards from there. After having this drilled into my head in one of the online courses it was funny to watch a video of Jeff Bezos during an All Hands meeting where someone asks if the “working backwards” process is optional.

Based on my previous experience with large companies I was certain of the answer: no, working backwards is not optional. Period.

But that wasn’t what he said. He said it wasn’t optional unless you can come up with something better. I know it is kind of a subtle distinction but it really resonated with me, as it drove home the fact that at Amazon no process is really written in stone. Everything is open to change if it can be improved. As I learn more about Amazon I’ve found that there are many “tenets”, or core principles, and every one of them is presented in the context that these exist until something better is discovered, and there seem to be a lot of processes in place to suggest those improvements at all levels of the company.

If there is anything that isn’t open to change, it is the goal of becoming the world’s most customer-centric company. While a lot of companies can claim to be focused on their customers without many specifics, at Amazon this is defined has having low prices, large selection and a great customer experience. Everything else is secondary.

I bring this up because it is key to understanding Amazon as a company. To get back to my area of expertise, open source, quite frequently open source involvement is measured by things such as number of commits, lines of code committed, number of projects sponsored and number of contributors. That is all well and good but seen through the lens of customer satisfaction they mean nothing, so they don’t work at Amazon. Amazon approaches open source as “how can our involvement improve the experience of our customers?”

(Again, please remember that is my personal opinion based on my short tenure at AWS and doesn’t constitute any formal policy or position)

Note that with respect to open source at AWS, “customer” can refer to both end users of software who want an easy and affordable way to leverage open source solutions as well as open source projects and companies themselves. My focus will be on the latter and I’m very eager to begin working with all of these cool organizations creating wonderful open source solutions.

This focus may not greatly increase those metrics mentioned above, but it is hoped that it will greatly increase customer satisfaction.

So, overall, I’m very happy with my decision to come to AWS. I grew up in North Carolina where the State motto is Esse Quam Videri, which is Latin for “to be rather than to seem”. My personal goal is to see AWS considered both a leader and an invaluable partner for open source companies and projects. I realize that won’t happen overnight and I welcome suggestions on how to reach that goal. In any case it looks like it is going to be a lot of fun.

by Tarus at June 08, 2022 04:20 PM

June 2022 Releases – Horizon 30.0.0, Meridians 2022.1.4, 2021.1.16, 2020.1.24, 2019.1.35

In May, we released updates to all OpenNMS Meridian versions under active support, as well as the first release of the Horizon 30 series.

Meridian Stable Updates

Meridians 2019.1.35, 2020.1.24, and 2021.1.16 contain mostly a number of small bug fixes.

Additionally, Meridian 2022.1.4 contains a bunch of documentation improvements and a few other bug fixes and enhancements.

For a list of changes, see the release notes:

Horizon 30.0.0

Release 30.0.0 is the first in the Horizon 30 series, introducing a number of new features, most notably a preview of a new web UI, and the ability to back up infrastructure device configs.

For a high-level overview of what has changed in Horizon 30, see What’s New in OpenNMS Horizon 30.

For a complete list of changes, see the changelog.

The codename for Horizon 30.0.0 is Nutria.

by RangerRick at June 08, 2022 02:02 PM

June 07, 2022

The OpenNMS Group Launches Horizon 30, the Latest Major Release of its Open Source Network Monitoring Solution

Official Release of OpenNMS Plugin API 1.0 Provides a Stable Development Ecosystem to Build Integrations and Plugins

RALEIGH, N.C. – June 8, 2022The OpenNMS Group, Inc., a subsidiary of NantHealth, Inc. (NASDAQ: NH), today announced OpenNMS Horizon 30, the latest major release of OpenNMS’ popular open source network monitoring solution. With the Horizon 30 release, OpenNMS is now improving network traffic analysis by providing advanced NetFlow thresholding and centralized storage of network device configurations, among other enhanced capabilities ideal for the enterprise.

Alongside Horizon 30, OpenNMS also announced the official release of the OpenNMS Plugin API 1.0, which provides the developer community with a reliable resource for building plugins that exchange information between OpenNMS and other systems.

“Horizon 30 provides a rich set of significant improvements to our NetFlow capabilities, not just with performance, but also by adding fine-grained analysis of network conversations,” said David Hustace, CEO of The OpenNMS Group. “We’ve also officially released our plugin API that facilitates the development of plugins that natively integrate a customer’s network infrastructure with the platform. This 1.0 version ensures compatibility against future Horizon releases preserving customer contributions across future releases.”


Horizon 30: NetFlow Thresholding, Device Configuration Backup, and More

With Horizon 30, OpenNMS builds on its existing support for traffic analysis by introducing the ability to generate alarms in real time by analyzing the flow data with algorithms that support high, low, and relative change threshold computations. Users can now define fine-grained monitoring of network circuits to help detect anomalies and changes in network traffic, thus ensuring circuits stay healthy, and bandwidth-related issues are identified promptly.

New to Horizon 30, users are now able to back up network device configurations on demand and/or schedule periodic backups. Horizon provides storage of centralized device configurations for comparative analysis in the event of an unexpected configuration change and the ability to manually restore backed up configurations.

Additional features and enhancements of Horizon 30 include:

  • OpenNMS Grafana Plugin Update (Helm 8.0): Provides updates to the integration between OpenNMS and Grafana to deliver a combination of fault, performance, and NetFlow data visualization in a single solution. Grafana dashboards built using OpenNMS Helm can now incorporate filtering by monitoring location, offer swapping of ingress and egress flow metrics, and take advantage of wildcard support to display data more dynamically than ever before.
  • Improved Device Inventory Workflow: A new way to configure the monitored device inventory subsystem, bringing both a user-friendly interface and a powerful API backend.
  • OpenAPI Support: Allows users to interact with the OpenNMS REST API directly from a web browser, accelerating understanding and shortening time to value.
  • Event-sourced Data Collection: Bridges fault-management and performance-management, enabling extraction of performance metrics from the fault-management domain. Metrics contained in SNMP traps or syslog messages can now be persisted for visualizing and thresholding.
  • Architecture for Learning-Enabled Correlation (ALEC) Topology Provider: Users can now view correlated situations and their constituent alarms on the topology map, as well as in list form.

OpenNMS Plugin API 1.0: Building Sustainable Integrations

With the official release of the Plugin API 1.0, OpenNMS provides a development ecosystem that facilitates integration of network infrastructure into a generalized framework of events, metrics, flows, and topology. OpenNMS features many integration points, making it a solid platform on which to build the monitoring solution an organization needs. The Plugin API clearly identifies, documents, and provides ongoing compatibility guarantees for those integration points, developers can create plugins that target a clear set of interfaces and work with a broad range of OpenNMS releases. As the Plugin API adoption increases, the community will benefit from an ecosystem of plugins that can be built more quickly, validated more easily, and assured to be compatible with future releases of OpenNMS.

For more information on Horizon 30, please visit: https://www.opennms.com/horizon/
For more information on the OpenNMS Plugin API 1.0, please visit: https://www.opennms.com/opennms-plugin-api

About OpenNMS
Based in Morrisville, NC, OpenNMS provides a highly reliable, scalable and comprehensive fault, performance and traffic monitoring solution that easily integrates with business applications and workflows to monitor and visualize everything in a network. The OpenNMS platform monitors some of the largest networks in existence, covering the healthcare, technology, finance, government, education, retail and industrial sectors, many with tens of thousands of networked devices. OpenNMS users include five of the top twenty companies on the Fortune 100, as well as multiple large and multi-state health providers and one of the largest electronic medical record providers in the United States. For more information, visit https://www.opennms.com/.

About NantHealth, Inc.
NantHealth, a member of the NantWorks ecosystem of companies, provides enterprise solutions that help businesses transform complex data into actionable insights. By offering efficient ways to move, interpret and visualize complex and highly sensitive information, NantHealth enables customers in healthcare, life sciences, logistics, telecommunications and other industries to automate, understand and act on data while keeping it secure and scalable. NantHealth’s product portfolio comprises the latest technology in payer/provider collaboration platforms for real-time coverage decision support (Eviti and NaviNet), and data solutions that provide multi-data analysis, reporting and professional services offerings (Quadris). The OpenNMS Group, Inc., a NantHealth subsidiary, helps businesses monitor and manage network health and performance. For more information, visit nanthealth.com, follow us on Twitter, Facebook, LinkedIn and YouTube, and subscribe to our blog.

NantHealth Forward Looking Statement

This news release contains certain statements of a forward-looking nature relating to future events or future business performance. Forward-looking statements can be identified by the words “expects," “anticipates," “believes," “intends," “estimates," “plans," “will," “outlook” and similar expressions. Forward-looking statements are based on management’s current plans, estimates, assumptions and projections, and speak only as of the date they are made. Risks and uncertainties include, but are not limited to: our ability to successfully integrate a complex learning system to address a wide range of healthcare issues; our ability to successfully amass the requisite data to achieve maximum network effects; appropriately allocating financial and human resources across a broad array of product and service offerings; raising additional capital as necessary to fund our operations; our ability to grow the market for our software and data solutions; successfully enhancing our software and data solutions to achieve market acceptance and keep pace with technological developments; customer concentration; competition; security breaches; bandwidth limitations; our ability to integrate The OpenNMS Group, Inc. into our operations; our use and distribution of open source software; our ability to obtain necessary regulatory approvals, certifications and licenses; dependence upon senior management; the need to comply with and meet applicable laws and regulations; unexpected adverse events; and anticipated cost savings. We undertake no obligation to update any forward-looking statement in light of new information or future events, except as otherwise required by law. Forward-looking statements involve inherent risks and uncertainties, most of which are difficult to predict and are generally beyond our control. Actual results or outcomes may differ materially from those implied by the forward-looking statements as a result of the impact of a number of factors, many of which are discussed in more detail in our reports filed with the Securities and Exchange Commission.

Media Contact
Erica Anderson
Offleash PR for OpenNMS
opennms@offleashpr.com

by Jess at June 07, 2022 11:59 AM

June 06, 2022

OpenNMS On the Horizon – June 6th, 2022

It's time once again for OpenNMS On the Horizon.

Since last time, we worked on documentation (daemons, ILR, device config backup, SCV, pollerd, passive status keeper, loop detector, BSM), topology maps and graph API tests, CI/CD for Horizon and Horizon Stream, smoke test improvements, Guava, Horizon Stream (Minion, events, detectors/scanning, Kubernetes, Keycloak, UI), Newts, opaque SNMP types, ALEC, Aruba switch configs, OIA, Telemetryd, Karaf, and UI improvements.

Github Project Updates

Internals, APIs, and Documentation
  • Antonio wrapped up adding Linkd layer/protocol view support to the topology maps, plus worked on fixing some graph API smoke tests.
  • Jason worked on CI/CD for Horizon Stream.
  • Gerald continued to work on development environment stuff for Stream.
  • Alexander did some work on cleaning up test API internals.
  • Morteza worked on CI/CD improvements for the Horizon build.
  • Bonnie worked on documentation for daemons and ILR.
  • I continued to work on updating Guava to a newer version.
  • Chandra wrote some documentation for Juniper device configuration backup, SCV, and poller threads.
  • Mark worked on docs for the passive status keeper, loop detector, and BSM.
  • Arthur continued to work on Minion support in Horizon Stream.
  • Gerardo worked on event serialization in Stream.
  • I worked on some dependency updates in Newts.
  • Dmitri did more work on opaque SNMP datatype support.
  • Arthur worked on getting simple detectors loading in Stream.
  • Benjamin Janssens did more ALEC algorithm work.
  • Jason worked on some Kubernetes ingress config for Stream.
  • Mark worked on inventory scanning in Stream.
  • Alberto added Aruba AOS-CX switch configs.
  • Gerald did more work on Keycloak config in Stream.
  • Chandra fixed an archetype issue in OIA.
  • Freddy worked on fixing Telemetryd shutdown issues.
  • Freddy did some enhancements to the stress-metrics Karaf command.
  • Morteza worked on optimizing some of our CircleCI image sizes.
  • Jesse worked on ALEC updates.
Web, ReST, UI, and Helm
  • Chinh Le did more work on topology, thread pool configuration, and IPv6 validation in the new UI.
  • Yang Li added user-management endpoints to the Stream REST API.
  • Mike Rose worked on login in Stream.
  • Christian removed some outdated support stuff from the help page.
  • Lars worked on some improvements to the notification UI.
  • Scott worked on some cleanups to sorting in the DCB UI.
  • Pushkar worked on a bug in event/alarm advanced search not passing parameters properly.
  • Jesse worked on exposing an ALEC UI through OIA.
  • Pushkar fixed an issue with map pins in the UI.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Jesse White
  • Chinh Le
  • Pushkar Suthar
  • Mark Frazier
  • Chandra Gorantla
  • Gerald Humphries
  • Arthur Naseef
  • Morteza Ershad-Manesh
  • Freddy Chu
  • Christian Pape
  • Jason Berry
  • Benjamin Reed
  • Scott Theleman
  • Alberto Ramos
  • Lars Schreiber
  • Benjamin Janssens
  • Bonnie Robinson
  • Mark Mahacek
  • Gerardo Montecon
  • Dustin Frisch
  • Dmitri Herdt
  • Mike Rose
  • Yang Li
  • Antonio Russo
  • Alexander Chadfield

Releases and Roadmap

Upcoming June Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is June 8th, 2022.

We currently expect the initial release of Horizon 30, plus Meridians 2019 through 2022.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • initial work moving configuration from XML files to the database -- the first config file implemented on top of the new system will be provisiond-configuration.xml
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2023 (Q1 2023)

Meridian 2023 is early in its development cycle, but you can expect it to contain, at the very least, the work that's going into Horizon 30.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HS-24: Migrate the provisiond module
  • HS-47: create keycloak utils
  • HS-51: Schedule interviews for the activity board
  • HS-73: User Self-host non-dev local env
  • HS-76: K8s Testing with Cucumber
  • HS-92: Add in memory cache for Keycloak user role lookup in REST server
  • HS-96: Investigation of Keycloak login page design limitations vs. feature access
  • HS-110: Create the PM/PO part for the agile cross team
  • HS-111: Run the classic Minion in DEV with Skaffold
  • HS-120: Reenable the validating webhook
  • HS-131: Megamenu navbar component: site search
  • HS-133: customizable dashboard: UX research
  • HS-134: site search: UX research
  • HS-142: Horizon Stream External IT - don't use the Horizon BOM
  • HS-146: Add keycloak themes folder to dev deployment
  • NMS-10393: there is no documentation on the instrumentation log reader
  • NMS-11042: LoopMonitor & detector
  • NMS-11052: Document PassiveServiceMonitor
  • NMS-14203: Add new KPIs to datachoices telemetry
  • NMS-14207: Add docs for SCV
  • NMS-14263: TEST: Provisioning config UI / thread pool sizes
  • NMS-14264: Test provisioning config UI / external requisitions
  • NMS-14266: Rogue opennms-tools/phonebook/pom.xml
  • NMS-14280: Remove "Commercial Support" ticket lookup from web ui support section
  • NMS-14301: DCB: Allow TFTP Port to be Parameterized in Script
  • NMS-14318: DCB UI: History and Compare should only display one config type
  • NMS-14324: DCB Rest API: Order by Location and Backup Status
  • NMS-14332: features/topology: update branch with develop
  • NMS-14337: Correct errors on Business Service Monitoring docs
  • NMS-14341: features/topology: upgrade dependencies
  • NMS-14342: features/topology: right panel menu is not reactive to sublayer context menu
  • NMS-14345: External Requisition UI: Thread pools adjust upper bound validation
  • OIA-38: Fix OIA archetype

by RangerRick at June 06, 2022 09:13 PM

May 31, 2022

OpenNMS On the Horizon – May 31st, 2022

It's time once again for OpenNMS On the Horizon.

Apologies for missing a few, but I was out of the office.

Since last time, we worked on, well, this list is huge.
Feel free to make the most inefficient summary possible by just reading all the updates.
Which I guess isn't really a summary.
¯\_(ツ)_/¯

Github Project Updates

Internals, APIs, and Documentation
  • Mark Mahacek worked on documentation updates for Meridian 2022.
  • Freddy continued his work on OIA improvements.
  • I continued my work on updating and refactoring various dependencies in our Karaf instance(s).
  • Chandra wrapped up his changes to support deleting devices configs when the related interface is removed.
  • Gerald worked on various Kubernetes and Skaffold config in Horizon Stream.
  • Chandra fixed a bug in DAO queries by IP address + location.
  • Alex worked on some device config backup test issues.
  • Mark Mahacek worked on BSM, Geocoder, Jetty SSL, LoopDetector, and PassiveStatus documentation.
  • Mike and Arthur worked on keycloak-related config for Stream development.
  • Patrick worked on some memory/GC optimization in the time-series layer.
  • Alex added a reason response for DCB.
  • Alberto worked on some DCB and Helm filter documentation updates.
  • I refactored how/when third-party license file generation happens.
  • Alexander did more work on HTTPS smoke tests.
  • Christian worked on making BgpSessionMonitor more flexible in what OIDs can be used.
  • Yang Li worked on being able to trigger events in Stream from the UI.
  • Alberto worked on making Collectd strictInterval=true by default for Horizon 30.
  • Christian fixed a bug in asset search.
  • Alberto updated documentation for the new location template variable in Helm.
  • Jason worked on the CI pipeline for Stream.
  • Gerald worked on Camel/Kafka routing in Stream.
  • Bonnie did some more work on upgrade and DCB documentation.
  • James fixed opennms restart so debug flags are preserved.
  • Christian worked on value mapping in the XML and SNMP collectors.
  • Dino added some thresholds for pollerd and collectd threads.
  • Chandra and Morteza fixed some issues in resolving OIA dependencies.
  • Chandra fixed some issues with script-file handling in DCB.
  • Antonio worked on some enlinkd topology improvements.
  • Dustin added support for setting what shell is used in DCB commands.
  • Bonnie added documentation for the Grafana Image Plugin and the WmiMonitor.
  • Gerardo worked on some ALEC modifications using Hellinger distance for correlation.
  • Alberto worked on an enhancement to validate SCV credentials in the Karaf shell.
  • Dmitri worked on supporting the OPAQUE SNMP data type.
  • Patrick did more work on SCV support in OIA.
  • Mark Frazier worked on provisioning scanning in Stream.
  • Arthur worked on Minion support in Stream.
  • Freddy worked on some additions to the stress Karaf command.
  • Morteza worked on some cleanups to how the CircleCI pipeline is run.
  • Chandra worked on supporting TFTP binary mode in DCB scripts.
  • Alberto fixed an issue with IP address SNMP parsing.
  • Dustin worked on better handling devices that send flows with an unknown direction.
Web, ReST, UI, and Helm
  • Pushkar worked on an access issue in resource graphs and ROLE_USER.
  • Mark Frazier worked on the provisioning REST service for Horizon Stream.
  • Alberto did more work on making sure Helm and reverse proxies play nice.
  • Mike worked on some path handling in the new UI, plus some other cleanups/validation changes.
  • Christian added DCB to the RTC dashboard.
  • Mike and Chinh Le worked on some improvements to the VMware form for requisition editing.
  • Scott added a new role ROLE_FILESYSTEM_EDITOR to allow access to editing configs from the UI.
  • Arthur added ack/unack to the Stream REST service.
  • Yang Li worked on authorization/CORS issues in Stream.
  • Maxim worked on some UI navigation and search fixes.
  • Alberto fixed some query issues in Helm.
  • Scott added OpenAPI annotations to the new DCB REST service.
  • Pushkar worked on a fix to event/alarm advanced search.
  • Alberto added support for multiple selection of applications/hosts/conversations in Helm.
  • Yang Li worked on cucumber tests for GraphQL in Stream.
  • Yang Li worked on role lookup/caching in Stream.
  • Chinh Le worked on a bunch of other improvements in the new UI.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Bonnie Robinson
  • Jason Berry
  • Gerald Humphries
  • Morteza Ershad-Manesh
  • Mark Mahacek
  • Chinh Le
  • Alberto Ramos
  • Antonio Russo
  • Dustin Frisch
  • Chandra Gorantla
  • Pushkar Suthar
  • Christian Pape
  • Alexander Chadfield
  • Freddy Chu
  • Mark Frazier
  • Arthur Naseef
  • Yang Li
  • Mike Rose
  • Marcel Fuhrmann
  • Scott Theleman
  • Dmitri Herdt
  • Alex May
  • Patrick Schweizer
  • James Hutchinson
  • Gerardo Montecon
  • Maxim Brener
  • Benjamin Reed
  • Dino Yancey

Releases and Roadmap

May Releases

In May, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 29.

NOTE: All releases this month received security updates that affect a number of core dependencies. While these dependency changes should not affect how the OpenNMS runtime works, these releases contain a larger than usual number of changes to "plumbing" to facilitate these dependency updates. We strongly recommend that you do more than the usual amount of testing before deploying this update to a production environment.

Meridian Stable Updates

Meridians 2019.1.34, 2020.1.23, and 2021.1.15 contain primarily dependency updates primarily for security improvements.

Additionally, Meridian 2022.1.3 contains a bunch of documentation improvements and a few other bug fixes.

For a list of changes, see the release notes:

Horizon 29.0.10

Release 29.0.10 contains all of the fixes included in Meridian 2022.1.3, plus a few other bug fixes and enhancements.

For a high-level overview of what has changed in Horizon 29, see What’s New in OpenNMS Horizon 29.

For a complete list of changes, see the changelog.

The codename for Horizon 29.0.10 is Duck.

Upcoming June Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is June 8th, 2022.

We currently expect the initial release of Horizon 30, plus Meridians 2019 through 2022.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • initial work moving configuration from XML files to the database -- the first config file implemented on top of the new system will be provisiond-configuration.xml
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2023 (Q1 2023)

Meridian 2023 is early in its development cycle, but you can expect it to contain, at the very least, the work that's going into Horizon 30.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-316: Document Grafana datasource expressions - Performance
  • HELM-326: Add documentation for location() template_variable
  • NMS-8504: Add a note to remember delete the browsers cache when upgrading OpenNMS
  • NMS-10226: Two BridgePort Node - Topology Mismatch
  • NMS-11065: WmiMonitor
  • NMS-12410: Topology Provider for CDP,LLDP,OSPF,ISIS,Bridge Topologies
  • NMS-12991: Missing datacollection file does not bring valueable error message
  • NMS-13684: Document how to set up SSL with Jetty
  • NMS-13692: Document how to upgrade OpenNMS
  • NMS-13971: Basic upgrade procedure
  • NMS-13987: [Web] - WebServer Fingerprinting
  • NMS-13991: Allow test mode flags in restart command
  • NMS-14008: Implement event sourced performance data
  • NMS-14038: DCB - Delete all device configs related to deleted interfaces / nodes
  • NMS-14084: Add the ability to define an enumeration to convert collected strings into numeric values
  • NMS-14109: Grafana box renders raw JS when Grafana behind reverse proxy with SSO
  • NMS-14148: Minions Trapd Listener Fails to Bind to udp/162 when broker is down
  • NMS-14174: DCB: Provide example scripts to download device configurations
  • NMS-14181: Audit Drift plugin and proportional_sum for accuracy
  • NMS-14185: Expose Secure Credentials Vault via Integration API
  • NMS-14193: Users with ROLE_USER face Access Denied when accessing Resource Graphs from Reports Section
  • NMS-14217: make sure license-maven-plugin is re-enabled in foundation and release branches
  • NMS-14227: SCV: Add Shell command to validate Credentials
  • NMS-14228: SCV: Cache JCEKS credentials in memory
  • NMS-14240: Exception when searching assets
  • NMS-14242: Super-admin role required to edit config files
  • NMS-14244: Add DCB services to 24-hour availability view
  • NMS-14245: Send events when a backup starts, succeds, or fails
  • NMS-14246: Requisition Web UI refers to "drop down" that doesn't exist
  • NMS-14247: Confusing web UI navigation titles
  • NMS-14248: Handle duplicate interface on a given location in DeviceConfig.
  • NMS-14249: modifiable OID prefix in BgpSessionMonitor
  • NMS-14250: Performance of time series integration layer
  • NMS-14253: Implement "latest" tag with documentation
  • NMS-14259: Make org.opennms.netmgt.collectd.strictInterval true by default
  • NMS-14260: UI: cannot configure requisition
  • NMS-14261: DCB menu items are mislabeled "Configuration Management"
  • NMS-14268: Test flow thresholding
  • NMS-14270: Disable editing of requisition:// URLs in external requisition editor
  • NMS-14271: Omit empty VMware credentials from URL in external requisition editor
  • NMS-14272: Fix requisition http/s path field and hostname validation
  • NMS-14273: Fix hostname validation
  • NMS-14275: DCB: Handle script file missing scenario better
  • NMS-14284: Incorrect validation of requisition name for DNS external requisitions
  • NMS-14285: Main requisition editor incorrectly mentions Requisition Definition
  • NMS-14286: Remove sorting of Schedule Frequency column
  • NMS-14290: Web UI search does not find External Requisitions and Thread Pools
  • NMS-14291: Circle ci caching OIA issue
  • NMS-14292: SCV entry attribute values become literal asterisks after editing in web
  • NMS-14295: OpenNMS build broken for release-30 and develop
  • NMS-14296: Query key/value added in Path input field causes duplicates in URL
  • NMS-14297: DCB: Whenever Sink pushes config, config type should be Sink instead of default
  • NMS-14298: DCB UI : Allow Config type to be more than two not just default/running
  • NMS-14304: Latest DCB UX Updates
  • NMS-14305: VMware type - username/password duplicated in URL
  • NMS-14308: Fix UI yarn.lock conflicts with latest updates
  • NMS-14309: Rename role from ROLE_CONFIG_EDITOR to ROLE_FILESYSTEM_EDITOR
  • NMS-14315: Global search box: gap between input field and dropdown result list
  • NMS-14316: Fix Feather Dialog issue on 0.10.10
  • NMS-14317: DCB Rest API: Update History to filter by config type
  • NMS-14320: External Requisition UI: Obfuscate vmware password in URL
  • NMS-14328: DCB: Unable to decompress the .gz file
  • NMS-14330: Shorten "External Requisitions and Thread Pools" item in New UI Preview
  • NMS-14333: DCB: Wrong cron expression results in no devices in DCB UI
  • NMS-14336: CircleCI : Intermittent failures in horizon-deb-build
  • NMS-14340: External Requisition UI: Advanced cron validation message of by 1
  • PRIS-157: IP Addresses are not validated before generating requisition

by RangerRick at May 31, 2022 05:59 PM

May 25, 2022

Creating Strong Passwords

For obvious reasons I’ve been creating some new passwords lately, and I wanted to share my method for creating strong passwords that are easy to remember yet hard to guess.

Of course, Randall Munroe set the bar with this comic:

xkcd Password Strength comic

It does make a lot of sense, but the method has its critics. Attackers can and do use random word generators which can break such passwords more quickly, even with, say, substituting “3” for “e”, etc.

There is also a good argument to be made that we should all be using password managers that generate long random passwords and not really creating passwords at all.

Then there is the very good idea of using two factor authentication, but that tends to augment passwords more than replace them.

In normal life you have to have at least a few passwords memorized, such as the one to get into your device and one to get into your password manager, so I thought I’d share my technique.

I like music, and I tend to listen to pretty obscure artists. What I do is to think of a random lyric from a song I like and then convert that into a password.

For example, right now I’m listening to the album Wet Tennis by Sofi Tukker. The track that gives me the biggest earworm is “Original Sin” which opens with the lyric:

So I think you’ve got
Something wrong with you
Something’s not right with me, too
It’s not right with me

If I were going to turn that into a password, I would come up with something like:

sItUgswwysnrwm,2inrwm

Looks pretty random, and contains lower case and upper case letters, a number and a special character. At 21 characters it isn’t quite as long as “correcthorsebatterystaple” but you can always add more words from the lyrics if needed.

Just thought I’d throw this out there as it works for me. The only thing I have to remember is not to hum the song while logging in.

by Tarus at May 25, 2022 01:54 PM

May 23, 2022

The Adventure Continues

Last year I wrote about parting ways with the OpenNMS Project and how I was ready for “Act III” of my professional career.

With my future being somewhat of a tabula rasa, I was a bit overwhelmed with choices, so I decided to return to my roots and dust off my consulting LLC. Soon I found myself in the financial sector helping to deploy network monitoring and observability solutions.

I was working with some pretty impressive applications and it was interesting to see the state of the art for monitoring. We’ve come a long way since SNMP. It was engaging and fun work, but all the software was proprietary and I missed the open source aspect.

Recently, Spot Callaway made me aware of an opportunity at Amazon Web Services for an open source evangelist position. Of all the things I’ve done in my career, acting as an evangelist for open source solutions was my favorite thing to do and here was a chance to do it full time. I will admit that Amazon was not the first name that popped into my head when I think “open source” but as I got to learn more about the team and AWS’s open source initiatives, the more interested I became in the position. After I made it through their rather intense interview process and met even more people with whom I’ll be working, it became a job I couldn’t refuse.

So I’m happy to announce that I’m now a Principal Evangelist at AWS, reporting to David Nalley, who, in addition to being a pretty awesome boss is also the current President of the Apache Software Foundation. OpenNMS would not have existed without software from the ASF, and it will be cool to learn, in addition, more about that organization first hand.

My main role will be to work with open source companies as an advocate for them within AWS. The solutions AWS provides can help jumpstart these companies toward profitability by providing the resources they need to be successful and to affordably grow as their needs change. While I am just getting started within the organization and it will take me some time to learn the ropes, I am hoping my own experience in running an open source business will provide a unique insight into issues faced by those companies.

Exciting times, so watch this space as my open source adventures continue.

by Tarus at May 23, 2022 03:22 PM

May 11, 2022

May 2022 Releases – Horizon 29.0.10, Meridians 2022.1.3, 2021.1.15, 2020.1.23, 2019.1.34

In May, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 29.

NOTE: All releases this month received security updates that affect a number of core dependencies. While these dependency changes should not affect how the OpenNMS runtime works, these releases contain a larger than usual number of changes to "plumbing" to facilitate these dependency updates. We strongly recommend that you do more than the usual amount of testing before deploying this update to a production environment.

Meridian Stable Updates

Meridians 2019.1.34, 2020.1.23, and 2021.1.15 contain primarily dependency updates primarily for security improvements.

Additionally, Meridian 2022.1.3 contains a bunch of documentation improvements and a few other bug fixes.

For a list of changes, see the release notes:

Horizon 29.0.10

Release 29.0.10 contains all of the fixes included in Meridian 2022.1.3, plus a few other bug fixes and enhancements.

For a high-level overview of what has changed in Horizon 29, see What’s New in OpenNMS Horizon 29.

For a complete list of changes, see the changelog.

The codename for Horizon 29.0.10 is Duck.

by RangerRick at May 11, 2022 07:07 PM

May 09, 2022

OpenNMS On the Horizon – May 9th, 2022

It's time once again for OpenNMS On the Horizon.

Since last time, we worked on documentation (OIA, upgrades, non-root, BGP session monitor, introductions, Alarmd, criteria API, XML collector, device config backup, event datacollection, new UI), boostrapping Horizon Stream, updating various dependencies, Trapd, OIA, SSH authentication, Cucumber integration tests, asset search, cron-based Quartz config, hardware inventory, and Helm flows.

Github Project Updates

Internals, APIs, and Documentation
  • Gerald, Arthur, and Jason continued to work on dev environment setup for Horizon Stream
  • Bonnie made updates to the OIA documentation
  • I updated our embedded Groovy to v2.5
  • Mark fixed a long-standing typo in the HttpPostMonitor config
  • I updated Vaadin to a newer version
  • Bonnie did more work on upgrade documentation
  • Marcel did some cleanup on the non-root docs
  • Alex worked on some fixes for Trapd startup when the subscriber hasn't registered yet
  • I cleaned up OIA's CircleCI build a bit and branched it for 1.0
  • Chandra updated Device Config Backup to delete old configs when the associated interface is deleted
  • Marcel and Bonnie worked on cleaning up some introduction bits in the docs
  • Mark did more doc updates for Alarmd
  • I worked on validating our Karaf features at compile time
  • Christian worked on an enhancement to the BgpSessionMonitor to allow modifying the OID prefix
  • I upgraded our outdated Jackson v1 dependency
  • I worked on upgrading our Camel and ActiveMQ dependencies
  • Alex updated DCB to send an event when backups are triggered
  • Arthur worked on the start of a cucumber integration test framework for Stream
  • Dustin did some more fixes to his SSH host key authentication work
  • Pushkar worked on documentation for the new multi-constraint feature in the criteria API
  • Mark added some more docs for the XML collector
  • Christian did some documentation updates for DCB
  • Christian worked on a fix for searching assets
  • Freddy added docs for collecting performance data from events
Web, ReST, UI, and Helm
  • Chinh Le worked on thread pool and quartz config improvements in the new UI
  • Scott worked on documentation for some of the new UI features
  • Mike Rose worked on some initial login and alarm view UI in Stream
  • Pushkar did more work on the hardware inventory REST interface
  • Yang Li worked on bringing up a core REST API in Stream
  • Alberto fixed a bug in Helm that could cause some flow data to not be shown if ingress and egress labels don't match
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Freddy Chu
  • Chandra Gorantla
  • Chinh Le
  • Mark Mahacek
  • Bonnie Robinson
  • Patrick Schweizer
  • Mike Rose
  • Scott Theleman
  • Benjamin Reed
  • Alex May
  • Christian Pape
  • Arthur Naseef
  • Gerald Humphries
  • Yang Li
  • Dmitri Herdt
  • Marcel Fuhrmann
  • Alberto Ramos
  • Pushkar Suthar
  • Dustin Frisch
  • Jason Berry

Releases and Roadmap

Upcoming May Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is May 11th, 2022.

We currently expect an update to Horizon 29, plus Meridians 2019 through 2022.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • initial work moving configuration from XML files to the database -- the first config file implemented on top of the new system will be provisiond-configuration.xml
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2023 (Q1 2023)

Meridian 2023 is early in its development cycle, but you can expect it to contain, at the very least, the work that's going into Horizon 30.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • ALEC-103: Spike: Improve on DBSCAN + Hellinger Distance: Using Key Customer Data and Compare results to Basic DBSCAN
  • HELM-307: Grafana Location Dashboard - Performance
  • HELM-319: Grafana Location Dashboard - Entity
  • HELM-320: FlowDS's combineIngressEgress transform loses the first query response result
  • NMS-13696: Migrate geographical maps Discourse article to docs
  • NMS-13973: Document how to backup system before upgrade
  • NMS-14050: Review wording of the new Provisiond UI
  • NMS-14051: Update existing documentation related to provisiond xml file
  • NMS-14085: Provisiond Fails to Start when wrong data is successfully POSTed via REST to hardwareInventory endpoint
  • NMS-14142: Invalid node Foreign ID not checked during provisioning resulting in various RRD graphing problems
  • NMS-14159: Typo in HttpPostMonitor parameters
  • NMS-14189: Document new UI features in H30
  • NMS-14204: Add tag for UI linked help
  • NMS-14208: Upgrade groovy-all dependency
  • NMS-14214: DCB: Handle Archival of backups
  • NMS-14238: Document multi constraint parameter feature addition
  • NMS-14239: Fixing new UI list log & etc fail due to symbolic link
  • NMS-14252: Upgrade jackson-mapper-asl dependency
  • NMS-14256: Expand XmlCollector documented parameters
  • NMS-14258: Restructure Collector docs file path

by RangerRick at May 09, 2022 09:05 PM

“Run-of-the-Mill Person”

I just noticed that my Wikipedia page has been deleted (the old version is still on the Internet Archive).

I’m not sure how I feel about this. When I was first made aware of its existence oh so many years ago I was both flattered and a little embarrassed, mainly because I didn’t think I rated a page on Wikipedia. But then I got to thinking that, hey, pretty much anyone should be able to have a page on Wikipedia as long as it adheres to their format guidelines. It’s not like it takes up much space, and as long as the person is verifiable as being a real person, why not?

I am certain I would have been okay with my page being deleted soon after it was created, but once you get used to having something, earned or not, there is a strong psychological reaction to having it taken away. From what I can tell the page was created in 2010, so it had been around for nearly 12 years with no one complaining.

The most hurtful thing was a comment about the deletion from EdwardX from London:

Nothing cited in the article counts towards WP:GNG, and I can find nothing better online. Run-of-the-mill person.

Really? Was the “Run-of-the-mill person” comment really necessary? (grin)

I’m still happy about what I was able to accomplish with OpenNMS and building the community around it, even if it was run-of-the-mill, and I plan to promote open source and open source companies for the remainder of my career, even if that isn’t Wikipedia-worthy.

by Tarus at May 09, 2022 12:19 PM

May 02, 2022

OpenNMS On the Horizon – May 2nd, 2022

It's time once again for OpenNMS On the Horizon.

Since last time, we worked on documentation (provisiond, upgrading, HTTPS config, external auth, notification commands, OSGi development), the OpenNMS Integration API, secure credentials vault, logging, device config backup (SCV support, metadata handling, SSH auth), Horizon Stream, Keycloak auth, arm64 Docker containers for Horizon and Setinel, Trapd and the Twin API, Skaffold Kubernetes deployment, Helm node filtering, SCV web UI, and cron expression handling in the new UI.

Github Project Updates

Internals, APIs, and Documentation
  • I updated OIA and branched for OIA 1.0
  • Bonnie did more work on provisiond and upgrade documentation
  • Patrick continued his work to expose the secure credentials vault to OIA
  • Gerald worked on using Protobuf and Kafka as a proof-of-concept Eventd replacement
  • Mark worked on HTTPS, external auth, and notification commands documentation
  • Chandra cleaned up the container bridge logging to be less chatty
  • Chandra updated device config backup APIs for persistence config
  • Arthur worked on example Horizon Stream docker-compose configs
  • Yang Li worked on role-based auth using Keycloak in Stream
  • Christian added support for disabling DCB for a device in requisition metadata
  • I worked on cleaning up some of our xerces/XML dependencies
  • Freddy worked to wrap up the arm64 branch for Horizon and Sentinel
  • Chandra did more work on integrating metadata handling and SCV
  • Dustin worked on support for recursive parsing of metadata expressions
  • Dustin did more work on SSH host key authentication for DCB
  • Chandra wrote some developer documentation on OSGi and Karaf
  • Arthur added the web detector to Horizon Stream
  • Chandra improved Trapd startup to use the twin subscriber without blocking on it
  • Gerald worked on a basic Skaffold-based workflow for deploying Stream locally using Kubernetes
Web, ReST, UI, and Helm
  • Alexander worked on an HTTPS smoke test
  • Alberto worked on wrapping up some of his node filter Helm work
  • Mike worked on adding SCV support to the new UI
  • Chandra updated the SCV REST service to handle masked credentials cleanly
  • Chinh Le worked on cron expression parsing
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Gerald Humphries
  • Benjamin Reed
  • Chandra Gorantla
  • Chinh Le
  • Bonnie Robinson
  • Alberto Ramos
  • Mike Rose
  • Alexander Chadfield
  • Yang Li
  • Marcel Fuhrmann
  • Arthur Naseef
  • Dustin Frisch
  • Mark Mahacek
  • Freddy Chu
  • Alex May
  • Christian Pape
  • Patrick Schweizer

Releases and Roadmap

Upcoming May Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is May 11th, 2022.

We currently expect the first release of Horizon 30, plus Meridians 2019 through 2022.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • initial work moving configuration from XML files to the database -- the first config file implemented on top of the new system will be provisiond-configuration.xml
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2023 (Q1 2023)

Meridian 2023 is early in its development cycle, but you can expect it to contain, at the very least, the work that's going into Horizon 30.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • ALEC-102: Improve on DBSCAN + Hellinger Distance: Dummy Data Hellinger Distance Test
  • HELM-318: Grafana Location Dashboard - Flows
  • NMS-14118: Support Host Key verification
  • NMS-14143: DCB: trigger backup via REST should block
  • NMS-14145: DCB: Allow to disable scheduling
  • NMS-14155: DCB: Add support for SCV retrieval through Metadata API
  • NMS-14176: DCB: Getting the device config also persists [RFC]
  • NMS-14184: Grafana dashboard box links are no longer valid in Grafana 8.4
  • NMS-14192: Dependabot: update Vaadin to the latest 8.x
  • NMS-14205: Add UI Components for SCV
  • NMS-14206: Restrict logging on org.opennms.container.web.bridge.rest
  • NMS-14218: SCV: Masked credentials should be ignored in update
  • NMS-14234: Add OpenNMS/OSGi HowTo document
  • NMS-14236: Upgrade to feather 0.10.8 & resolve TS issues

by RangerRick at May 02, 2022 09:12 PM

April 28, 2022

International Girls in ICT Day 2022: Access and Safety

We invited OpenNMS employees to share their own experiences in ICT as women, non-binary, those identifying as female, or allies. Read their stories.

International Girls in ICT Day celebrates the importance of girls and women in the information and communications technology sector. Since 2001, the International Telecommunication Union (ITU), a United Nations agency, has sponsored this event. The theme for 2022 is "access and safety", still a significant issue for many girls, women, and non-binary folks in the technology space.

Diversity in STEM

Now, more than ever, technology organizations realize the value of diversity, and are taking steps to address under-representation of different groups, including women and girls. Despite these efforts, women hold only 16% of engineering roles and 27% of computing roles in companies in the U.S.1

Numerous factors contribute to this imbalance, but the most cited explanation is the relatively low number of girls and women studying STEM (science, technology, engineering, and mathematics). While governments, educators, and other organizations encourage girls and women to pursue STEM activities, we also need to work to make STEM education and workplaces welcoming and safe. We will know we have succeeded when girls and women are no longer seen as exceptions in these fields.

Beyond STEM

It is essential to have more girls and women engineers and developers, not just for gender equity, but to benefit from the different perspectives any under-represented group brings to the table. However, by focusing exclusively on STEM, we fail to recognize the contributions from women in ICT who bring other skills.

Technology is worthless if it doesn’t connect with people. Software is more than just writing code; hardware is more than just building a device. Whether the technology is sold or shared, someone needs to promote it, document it, package it, brand it, ship it, provide support for it, research and plan improvements to it. Marketing, graphic design, writing, sales, customer support, and user experience are just a few of the roles in ICT where women have better representation.

ICT not only needs to welcome girls, women, and non-binary folks in STEM, but also celebrate the existing contributions from those with an arts and social sciences background.

1 2019 U.S. Bureau of Labor Statistics cited in Resetting Tech Culture, a research report by Accenture and Girls Who Code.

by Bonnie Robinson at April 28, 2022 06:16 PM

April 25, 2022

OpenNMS On the Horizon – April 25th, 2022

It's time once again for OpenNMS On the Horizon.

Since last time, we worked on documentation (alarms, collection, device config backup, provisioning), the secure credentials vault (OIA and metadata support), Karaf dependency cleanup, wrapping up device config backup features, non-root fixes, Horizon Stream, Flows, dependency updates, Datachoices, Thresholding metadata, Helm filters, REST, and OpenNMS.js.

Github Project Updates

Internals, APIs, and Documentation
  • Bonnie worked on device config backup UI and provisioning documentation
  • Patrick did some work on exposing the secure credentials vault to OIA plugins
  • Chandra worked on changes to the JCEKS implementation of SCV
  • I continued continuing my work on improving our spring (and other) dependencies in Karaf
  • Dustin worked on DCB end-to-end tests
  • Alex made some improvements to requisition foreign-source name validation
  • Chandra did some fixes to the DCB monitor's behavior
  • I fixed a few issues with validation of non-root access during install
  • Dustin added support for SSH host keys in the DCB SSH code
  • Jesse removed the enforcer plugin from the OIA plugin archetype
  • Gerald worked on a PoC to replace Eventd's transport with Kafka streams
  • Christian added some extra service-binding validation to the DCB service
  • Christian did more work on ingressPhysicalInterface/egressPhysicalInterface support in flows
  • Chandra worked on metadata-handling for SCV data
  • I worked on upgrading Vaadin to 8.14.x
  • Christian worked on file suffix handling in DCB
  • Jason worked on figuring out a good dev environment config for horizon stream and kubernetes
  • Mark cleaned up some Alarmd, collection, and HTTPS documentation
  • Yang Li and Arthur worked on Keycloak integration in horizon stream
  • Chandra added support for blocking requests in DCB
  • Freddy did more work on arm64 image support for Horizon and Sentinel
  • Freddy worked on some changes to thresholding support for metadata
  • Jesse worked on updating the datachoices plugin to support sending additional statistics relating to situations, locations, minion, sentinel, and Karaf features
Web, ReST, UI, and Helm
  • Yang Li worked on prototyping graphql support in horizon stream
  • Mike did some more polish and improvements to the DCB vue UI
  • Alberto continued his work on wildcard support in certain types of Helm filters
  • Scott made some improvements to the DCB REST API (and the DAO serving it)
  • Pushkar did more work on validation of hardware inventory REST input
  • I cleaned up a bunch of dependencies in OpenNMS.js and Helm
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Jesse White
  • Chandra Gorantla
  • Freddy Chu
  • Pushkar Suthar
  • Mark Mahacek
  • Arthur Naseef
  • Benjamin Reed
  • Patrick Schweizer
  • Mike Rose
  • Bonnie Robinson
  • Alex May
  • Jason Berry
  • Yang Li
  • Alberto Ramos
  • Gerald Humphries
  • Scott Theleman
  • Alexander Chadfield
  • Maxim Brener
  • Christian Pape
  • Dustin Frisch

Releases and Roadmap

Upcoming May Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is May 11th, 2022.

We currently expect the first release of Horizon 30, plus Meridians 2019 through 2022.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • initial work moving configuration from XML files to the database -- the first config file implemented on top of the new system will be provisiond-configuration.xml
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2023 (Q1 2023)

Meridian 2023 is early in its development cycle, but you can expect it to contain, at the very least, the work that's going into Horizon 30.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • ALEC-100: Present Current Useful Telemetry Metrics and Gap Analysis
  • HELM-309: Grafana Datasource expressions - Performance
  • NMS-13968: Retroactively tie in the endpoints
  • NMS-14005: Multi parameter constraints in the rules engine implementation
  • NMS-14012: Add End-to-End Integration Test for Device Config Monitor
  • NMS-14032: install script fails if an OpenNMS directory contains root-owned lost+found directory
  • NMS-14121: Support new role for viewing and performing manual Device Backups
  • NMS-14127: DCB: Verify that service is actually bound
  • NMS-14131: DCB: UI Documentation
  • NMS-14134: CVE-2022-22965: Spring RCE in Data Bindings
  • NMS-14144: DCB: filename suffix should be globally unique
  • NMS-14156: DCB: Expecting dot before filename suffix
  • NMS-14163: DCB: Monitor should return poll status based on last retrieval
  • NMS-14167: DCB: List devices that never has done a backup
  • NMS-14169: IPFIX: Also support ingressPhysicalInterface and egressPhysicalInterface for input and output ifIndex
  • NMS-14170: DCB: add messages in UI to indicate the lack of the new DCB role
  • NMS-14173: Add SCV Rest API
  • NMS-14175: DCB: New UI display for Config Type
  • NMS-14182: Fix formatting in alarmd documentation
  • NMS-14190: Fix new UI back button test failure
  • NMS-14200: DCB: Configuration Management from Main menu lands on Nodes page in New UI

by RangerRick at April 25, 2022 07:37 PM

April 18, 2022

OpenNMS On the Horizon – April 18th, 2022

It's time once again for OpenNMS On the Horizon.

Since last time, we worked on documentation (provisioning, capabilities, device config backup UI, ticketer), a number of device config backup changes (roles, filename and suffix handling, scheduling, authentication, REST), Netflow 9 parsing, Keycloak, time-series tag matching, ID types, HTTPS smoke tests, OIA, hardware inventory, notification editing, surveillance dashboards, Helm filtering, and topology in the new UI.

Github Project Updates

Internals, APIs, and Documentation
  • Bonnie did more work on provisioning documentation
  • Mark made some improvements to the documentation on capabilities in the deployment guide
  • Christian added a role for device config backup
  • I worked on cleaning up our Spring dependency-handling in Karaf
  • Bonnie made some updates to the device config backup documentation
  • Christian added parsing of ingressPhysicalInterface and egressPhysicalInterface to the Netflow 9 parser
  • Christian made some changes to the way unique filenames and suffixes are handled in DCB
  • Mark did some cleanups to the ticketer documentation
  • Bonnie did more work on documenting the DCB UI
  • Arthur worked on Keycloak support in Stream
  • Freddy did more work on doing datacollection from events
  • Dustin fixed some issues with DCB scheduling
  • Chandra and Dustin worked on Secure Credentials Vault support for DCB authentication
  • Patrick did some more fixes to tag matching in the time-series API
  • Yang Li worked on converting IDs to be Longs in Stream
  • Alexander worked on fixes for issue with smoke tests running in HTTPS mode
  • Freddy worked on updating the handling of thresholding definitions in OIA
Web, ReST, UI, and Helm
  • Pushkar worked on fixing a bug with POSTing bad data to the hardware inventory REST API
  • Christian cleaned up some input-handling in the notification path editor
  • Christian fixed an issue with availability calculation in the surveillance dashboard
  • Alberto worked on some filtering improvements in Helm
  • Scott fixed an issue with device counts in the DCB REST interface
  • Mike did more work on topology in the new UI
  • Chinh Le fixed an issue with handling of spaces in foreign source names in the new UI
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Freddy Chu
  • Chinh Le
  • Alexander Chadfield
  • Marcel Fuhrmann
  • Patrick Schweizer
  • Chandra Gorantla
  • Bonnie Robinson
  • Mike Rose
  • Dustin Frisch
  • Benjamin Reed
  • Mark Mahacek
  • Alberto Ramos
  • Christian Pape
  • Scott Theleman
  • Pushkar Suthar

Releases and Roadmap

April 2022 Releases

In April, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 29.

Meridian Stable Updates

Meridians 2019.1.33 and 2020.1.22 contained a few targeted security fixes and enhancements.

On top of those changes, Meridian 2021.1.14 includes additional documentation updates and a few more small bug fixes.

Meridian 2022.1.2 contains more documentation updates, plus a few fixes for running as non-root, XML processing dependency cleanups, and a few other minor improvements.

For a list of changes, see the release notes:

Horizon 29.0.9

Release 29.0.9 contains all of the fixes included in Meridian 2022.1.2.

For a high-level overview of what has changed in Horizon 29, see What’s New in OpenNMS Horizon 29.

For a complete list of changes, see the changelog.

The codename for Horizon 29.0.9 is Kiwi.

Upcoming May Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is May 11th, 2022.

We currently expect the first release of Horizon 30, plus Meridians 2019 through 2022.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • initial work moving configuration from XML files to the database -- the first config file implemented on top of the new system will be provisiond-configuration.xml
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2023 (Q1 2023)

Meridian 2023 is early in its development cycle, but you can expect it to contain, at the very least, the work that's going into Horizon 30.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-311: Add a transform to swap Ingress and Egress
  • NMS-13443: Jira Cloud Support
  • NMS-13802: DCB - Document how to use the polling packages and the requisition to configure backups
  • NMS-13992: Docker usage documentation is out of date
  • NMS-14048: Node availability > 100% in the dashboard
  • NMS-14111: Destination Path Edit Button fails when Name field is empty
  • NMS-14130: Support for netflowv9 fields ingressPhysicalInterface & egressPhysicalInterface
  • NMS-14146: DCB: Backup is triggered after provisioning
  • NMS-14162: Update docs for binding ports <1024
  • NMS-14165: DCB: Display Device Count for queries
  • NMS-14166: Merge feature/device-config back to develop
  • NMS-14168: DCB: Backup is always triggered on minion
  • NMS-14172: Cleanup Ticketer docs formatting

by RangerRick at April 18, 2022 09:21 PM

April 13, 2022

April 2022 Releases – Horizon 29.0.9, Meridians 2022.1.2, 2021.1.14, 2020.1.22, 2019.1.33

In April, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 29.

Meridian Stable Updates

Meridians 2019.1.33 and 2020.1.22 contained a few targeted security fixes and enhancements.

On top of those changes, Meridian 2021.1.14 includes additional documentation updates and a few more small bug fixes.

Meridian 2022.1.2 contains more documentation updates, plus a few fixes for running as non-root, XML processing dependency cleanups, and a few other minor improvements.

For a list of changes, see the release notes:

Horizon 29.0.9

Release 29.0.9 contains all of the fixes included in Meridian 2022.1.2.

For a high-level overview of what has changed in Horizon 29, see What’s New in OpenNMS Horizon 29.

For a complete list of changes, see the changelog.

The codename for Horizon 29.0.9 is Kiwi.

by RangerRick at April 13, 2022 07:02 PM

April 12, 2022

OpenNMS On the Horizon – April 11th, 2022

It's time once again for OpenNMS On the Horizon.

Since last time, we did more work on documentation (upgrade/backup/restore, provisioning UI, REST), device config backup (tests, metadata, monitor status, UI), REST API improvements, arm Docker images, dependency version cleanups, criteria API, license cleanup, Spring dependencies, flow tracing, JICMP, minion/sentinel non-root improvements, datacollection from events, JIRA client updates, timeseries tag matching, JavaScript dependency updates, topology UI, wildcard resources in Helm perf-ds, and cron expression editing.

Github Project Updates

Internals, APIs, and Documentation
  • Chandra worked on support for device config backup (DCB) in OSGi
  • I fixed an issue with a circular dependency between applications and monitored services in the REST API
  • Chandra fixed up some testing issues for DCB
  • Bonnie and Marcel worked on upgrade/backup/restore documentation
  • Freddy worked on arm docker image support for Horizon and Sentinel
  • Dustin cleaned up some metadata handling in DCB
  • I worked on cleaning up a bunch of mismatched dependency versions
  • Pushkar made improvements to the criteria API to allow for multiple queries ("multiAnd") on joined many-to-many tables like event parameters
  • I moved the old "request tracker" code out of the archived opennms-lib repo and back into OpenNMS core
  • I worked on cleaning up our Spring dependencies
  • Dustin worked on adding some tracing to flow handling
  • I released JICMP 3.0.0 (now requires Java 8, re-licensed to LGPLv3, publish API docs)
  • Alex fixed Minion and Sentinel to use systemd capabilities and run as opennms by default
  • Freddy worked more on supporting collecting data from events
  • Chandra made some fixes to the jira client dependencies
  • Patrick and Jesse worked on updating the timeseries tag matchers to match node resources
  • Chandra changed the DCB monitor to return up/down status based on the last retrieval attempt
Web, ReST, UI, and Helm
  • Mike worked on a bunch of improvements and feedback for the device config backup UI
  • I fixed/updated a bunch of javascript dependencies in the OpenNMS core and OpenNMS.js
  • Mike did more topology work in the new UI
  • Chinh Le did some dependency cleanup in the new UI
  • Alberto worked on basic support for using wildcards in resources in the Helm performance datasource
  • Alberto worked on supporting swapping ingress and egress in Helm flows for weird devices
  • Scott worked on back- and frontend improvements for querying DCB configs
  • Alex fixed rendering availability percentages in the new UI
  • Chinh Le worked on cron expression validation in the new UI
  • Bonnie worked on provisioning UI wording and documentation
  • Dustin made some changes to the DCB event REST model
  • Pushkar worked on validation of hardware inventory REST data
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Jesse White
  • Patrick Schweizer
  • Chandra Gorantla
  • Bonnie Robinson
  • Freddy Chu
  • Chinh Le
  • Alexander Chadfield
  • Alex May
  • Pushkar Suthar
  • Christian Pape
  • Mike Rose
  • Alberto Ramos
  • Scott Theleman
  • Dustin Frisch
  • Marcel Fuhrmann
  • Mark Mahacek
  • Stefan Wachter
  • Maxim Brener

Releases and Roadmap

Upcoming April Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is April 13th, 2022.

We currently expect an update to Horizon 29, plus Meridians 2019 through 2022.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • initial work moving configuration from XML files to the database -- the first config file implemented on top of the new system will be provisiond-configuration.xml
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2022 (Q1 2022)

Meridian 2022 binaries are ready and we are prepping for release on schedule, at the end of this month.

If you want a taste of what's coming, the documentation is available on docs.opennms.com.

Meridian 2022 is based on Horizon 29.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-305: Helm's Flow datasource cannot filter "NaN" results, breaking Grafana reduce expressions
  • NMS-11747: Documentation for all pollers misses RRD config parameter
  • NMS-13833: Class not found exception in web.log for the GeocoderServiceManager
  • NMS-13946: Investigate CircleCI storage usage
  • NMS-13972: Document housekeeping tasks before upgrade
  • NMS-14013: Add introduction for Device Config Backup feature
  • NMS-14016: Can't set capabilities in Minion systemd unit
  • NMS-14046: DCB Rest API: Ensure various sorting/filtering criteria work
  • NMS-14086: Resource Graphs disfunction
  • NMS-14089: DCB: Create UI for comparing 2 backup configurations
  • NMS-14105: clean up JAXB dependencies
  • NMS-14107: DeviceConfig monitor fails to load on OpenNMS
  • NMS-14110: DCB UI Changes based on latest Rest API
  • NMS-14112: DCB Rest API Updates
  • NMS-14114: Availability percentages show too many decimals
  • NMS-14115: Broken links in docs
  • NMS-14116: Update Monitor/Collector Registry to not complete Future with timeout
  • NMS-14117: Fix for NMS-13887 did not make it to Core
  • NMS-14123: Sentinel debian package fail to install
  • NMS-14126: Upgrade FeatherDS to v0.10.2
  • NMS-14141: DCB: UI changes to align with latest Rest API
  • NMS-14147: DCB: API endpoint renaming
  • NMS-14151: DCB: Rest API and UI: Fixes to device backup
  • NMS-14153: DCB: Multiple Device Backup from UI/Rest
  • NMS-14157: Update all new UI packages to latest versions
  • NMS-14164: Fix flaky test HeartbeatConsumerIT

by RangerRick at April 12, 2022 01:43 PM

April 01, 2022

OpenNMS + SpringShell CVE-2022-22965

OpenNMS and the Spring Core Remote Code Execution Vulnerability (SpringShell) CVE-2022-22965

A serious remote code execution (RCE) vulnerability exists in some versions of the Spring Framework, which is used by OpenNMS Meridian and Horizon. OpenNMS Meridian and Horizon are not known to be vulnerable because the published exploit for this RCE requires:

All Attributes Required for Exploit Use by OpenNMS Meridian/Horizon Vulnerable?
JDK 9 or higher JDK 11+ Yes
Apache Tomcat as the Servlet container Not applicable. OpenNMS uses Jetty No
Packaged as WAR OpenNMS uses WAR files (unpacked) Unlikely
spring-webmvc or spring-webflux dependency OpenNMS uses spring-webmvc Yes

OpenNMS Meridian and Horizon are not known to be vulnerable because they do not have all of the attributes required for exploitation, as confirmed by the simple test documented here. However, Spring is at the core of OpenNMS, and the affected introspection cache is at the core of Spring, so it is likely that new attack vectors for the exploit will be found. We are working proactively to update Meridian and Horizon's use of the Spring Framework to reduce risk. We will post updates as they become available.

Recommendations

  • Upgrade to Meridian 2022 or Horizon 29, which now run without "root" (administrator) privileges, reducing the risk impact of an RCE attack.
  • Watch the OpenNMS blog and Discourse posts for updates on this issue.

References

by Jess at April 01, 2022 10:17 PM

March 31, 2022

The OpenNMS Group Releases OpenNMS Meridian 2022 with Enhanced Network Monitoring and Security Capabilities

Updates to Meridian 2022 underscore OpenNMS’ commitment to security and investment in ongoing penetration testing efforts

RALEIGH, N.C. – March 31, 2022 – The OpenNMS Group, Inc., a subsidiary of NantHealth, Inc. (NASDAQ: NH), today announced the release of OpenNMS Meridian 2022. With this next major release, the fully open source Meridian product, which is the optimized and stable version of the OpenNMS platform curated by The OpenNMS Group for production environments, now features enhanced security among other improvements.

“As a leading open source network monitoring platform leveraged by some of the largest companies across all industry sectors, OpenNMS is dedicated to delivering a first-class enterprise solution that can be securely deployed to meet the security and compliance requirements these organizations demand,” said David Hustace, CEO of The OpenNMS Group.

“Our investment in cybersecurity risk assessments and penetration testing for our products further demonstrates this commitment. We are proud to release this new version of Meridian and continue our mission of providing best-in-class, open source network monitoring for our customers.”

Major updates to Meridian include:

  • Improved security by removing requirements for privileged access. Running as a non-root user limits the potential access that malicious code can gain to system resources, thereby reducing risk in the event of a system compromise.
  • Improved analytics through enhanced flow processing. Updates to the NetFlow component allow users to add business metadata to flow records. This update also enables Meridian 2022 to classify network conversation data at speeds up to 30x faster than in previous releases.
  • Simplified Minion communication. Minions now communicate with the Meridian core simply via the message broker, no longer requiring access to the core REST API. This single communication simplifies securing the Meridian platform and supporting firewalls policies.
  • Enhanced geolocation with IP addresses. Users can now specify and/or query a node's location using its IP address with the new GeoIP provisioning adapter.
  • An expanded set of REST APIs. Users can integrate Meridian with their internal systems and customize it to fit their business needs and goals. APIs have full documentation in compliance with OpenAPI/Swagger.

Meridian is a subscription-based platform that includes the most stable and secure features from Horizon, OpenNMS’ community-driven distribution. The platform features inventory, performance, fault, and traffic management, business service monitoring, remote data collection, BGP Monitoring Protocol (BMP) support, and application perspective monitoring. Known for its reliability, adaptability, and scalability, Meridian allows users to customize the platform so it fits the unique needs of their business. A new major version of Meridian is released annually and updates are issued monthly, to maximize the platform’s value and minimize the effort required to maintain it.

OpenNMS has adopted penetration testing as a key aspect of our development and release processes for both the current products and forthcoming cloud services. In addition, The OpenNMS Group is improving its processes to align with the ISO 27001 security framework. This will help to ensure that the appropriate people, processes, and technologies are in place to assess cybersecurity risks and implement the measures necessary to protect, remediate, or recover from those risk events. The OpenNMS Group is also working towards becoming part of the Common Vulnerabilities and Exposures (CVE) system’s Numbering Authorities (CNA) program to augment its CVE reporting capabilities.

For more information about OpenNMS Meridian 2022, please visit: https://www.opennms.com/meridian-2022/.

About OpenNMS

Based in Morrisville, NC, OpenNMS provides a highly reliable, scalable and comprehensive fault, performance and traffic monitoring solution that easily integrates with business applications and workflows to monitor and visualize everything in a network. The OpenNMS platform monitors some of the largest networks in existence, covering the healthcare, technology, finance, government, education, retail and industrial sectors, many with tens of thousands of networked devices. OpenNMS users include five of the top twenty companies on the Fortune 100, as well as multiple large and multi-state health providers and one of the largest electronic medical record providers in the United States. For more information, visit https://www.opennms.com/.

About NantHealth, Inc.

NantHealth, a member of the NantWorks ecosystem of companies, provides enterprise solutions that help businesses transform complex data into actionable insights. By offering efficient ways to move, interpret and visualize complex and highly sensitive information, NantHealth enables customers in healthcare, life sciences, logistics, telecommunications and other industries to automate, understand and act on data while keeping it secure and scalable. NantHealth’s product portfolio comprises the latest technology in payer/provider collaboration platforms for real-time coverage decision support (Eviti and NaviNet), and data solutions that provide multi-data analysis, reporting and professional services offerings (Quadris). The OpenNMS Group, Inc., a NantHealth subsidiary, helps businesses monitor and manage network health and performance. For more information, visit nanthealth.com, follow us on Twitter, Facebook, LinkedIn and YouTube, and subscribe to our blog.

NantHealth Forward Looking Statement

This news release contains certain statements of a forward-looking nature relating to future events or future business performance. Forward-looking statements can be identified by the words "expects," "anticipates," "believes," "intends," "estimates," "plans," "will," "outlook" and similar expressions. Forward-looking statements are based on management's current plans, estimates, assumptions and projections, and speak only as of the date they are made. Risks and uncertainties include, but are not limited to: our ability to successfully integrate a complex learning system to address a wide range of healthcare issues; our ability to successfully amass the requisite data to achieve maximum network effects; appropriately allocating financial and human resources across a broad array of product and service offerings; raising additional capital as necessary to fund our operations; our ability to grow the market for our software and data solutions; successfully enhancing our software and data solutions to achieve market acceptance and keep pace with technological developments; customer concentration; competition; security breaches; bandwidth limitations; our ability to integrate The OpenNMS Group, Inc. into our operations; our use and distribution of open source software; our ability to obtain necessary regulatory approvals, certifications and licenses; dependence upon senior management; the need to comply with and meet applicable laws and regulations; unexpected adverse events; and anticipated cost savings. We undertake no obligation to update any forward-looking statement in light of new information or future events, except as otherwise required by law. Forward-looking statements involve inherent risks and uncertainties, most of which are difficult to predict and are generally beyond our control. Actual results or outcomes may differ materially from those implied by the forward-looking statements as a result of the impact of a number of factors, many of which are discussed in more detail in our reports filed with the Securities and Exchange Commission.

Media Contact

Erica Anderson
Offleash PR for OpenNMS
opennms@offleashpr.com

by Jess at March 31, 2022 09:00 AM

March 28, 2022

OpenNMS On the Horizon – March 28th, 2022

It's time once again for OpenNMS On the Horizon.

Since last time, we worked on newts, detector, OpenDaylight, build, provisioning handler, geomap, and JICMP docs, plus maven optimizations, flapping tests, device config backup improvements, installation bugs, datacollection from events, event parm querying, Scriptd, octet-string handling for traps, JAXB dependencies, SNMP community string handling, arm64 Horizon, new UI updates, the Helm flow datasource, and HTTP pre-auth.

Github Project Updates

Internals, APIs, and Documentation
  • I did a bunch of cleanup in our <repository> entries to (hopefully) do less work finding dependencies during builds
  • I worked on fixing some flapping tests
  • Mark updated some Newts and detector documentation
  • Chandra worked on some improvements to device config backup scripting
  • Dustin did more work on device config backup config in the poller config (whew!)
  • Christian fixed an issue with permissions on the log directory
  • Dustin cleaned up the device config backup metadata types
  • Bonnie worked on documentation for OpenDaylight, building from source, and provisioning handlers
  • Freddy continued his work implementing datacollection on incoming event data
  • Pushkar worked on making it possible to query events based on multiple parms
  • Marked fixed the links printed out in Debian and RPM postinstalls
  • Zoë's worked on making Scriptd not register an event processor if it has an empty config
  • Alex fixed an upgrade issue with the data directory on Debian
  • Marcel worked on geomap documentation
  • Chandra cleaned up device config backup test dependencies
  • Alex cleaned up some escaping in traps when handling octet-strings
  • I worked on cleaning up our JAXB dependencies using the maven-enforcer-plugin
  • I updated RANCID to be LGPLv3 and fixed our dependencies to use it
  • Christian worked on end-to-end tests of the device config backup feature
  • I worked on documentation for JICMP, as well as fixing the CI pipeline
  • Mark cleaned up a bunch of common parameter stuff in the docs
  • Alex fixed a bug in community string handling in the SNMP4J strategy
  • I fixed some weird dependency stuff in the remote poller in older foundation branches
  • Freddy worked on converting the Horizon Docker container to use our newer deploy base so it can support native arm64 images
Web, ReST, UI, and Helm
  • Mike added some test framework stuff for the new UI
  • Alex updated the MailerServlet to use java APIs under the hood rather than wrapping an external binary
  • Mike did more work on fleshing out the device config backup web UI
  • Alberto worked on the handling of null values in the Helm flow datasource
  • I cleaned up some dependencies in some of our javascript-based projects
  • Chinh Le worked on various cleanups in the new UI
  • Jesse wrapped up his changes to support honoring pre-authorization headers
  • Chinh Le updated the UI to the latest Feather
  • Alberto fixed an issue with URL handling in the graph UI
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Mike Rose
  • Alex May
  • Freddy Chu
  • Stefan Wachter
  • Christian Pape
  • Pushkar Suthar
  • Chinh Le
  • Alberto Ramos
  • Jesse White
  • Bonnie Robinson
  • Scott Theleman
  • Mark Mahacek
  • Chandra Gorantla
  • Ronny Trommer
  • Dustin Frisch
  • Marcel Fuhrmann
  • Zoë Knox
  • Maxim Brener
  • Benjamin Reed

Releases and Roadmap

March Releases

In March, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 29. (Twice!)

Meridian Stable Updates

Meridians 2019.1.31 and 2020.1.20 contain a number of bug fixes and small security updates.

On top of those changes, Meridian 2021.1.12 includes few documentation updates.

Later in the month, we made another release to fix a regression in graph viewing.

For a list of changes, see the release notes:

Horizon 29

Release 29.0.7 contains all of the fixes included in the Meridian March stable releases, as well as a number of additional bugfixes and enhancements, as well as an improvement to support pre-auth HTTP headers.

For a high-level overview of what has changed in Horizon 29, see What’s New in OpenNMS Horizon 29.

For a complete list of changes, see the 29.0.7 and 29.0.8 changelogs.

The codename for Horizon 29.0.7 is Pileated Woodpecker, and the codename for 29.0.8 is Chickadee.

Upcoming April Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is April 13th, 2022.

We currently expect an update to Horizon 29, plus Meridians 2019 through 2022.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.
It is currently expected to be released in May.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • initial work moving configuration from XML files to the database -- the first config file implemented on top of the new system will be provisiond-configuration.xml
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2022 (Q1 2022)

Meridian 2022 binaries are ready and we are prepping for release on schedule, at the end of this month.

If you want a taste of what's coming, the documentation is available on docs.opennms.com.

Meridian 2022 is based on Horizon 29.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • JICMP-26: Create Antora documentation for JICMP
  • NMS-13805: Validate IP Addresses when adding/updating nodes via REST API
  • NMS-13806: Improve handling of invalid IP addresses during provisioning cycle
  • NMS-13888: Trap parameter values are incorrectly saved in the database
  • NMS-13925: End to End Poller test with Sample device
  • NMS-13951: Create alarm when device config backup fails
  • NMS-14000: Upgrading opennms ignores RUNAS when setting ownership on logs directory
  • NMS-14002: Resolve SonarCloud High priority Security Hotspots
  • NMS-14015: Switch to using a java e-mail library instead of system mail
  • NMS-14019: Minion installation from Debian packages failed with missing dir /var/lib/minion/data/tmp
  • NMS-14040: Fix issues on DeviceConfig Rest Service
  • NMS-14045: Scriptd helpers ignore community setting
  • NMS-14049: Unify and streamline metadata and service handling
  • NMS-14050: Review wording of the new Provisiond UI
  • NMS-14053: Wrong wiki URL in debian installer
  • NMS-14057: OpenNMS points to the wrong URL when trying to generate graphs
  • NMS-14059: Add support for pre-authorization via HTTP header (to be used with pre-authentication)
  • NMS-14061: Revisit error/exception handling in SshScriptingServiceImpl
  • NMS-14062: Update inline help text for new provisiond UI
  • NMS-14065: Document missing handlers
  • NMS-14066: Document HTTP and HTTPS handlers
  • NMS-14069: Always retrieve script from file instead of inline script
  • NMS-14073: Expand newts converter documentation
  • NMS-14074: Add TcpDetector documentation
  • NMS-14077: Device Config Retrieval fails if TFTP Server is getting reopened
  • NMS-14080: Incorporate Device Config Demo feedback
  • NMS-14081: DCB: UI fixes as per Demo Feedback
  • NMS-14082: DCB: Return config data as text in Rest API
  • NMS-14088: Build from source documentation needs a minor correction
  • NMS-14090: Vue UI - Upgrade all packaged to latest, introduce auto-imports
  • NMS-14091: Misspelling in SystemExecuteMonitor error text
  • NMS-14093: relicense rancid-api to LGPL, change dependency to match
  • NMS-14095: Unable to configure dispatcher threads amount in QueueConfig
  • NMS-14100: Hostname command is missing when running in a container
  • NMS-14104: Upgrade feather to v0.10.1, fix CSS changes, breaking TS changes

by RangerRick at March 28, 2022 09:29 PM

March 25, 2022

New Releases – Horizon 29.0.8, Meridians 2021.1.13, 2020.1.21, 2019.1.32

Today we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 29.

Meridian Stable Updates

Meridians 2019.1.32, 2020.1.21, and 2021.1.13 contain a fix for a regression in graph viewing.

For a list of changes, see the release notes:

Horizon 29.0.8

Release 29.0.8 contains all of the fixes included in the Meridian stable releases, as well as a few small bug fixes relating to upgrades and an improvement to support pre-auth HTTP headers.

For a high-level overview of what has changed in Horizon 29, see What’s New in OpenNMS Horizon 29.

For a complete list of changes, see the changelog.

The codename for Horizon 29.0.8 is Chickadee.

by RangerRick at March 25, 2022 02:38 AM

March 17, 2022

March 2022 Releases – Horizon 29.0.7, Meridians 2021.1.12, 2020.1.20, 2019.1.31

In March, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 29.

Meridian Stable Updates

Meridians 2019.1.31 and 2020.1.20 contain a number of bug fixes and small security updates.

On top of those changes, Meridian 2021.1.12 includes few documentation updates.

For a list of changes, see the release notes:

Horizon 29.0.7

Release 29.0.7 contains all of the fixes included in the Meridian stable releases, as well as a number of additional bugfixes and enhancements.

For a high-level overview of what has changed in Horizon 29, see What’s New in OpenNMS Horizon 29.

For a complete list of changes, see the changelog.

The codename for Horizon 29.0.7 is Pileated Woodpecker.

by RangerRick at March 17, 2022 08:10 PM

March 14, 2022

OpenNMS On the Horizon – March 14th, 2022

It's time once again for OpenNMS On the Horizon.

Since last time, we worked on license management, flow, geomap, provisioning, and report documentation, device config backup, the SNMP detector, quartz scheduling, K/V support in OIA, time-series API improvements, and UI cleanups.

Github Project Updates

Internals, APIs, and Documentation
  • I continued my work to enumerate 3rd-party dependency licenses.
  • Bonnie worked on wrapping up the new flow documentation.
  • Stefan did more work on SFTP file naming for device config backup.
  • Chandra worked on serialization of config for DCB.
  • Stefan continued his work on documenting DCB.
  • Freddy made some improvements to provisioning metric tracking.
  • Christian fixed the SNMP detector to support TTL config.
  • Chandra updated the poller code to provide the device config.
  • Christian did more work on DCB scheduling.
  • Zoë's quartz scheduling update got some fixes.
  • Chandra added support for manually triggering DCB.
  • Yang Li worked on adding an API for accessing the K/V store in OIA.
  • Patrick worked on some improvements to string property storage in the time-series API.
  • Bonnie added documentation for the built-in database reports.
  • Marcel worked on documentation for the geomaps.
  • Jesse added support for pre-authorization based on proxy headers.
  • Bonnie updated a bunch of provision UI documentation.
Web, ReST, UI, and Helm
  • Mike cleaned up a bunch of new UI code.
  • Mike worked on the UI for DCB.
  • Scott worked on filling out the REST API for DCB.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Chandra Gorantla
  • Scott Theleman
  • Bonnie Robinson
  • Mike Rose
  • Stefan Wachter
  • Christian Pape
  • Ronny Trommer
  • Jesse White
  • Yang Li
  • Marcel Fuhrmann
  • Patrick Schweizer
  • Maxim Brener
  • Alberto Ramos
  • Zoë Knox
  • Alex May
  • Freddy Chu
Upcoming March Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

FYI: March's releases are being pushed out a week.

The next OpenNMS release day is March 16th, 2022.

We currently expect updates to Horizon 29 and Meridians 2019 through 2022.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • initial work moving configuration from XML files to the database -- the first config file implemented on top of the new system will be provisiond-configuration.xml
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2022 (Q1 2022)

The current expectation is that we will release Meridian 2022 in March of 2022.
It will be based on Horizon 29.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • NMS-8561: EnhancedLinkd
  • NMS-8563: Collectd
  • NMS-8564: Discovery
  • NMS-8572: Alarmd
  • NMS-8577: Syslogd
  • NMS-9228: Alter requisition UI screenshots in the documentation to reflect the new Angular-based UI
  • NMS-13244: Move detectors from Provisioning chapter to Reference section
  • NMS-13245: Move service monitors section from Service Assurance chapter to Reference section.
  • NMS-13691: Create task driven flows documentation
  • NMS-13835: Cross site scripting - Reflected
  • NMS-13900: When examining the service status of the opennms -v, the service is stopped.
  • NMS-13902: update jsch
  • NMS-13924: Tackle poller scheduling with Device Config Backup
  • NMS-13939: Prevent REST API from allowing multiple primary SNMP interfaces on a single node
  • NMS-13952: Add Rest API to trigger manual backup of Device Config
  • NMS-13990: DCB - Rest API for Downloading Device Configuration
  • NMS-13997: SNMP Detector configuration page excludes useSnmpProfiles and ttl options
  • NMS-13999: Persist custom snmp trap data into collectd
  • NMS-14004: Releases should document third party libraries and their licenses
  • NMS-14017: Return device config filename when polling
  • NMS-14023: Provisiond does not use the rescan-existing attribute from provisiond-configuration.xml
  • NMS-14026: Delete BSM window should name the BSM
  • NMS-14035: Enable key value store access in API plugin
  • NMS-14036: Update OS system requirements in docs
  • NMS-14037: Web UI copyright year needs updating
  • NMS-14039: Determine Local IPAddress on Minion/OpenNMS system
  • NMS-14047: DCB Rest API: Parse cron scheduling info
  • NMS-14055: String Properties / External Tags not working properly
  • NMS-14063: OpenNMS build failure ( related to license-maven-plugin )
  • OIA-34: Key Value Store API support

by RangerRick at March 14, 2022 09:06 PM

February 28, 2022

OpenNMS On the Horizon – February 28th, 2022

It's time once again for OpenNMS On the Horizon.

Since last time, we worked on DAO internals, the config manager API, flow and flow thresholding documentation, device config backup, CI and flapping tests, non-root documentation, metadata provisioning updates, SSH support, Minion docker images, the SNMP detector, the Quartz scheduler, servlet input improvements, node page service bar graphs, TLS config, new UI plugins, topology, and provisioning, legacy UI dependency updates, and node REST validation.

Github Project Updates

Internals, APIs, and Documentation
  • Alex updated some DAO internals to use better SQL APIs
  • Patrick and Yang Li did more work on exposing multiple instances of the same config service in OSGi
  • Bonnie did more work on flow documentation improvements
  • Chandra cleaned up service name mapping in the device config backup code
  • I cleaned up some CI build image issues
  • Ronny added example documentation for running Horizon 29 as root
  • Alberto worked on fixing some flaky smoke tests
  • Chandra implemented manual device config backup triggering
  • I worked on implementing reporting dependency licenses in our build
  • Alex cleaned up some query parameter binding in DAO code
  • Christian worked on flow thresholding documentation
  • Julian changed the CI build to cache node artifacts
  • Christian fixed metadata handling to update properly from the requisition
  • Chandra worked on SSH fixes in Karaf
  • Julian did more work on pushing Minion docker images to Azure
  • Chandra created a default poller config for device config backup
  • Stefan updated our embedded JSCH
  • Christian fixed the SNMP detector to expose TTL parameters
  • Stefan updated the device config poller to expose metadata about the filename
  • Zoë fixed an issue with quartz scheduler job details
  • Stefan added initial documentation for device config backup
Web, ReST, UI, and Helm
  • Alex worked on cleaning up some servlet input handling
  • Gerald updated the bar graph on the node page to indicate better when polling started
  • Mike did more work on loading web UI plugins dynamically
  • Stefan and Scott worked on the REST service for device config backups
  • Alberto cleaned up the default TLS types used in our example Jetty SSL config
  • Yang Li did more work on the UI plugin backend
  • Mike started working on topology in the new UI
  • Scott did more work on provisioning in the new UI
  • I updated a number of dependencies in the legacy web UI build
  • Gerald fixed the node interface REST API to disallow creating multiple SNMP primary interfaces on a device
  • Scott worked on implementing device config backup downloading
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Alberto Ramos
  • Mike Rose
  • Benjamin Reed
  • Scott Theleman
  • Zoë Knox
  • Chandra Gorantla
  • Stefan Wachter
  • Alex May
  • Christian Pape
  • Yang Li
  • Bonnie Robinson
  • Gerald Humphries
  • Scott Thompson
  • Julian Buliga
  • Patrick Schweizer
  • Mark Mahacek
  • Ronny Trommer
  • Pushkar Suthar
Upcoming March Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

FYI: March's releases are being pushed out a week.

The next OpenNMS release day is March 16th, 2022.

We currently expect updates to Horizon 29 and Meridians 2019 through 2021.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • initial work moving configuration from XML files to the database -- the first config file implemented on top of the new system will be provisiond-configuration.xml
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2022 (Q1 2022)

The current expectation is that we will release Meridian 2022 in March of 2022.
It will be based on Horizon 29.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • NMS-13629: Test latest Grafana security update
  • NMS-13647: Provide the ability to define application thresholds and trigger events based on the thresholds.
  • NMS-13746: NMS-13746: Allow OIA plugins to extend the new Vue3 UI
  • NMS-13795: Telemetryd error occurring when testing with hsflowd
  • NMS-13801: DCB - Create a default poller config for backup
  • NMS-13811: Troubleshooting flows: basic
  • NMS-13822: OpenNMS Availability 'Chart' Shouldn't Include Time Before Connected
  • NMS-13830: Update Classification Engine chapter in flows section
  • NMS-13845: TLS: Diffie-Hellman Key Exchange Insufficient DH Group Strength Vulnerability
  • NMS-13847: Password field with autocomplete enabled
  • NMS-13862: Sitemap is generated with www.opennms.com instead docs.opennms.com
  • NMS-13872: Revisit smoke test for OIA plugins
  • NMS-13890: Unable to modify node/interface/service metadata through requisition after initial synchronization
  • NMS-13901: Web UI redirects to http even with base-url set to https
  • NMS-13936: Create module to retrieve Device Config backup manually
  • NMS-13937: Create Sink module that can receive Device Config backup updates
  • NMS-13947: Build process improvement: Cache node artifacts
  • NMS-13954: Vue/Charjs Resource Graphs
  • NMS-13965: Handle both Running/Default ConfigTypes in the same Poller
  • NMS-13970: Add Rest API to Retrieve Device Config Schedule Data
  • NMS-13998: Make sure current CM Rest API meet KDMP needs
  • NMS-14030: Doc Update: Don't expose ONMS console to Internet
  • NMS-14031: Add Karaf command to retrieve Device Config
  • NMS-14032: install script fails if an OpenNMS directory contains root-owned lost+found directory

by RangerRick at February 28, 2022 10:17 PM

February 19, 2022

Nineteen Years

Nineteen years ago my friend Ben talked me into starting this blog. I don’t update it as frequently any more for a variety of reasons, specifically because more people interact on social media these days and I’m not as involved in open source as I used to be, but it is still somewhat of an achievement to keep something going this long.

My “adventures” in open source started out on September 10th, 2001, when I started a new job with a company called Oculan to work on their open source monitoring platform OpenNMS. In May of 2002 I became the lead maintainer on the project, and by the time I started this blog I’d been at it for several months. Back then blogs were one of the main ways an open source project could communicate with its community.

The nearly two decades I spent with OpenNMS were definitely an adventure, and this site can serve as a record of both those successes and those struggles.

Nineteen years ago open source was very different than it is today. Today it is ubiquitous: I think it would be rare for a person to go a single day without interacting with open source software in some fashion. But back then there was still a lot of fear, uncertainty and doubt about using it, with a lot of confusion about what it meant. Most people didn’t take it seriously, often comparing it to “shareware” and never believing that it would ever be used for doing “real” things. On a side note, even in 2022 I recently had one person make the shareware comparison when I brought up Grafana, a project that has secured nearly US$300 million in funding.

Back then we were trying to figure out a business model for open source, and I think in many ways we still are. The main model was support and services.

You would have thought this would have been more successful than it turned out to be. Proprietary software costing hundred of thousands if not millions of dollars would often require that you purchase a maintenance or support contract running anywhere from 15% to 25% of the original software cost per year just to get updates and bug fixes. You would think that people would be willing to pay that amount or less for similar software, avoiding the huge upfront purchase, but that wasn’t the case. If they didn’t have to buy support they usually wouldn’t. Plus, support doesn’t easily scale. It is hard finding qualified people to support complex software. I’d often laugh when someone would contact me offering to double our sales because we wouldn’t have been able to handle the extra business.

One company, Red Hat, was able to pull it off and create a set of open source products people were willing to purchase at a scale that made them a multi-billion dollar organization, but I can’t think of another that was able to duplicate that success.

Luckily, the idea of “hosted” software gained popularity. One of my favorite open source projects is WordPress. You are reading this on a WordPress site, and the install was pretty easy. They talk about a “five minute” install and have done a lot to make the process simple.

However, if you aren’t up to running your own server, it might as well be a five year install process. Instead, you can go to “wordpress.com” and get a free website hosted by them and paid for by ads being shown on your site, or you can remove those ads for as little as US$4/month. One of the reasons that Grafana has been able to raise such large sums is that they, too, offer a hosted version. People are willing to pay for ease of use.

But by far the overwhelming use of open source today is as a development methodology, and the biggest open source projects tend to be those that enable other, often proprietary, applications. Two Sigma Ventures has an Open Source Index that tries to quantify the most popular open source projects, and at the moment these include Tensorflow (a machine learning framework), Kubernetes (a container orchestration platform) and of course the Linux kernel. What you don’t see are end user applications.

And that to me is a little sad. Two decades ago the terms “open source” and “free software” were often used interchangeably. After watching personal computers go from hobbyists to mainstream we also saw control of those systems move to large companies like Microsoft. The idea of free software, as in being able to take control of your technology, was extremely appealing. After watching companies spend hundreds of thousands of dollars on proprietary software and then being tied to those products, I was excited to bring an alternative that would put the power of that software back into the hands of the users. As my friend Jonathan put it, we were going to change the world.

The world did change, but not in the way we expected. The main reason is that free software really missed out on mobile computing. While desktop computers were open enough that independent software could be put on them, mobile handsets to this day are pretty locked down. While everyone points to Android as being open source, to be honest it isn’t very useful until you let Google run most of it. There was a time where almost every single piece of technology I used was open, including my phone, but I just ran out of time to keep up with it and I wanted something that just worked. Now I’m pretty firmly back into the Apple ecosystem and I’m amazed at what you can do with it, and I’m so used to just being able to get things going on the first try that I’m probably stuck forever (sigh).

I find it ironic that today’s biggest contributors to open source are also some of the biggest proprietary software companies in the world. Heck, even Red Hat is now completely owned by IBM. I’m not saying that this is necessarily a bad thing, look at all the open source software being created by nearly everyone, but it is a long way from the free software dream of twenty years ago. Even proprietary, enterprise software has started to leverage open APIs that at least give a nod to the idea of open source.

We won. Yay.

Recently some friends of mine attended a fancy, black-tie optional gala hosted by the Linux Foundation to celebrate the 30th anniversary of Linux. Most of them work for those large companies that heavily leverage open source. And while apparently a good time was had by all, I can’t help but think of, say, those developers who maintain projects like Log4j who, when there is a problem, get dumped on to fix it and probably never get invited to cool parties.

Open source is still looking for a business model. Heck, even making money providing hosted versions of your software is a risk if one of the big players decides to offer their version, as to this day it is still hard to compete with a Microsoft or an Amazon.

But this doesn’t mean I’ve given up on open source. Thanks to the Homebrew project I still use a lot of open source on my Macintosh. I’m writing this using WordPress on a server running Ubuntu through the Firefox browser. I still think there are adventures to be had, and when they happen I’ll write about them here.

by Tarus at February 19, 2022 02:42 PM

February 14, 2022

OpenNMS On the Horizon – Config Manager, Requisitions and Provisioning, Docker, System Report, Nephron, Flows, Docs, Adoptium and Temurin, Device Config Backup, Helm, Karaf, Telemetryd, JMX RMI, IPC, Maven, Non-Root, Jetty, Vue UI, Web Plugins

It's time once again for OpenNMS On the Horizon.

Since last time, we worked on moving configs to the new config manager API, requisition validation, Docker image updates, test infrastructure improvements, system report improvements, Nephron, flow, and SNMP property extender docs, Adoptium/Temurin JDK support, device config backup, Helm docs, Karaf shell, Telemetryd, JMX RMI, IPC, service startup, Maven, Non-Root, Jetty config, UI dependencies, web plugins, event configuration UI, and provisioning UI updates.

Github Project Updates

Internals, APIs, and Documentation
  • Pushkar, Dmitri, and Freddy worked on moving notificationCommands.xml, notifications.xml, and wsman-config.xml to the config manager API
  • Alex worked on performing IP address validation in provisioning requisitions
  • Julian did more work on pushing Docker images to Azure
  • I worked on eliminating EasyMock from our tests to ease moving to JDK 17
  • Gerald worked on cleaning up the system reports to scrub password information
  • Bonnie continued her work updating nephron and flow documentation
  • I did more work on fixing the build on JDK17
  • Chandra worked on integrating the new device config backup persistence into the poller
  • Christian did a bit more work to wrap up flow thresholding
  • I updated our build environment docker containers to use CentOS stream and newer Adoptium JDKs
  • I fixed our Debian dependencies to accept Temurin as a valid JDK
  • Gerard fixed a rendering issue in the full text system report
  • Patrick continued his work on handling multiple config service instances in OSGi
  • Gerard fixed opennms:show-event-config to filter out duplicates
  • I did more work on trying to fix flapping tests
  • Marcel wrapped up his changes to split up the SNMP property extender docs into separate pages
  • Stefan fixed a thread-safety issue in telemetry registry lookup
  • Stefan worked on triggering config retrieval from devices
  • Dustin worked on scheduling for the device config backup
  • Christian fixed a regression in JMX RMI config in Karaf
  • Julian worked on a tool to clean up old docker feature branches in dockerhub
  • Bonnie updated the docs for running as non-root on older (eg RHEL7) Linux kernels
  • Chandra worked on being able to manually trigger device config backup jobs
  • Freddy fixed some issues in recent datacollection config changes
  • Chandra added some documentation on the new consolidated IPC config for Minion
  • I did more work on fixing opennms status and opennms stop on linux when JMX RMI is unavailable
  • I did some work attempting to optimize our CircleCI pipeline
  • Stefan refactored a bunch of the device config pieces into features
  • Freddy changed the Systemd service to not use the SysV init links for startup
  • I bumped our embedded build Maven to 3.8.4
  • Alberto removed the (unused) REST client code from the Minion and Sentinel
  • Alberto changed the default Jetty config to exclude some old cipher algorithms
  • I fixed a bug in Telemetryd that would block OpenNMS clean shutdown
Web, ReST, UI, and Helm
  • Mike updated a bunch of UI dependencies, plus cleaned up color/font handling
  • Yang Li worked on cleaning up/simplifying the new web plugin API
  • Mike started working on a UI for the device config backup
  • I made some additions to the Helm developer documentation
  • Scott did some work on the new configuration UI
  • Chandra and Stefan worked on the device config backup REST API
  • I updated a number of web UI node dependencies
  • Alberto fixed a bug in the event configuration web UI where log destination changes wouldn't persist
  • Yang Li worked on an issue with broken redirects when using HTTPS
  • Gerald worked on fixing password input types around the UI
  • Maxim did some work on provisioning UI tests
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Alberto Ramos
  • Gerald Humphries
  • Maxim Brener
  • Benjamin Reed
  • Yang Li
  • Stefan Wachter
  • Scott Thompson
  • Freddy Chu
  • Chandra Gorantla
  • Bonnie Robinson
  • Dustin Frisch
  • Dmitri Herdt
  • Julian Buliga
  • Mike Rose
  • Alex May
  • Pushkar Suthar
  • Christian Pape
  • Patrick Schweizer
  • Marcel Fuhrmann
  • Ronny Trommer

Release Roadmap

Completed February 2022 Releases - Horizon 29.0.6, Meridians 2021.1.11, 2020.1.19, 2019.1.30

In February, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 29.

Meridian Stable Updates

Meridians 2019.1.30 and 2020.1.19 contain a number of bug fixes and security updates.

On top of those changes, Meridian 2021.1.11 includes few additional bug fixes and a doc update.

For a list of changes, see the release notes:

Horizon 29.0.6

Release 29.0.6 contains all of the fixes included in the Meridian stable release, as well as a number of additional bugfixes and enhancements.

For a high-level overview of what has changed in Horizon 29, see What’s New in OpenNMS Horizon 29.

For a complete list of changes, see the changelog.

Thanks to Sahil Tikoo from Etisalat for reporting the Grafana endpoint issue.

A note about security issues: we have traditionally created CVEs in a pretty ad-hoc manner. We are in the process of formalizing how we’ll be doing so going into the future.

The codename for Horizon 29.0.6 is Dodo.

Upcoming March Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is March 9th, 2022.

We currently expect updates to Horizon 29 and all supported Meridian releases.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • initial work moving configuration from XML files to the database -- the first config file implemented on top of the new system will be provisiond-configuration.xml
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2022 (Q1 2022)

The current expectation is that we will release Meridian 2022 in March of 2022.
It will be based on Horizon 29.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • NMS-4487: Make password field on the node asset page a true passord field type that masks out the password
  • NMS-11064: WebMonitor
  • NMS-11885: Update OpenNMS to compile with JDK 11
  • NMS-12863: show-event-config displays unexpected content after adding new event definitions
  • NMS-13474: Split long doc pages into multiple for readability
  • NMS-13695: Migrate Discourse KSC Reports article to main docs
  • NMS-13707: Flow Thresholds: Documentation
  • NMS-13729: Event configuration UI fails to persist logmsg dest changes
  • NMS-13760: Split SNMP Property Extenders into multiple pages
  • NMS-13768: Remove requirements/logic from Dockerfile/Entrypoint/Confd about the OpenNMS HTTP URL from the Minion and Sentinel due to Twin API
  • NMS-13783: Systemd startup uses legacy SysV init script
  • NMS-13810: Phase 4 flows documentation: Nephron for aggregation
  • NMS-13831: Support -> System Report exposes credentials in plain text
  • NMS-13865: Lunr search indexing runs out of memory while building the docs
  • NMS-13866: Add additional steps running as non-root on old Kernels, e.g. RHEL7
  • NMS-13887: Remote RMI is broken in 29.0.x
  • NMS-13914: rest endpoint for device config retrieval
  • NMS-13920: Setup OpenNMS with appropriate configuration for Pen Testing
  • NMS-13921: Define scope and outline scenarios for OpenNMS PenTest effort
  • NMS-13928: automatically prune old feature branches from dockerhub
  • NMS-13929: Kafka Minions with JMS disabled log errors loading JMS bundles
  • NMS-13935: Create a module that handles all device config retrieval and receiving backup config
  • NMS-13945: Flow Thresholds: Fix handling of rrdRepository
  • NMS-13948: "full" report type in Support -> System Report inserts "%n%n" between entries instead of newlines
  • NMS-13950: Move persistence to MonitorAdaptor, add failure related fields
  • NMS-13957: remove easymock from tests
  • NMS-13960: Update UI packages, fix breaking change, modify featherDS color var usage
  • NMS-13961: Unsynchronized access to service factories in TelemetryServiceRegistryImpl
  • NMS-13967: Add DCB UI Scaffolding - Components/Store/Service/Routing

by RangerRick at February 14, 2022 09:53 PM

February 09, 2022

February 2022 Releases – Horizon 29.0.6, Meridians 2021.1.11, 2020.1.19, 2019.1.30

In February, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 29.

Meridian Stable Updates

Meridians 2019.1.30 and 2020.1.19 contain a number of bug fixes and security updates.

On top of those changes, Meridian 2021.1.11 includes few additional bug fixes and a doc update.

For a list of changes, see the release notes:

Horizon 29.0.6

Release 29.0.6 contains all of the fixes included in the Meridian stable release, as well as a number of additional bugfixes and enhancements.

For a high-level overview of what has changed in Horizon 29, see What’s New in OpenNMS Horizon 29.

For a complete list of changes, see the changelog.

Thanks to Sahil Tikoo from Etisalat for reporting the Grafana endpoint issue.

A note about security issues: we have traditionally created CVEs in a pretty ad-hoc manner. We are in the process of formalizing how we’ll be doing so going into the future.

The codename for Horizon 29.0.6 is Dodo.

by RangerRick at February 09, 2022 05:46 PM

February 08, 2022

Nextcloud News

I think the title of this post is a little misleading, as I don’t have any news about Nextcloud. Instead I want to talk about the News App on the Nextcloud platform, and I couldn’t think of a better one.

I rely heavily on the Nextcloud News App to keep up with what is going on with the world. News provides similar functionality to the now defunct Google Reader, but with the usual privacy bonuses you expect from Nextcloud.

Back before social networks like Facebook and Twitter were the norm, people used to communicate through blogs. Blogs provide similar functionality: people can write short or long form posts that will get published on a website and can include media such as pictures, and other people can comment and share them. Even now when I see an incredibly long thread on Twitter I just wish the author would have put it on a blog somewhere.

Blogs are great, since each one can be individually hosted without requiring a central authority to manage it all. My friend Ben got me started on my first blog (this one) that in the beginning was hosted using a program called Moveable Type. When their licensing became problematic, most of us switched to WordPress, and a tremendous amount of the Web runs on WordPress even now.

Now the problem was that the frequency that people would post to their blogs varied. Some might post once a week, and others several times an hour. Unless you wanted to go and manually refresh their pages, it was difficult to keep up.

Enter Really Simple Syndication (RSS).

RSS is, as the name implies, an easy way to summarize content on a website. Sites that support RSS craft a generic XML document that reflects titles, descriptions, links, etc. to content on the site. The page is referred to as a “feed” and RSS “readers” can aggregate the various feeds together so that a person can follow the changes on websites that interest them.

Google Reader was a very useful feed reader that was extremely popular, and it in turn increased the popularity of blogs. I put some of the blame on Google for the rise of the privacy nightmare of modern social networks on their decision to kill Reader, as it made individual blogs less relevant.

Now in Google’s defense they would say just use some other service. In my case I switched to Feedly, an adequate Reader replacement. The process was made easier by the fact that most feed readers support a way to export your configuration in the Outline Processor Markup Language (OPML) format. I was able to export my Reader feeds and import them into Feedly.

Feedly was free, and as they say if you aren’t paying for the product you are the product. I noticed that next to my various feed articles Feedly would display a count, which I assume reflected the number of Feedly users that were interested in or who had read that article. Then it dawned on me that Feedly could gather useful information on what people were interested in, just like Facebook, and I also assume, if they chose, they could monetize that information. Since I had a Feedly account to manage my feeds, they could track my individual interests as well.

While Feedly never gave me any reason to assign nefarious intentions to them, as a privacy advocate I wanted more control over sharing my interests, so I looked for a solution. As a Nextcloud fan I looked for an appropriate app, and found one in News.

News has been around pretty much since Nextcloud started, but I rarely hear anyone talking about its greatness (hence this post). Like most things Nextcloud it is simple to install. If you are an admin, just click on your icon in the upper right corner and select “+ Apps”. Then click on “Featured apps” in the sidebar and you should be able to enable the “News” app.

That’s it. Now in order to update your feeds you need to be using the System Cron in Nextcloud, and instructions can be found in the documentation.

Once you have News installed, the next challenge is to find interesting feeds to which you can subscribe. The news app will suggest several, but you can also find more on your own.

Nextcloud RSS Suggestions

It used to be pretty easy to find the feed URL. You would just look for the RSS icon and click on it for the link:

RSS Icon

But, again, when Reader died so did a lot of the interest in RSS and finding feed URLs more became difficult. I have links to feeds at the very bottom of the right sidebar of this blog, but you’d have to scroll down quite a way to find them.

But for WordPress sites, like this one, you just add “/feed” to the site URL, such as:

https://www.adventuresinoss.com/feed

There are also some browser plugins that are supposed to help identify RRS feed links, but I haven’t used any. You can also “view source” on a website of interest and search for “rss” and that may help out as well.

My main use of the News App is to keep up with news, and I follow four main news sites. I like the BBC for an international take on news, CNN for a domestic take, Slashdot for tech news and WRAL for local news.

Desktop Version of News App

Just for reference, the feed links are:

BBC: http://newsrss.bbc.co.uk/rss/newsonline_uk_edition/front_page/rss.xml

CNN: http://rss.cnn.com/rss/cnn_topstories.rss

Slashdot: http://rss.slashdot.org/slashdot/slashdotMain

WRAL: http://www.wral.com/news/rss/48/

This wouldn’t be as useful if you couldn’t access it on a mobile device. Of course, you can access it via a web browser, but there exist a number of phone apps for accessing your feeds in a native app.

Now to my knowledge Nextcloud the company doesn’t produce a News mobile app, so the available apps are provided by third parties. I put all of my personal information into Nextcloud, and since I’m paranoid I didn’t want to put my access credentials into those apps but I wanted the convenience of being able to read news anywhere I had a network connection. So I created a special “news” user just for News. You probably don’t need to do that but I wanted to plant the suggestion for those who think about such things.

On my iPhone I’ve been happy with CloudNews.

iPhone Version of CloudNews App

It sometimes gets out of sync and I end up having to read everything in the browser and re-sync in CloudNews, but for the most part it’s fine.

For Android the best app I’ve used is by David Luhmer. It’s available for a small fee in the Play Store and for free on F-Droid.

Like all useful software, you don’t realize how much you depend on it until it is gone, and in the few instances I’ve had problems with News I get very anxious as I don’t know what’s going on in the world. Luckily this has been rare, and I check my news feed many times during the day to the point that I probably have a personal problem. The mobile apps mean I can read news when I’m in line at the grocery store or waiting for an appointment. And the best part is that I know my interests are kept private as I control the data.

If you are interested, I sporadically update a number of blogs, and I aggregate them here. In a somewhat ironic twist, I can’t find a feed link for the “planet” page, so you’d need to add the individual blog feeds to your reader.

by Tarus at February 08, 2022 04:19 PM

January 31, 2022

Review: AT&T Cell Booster

Back in the mid-2000s I was a huge Apple fanboy, and I really, really, really wanted an iPhone. At that time it was only available from AT&T, and unfortunately the wireless coverage on that network is not very good where I live.

In 2008 a couple of things happened. Apple introduced the iPhone 3G, and AT&T introduced the 3G Microcell.

The 3G Microcell, technically a “femtocell“, is a small device that you can plug into your home network and it will leverage your Internet connection to augment wireless coverage in a small area (i.e. your house). With that I could get an iPhone and it would work at my house.

In February 3G service in the US will cease, and I thought I was going to have to do without a femtocell. Most modern phones support calling over WiFi now, but it just isn’t the same. For example, if I am trying to send an SMS and there is any signal at all from AT&T, my phone will try to use that network instead of the much stronger wireless network in my house. If I disable mobile access altogether, the SMS will send fine but then I can’t get phone calls reliably. (sigh)

I thought I was going to have to just deal with it when AT&T sent me a notice that they were going to replace my 3G Microcell with a new product called a Cell Booster.

Now a lot of people criticize AT&T for a number of good reasons, but lately they’ve really been hitting the whole “customer service” thing out of the park. The Cell Booster currently shows out of stock on their website with a cost of $229, but they sent me one for free.

AT&T Cell Booster Box

In a related story my mother-in-law, who is on our family plan, was using an older Pixel that was going to stop working with the end of 3G service (it was an LTE phone but doesn’t support “HD Voice” which is required to make calls). So AT&T send us a replacement Samsung S9. Pretty cool.

In any case the Cell Booster installation went pretty smoothly. I simply unplugged the existing 3G Microcell and plugged in the new device. The box included the Cell Booster, a GPS sensor, a power supply and an Ethernet cable. No other instructions outside of a QR code which will take you to the appropriate app store to download the necessary application to set it up.

The Booster requires a GPS lock, and they include a little “puck” connected to a fairly long wire that is supposed to allow one to get a signal even when the device is some distance away from a clear line of sight, such as away from windows. I just plugged it in to the back and left it next to the unit and it eventually got a signal, but it is also pretty much beneath a skylight.

In order to provision the Cell Booster you have to launch the mobile app and fill out a few pages of forms, which includes the serial number of the device. It has five lights on the front and while the power light came on immediately, it did take some time for the other lights, including “Internet” to come up. I assumed the Internet light would have turned on as soon as an IP address was assigned, but that wasn’t the case. It took nearly a half and hour for the first four lights to come on, and then another 15 minutes or so for the final “4G LTE” light to illuminate and the unit to start working. Almost immediately I got an SMS from AT&T saying the unit was active.

AT&T Cell Booster Lights

Speaking of IP addresses, I don’t like putting random devices on my LAN so I stuck this on my public network which only has Internet access (no LAN access). I ran nmap against it and there don’t appear to be any ports open. A traffic capture shows traffic between the Cell Booster and a 12.0.0.0 network address owned by AT&T.

I do like the fact that, unlike the 3G Microcell, you do not need to specify the phone number of the handsets that can use the Cell Booster. It claims to support up to 8 at a time, and while I haven’t had anyone over who is both on the AT&T network and also not on my plan, I’m assuming it will work for them as well (I used to have to manually add phone numbers of my guests to allow them to use the 3G device).

The Cell Booster is a rebranded Nokia SS2FII. One could probably buy one outside of AT&T but without being able to provision it I doubt it would work.

So far we’ve been real happy with the Cell Booster. Calls and SMS messages work just fine, if not better than before (I have no objective way to measure it, though, so it might just be bias). If you get one, just remember that it takes a really long time to start up that first time, but after you have all five lights you should be able to forget it’s there.

by Tarus at January 31, 2022 07:40 PM

OpenNMS On the Horizon – Config Manager, Nephron, Datacollection, Flow Thresholds, Minion, Provisioning, Docker, Azure, Non-Root, JDK17, Netflow, Device Config Backup, Kafka, Web Plugins, Graphing

It's time once again for OpenNMS On the Horizon.

Since last time, we worked on the config manager, documentation for Nephron, the web UI, datacollection, and flow thresholds, flapping tests, provisioning scanning on Minion, Minion docker publishing in Azure, running as non-root, JDK17 support, IP validation, Netflow template options, device config backup, Kafka IPC, a plugin API for the web UI, and graphs.

Github Project Updates

Internals, APIs, and Documentation
  • Pushkar did more work on converting SNMP configs to the config manager
  • Bonnie wrapped up her work cleaning up the main README
  • I spent more time trying to clean up integration and smoke test flappers
  • Jesse and I fixed a bug in provisiond accessing JAXB serialization on Minion
  • Bonnie worked on Nephron and web UI documentation
  • Julian did more work on publishing Minion docker images to Azure
  • Patrick did more work on handling multiple configurations in the config manager
  • I fixed the fix-karaf-setup.sh to rerun itself as the correct user
  • Freddy worked on some refactoring and tests for SNMP configs
  • Marcel did some updates to datacollection documentation
  • Alex worked on IP address validation in requisitions
  • I worked on moving from EasyMock to Mockito in a bunch of unit and integration tests
  • Brent fixed up weekly test coverage runs in Sonar
  • Stefan fixed an issue in Netflow template option handling
  • Chandra worked on wrapping up the device config backup core implementation
  • Christian did some more work on docs for flow thresholding
  • Chandra worked on some issues with the new unified Kafka IPC config
  • Pierre made some updates to the Minion confd schema
Web, ReST, UI, and Helm
  • Yang Li worked on a web plugin extension API
  • Mike continued his work on graphing/charting in the new UI
  • Stefan worked on a REST service for device config backups
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Freddy Chu
  • Pushkar Suthar
  • Chandra Gorantla
  • Patrick Schweizer
  • Yang Li
  • Mike Rose
  • Julian Buliga
  • Bonnie Robinson
  • Benjamin Reed
  • Scott Thompson
  • Stefan Wachter
  • Pierre Bouffard
  • Christian Pape
  • Brent Borovan
  • Alex May
  • Maxim Brener
  • Marcel Fuhrmann
  • Antonio Russo
  • Ronny Trommer

Release Roadmap

Upcoming February Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is February 9th, 2022.

We currently expect updates to Horizon 29 and all supported Meridian releases.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2022 (Q1 2022)

The current expectation is that we will release Meridian 2022 in Q1 of next year. It will be based on Horizon 29 plus any bug fixes that happen between November and the Meridian release.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • NMS-13213: Update Readme file content
  • NMS-13694: Migrate Discourse charts article into main docs
  • NMS-13865: Lunr search indexing runs out of memory while building the docs
  • NMS-13876: Vue UI Housekeeping
  • NMS-13881: fix-karaf-setup.sh should honor RUNAS
  • NMS-13923: TIMETETRA LLDP supported device does not persist all remote links
  • NMS-13926: Agg Flow via Nephron showing gaps/drops since upgrading to 29.0.4
  • NMS-13927: Minion fails to marshall requisition with JAXB error: Class [org.opennms.netmgt.model.PrimaryTypeAdapter] not found

by RangerRick at January 31, 2022 07:35 PM

January 26, 2022

Review: ProtonMail

I love e-mail. I know for many it is a bane, which has resulted in the rise of “inbox zero” and even the “#noemail” movement, but for me it is a great way to communicate.

I just went and looked, and the oldest e-mail currently in my system is from July of 1996. I used e-mail for over a decade before then, on school Unix systems and on BBS’s, but it wasn’t until the rise of IMAP in the 1990s that I was able to easily keep and move my messages from provider to provider.

That message from 1996 was off of my employer’s system. I didn’t have my own domain until two years later, in 1998, and I believe my friend Ben was the one to host my e-mail at the time.

When I started maintaining OpenNMS in 2002 I had a server at Rackspace that I was able to configure for mail. I believe the SMTP server was postfix but I can’t remember what the IMAP server was. I want to say it was dovecot but that really wasn’t available until later in 2002, so maybe UW IMAP? Cyrus was pretty big at the time but renown for being difficult to set up.

In any case I was always a little concerned about the security of my mail messages. Back then disks were not encrypted and even the mail transport was done in the clear (this was before SSL became ubiquitous), so when OpenNMS grew to the point where we had our own server room, I set up a server for “vanity domains” that anyone in the company could use to host their e-mail and websites, etc. At least I knew the disks were behind a locked door, and now that Ben worked with us he could continue to maintain the mail server, too. (grin)

Back then I tried to get my friends to use encrypted e-mail. Pretty Good Privacy (PGP) was available since the early 1990s, and MIT used to host plugins for Outlook, which at the time was the default e-mail client for most people. But many of them, including the technically minded, didn’t want to be bothered with setting up keys, etc. It wasn’t until later when open source really took off and mail clients like Thunderbird arrived (with the Enigmail plug-in) that encrypted e-mail became more common among my friends.

In 2019 the decision was made to sell the OpenNMS Group, and since I would no longer have control over the company (and its assets) I decided I needed to move my personal domains somewhere else. I really didn’t relish the idea of running my own mail server. Spam management was always a problem, and there were a number of new protocols to help secure e-mail that were kind of a pain to set up.

The default mail hosting option for most people is GMail. Now part of Google Workspace, for a nominal fee you can have Google host your mail, and get some added services as well.

I wasn’t happy with the thought of Google having access to my e-mail, so I looked for options. To me the best one was ProtonMail.

The servers for ProtonMail are hosted in Switzerland, a neutral country not beholden to either US or EU laws. They are privacy focused, with everything stored encrypted at rest and, when possible, encrypted in transport.

They have a free tier option that I used to try out the system. Now, as an “old”, I prefer desktop mail clients. I find them easiest to use and I can also bring all of my mail into one location, and I can move messages from one provider to another. The default way to access ProtonMail is through a web client, like GMail. Unlike GMail, ProtonMail doesn’t offer a way to directly access their services through SMTP or IMAP. Instead you have to install a piece of software called the ProtonMail Bridge that will create an encrypted tunnel between your desktop computer and their servers. You can then configure your desktop mail client to connect to “localhost” on a particular port and it will act as if it were directly connected to the remote mail server.

In my trial there were two shortcomings that immediately impacted me. As a mail power user, I use a lot of nested folders. ProtonMail does not allow you to nest folders. Second, I share some accounts with my spouse (i.e. we have a single Paypal account) and previously I was able to alias e-mail addresses to send to both of our user accounts. ProtonMail does not allow this.

For the latter I think it has to do with the fact that each mail address requires a separate key and their system must not make it easy to use two keys or to share a key. I’m not sure what the issue is with nested folders.

In any case, this wasn’t a huge deal. To overcome the nested folder issue I just added a prefix, i.e. “CORR” for “Correspondence” and “VND” for “Vendor”, to each mailbox, and then you can sort on name. And while we share a few accounts we don’t use them enough that we couldn’t just assign it to a particular user.


UPDATE: It turns out it is now possible to have nested folders, although it doesn’t quite work the way I would expect.

Say I want a folder called “Correspondence” and I want sub-folders for each of the people with whom I exchange e-mail. I tried the following:

So I have a folder named something like “CORR-Bill Gates”, but I’d rather have that nested under a folder entitled “Correspondence”. In my desktop mail client, if I create a folder called “Correspondence” and then drag the “CORR-Bill Gates” folder into it, I get a new folder titled “Correspondence/CORR-Bill Gates” which is not what I want.

However, I can log into the ProtonMail webUI and next to folders there is a little “+” sign.

Add Folder Menu Item
If I click on that I get a dialog that lets me add new folders, as well as to add them to a parent folder.

Add Folder Dialog Box

If I create a “Correspondence” folder with no parent via the webUI and then a “Bill Gates” folder, I can parent the “Bill Gates” folder to “Correspondence” and then the folders will show up and behave as I expect in my desktop e-mail client. Note that you can only nest two levels deep. In other words if I wanted a folder structure like:

Bills -> Taxes -> Federal -> 2021

It would fail to create, but

Bills -> Taxes -> 2021-Federal

will work.


After I was satisfied with ProtonMail, I ended up buying the “Visionary” package. I pay for it in two-year chunks and it runs US$20/month. This gives me ten domains and six users, with up to 50 e-mail aliases.

Domain set up was a breeze. Assuming you have access to your domain registrar (I’m a big fan of Namecheap) all you need to do is follow the little “wizard” that will step you through the DNS entries you need to make to point your domain to ProtonMail’s servers as well as to configure SPF, DKIM and DMARC. Allowing for the DNS to update, it can be done in a few minutes or it may take up to an hour.

I thought there would be a big issue with the 50 alias limit, as I set up separate e-mails for every vendor I use. But it turns out that you only need to have a alias if you want to send e-mail from that address. You can set up a “catch all” address that will take any incoming e-mail that doesn’t expressly match an alias and send it to a particular user. In my case I set up a specific “catchall@” address but it is not required.

You can also set up filters pretty easily. Here is an example of sending all e-mail sent to my “catchall” address to the “Catch All” folder.

require ["include", "environment", "variables", "relational", "comparator-i;ascii-numeric", "spamtest"];
require ["fileinto", "imap4flags"];

# Generated: Do not run this script on spam messages
if allof (environment :matches "vnd.proton.spam-threshold" "*", spamtest :value "ge" :comparator "i;ascii-numeric" "${1}") {
return;
}


/**
* @type and
* @comparator matches
*/
if allof (address :all :comparator "i;unicode-casemap" :matches ["Delivered-To"] "catchall@example.com") {
fileinto "Catch All";
}

I haven’t had the need to do anything more complicated but there are a number of examples you can build on. I had a vendor that kept sending me e-mail even though I had unsubscribed so I set up this filter:

require "reject";


if anyof (address :all :comparator "i;unicode-casemap" :is "From" ["noreply@petproconnect.com"]) {
reject "Please Delete My Account";
}

and, voilà, no more e-mail. I’ve also been happy with the ProtonMail spam detection. While it isn’t perfect it works well enough that I don’t have to deal with spam on a daily basis.

I’m up to five users and eight domains, so the Visionary plan is getting a little resource constrained, but I don’t see myself needing much more in the near future. Since I send a lot of e-mail to those other four users, I love the fact that our correspondence is automatically encrypted since all of the traffic stays on the ProtonMail servers.

As an added bonus, much of the ProtonMail software, including the iOS and Android clients, are available as open source.

While I’m very satisfied with ProtonMail, there have been a couple of negatives. As a high profile pro-privacy service it has been the target of a number of DDOS attacks. I have never experienced this problem but as these kinds of attacks get more sophisticated and more powerful, it is always a possibility. Proton has done a great job at mitigating possible impact and the last big attack was back in 2018.

Another issue is that since ProtonMail is in Switzerland, they are not above Swiss law. In a high profile case a French dissident who used ProtonMail was able to be tracked down via their IP address. Under Swiss law a service provider can be compelled to turn over such information if certain conditions are met. In order to make this more difficult, my ProtonMail subscription includes access to ProtonVPN, an easy to use VPN client that can be used to obfuscate a source IP, even from Proton.

They are also launching a number of services to better compete with GSuite, such as a calendar and ProtonDrive storage. I haven’t started using those yet but I may in the future.

In summary, if you are either tired of hosting your own mail or desire a more secure e-mail solution, I can recommend ProtonMail. I’ve been using it for a little over two years and expect to be using it for years to come.

by Tarus at January 26, 2022 12:55 PM

January 24, 2022

OpenNMS On the Horizon – JDK17, Device Config Backup, Config Management API, OIA, Detectors, Karaf, Alarmd, Sentinel, LLDP, Documentation, CircleCI, Zabbix, Grafana, Reports, Vue UI, Charts, JavaScript, Helm, REST, Node Rescan

It's time once again for OpenNMS On the Horizon.

Since last time, we worked on JDK 17 support, device config backup, config management, detectors in OIA, Karaf 4.3.6, Alarmd in Sentinel, TIMETETRA LLDP linkd, documentation improvements, CircleCI updates, the Zabbix plugin, Grafana reports, chart UI, AngularJS fixes, core and Helm JS build updates, node rescan REST support, and Sentinel smoke test improvements.

Github Project Updates

Internals, APIs, and Documentation
  • I got OpenNMS running on JDK 17. There's still a lot of work to fix test infrastructure before this is actually ready, though.
  • Stefan worked on making a utility for doing basic scripting of remote SSH interaction for device config backup.
  • Puskhar did more work on migrating SNMP configs to the config management API.
  • Stefan did more work on TFTP support for device config backup.
  • Yang Li continued his work to support writing detectors in OIA.
  • Yang Li finished upgrading our embedded Karaf to 4.3.6.
  • Patrick updated the CM migrator to handle multiple configs of the same type.
  • Freddy did more work on config management test infrastructure.
  • Arthur worked on running alarmd and the event REST service in Sentinel.
  • Antonio fixed an issue with persisting links for TIMETETRA LLDP devices.
  • I spent more time trying to clean up flapping tests.
  • Chandra worked on device config backup tests.
  • Bonnie migrated some info from Discourse to the official docs.
  • I fixed up some CircleCI changes related to splitting the builds.
  • Julian worked on publishing Minion Docker images to Azure.
  • Brent worked on getting Sonar code coverage pushing again.
  • Jesse did some dependency updates to the Zabbix plugin.
  • Bonnie worked on improving the main README.md file.
  • Marcel did more work on cleaning up some doc rearranging.
  • Chandra worked on poller integration for device config backups.
Web, ReST, UI, and Helm
  • I fixed a bug in the grafana report editor UI.
  • Stefan started work on a REST endpoint for device config backup.
  • Mike continued to work on charts and graph data display in the new Vue UI.
  • I fixed some issues with AngularJS template handling.
  • I did a bunch of dependency and build cleanup in the core webapp and helm build systems.
  • Christian did more work on graph templates for flow thresholds.
  • Stefan merged his updates to Helm to use native JS promises.
  • Alex did more work on being able to trigger a rescan of a node through REST.
  • Alberto added documentation for the healthcheck REST API.
  • Alberto worked on making the smoke tests use the healthcheck REST API rather than SSH to check test containers.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Chandra Gorantla
  • Marcel Fuhrmann
  • Bonnie Robinson
  • Benjamin Reed
  • Mike Rose
  • Jesse White
  • Julian Buliga
  • Stefan Wachter
  • Brent Borovan
  • Alberto Ramos
  • Freddy Chu
  • Dmitri Herdt
  • Alex May
  • Pushkar Suthar
  • Arthur Naseef
  • Antonio Russo
  • Christian Pape
  • Patrick Schweizer
  • Yang Li
  • Dustin Frisch

Release Roadmap

Upcoming February Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is February 9th, 2022.

We currently expect updates to Horizon 29 and all supported Meridian releases.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2022 (Q1 2022)

The current expectation is that we will release Meridian 2022 in Q1 of next year. It will be based on Horizon 29 plus any bug fixes that happen between November and the Meridian release.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-301: Use official Grafana typings
  • NMS-13386: Add docs to Health-Check Rest API
  • NMS-13645: Smoke tests should use HealthCheck Rest instead of connecting to SSH
  • NMS-13658: Upgrade Karaf to v4.3.6
  • NMS-13710: Flow Thresholds: Graph Templates
  • NMS-13745: Allow detectors exposed via OIA to be scheduled with provisiond
  • NMS-13758: Split Database Reports docs into multiple pages
  • NMS-13759: Split Asset Topology Provider docs into multiple pages
  • NMS-13796: Implement TFTP Server to fetch config from network devices
  • NMS-13848: Outdated javascript library
  • NMS-13899: ssh scripting support for triggering TFTP upload of device configurations
  • NMS-13909: Integrate SonarCloud with CircleCI builds for develop branch
  • NMS-13910: org.opennms.core.commands never got added to Karaf build
  • NMS-13913: Sanitize application names in resources
  • NMS-13915: Flow Thresholds: Improve logging and debug
  • NMS-13917: grafana endpoint can be used to port-scan internal resources

by RangerRick at January 24, 2022 07:37 PM

January 18, 2022

OpenNMS On the Horizon – Config Manager, Flows, Protobuf, Non-Root, Topology, Flow Thresholding, CI, Device Config Backup, Karaf, REST, Vue, Charts, Helm, OpenNMS.js

It's time once again for OpenNMS On the Horizon.

Since last time, we worked on config manager migrations and importing, flow docs, protobuf updates, non-root validation, topology provider and wiki migration docs, CI improvements, device config backup, Karaf tools and upgrade, TFTP support, flow thresholding, resource and health REST endpoints, vue charting, Helm and OpenNMS.js.

Github Project Updates

Internals, APIs, and Documentation
  • Pushkar and Freddy worked on migrating the notification, SNMP, and WMI configs to the new config manager
  • Bonnie worked on improving flow documentation
  • Patrick did some more work on cleaning up the config manager import process
  • Chandra updated our protobuf code to the latest version
  • I fixed a bug in non-roow ownership validation in the installer
  • Freddy improved some of the property handling in the config migration
  • Marcel made updates to the asset topology provider docs
  • Marcel migrated some docs from the old wiki
  • I reworked some of our CircleCI workflows to avoid full builds when unnecessary
  • Chandra did more work on backend support for device config backups
  • I updated our Karaf container(s) to include Jeff's Karaf CLI IP address range generator tool
  • Stefan updated our SSH integration to use a newer implementation
  • Stefan did some more work on TFTP support for device backup
  • Julian worked on publishing docker images to Azure
  • Yang Li updated our embedded Karaf to 4.3.6
  • Chandra worked on integrating the device config backup tools to the poller
  • Christian added some graph definitions for flow thresholds
Web, ReST, UI, and Helm
  • Stefan made some optimizations in the node resource REST endpoint
  • Stefan implemented support for the optimized node resource endpoint in Helm and OpenNMS.js
  • I worked on cleaning up Helm and OpenNMS.js's dependencies
  • Mike worked on charting support in the new featherds UI
  • Alberto worked on wrapping up support for expanding healthcheck REST endpoint
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Freddy Chu
  • Patrick Schweizer
  • Chandra Gorantla
  • Yang Li
  • Alberto Ramos
  • Julian Buliga
  • Christian Pape
  • Dustin Frisch
  • Stefan Wachter
  • Pushkar Suthar
  • Bonnie Robinson
  • Benjamin Reed
  • Upendra Guggilam
  • Mike Rose
  • Dmitri Herdt
  • Marcel Fuhrmann

Release Roadmap

Completed January 2022 Releases - Horizon 29.0.5, Meridians 2021.1.10, 2020.1.18, 2019.1.29

In January, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 29.

Horizon 29.0.5

Release 29.0.5 contains a number of bug and security fixes, as well as a few enhancements.

It include an update to the latest Log4j2 release. It is not believed that we are vulnerable to the Log4j issues fixed in these newer releases, but are updating anyway just to be sure.

For a high-level overview of what has changed in Horizon 29, see What’s New in OpenNMS Horizon 29.

The codename for Horizon 29.0.5 is Kingfisher.

Meridian Point Releases

Meridians 2019.1.29 and 2020.1.18 contain a Log4j version bump, plus an NPE fix in the topology UI.

Meridian 2021.1.10 adds on top of that some Javascript dependency updates and doc improvements.

For a list of changes, see the release notes:

Helm and OpenNMS.js

After adapting to the new process for getting plugins validated, Helm 7.3.0 is now available in the official Grafana plugin registry, and there should be less lag going forward getting updates released.

Additionally, OpenNMS.js 2.4 is now available, which adds support for optimized node resource querying, and a ton of depedency updates to keep up with upstream node security patches.

Upcoming February Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is February 9th, 2022.

We currently expect updates to Horizon 29 and all supported Meridian releases.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2022 (Q1 2022)

The current expectation is that we will release Meridian 2022 in Q1 of next year. It will be based on Horizon 29 plus any bug fixes that happen between November and the Meridian release.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-297: Create Helm Docker Test Infrastructure
  • HELM-303: Retrieve partial resources by performance datasource
  • JS-51: feature toggle for the select resources endpoint
  • NMS-13441: TimescaleDB extension can't added to existing opennms DB.
  • NMS-13754: Daemon config file docs missing info
  • NMS-13775: Create Config Backup DB table and DAO layer
  • NMS-13819: [CircleCI] - separate build-ui build step
  • NMS-13820: [CircleCI] - move java docs generation from tarball-assembly to build step
  • NMS-13837: Add Health Check Rest API on Sentinel
  • NMS-13860: Permission check in ./install -dis flags unwriteable files in the .git directory - redux
  • NMS-13863: Support an endpoint that allows to access parts of resources
  • NMS-13883: Add graphics to flows documentation
  • NMS-13885: Minion Kafka docs missing reference to custom.system.properties
  • NMS-13889: Upgrade protobuf-java version

by RangerRick at January 18, 2022 05:16 PM

January 13, 2022

OpenNMS.js v2.4.1

This is just a rerelease to fix an issue with artifact generation in 2.4.0.

by RangerRick at January 13, 2022 02:43 PM

OpenNMS.js v2.4.0

This release includes a ton of dependency updates, as well as an enhancement to specify whether a remote OpenNMS system supports the newer, more efficient, query API for selecting resources.

by RangerRick at January 13, 2022 02:05 PM

OpenNMS.js v2.3.0

This release adds support for querying SNMP interfaces, monitored services, and outages.

by RangerRick at January 13, 2022 01:57 PM

January 12, 2022

January 2022 Releases – Horizon 29.0.5, Meridians 2021.1.10, 2020.1.18, 2019.1.29

In January, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 29.

Horizon 29.0.5

Release 29.0.5 contains a number of bug and security fixes, as well as a few enhancements.

It include an update to the latest Log4j2 release. It is not believed that we are vulnerable to the Log4j issues fixed in these newer releases, but are updating anyway just to be sure.

For a high-level overview of what has changed in Horizon 29, see What’s New in OpenNMS Horizon 29.

The codename for Horizon 29.0.5 is Kingfisher.

Meridian Point Releases

Meridians 2019.1.29 and 2020.1.18 contain a Log4j version bump, plus an NPE fix in the topology UI.

Meridian 2021.1.10 adds on top of that some Javascript dependency updates and doc improvements.

For a list of changes, see the release notes:

by RangerRick at January 12, 2022 04:00 PM

January 11, 2022

OpenNMS On the Horizon – Config Manager, Log4j, TimescaleDB, Twin API, Karaf, Router Configs, CI, Docs, Helm, Sentinel, FeatherDS, Graphs

It's time once again for OpenNMS On the Horizon.

Since last time, we worked on the config manager, Log4j, TimescaleDB, the Twin API, Karaf updates, router config handling, CI improvements, flow/Minion/Sentinel doc improvements, interface and node caching, Helm, Sentinel health-check, resource graphs in the featherds UI, and jQuery.

Github Project Updates

Internals, APIs, and Documentation
  • Freddy worked on exception handling changes in the config manager
  • I bumped pax-logging and log4j versions
  • Alberto worked on cleanups to TimescaleDB upgrade handling
  • Chandra did more work on adding metrics for the Twin API
  • Yang Li and I experimented with updating our embedded Karaf
  • Patrick did more work on the Karaf config manager integration
  • Freddy and Patrick continued their work on config manager import infrastructure
  • Chandra worked on persisting router info
  • I did some adjustments to our CI infrastructure to support CircleCI's dynamic configs
  • I worked on moving javadoc building in CircleCI to improve build times
  • Pushkar and Dmitri worked on migrating notification and SNMP configs to the config manager
  • Bonnie and Mark worked on flow, Minion, and Sentinel docs
  • Chandra and Stefan worked on asynchronous and locking improvements in the interface/node cache
Web, ReST, UI, and Helm
  • I cleaned up some dependencies in Helm
  • Alberto worked on adding health-check REST to Sentinel
  • Mike worked on resource graph support in the featherds UI
  • I worked on updating our jQuery in the web UI
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Freddy Chu
  • Alberto Ramos
  • Benjamin Reed
  • Mark Mahacek
  • Bonnie Robinson
  • Chandra Gorantla
  • Dmitri Herdt
  • Yang Li
  • Patrick Schweizer
  • Pushkar Suthar
  • Mike Rose

Release Roadmap

Upcoming January Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is January 12th, 2021.

We currently expect minor updates to Horizon 29 and all supported Meridian releases.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2022 (Q1 2022)

The current expectation is that we will release Meridian 2022 in Q1 of next year. It will be based on Horizon 29 plus any bug fixes that happen between November and the Meridian release.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • NMS-12839: It's not possible to configure Slack/Mattermost notifications using the web UI
  • NMS-13649: Add metrics about twin communication
  • NMS-13808: Phase 2 flows documentation: remote flows collection with Minion
  • NMS-13809: Phase 3 flows docs: Sentinel to scale write performance
  • NMS-13818: [CircleCI] - separate build-docs build step
  • NMS-13859: Very large node caches can cause telemetry adapters to fail on Sentinel
  • NMS-13861: Nephron chapter missing from TOC
  • NMS-13878: upgrade to log4j2 2.17.1 and pax-logging 1.11.13/2.0.14

by RangerRick at January 11, 2022 10:55 PM

January 04, 2022

OpenNMS On the Horizon – Config API, OIA, Detectors, Log4j2, TFTP, Nephron, Events, Caching, ReST, OpenAPI, Vue, Helm, Geomap

It's time once again for OpenNMS On the Horizon.

Since last time, we did more work on config manager migrations, OIA, asynchronous detectors, log4j2, TFTP, Nephron docs, events, caching, resource ReST API, OpenAPI, the Vue UI, Helm tests, and the geomap.

Github Project Updates

Internals, APIs, and Documentation
  • Upendra, Tikayat, Freddy, Pushkar, and Dmitri did more work on migrating notifications, WMI and WS-Man to the new config manager
  • Jesse fixed an issue with integration API tests
  • Yang Li worked on making detectors more asynchronous
  • I updated Log4j2
  • Jesse did more work on running OIA plugins on the Sentinel
  • Stefan worked on an embedded TFTP server for getting router configs
  • Ronny worked on nephron doc generation
  • I worked on a change to make eventid a BIGINT to help avoid wraparounds
  • Stefan fixed a synchronization issue in the interface/node cache
Web, ReST, UI, and Helm
  • Stefan worked on making the resources ReST API capable of querying multiple string parameters in a single request
  • Mike worked on adding rapidoc to the UI for handling OpenAPI info
  • Makarand worked on cleaning up some of the Vue UI code
  • I worked on creating a test environment for Helm
  • Farid worked on the node detail popup in the geomap
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Dmitri Herdt
  • Farid Ahmad
  • Freddy Chu
  • Jesse White
  • Makarand Patil
  • Mike Rose
  • Pushkar Suthar
  • Ronny Trommer
  • Stefan Wachter
  • Tikayat Mohanta
  • Upendra Guggilam
  • Yang Li

Release Roadmap

Upcoming January Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is January 12th, 2021.

We currently expect minor updates to Horizon 29 and all supported Meridian releases.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2022 (Q1 2022)

The current expectation is that we will release Meridian 2022 in Q1 of next year. It will be based on Horizon 29 plus any bug fixes that happen between November and the Meridian release.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • ALEC-97: upgrade log4j to 2.17.0
  • NMS-13751: Add OIA plugin support for Sentinel
  • NMS-13782: Synchronization violated for InterfaceToNodeCacheDaoImpl
  • NMS-13867: Fix the RRD path for the plugin collectors
  • NMS-13868: CVE-2021-45105: Update to Log4j 2.17.0
  • NMS-13871: Bump log4j2 version in Nephron
  • NMS-13873: Add new UI RapiDoc interface to consume OpenApi spec

by RangerRick at January 04, 2022 08:53 PM

December 20, 2021

OpenNMS On the Horizon – Log4j, Prometheus, Grafana, Enlinkd, IPC, Docs, Config API, Non-Root, Sentinel, Minion, Flows, Thresholding, Discovery, OIA, TimescaleDB, Karaf, Twin API, Provisioning, Vue, Geomap, Helm

Sorry for the missing OOH last week... I was really busy for some reason.

Aaaaaaaanyway...

Since last time, we released Horizon and Meridian 73 times, and worked on Prometheus collections, Grafana package signatures, Enlinkd performance, IPC config, reports, docs for daemons, VMware, flows, and topology, config API support, running as non-root, Sentinel, Maven, Minion, flow thresholding, discovery config, OIA, TimescaleDB, Log4j2, Karaf, the Twin API, provisioning, the vue geomap, the new UI, and Helm.

Github Project Updates

Internals, APIs, and Documentation
  • Dino created some graphs and collections for prometheus
  • I worked on fixing our grafana package signatures and docker publishing
  • Stefan did more work on Enlinkd performance improvements
  • Chandra updated the IPC code to accept a simplified config for Kafka RPC/Sink/Twin
  • Zoë fixed a hardcoded path in IOwait report template
  • Mark worked on daemon reload and VMware docs
  • Bonnie and Ronny did more work on flow documentation
  • Dmitri, Pushkar, Tikayat, and Upendra worked on config API support for notification, SNMP, WSMan, and WMI configs
  • I fixed a bug in Minion non-root support
  • I updated the installer's non-root write validator to ignore .git and the lib/ and system/ directories
  • Arthur updated the Karaf install to include Alarmd on Sentinel
  • I fixed an error in our pom references to Atlassian's maven repo
  • Pierre did some fixups to the Minion config schema
  • Jesse worked on schema handling in the config API
  • Dustin and Christian did more work on thresholding support for flow data
  • Alberto wrapped up his changes to support exclude-url in discovery
  • Stefan got rid of an unused API in OIA
  • Alberto worked on handling TimescaleDB better in upgrades
  • Jerry worked on the component cleanup project
  • I updated Log4j2
  • Stefan wrote a tool for generating fake flow data
  • Freddy did more work on config management API upgrades
  • Yang Li worked on Collectd and Pollerd support in OIA
  • Patrick continued his work to integrate the config manager and Karaf
  • Chandra fixed an NPE in the topology linkd provider
  • Marcel worked on cleaning up the asset topology provider docs
  • Chandra worked on adding metrics to the twin API
  • Sean updated the SnmpMetadataProvisioningAdapter to support specifying exact OIDs
Web, ReST, UI, and Helm
  • Mike did more work on UI improvements to the new geomap
  • Tripti and Makarand did more updates to the requisition code
  • I did some dependency updates and release stuff for Helm
  • Farid worked on improving popups in the new geomap
  • Maxim cleaned up some stuff in the new UI code
  • Stefan added support for querying string properties in Helm
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Alberto Ramos
  • Arthur Naseef
  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dino Yancey
  • Dmitri Herdt
  • Dustin Frisch
  • Farid Ahmad
  • Freddy Chu
  • Jane Hou
  • Jerry Beuree
  • Jesse White
  • Makarand Patil
  • Marcel Fuhrmann
  • Mark Mahacek
  • Maxim Brener
  • Mike Rose
  • Patrick Schweizer
  • Pierre Bouffard
  • Pushkar Suthar
  • Ronny Trommer
  • Sean Torres
  • Stefan Wachter
  • Tikayat Mohanta
  • Tripti Bansal
  • Upendra Guggilam
  • Yang Li
  • Zoë Knox

Release Roadmap

Completed December 2021 Releases - Horizon 29.0.2, Meridians 2021.1.7, 2020.1.15, 2019.1.26

In December, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 29.

Horizon 29.0.2

Release 29.0.2 contains a fix for a Jetty CVE, plus a number of bug fixes and small enhancements, including changes to user auth, Twin API, VMware, and running as non-root.

For a high-level overview of what has changed in Horizon 29, see What’s New in OpenNMS Horizon 29.

The codename for Horizon 29.0.2 is Satanic Nightjar.

Meridian Point Releases

Meridian 2019.1.26 contains a fix for a Jetty CVE, and an update to fix a bug in user auth changes.

Meridian 2020.1.15 added some SNMP auth related fixes on top of 2019's changes.

Meridian 2021.1.7 added doc updates, auth fixes, and Trapd improvements on top of 2020's updates.

For a list of changes, see the release notes:

Completed Security Releases - Horizon 29.0.3, Meridians 2021.1.8, 2020.1.16, 2019.1.27

On December 13th, we released off-cycle updates to all OpenNMS Meridian versions under active support, as well as Horizon 29, to address the Log4j2 "Log4Shell" vulnerability.

It is strongly recommended that you upgrade to the latest releases immediately.

  • Horizon 29.0.3 (codename Penguin)
  • Meridian 2021.1.8 (codename Cassini)
  • Meridian 2020.1.16 (codename Stack)
  • Meridian 2019.1.27 (codename Ixbalanqué)
Completed Security Releases - Horizon 29.0.4, Meridians 2021.1.9, 2020.1.17, 2019.1.28

On December 16th, we released off-cycle updates to all OpenNMS Meridian versions under active support, as well as Horizon 29, to address additional Log4j2 "Log4Shell" vulnerabilities.

It is strongly recommended that you upgrade to the latest releases immediately.

Helm Releases

Helm 7.2.0 and 7.3.0 were released recently as well.

7.2.0

7.2.0 bumps a bunch of dependencies, improves documentation, tweaks plugin signing, and adds a number of new features, including:

  • More Helm flow dashboard updates (Issue HELM-277)
  • A new "About Helm" dashboard (Issue HELM-281)
  • Support for returning node primary ifIndex and IP address in the entity datasource (Issue HELM-188)
  • New entities in the entity datasource: IP interface, SNMP interface, ifService, outagers (Issue HELM-228)
  • Support for prefixing/suffixing label names of flow series and summaries (Issue HELM-298)
  • Support multiple flow queries per panel (Issue HELM-299)
  • A new dashboard for flow aggregations using data from Cortex/Prometheus (Issue NMS-13374)
  • Fixes for host traffic aggregations from Nephron (Issue NMS-13534)

Packages are available in our repos, as well as the Helm github page.

I am in the process of revamping how we deal with Helm plugin releases so we can get it (re-)submitted to Grafana's upstream plugin registry.

7.3.0

7.3.0 adds a new feature to allow querying string properties in the perf datasource.

  • support string properties in performance datasource (Issue HELM-293)
Upcoming January Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is January 12th, 2021.

We currently expect minor updates to Horizon 29 and all supported Meridian releases.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2022 (Q1 2022)

The current expectation is that we will release Meridian 2022 in Q1 of next year. It will be based on Horizon 29 plus any bug fixes that happen between November and the Meridian release.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-291: debian package for Helm 7.1.2 - unsigned message in Grafana
  • HELM-293: string properties can't be used easily in Helm
  • HELM-296: Create Helm 7.2.0 Release
  • NMS-9889: Update VMWare import documentation regarding multiple parameters
  • NMS-11725: HTTPS monitor with letsencrypt certificates
  • NMS-13507: Enlinkd API response extremely slow for some nodes
  • NMS-13564: Dynamic Configuration of Trap Listener
  • NMS-13589: Geo-Map: port Geo-Map code to ui-foundation
  • NMS-13610: Consolidate all IPC features into one / need conf.d changes
  • NMS-13708: Flow Thresholds: Data collection
  • NMS-13711: Flow Thresholds: Housekeeping
  • NMS-13712: Flow Thresholds: Allow to enable/disable thresholding/data collection
  • NMS-13718: Add "exclude-url" to Discoverd's configuration
  • NMS-13743: Allow collectors exposed via OIA to be scheduled via collectd
  • NMS-13744: Allow monitors exposed via OIA to be scheduled with pollerd
  • NMS-13778: Permission check in ./install -dis flags unwriteable files in the .git directory
  • NMS-13789: 29.0.1 minion should be RUNAS=minion
  • NMS-13790: Flow Thresholds: Compute sequence numbers to support distributed flow thresholding
  • NMS-13807: Phase 1 flows documentation: "Basic" setup
  • NMS-13812: Missing RRD package definition in BMP persisting adapter
  • NMS-13824: Flesh out Prometheus datacollection shipped config
  • NMS-13832: CVE-2021-28164: access to WEB-INF
  • NMS-13842: Extend SnmpMetadataProvisioningAdapter configuration to support exact OID matches
  • NMS-13850: Log4j2 0-day: CVE-2021-44228
  • NMS-13851: Customer is not able to view Topology
  • NMS-13854: validate doc merge
  • NMS-13855: Flow Thresholds: Add ifName to strings.properties
  • NMS-13857: Javascript security updates (December, 2021)
  • NMS-13858: CVE-2021-45046: incomplete Log4j2 vulnerability mitigation

by RangerRick at December 20, 2021 09:40 PM

December 16, 2021

Security Releases – Horizon 29.0.4, Meridians 2021.1.9, 2020.1.17, 2019.1.28

Today we released off-cycle updates to all OpenNMS Meridian versions under active support, as well as Horizon 29, to address additional Log4j2 "Log4Shell" vulnerabilities.

It is strongly recommended that you upgrade to the latest releases immediately.

by RangerRick at December 16, 2021 06:51 PM

December 13, 2021

Security Releases – Horizon 29.0.3, Meridians 2021.1.8, 2020.1.16, 2019.1.27

Today we released off-cycle updates to all OpenNMS Meridian versions under active support, as well as Horizon 29, to address the Log4j2 "Log4Shell" vulnerability.

It is strongly recommended that you upgrade to the latest releases immediately.

  • Horizon 29.0.3 (codename Penguin)
  • Meridian 2021.1.8 (codename Cassini)
  • Meridian 2020.1.16 (codename Stack)
  • Meridian 2019.1.27 (codename Ixbalanqué)

by RangerRick at December 13, 2021 10:22 PM

December 10, 2021

OpenNMS Products Affected by Apache Log4j Vulnerability CVE-2021-44228, CVE-2021-45046, and CVE-2021-45105 (updated Dec. 20, 2021)

Serious remote code execution (RCE) and denial of service (DOS) vulnerabilities in Apache Log4j could affect customers running some OpenNMS products. These vulnerabilities could allow an attacker to shut down or compromise your system by causing OpenNMS to log specially crafted messages into system log files for malicious purposes. Apache Log4j could interpret one of those messages to download, run, or install malicious software.

To mitigate this risk, consult the following list to install the latest OpenNMS software upgrades or work-around.

For more information about the Log4j vulnerability, see the Apache Log4j security notice for CVE-2021-44228, CVE-2021-45046, and CVE-2021-45105 at https://logging.apache.org/log4j/2.x/security.html.

(Updated December 14, 2021 for Horizon 26.1.2 and earlier versions. Updated December 16 for CVE-2021-45046. Updated December 20 for CVE-2021-45105. Major text changes appear in red.) Note that the log4j.formatMsgNoLookups work-around is no longer recommended. We are evaluating CVE-2021-45105 and at this time do not believe our products are affected.

Version: Meridian 2021.1.8, 2020.1.16, 2019.1.27, or earlier
  • Work-around:
    Edit or create $OPENNMS_HOME/etc/log4j2.component.properties file to include the line:
    log4j.formatMsgNoLookups=true

    Remove the JndiLookup class from the classpath (directories that contain log4j files) with this set of commands inside your OpenNMS directory (if you are on Debian, replace "/opt/opennms" with "/usr/share/opennms" instead):
    find /opt/opennms -type f -name *log4j*.jar | while read -r JAR; do
    zip -q -d "$JAR" org/apache/logging/log4j/core/lookup/JndiLookup.class
    done &&
    find /opt/opennms/system -type f -name *log4j*.jar.sha1 -delete &&
    systemctl stop opennms.service &&
    rm -rf /opt/opennms/data/* &&
    systemctl start opennms.service

  • Permanent Fix:
    Upgrade to Meridian 2021.1.9, 2020.1.17, 2019.1.28, or newer
Version: Horizon 26.1.3 through 29.0.2
  • Work-around:
    Edit or create $OPENNMS_HOME/etc/log4j2.component.properties file to include the line:
    log4j.formatMsgNoLookups=true and restart Horizon
  • Permanent Fix:
    Upgrade to Horizon 29.0.3 or newer

Version: Horizon 29.0.3 or earlier

  • Work-around:
    Remove the JndiLookup class from the classpath (directories that contain log4j files) with this set of commands inside your OpenNMS directory (if you are on Debian, replace "/opt/opennms" with "/usr/share/opennms" instead):
    find /opt/opennms -type f -name *log4j*.jar | while read -r JAR; do
    zip -q -d "$JAR" org/apache/logging/log4j/core/lookup/JndiLookup.class
    done &&
    find /opt/opennms/system -type f -name *log4j*.jar.sha1 -delete &&
    systemctl stop opennms.service &&
    rm -rf /opt/opennms/data/* &&
    systemctl start opennms.service
  • Permanent Fix:
    Upgrade to Horizon 29.0.4 or newer
Version: PoweredBy OpenNMS
  • Work-around:
    Not available
  • Permanent Fix:
    Pull from latest GitHub source that has Log4j2 v2.17.0 or newer in pom.xml
Version: Minions derived from Meridian 2021.1.8, 2020.1.16, 2019.1.27, Horizon 29.0.3, or earlier
  • Work-around:
    For each Minion, edit/opt/minion/etc/config.properties config file to include the line:
    log4j.formatMsgNoLookups=true Remove the JndiLookup class from the classpath (directories that contain log4j files) with this set of commands inside your OpenNMS directory (if you are on Debian, replace "/opt/minion" with "/usr/share/minion" instead):
    find /opt/minion -type f -name *log4j*.jar | while read -r JAR; do
    zip -q -d "$JAR" org/apache/logging/log4j/core/lookup/JndiLookup.class
    done &&
    find /opt/minion/system -type f -name *log4j*.jar.sha1 -delete &&
    systemctl stop minion.service &&
    rm -rf /opt/minion/data/* &&
    systemctl start minion.service
  • Permanent Fix:
    Upgrade to Minion included with Meridian 2021.1.9, 2020.1.17, 2019.1.28, Horizon 29.0.4, or newer
Version: Minion Appliance – all versions
  • Work-around:
    Not applicable – Automatic Updates
  • Permanent Fix:
    Appliance service provides automatic updates to Minion appliances to match the version of Meridian or Horizon in use.
Version: Sentinels derived from Meridian 2021.1.8, 2020.1.16, 2019.1.27, Horizon 29.0.3 or earlier
  • Work-around:
    For each Sentinel, edit /opt/sentinel/etc/config.properties config file to include the line:
    log4j.formatMsgNoLookups=true
    Remove the JndiLookup class from the classpath (directories that contain log4j files) with this set of commands inside your OpenNMS directory (if you are on Debian, replace "/opt/minion" with "/usr/share/minion" instead):
    find /opt/minion -type f -name *log4j*.jar | while read -r JAR; do
    zip -q -d "$JAR" org/apache/logging/log4j/core/lookup/JndiLookup.class
    done &&
    find /opt/minion/system -type f -name *log4j*.jar.sha1 -delete &&
    systemctl stop minion.service &&
    rm -rf /opt/minion/data/* &&
    systemctl start minion.service

     

  • Permanent Fix:
    Upgrade to Sentinel included with Meridian 2021.1.9, 2020.1.17, 2019.1.28, Horizon 29.0.4, or newer

Version: Sentinels derived Horizon 26.1.2 or earlier

  • Work-around:
    For each Sentinel, remove the JndiLookup class from the classpath (directories that contain log4j-core-*.jar files) with this command: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class and restart Sentinel
  • Permanent Fix:
    Upgrade to Sentinel included with Horizon 29.0.3 or newer

Addendum

Find out how to verify that the mitigations you put in place are protecting you from CVE-2021-44228 and CVE-2021-45046 in this Discourse article.

by Jeff Jancula at December 10, 2021 10:26 PM

December 08, 2021

December 2021 Releases – Horizon 29.0.2, Meridians 2021.1.7, 2020.1.15, 2019.1.26

In December, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 29.

Horizon 29.0.2

Release 29.0.2 contains a fix for a Jetty CVE, plus a number of bug fixes and small enhancements, including changes to user auth, Twin API, VMware, and running as non-root.

For a high-level overview of what has changed in Horizon 29, see What’s New in OpenNMS Horizon 29.

The codename for Horizon 29.0.2 is Satanic Nightjar.

Meridian Point Releases

Meridian 2019.1.26 contains a fix for a Jetty CVE, and an update to fix a bug in user auth changes.

Meridian 2020.1.15 added some SNMP auth related fixes on top of 2019's changes.

Meridian 2021.1.7 added doc updates, auth fixes, and Trapd improvements on top of 2020's updates.

For a list of changes, see the release notes:

by RangerRick at December 08, 2021 08:15 PM

December 06, 2021

OpenNMS On the Horizon – Config API, OIA, VMware, Twin API, Collectd, Enlinkd, Karaf, Flows, BMP, JAAS, Sentinel, FeatherDS, Vue, Geomaps, Helm

Since last time, we worked on config management and validation, OIA, VMware collection, Twin API tracing, documentation, Collectd, IPC, Enlinkd, Karaf, flow thresholding, Pollerd, router config backup, discovery exclude-url, BMP telemetry RRDs, JAAS and Setinel, FeatherDS UI updates, Vue geomaps, smoke tests, and Helm.

Github Project Updates

Internals, APIs, and Documentation
  • Freddy did some cleanup and cosolidation in the config validation and marshalling code.
  • Jesse worked on some OIA API improvements, including adding health check support.
  • Christian fixed some VMware datacollection config issues.
  • Chandra did more work on tracing support for the Twin API.
  • Stefan fixed an issue with the node/interface cache.
  • Jesse fixed a race condition in eventconf reloading.
  • Bonnie and Ronny updated some BMP, developer, flow, and SNMP datacollection docs.
  • Yang did more work on Collectd refactoring improvements.
  • Tikayat, Pushkar, and Upendra worked on config management support for SNMP, Trapd, WMI, and XMP.
  • Chandra worked on setting up some default IPC config.
  • Patrick continued his work on integrating Karaf and the config API.
  • Stefan worked on some performance improvements to Enlinkd.
  • Christian and Dustin worked on flow thresholding support.
  • Stefan worked around a bug where scheduling in Pollerd could still be referencing deleted services.
  • Dustin worked on TFTP integration for router configs.
  • Alberto worked on exclude-url support in the discovery config.
  • Upendra worked on some DAO ITs for the config management API.
  • Ronny added a default RRD config for BMP telemetry.
  • Mark Bordelon worked on some PoC code for jaas authentication in Sentinel.
Web, ReST, UI, and Helm
  • Mike did more Feather updates to the UI.
  • Jane and Mike worked on some fixes in the new geomap.
  • Shankar worked on some schema REST tests.
  • Stefan updated Helm to not use legacy (Angular) promises.
  • Stefan made it possible to use multiple queries in the Helm flow datasource.
  • Makarand updated a bunch of UI code to use feather components.
  • Alberto updated the requisitions to remember which node layout you're using.
  • I worked on some OpenNMS.js dependency updates.
  • Stefan added support to the query "hide" flag in Helm for flows.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Alberto Ramos
  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Freddy Chu
  • Jane Hou
  • Jesse White
  • Makarand Patil
  • Mark Bordelon
  • Mark Mahacek
  • Mike Rose
  • Patrick Schweizer
  • Pushkar Suthar
  • Ronny Trommer
  • Shankar Suman
  • Stefan Wachter
  • Tikayat Mohanta
  • Upendra Guggilam
  • Yang Li
  • Zoë Knox

Release Roadmap

Upcoming December Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is December 8th, 2021.

We currently expect minor updates to Horizon 29 and all supported Meridian releases.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2022 (Q1 2022)

The current expectation is that we will release Meridian 2022 in Q1 of next year. It will be based on Horizon 29 plus any bug fixes that happen between November and the Meridian release.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • NMS-12992: Update labelling in Configure Discover screen
  • NMS-13212: Vertical/Horizontal Layout Choice Not Persisting
  • NMS-13421: BMP monitoring documentation diagram update
  • NMS-13508: Node cache gets out of sync with database
  • NMS-13579: Link to release notes in web Help / About needs updating
  • NMS-13650: Tracing support for twin communication
  • NMS-13659: Minion /etc/sysconfig/minion file refers to Sentinel
  • NMS-13685: Document how to install from source
  • NMS-13689: Deprecate wiki to public, make internal only
  • NMS-13690: Make Wiki internal only
  • NMS-13709: Flow Thresholds: Scheduling for data collection & thresholding
  • NMS-13731: Twin logs doesn't appear in ipc.log
  • NMS-13739: Add OIA plugin support for Minion
  • NMS-13765: Optionally include a table of event parameters on the event detail page
  • NMS-13772: Web-based file editor for $OPENNMS_HOME/etc/
  • NMS-13779: Remove link to wiki from the landing page
  • NMS-13780: Add support for VMware 7.0.3 performance data collection
  • NMS-13781: Uncatched exception when importing a VMware virtual machine without an IP interface
  • NMS-13787: OIA event configuration extensions do not work reliably
  • NMS-13788: opennms-webapp-hawtio %post chown errors
  • NMS-13798: Update FeatherDS, replace LightDark icon, replace sidebar with navigation rail

by RangerRick at December 06, 2021 10:47 PM

November 29, 2021

OpenNMS On the Horizon – Docs, Karaf, Config Management, Twin API, Maven, VMware, Flows, Thresholding, Collectd, Enlinkd, OIA, Minion, FeatherDS UI, Geomap, REST

Since last time, we worked on docs, Karaf support and config migration in the config management API, the Twin API, Maven component mapping, integration test fixes, VMware support, flow thresholding, collector and Enlinkd improvements, OIA on the Minion, file editing in the new UI, the Vue geomap, requisition editing, and REST APIs.

Github Project Updates

Internals, APIs, and Documentation
  • Mark worked on daemon config docs.
  • Patrick did more work on Karaf internal support for config stored in the CM API.
  • Chandra continued his changes to add tracing support to the Twin API.
  • Pushkar, Dmitri, and Upendra worked on migrating the JMX, SNMP, Trapd, WMI, and XMP configs to the CM API.
  • Bonnie worked on more migration of docs from the wiki.
  • Freddy did more work on validation/mapping in the CM API.
  • Jerry and Jesse did more work on a tool for mapping our Maven components.
  • Tikayat worked on integration test changes related to the CM API.
  • Shankar wrapped up some VMware integration updates.
  • Dustin worked on thresholding for flow data.
  • Marcel worked on some updates to the asset topology provider docs.
  • Yang Li worked on some improvements to the collector engine.
  • David Schlenk contributed a fix for role and user changes.
  • Stefan worked on some performance improvements to Enlinkd queries.
  • Ronny added support for collecting from VMware 7.x.
  • Bonnie worked on some BMP monitoring and flow doc updates.
  • Stefan continued to work on cleaning up Karaf bundle auto-refresh behavior.
  • Ronny updated the developer docs to include instructions on running PostgreSQL in a container.
  • Jesse worked on adding support for running OIA plugins on the Minion.
Web, ReST, UI, and Helm
  • Mike did more work on web-based file editing as well as some refactoring in the new UI.
  • Jane worked on some cleanup of the new Vue geomap code.
  • Farid and Jane continued to work on wrapping up alarm marker color updates in the geomap.
  • Tripti worked on dependency updates in the new UI.
  • Jesse did some build updates to the new UI.
  • Alberto worked on a fix to remember layout preferences in the requisition editor.
  • Shankar made some unit tests for the REST API for the CM backend.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Alberto Ramos
  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • David Schlenk
  • Dmitri Herdt
  • Dustin Frisch
  • Farid Ahmad
  • Freddy Chu
  • Jane Hou
  • Jerry Beuree
  • Jesse White
  • Marcel Fuhrmann
  • Mark Mahacek
  • Mike Rose
  • Patrick Schweizer
  • Pushkar Suthar
  • Ronny Trommer
  • Shankar Suman
  • Stefan Wachter
  • Tikayat Mohanta
  • Tripti Bansal
  • Upendra Guggilam
  • Yang Li

The Wiki is Dead, Long Live the (Discourse) Wiki

As many of you know, the OpenNMS wiki has long been a bit of a mess.
A bunch of folks have been doing the hard work of migrating the useful bits to the Discourse.

At this point, the value of keeping the wiki around is lower than the value of closing it down, so we are going to finally do just that, on December 1st.

We'll keep an internal copy around in case we need to migrate anything else that got missed, so if you can think of something specific that really needs moving over, let us know.

The new location for general (non-versioned) configuration tips and other useful stuff in the Knowledge Base category of the OpenNMS Discourse.

Knowledge Base.

Discourse.

Tell your friends.

Release Roadmap

Upcoming December Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is December 8th, 2021.

We currently expect a minor update to Horizon 29.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2022 (Q1 2022)

The current expectation is that we will release Meridian 2022 in Q1 of next year. It will be based on Horizon 29 plus any bug fixes that happen between November and the Meridian release.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-299: Support multiple flow queries per panel
  • NMS-8769: New created user cannot login
  • NMS-13532: Migrate ResourceTypes from wiki to docs
  • NMS-13538: SNMP Asset Provisioning Adapter missing docs
  • NMS-13561: Geo map: Display different colors on map base on alarm severity
  • NMS-13605: Geo-Map: make Alarms | Nodes tab more apparent
  • NMS-13632: geo-map: rename "LAST CAPABILITIES SCAN", "Apply Filter" and "Submit"
  • NMS-13665: Geo-Map: add Feather UI to geo-map project
  • NMS-13706: Flow Thresholds: Proof-of-concept implementation (in-memory approach)
  • NMS-13749: Improve Related Events box in Alarm detail page
  • NMS-13761: Authorization changes not taking immediate effect
  • NMS-13771: Flow Threshold: Create session by Interface Id
  • NMS-13774: VMware sessions not correctly closed in all cases

by RangerRick at November 29, 2021 07:16 PM

November 22, 2021

OpenNMS On the Horizon – Config API, Docs, Twin API, SNMP Metadata, Maven, Zabbix, Sentinel, JAXB, Karaf, Collectd, Alarms, ALEC, Vue, Geomap, FeatherDS

Since last time, we worked on migrating configs to the database, documentation improvements, the Twin API, SNMP metadata, Maven, the Zabbix adapter, alarms in Sentinel, JAXB processing, Karaf, Collectd, Alarmd and ALEC collections, the Vue geomap, and the new FeatherDS UI.

Github Project Updates

Internals, APIs, and Documentation
  • Dmitri, Pushkar, Shankar, and Upendra worked on loading JMX, notification, Trapd, VMware, WMI, and XMP configurations into the database.
  • Mark and Ronny worked on some documentation updates and improvements,
    including building OpenNMS from source and Kafka producer config.
  • Chandra fixed some issues in Twin API communication found in Horizon 29.
  • Dustin finished adding some retry logic to the Twin API.
  • I fixed a bug in the snmp-metadata-adapter-configuration.xml processing so that it would
    accept multiple <config> blocks.
  • Jesse did some work classifying our Maven build structure.
  • I worked on improving some smoke test flappers.
  • Yang Li did some more work on the Zabbix adapter.
  • Mark Bordelon did more work on alarm-processing support in Sentinel.
  • Patrick did more work on using the new config management API for handling Karaf config.
  • Christian enhanced hardware discovery events to include some extra metadata metadata.
  • Freddy worked on converting some JAXB code to use EclipseLink rather than MOXY.
  • Stefan did some more work on Karaf bundle refresh.
  • I fixed some non-root bugs found in Horizon 29.0.0.
  • Yang Li worked on some threading improvements to Collectd.
  • Marcel worked on refactoring some reporting and topology provider docs.
  • Chandra worked on adding tracing to the Twin API.
  • Dino added some new collections and graphs for Alarmd and ALEC.
  • Bonnie worked on migrating some ResourceType documentation from the wiki to the docs.
Web, ReST, UI, and Helm
  • Jane worked on layout updates to the new Vue-based geomap.
  • Mike and Jesse continued to work on file editing in the new UI.
  • Tripti did more work on the new provisioning config UI and updating some code to use FeatherDS.
  • Jane and Farid worked on alarm coloring in the Vue geomap.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dino Yancey
  • Dmitri Herdt
  • Dustin Frisch
  • Freddy Chu
  • Jane Hou
  • Jerry Beuree
  • Jesse White
  • Marcel Fuhrmann
  • Mark Bordelon
  • Mark Mahacek
  • Mike Rose
  • Patrick Schweizer
  • Pushkar Suthar
  • Ronny Trommer
  • Shankar Suman
  • Stefan Wachter
  • Tikayat Mohanta
  • Tripti Bansal
  • Upendra Guggilam
  • Yang Li

The Wiki is Dead, Long Live the (Discourse) Wiki

As many of you know, the OpenNMS wiki has long been a bit of a mess.
A bunch of folks have been doing the hard work of migrating the useful bits to the Discourse.

At this point, the value of keeping the wiki around is lower than the value of closing it down, so we are going to finally do just that, on December 1st.

We'll keep an internal copy around in case we need to migrate anything else that got missed, so if you can think of something specific that really needs moving over, let us know.

The new location for general (non-versioned) configuration tips and other useful stuff in the Knowledge Base category of the OpenNMS Discourse.

Knowledge Base.

Discourse.

Tell your friends.

Release Roadmap

Completed Off-schedule Release: Horizon 29.0.1

Horizon 29.0.1 is a quick release outside of the normal schedule to address some bugs found in 29.0.0 mostly related to running as non-root, and Minion communication.

For a high-level overview of what has changed in Horizon 29, see What’s New in OpenNMS Horizon 29.

The codename for Horizon 29.0.1 is Emu.

Bug
  • Kafka topics should start with OpenNMS Instance ID for Twin (Issue NMS-13733)
  • opennms.spec file tries to find out if gid 1000 is used but doesn’t actually check hat (Issue NMS-13734)
  • Events from Hardware Inventory Provisioning Adapter and SNMP Metadata Provisioning Adapter cannot be distinguished (Issue NMS-13735)
  • Upgrade to 29: fix-permissions script fails changing ownership (Issue NMS-13736)
  • Minion user not authorized to read from topic OpenNMS.Twin.Sink (Issue NMS-13742)
  • opennms-plugin-provisioning-wsman-asset missing on Debian (Issue NMS-13747)
  • Upgrade to 29: "$RUNAS is not set" (Issue NMS-13748)
  • SNMP Metadata XSD does not allow multiple <config> elements (Issue NMS-13752)
Enhancement
  • Support multiple auth params for same SNMPV3 username (Issue NMS-13490)
  • Add retry for RPC calls (Issue NMS-13652)
  • Migrate Discovery settings from wiki into docs (Issue NMS-13730)

Upcoming December Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is December 8th, 2021.

We currently expect a minor update to Horizon 29.

Next Horizon: 30 (Q2 2022)

The next major Horizon release will be Horizon 30.

Horizon 30 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2022 (Q1 2022)

The current expectation is that we will release Meridian 2022 in Q1 of next year. It will be based on Horizon 29 plus any bug fixes that happen between November and the Meridian release.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • NMS-10536: Add a breaking change entry for telemetryd-configuration in the release notes
  • NMS-11769: Scheduled Weekly Outages Missing 'Day of the Week'
  • NMS-12111: Event and alarm templates fail with Elasticsearch 7.X
  • NMS-13419: CI: Don't publish artifacts until smoke tests have passed
  • NMS-13490: Support multiple auth params for same SNMPV3 username
  • NMS-13733: Kafka topics should start with OpenNMS Instance ID for Twin
  • NMS-13735: Events from Hardware Inventory Provisioning Adapter and SNMP Metadata Provisioning Adapter cannot be distinguished
  • NMS-13747: opennms-plugin-provisioning-wsman-asset missing on Debian
  • NMS-13748: Upgrade to 29: "$RUNAS is not set"
  • NMS-13752: SNMP Metadata XSD does not allow multiple <config> elements

by RangerRick at November 22, 2021 07:39 PM

OpenNMS Horizon 29.0.1 Released

Horizon 29.0.1 is a quick release outside of the normal schedule to address some bugs found in 29.0.0 mostly related to running as non-root, and Minion communication.

For a high-level overview of what has changed in Horizon 29, see What’s New in OpenNMS Horizon 29.

The codename for Horizon 29.0.1 is Emu.

Bug

  • Kafka topics should start with OpenNMS Instance ID for Twin (Issue NMS-13733)
  • opennms.spec file tries to find out if gid 1000 is used but doesn’t actually check hat (Issue NMS-13734)
  • Events from Hardware Inventory Provisioning Adapter and SNMP Metadata Provisioning Adapter cannot be distinguished (Issue NMS-13735)
  • Upgrade to 29: fix-permissions script fails changing ownership (Issue NMS-13736)
  • Minion user not authorized to read from topic OpenNMS.Twin.Sink (Issue NMS-13742)
  • opennms-plugin-provisioning-wsman-asset missing on Debian (Issue NMS-13747)
  • Upgrade to 29: "$RUNAS is not set" (Issue NMS-13748)
  • SNMP Metadata XSD does not allow multiple <config> elements (Issue NMS-13752)

Enhancement

  • Support multiple auth params for same SNMPV3 username (Issue NMS-13490)
  • Add retry for RPC calls (Issue NMS-13652)
  • Migrate Discovery settings from wiki into docs (Issue NMS-13730)

by RangerRick at November 22, 2021 02:22 PM

November 15, 2021

OpenNMS On the Horizon – Provisiond, Karaf, Enlinkd, LLDP, Config API, Docs, Sentinel, Twin API, Non-Root, Maven, Pollerd, IPv6, GeoIP, Flows, Azure, PostgreSQL, Kafka, Geomaps, FeatherDS, Vue, Helm

Since last time, we worked on Provisiond, Karaf, Enlinkd and LLDP, the config management API, documentation, Sentinel, the Twin API, running as non-root, Maven improvements, Pollerd, IPv6 in the GeoIP provisioning adapter, config validation, flows, Azure PostgreSQL support, Kafka, Geomaps, FeatherDS Vue UI, and Helm.

Github Project Updates

Internals, APIs, and Documentation
  • Christian fixed an NPE in provisioning
  • Stefan worked on some changes to bundle refresh in Karaf
  • Christian worked on a performance issue in enlinkd
  • Freddy cleaned up some test infrastructure in the config management branch
  • Mark worked on KSC report, Discovery, and SSL documentation
  • Mark Bordelon started implementing some event forwarding infrastructure for Sentinel
  • Chandra did more work on some Twin API improvements
  • Maxim worked on some Sentinel smoke test issues
  • I fixed a number of bugs in non-root support
  • Jerry and Jesse worked on some tools to map out Maven project components
  • Ronny updated the docs to note about time sync issues between devices
  • Stefan worked on some performance improvements to poller locking
  • Antonio did more work on LLDP enhancements in Enlinkd
  • Christian added IPv6 support to the GeoIP provisioning adapter
  • Freddy did more work on storing validation info in the DB rather than XSDs
  • Tikayat worked on migrating the WMI config to the config management API
  • Dustin made some cache improvements to flow code
  • Ronny updated the supported version docs for various 3rd-party tools
  • Yang fixed the installer to work with Azure user@host style PostgreSQL usernames
  • Pushkar worked on trapd-configuration.xml support in the config management API
  • Patrick worked on persisting Karaf configuration to the config management database
  • Sean contributed an update to Kafka dependencies 3.0.0
Web, ReST, UI, and Helm
  • Jane worked on UI updates to the vue geomap including transitioning to Feather
  • Farid did more work on showing alarm severity color on the vue geomap markers
  • Mike worked on showing logs in the new UI
  • Tripti, Mike, and Makarand worked on wrapping up the PoC for the new UI
  • Stefan added support for adding a prefix or suffix to Helm results
  • Stefan worked on support for multiple flow queries per panel in Helm
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Antonio Russo
  • Benjamin Reed
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Farid Ahmad
  • Freddy Chu
  • Jane Hou
  • Jerry Beuree
  • Jesse White
  • Makarand Patil
  • Mark Bordelon
  • Mark Mahacek
  • Maxim Brener
  • Mike Rose
  • Patrick Schweizer
  • Pushkar Suthar
  • Ronny Trommer
  • Sean Torres
  • Stefan Wachter
  • Tikayat Mohanta
  • Tripti Bansal
  • Yang Li

Release Roadmap

Completed November 2021 Releases - Horizon 29.0.0, Meridians 2021.1.6, 2020.1.14, 2019.1.25

In November, we released updates to all OpenNMS Meridian versions under active support, and introduced a new major release of Horizon.

Horizon 29.0.0

Release 29.0.0 is the first in the Horizon 29 series, introducing running as non-root by default, optimizations to Minion communication, time-series improvements, support for Cortex for storing flow data, and more.

For a high-level overview of what has changed in Horizon 29, see What’s New in OpenNMS Horizon 29.

The codename for Horizon 29.0.0 is Turkey.

Meridian Point Releases

Meridian 2019.1.25 included a few small features updates and a number of bug fixes, including an XSS security issue in the notifications wizard.

Meridian 2020.1.14 added a fix for handling multiple authentication params in SNMPv3.

Meridian 2021.1.6 included an additional ReST fix, plus a number of documentation updates.

For a list of changes, see the release notes:

Upcoming December Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is December 8th, 2021.

We currently expect a minor update to Horizon 29.

Next Horizon: 30 (Q1 2022)

The next major Horizon release will be Horizon 30.

Horizon 29 is currently expected to have the following features:

  • the start of a new Vue-based UI using the Feather Design System
  • thresholding support for Flow data
  • support for running OIA plugins on Minion and Sentinel
  • support for backing up router configuration files
Next Meridian: 2022 (Q1 2022)

The current expectation is that we will release Meridian 2022 in Q1 of next year. It will be based on Horizon 29 plus any bug fixes that happen between November and the Meridian release.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • HELM-220: Decommission Helm on Bamboo
  • HELM-298: Allow to prefix / suffix label names of flow series / summaries
  • NMS-12177: Ubuntu /etc/init.d/opennms file
  • NMS-12349: Create some services for firewalld
  • NMS-12810: Update Provisioning chapter
  • NMS-13284: EvaluationMetrics.log is contaminated with non-related metrics.
  • NMS-13372: Provide ability to store aggregated flow data from Nephron in Cortex
  • NMS-13496: Reflected XSS in webapp notice wizard
  • NMS-13642: Update docs with Twin implementation
  • NMS-13652: Add retry for RPC calls
  • NMS-13715: Install script fails when using Azure PostgreSQL Services
  • NMS-13716: Upgrade Kafka components to 3.0.0
  • NMS-13720: Initial framework for new UI developed with Vue3 & FeatherDS
  • NMS-13721: Update Netty to 4.1.69
  • NMS-13724: Add hint for time sync on OpenNMS components
  • NMS-13725: invalid permissions in /var/opennms on fresh install
  • NMS-13726: JMS Twin doesn't work with minion user
  • NMS-13727: Remove reference to DHCP plugin from docs
  • NMS-13728: GeoIP Provisioning Adapter: SubnetUtils does not support IPv6
  • NMS-13730: Migrate Discovery settings from wiki into docs
  • NMS-13734: opennms.spec file tries to find out if gid 1000 is used but doesn't actually check hat
  • NMS-13736: Upgrade to 29: fix-permissions script fails changing ownership
  • NMS-13740: 28.1.1 deb package is missing opennms-snmp-metadata-provisioning-adapter-28.1.1.jar
  • NMS-13742: Minion user not authorized to read from topic OpenNMS.Twin.Sink
  • OIA-16: Time series persistence strategy

by RangerRick at November 15, 2021 09:53 PM

November 10, 2021

November 2021 Releases – Horizon 29.0.0, Meridians 2021.1.6, 2020.1.14, 2019.1.25

In November, we released updates to all OpenNMS Meridian versions under active support, and introduced a new major release of Horizon.

Horizon 29.0.0

Release 29.0.0 is the first in the Horizon 29 series, introducing running as non-root by default, optimizations to Minion communication, time-series improvements, support for Cortex for storing flow data, and more.

For a high-level overview of what has changed in Horizon 29, see What’s New in OpenNMS Horizon 29.

The codename for Horizon 29.0.0 is Turkey.

Meridian Point Releases

Meridian 2019.1.25 included a few small features updates and a number of bug fixes, including an XSS security issue in the notifications wizard.

Meridian 2020.1.14 added a fix for handling multiple authentication params in SNMPv3.

Meridian 2021.1.6 included an additional ReST fix, plus a number of documentation updates.

For a list of changes, see the release notes:

by RangerRick at November 10, 2021 08:12 PM

November 08, 2021

OpenNMS On the Horizon – Horizon 29, Zabbix, Karaf, Twin API, Documentation, Config API, SNMPv3, macOS, Schemas, gRPC, PostgreSQL, SQS, Minion, REST, JavaMail, GeoIP, LLDP, Healthcheck, Geomaps, Vue, featherDS

Since last time, we prepped for Horizon 29 and worked on Zabbix agent support, test fixes, Karaf, the Twin API, documentation, the config management API, SNMPv3 settings, macOS Monterey fixes, schema handling, gRPC, PostgreSQL, SQS, Minion, REST, JavaMail TLS, GeoIP provisioning, Enlinkd LLDP, healthcheck, the web config editor, vue Geomaps, and the new featherDS UI.

Github Project Updates

Internals, APIs, and Documentation
  • Yang Li and Jesse did some more work on Zabbix agent support.
  • I forked the release-29.x branch in preparation for the upcoming Horizon 29.
  • Dustin cleaned up some Karaf shell code for the Twin API.
  • David Schlenk made ping less demonic 😈
  • Maxim worked on config API updates.
  • Christian worked on wrapping up support for multiple SNMPv3 settings per user.
  • Christian fixed a bug in starting OpenNMS on macOS Monterey.
  • Freddy made some improvements to config API schema handling.
  • Chandra cleaned up some gRPC/Karaf service code.
  • I updated H29 to support PostgreSQL versions through 14.
  • Dustin removed the last vestiges of SQS support.
  • David Schlenk's changes to update JavaMail to 1.6 (for better TLS support) were merged to Horizon 29.
  • Christian worked on wrapping up his GeoIP provisioning adapter.
  • Antonio worked on some updates to Enlinkd LLDP support.
  • Sean worked on bumping the Kafka test dependencies to v3.
  • Chandra did more work on Twin API patch (incremental update) support.
  • Patrick worked on moving the datasources config to the new config manager.
  • Chandra added healthcheck support for the Kafka twin subscriber.
Web, ReST, UI, and Helm
  • Freddy did more work on the config ReST API.
  • Mike continued to work on the config editor UI.
  • Tripti worked on some updates to the UI code.
  • The first proof-of-concept of the new featherDS Vue UI has been merged to develop.
  • Stefan removed unneccesary REST client code from the Minion.
  • Farid worked on some alarm code in the new Geomaps.
  • Jane worked on some visual improvements to the new Geomaps.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Antonio Russo
  • Benjamin Reed
  • Chandra Gorantla
  • Christian Pape
  • David Schlenk
  • Dustin Frisch
  • Farid Ahmad
  • Freddy Chu
  • Jane Hou
  • Jesse White
  • Maxim Brener
  • Mike Rose
  • Patrick Schweizer
  • Sean Torres
  • Stefan Wachter
  • Tripti Bansal
  • Yang Li

Reminder: Breaking Changes Coming in Horizon 29

With Horizon 29 slated for release this week, here is one last reminder to note some changes that are coming.

Along with a bunch of bug fixes and enhancements, we have a couple of things that are changing significantly that it's worth noting.

  1. OpenNMS will run as non-root by default.
    However, because it is possible to have a significant number of resources
    writing files into the $OPENNMS_HOME/share directory, we will not automatically
    fix ownership of those files on upgrade, because it could take an indeterminate
    amount of time to run chown on the entire shared data tree.

    Be prepared for some downtime while upgrading.

  2. Minion Communication Changes
    If you are using gRPC or Kafka for Minion communication, you will need to perform
    some additional configuration with the introduction of the new Twin API.

    If you are using SQS for Minion communication, it will no longer be supported as of Horizon 29.

  3. Time-Series Metadata Changes
    Resource level string attributes are now also stored via the plugin in the respective time series database.
    The timeseries_meta table which previously stored this metadata has been removed.
    There is no migration; string values are generally updated on the next poll.

Release Roadmap

Upcoming December Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is December 8th, 2021.

We currently expect a minor update to Horizon 29.

Next Horizon: 29 (Q4 2021)

The next major Horizon release will be Horizon 29.

Horizon 29 will be a new release branch for Horizon, introducing a ton of bug fixes and cleanups, plus a number of new features:

  • running as non-root by default
  • the Minion's communication has been refactored to get rid of out-of-band ReST calls to the OpenNMS core
  • persistence of flows to Cortex
  • many improvements and optimizations to Nephron, flow processing, and flow classification
  • a number of other improvements to polling, metadata handling, and validation
  • Enlinkd support for TIMETRA-LLDP-MIB-capable devices
Next Meridian: 2022 (Q1 2022)

The current expectation is that we will release Meridian 2022 in Q1 of next year. It will be based on Horizon 29 plus any bug fixes that happen between November and the Meridian release.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • NMS-1652: Data Collection Retries not really Retries
  • NMS-12717: Prometheus collector won't process untyped metrics
  • NMS-13283: The node and interface counters of the Evaluation Layer are incorrect
  • NMS-13402: Integrate Object replication with Trapd (for SNMPV3 Users)
  • NMS-13488: Add Karaf Command to add query and publish Twin Objects
  • NMS-13576: Support partial updates to Twin API
  • NMS-13598: Add version support for Twin Object retrieval
  • NMS-13636: Components that use JavaMail unable to use TLS 1.2+
  • NMS-13637: Discover LLDP topology on devices running MikroTik RouterOS
  • NMS-13640: Drop SQS support
  • NMS-13641: Remove Rest Client / OpenNMS Rest Health Checks on Minion
  • NMS-13663: Add Health Check for Twin on Minion
  • NMS-13701: Add Twin feature/strategy to conf.d/smoke test
  • NMS-13704: GeoIP Provisioning Adapter
  • NMS-13714: Allow PostgreSQL 14
  • NMS-13717: SNMP Metadata Provisioning Adapter: wrong line in debian/rules
  • NMS-13719: NPE when synchronizing requisition with existing nodes in database

by RangerRick at November 08, 2021 07:40 PM

November 01, 2021

OpenNMS On the Horizon – Config Manager, Zabbix, Enlinkd, MikroTik, Twin API, SNMP, Docs, IFTTT, Flows, Vue UI, Geomaps

Since last time, we worked on the config manager API schemas, imports, validation, and editing, a proof-of-concept Zabbix agent plugin, Enlinkd optimization and MikroTik router support, the Twin API, SNMP improvements, documentation, IFTTT SSL handling, Flows, startup, related events, the featherDS Vue UI, and Vue geomaps.

Github Project Updates

Internals, APIs, and Documentation
  • Freddy worked on exposing an OpenAPI URL with config manager schemas.
  • Jesse and Yang Li worked on a plugin for interacting with the Zabbix agent.
  • Antonio worked on discovering topology on MikroTik routers.
  • Upendra updated the config manager to import trapd-configuration.xml.
  • Chandra did more improvements to the gRPC Twin implementation.
  • Shankar updated the config manager to import enlinkd-configuration.xml.
  • Chandra changed the SNMP API to use the full trap OID even if the sub-id is 0.
  • Dustin worked on wrapping up the JMS and in-memory implementations of the Twin API.
  • Patrick reworked some of the config API implementation for managing types and validation.
  • Chandra simplified some response handling in the core Twin API.
  • Christian optimized some bridge node handling in Enlinkd.
  • Tikayat updated the config manager to import discovery-configuration.xml.
  • Bonnie worked on a glossary of terms for the docs.
  • Stefan updated the documentation for Cortex persistence.
  • David Schlenk contributed a fix to honor START_TIMEOUT in systemd mode.
  • Patrick started to implement .cfg importing into the config API.
  • Chandra worked on supporting "patch" changes in Twin API communication.
  • Chandra added node label and location to protobuf node metadata.
  • Christian wrapped up his SSL handling changes for IFTTT.
  • Christian fixed an issue with connecting to the local JVM.
  • Dustin started to work on adding thresholding support to flow data.
  • Marcel continued working on daemon reload documentation.
  • Stefan did more work on flow document optimizations.
  • David Schlenk contributed a fix to the "related events" UI when no metadata matches.
Web, ReST, UI, and Helm
  • Mike and Sagar continued work on the new featherDS Vue UI, including UX improvements, validation, and a GUI file editor.
  • Jane worked on autosizing and other UX improvements in the new Vue geomaps.
  • Jesse worked on exposing certain config files over ReST.
Contributors

Thanks to the following contributors for committing changes since last OOH:

  • Antonio Russo
  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • David Schlenk
  • Dustin Frisch
  • Freddy Chu
  • Jane Hou
  • Jesse White
  • Marcel Fuhrmann
  • Mark Mahacek
  • Maxim Brener
  • Mike Rose
  • Patrick Schweizer
  • Sagar Salunkhe
  • Shankar Suman
  • Stefan Wachter
  • Tikayat Mohanta
  • Tripti Bansal
  • Upendra Guggilam
  • Yang Li

Reminder: Breaking Changes Coming in Horizon 29

With Horizon 29 slated for next month, I wanted to take a moment to note some changes that are coming.

Along with a bunch of bug fixes and enhancements, we have a couple of things that are changing significantly that it's worth noting.

  1. OpenNMS will run as non-root by default.
    However, because it is possible to have a significant number of resources
    writing files into the $OPENNMS_HOME/share directory, we will not automatically
    fix ownership of those files on upgrade, because it could take an indeterminate
    amount of time to run chown on the entire shared data tree.

    Be prepared for some downtime while upgrading.

  2. Amazon SQS support for communicating with Minion will be removed.
    RPC communication and the handling of configuration are changing significantly
    enough that we would need to rewrite the SQS component and we don't believe
    it to be in wide deployment, compared to using gRPC or Kafka.

  3. Time-Series Metadata Changes
    Resource level string attributes are now also stored via the plugin in the respective time series database.
    The timeseries_meta table which previously stored this metadata has been removed.
    There is no migration; string values are generally updated on the next poll.

Release Roadmap

Upcoming November Releases

OpenNMS is on a monthly release schedule, with releases happening on the second Wednesday of the month.

The next OpenNMS release day is November 10th, 2021.

We currently expect the first release in the Horizon 29 series, as well as updates to Meridians 2019 through 2021.

Next Horizon: 29 (Q4 2021)

The next major Horizon release will be Horizon 29.

Horizon 29 will be a new release branch for Horizon, introducing a ton of bug fixes and cleanups, plus a number of new features:

  • running as non-root by default
  • the Minion's communication has been refactored to get rid of out-of-band ReST calls to the OpenNMS core
  • persistence of flows to Cortex
  • many improvements and optimizations to Nephron, flow processing, and flow classification
  • a number of other improvements to polling, metadata handling, and validation
  • Enlinkd support for TIMETRA-LLDP-MIB-capable devices
Next Meridian: 2022 (Q1 2022)

The current expectation is that we will release Meridian 2022 in Q1 of next year. It will be based on Horizon 29 plus any bug fixes that happen between November and the Meridian release.

Disclaimer

Note that this is just based on current plans; dates, features, and releases can change or slip depending on how development goes.

The statements contained herein may contain certain forward-looking statements relating to The OpenNMS Group that are based on the beliefs of the Group’s management as well as assumptions made by and information currently available to the Group’s management. These forward-looking statements are, by their nature, subject to significant risks and uncertainties.

...We apologize for the excessive disclaimers. Those responsible have been sacked.

Mynd you, møøse bites Kan be pretti nasti...

We apologise again for the fault in the disclaimers. Those responsible for sacking the people who have just been sacked have been sacked.

Until Next Time…

If there’s anything you’d like me to talk about in a future OOH, or you just have a comment or criticism you’d like to share, don’t hesitate to say hi.

- Ben

Resolved Issues Since Last OOH

  • NMS-2510: RRD creation for JMX data fails
  • NMS-3171: HttpMonitor doesn't check JSON responses for response-text
  • NMS-3336: provisiond : snmpinterfaces not created
  • NMS-3736: Resource Graphs and custom time period error while refreshing
  • NMS-3848: Reasons Missing From nodeLostService events
  • NMS-12611: Documentation for reloadable daemons
  • NMS-12778: Incorporate node related information to events and alarms topic in opennms-kafka-producer feature
  • NMS-13377: Nephron: Get rid of convo_key and grouped_by_key
  • NMS-13437: The Info ReST endpoint is not showing the services status
  • NMS-13487: Grpc IPC and Twin should be able to run from the same port
  • NMS-13490: Support multiple auth params for same SNMPV3 username
  • NMS-13501: IFTTT integration not working anymore
  • NMS-13593: Discovery LLDP Topology for devices supporting TIMETRA-LLDP-MIB
  • NMS-13622: Topologies menu
  • NMS-13627: Move IFTTT integration topic under Alarms
  • NMS-13633: geo-map: "

    " in column "LOG MESSAGE"

  • NMS-13634: geo-map: Adjust to column width
  • NMS-13635: Documentation for the new feature persisting flows in Cortex
  • NMS-13639: geo-map: Add count to the Alarms and Nodes tab name
  • NMS-13660: Nodes with complex hardware configuration are not correctly rendered
  • NMS-13661: automation cleanUpRpStatusChanges that references removed action with same name remains in default vacuumd-configuration.xml configuration
  • NMS-13662: Implement auto-labeling of GitHub Pull Requests
  • NMS-13664: ALEC in distributed mode doesn't start on Sentinel
  • NMS-13670: property name importer.adapter.dns.reverse.level is incorrect in commented out example
  • NMS-13688: Check doc source for wiki links
  • NMS-13700: Create Release Notes for Horizon 29
  • NMS-13702: START_TIMEOUT ignored when run from systemd
  • NMS-13703: macOS Monterey: older OpenNMS branches do not start anymore
  • NMS-13705: related events box in alarm detail shows all events when alarm has no node / interface / service / ifindex

by RangerRick at November 01, 2021 07:57 PM