Planet OpenNMS

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

October 25, 2021

OpenNMS On the Horizon – Docs, Config Management, IFTTT, CI, Twin API, Router Config Backup, Pollerd, Catheter, Nephron, FeatherDS UI, Geomaps, Kafka, GRPC

Since last time, we worked on docs, the configuration management API, IFTTT, CI, the Twin API, router config backup, poller performance, Catheter and Nephron, and the new UI and geomaps.

Github Project Updates

Internals, APIs, and Documentation
  • Bonnie and Mark continued their work on cleaning up and rearranging the admin guide docs.
  • Patrick, Tikayat, and Shankar did more work on the new configuration backend.
  • Christian did some SSL-related bug fixes to the IFTTT integration.
  • I did more work cleaning up CircleCI build issues.
  • Chandra worked on making the Twin API reuse the existing GRPC IPC port and server.
  • Stefan worked on wrapping up his changes to make health-check calls asynchronous.
  • Stefan documented the Cortex integration for Nephron.
  • Stefan cleaned up some extra dependencies in the Minion client.
  • Chandra worked on updating the Twin API to support incremental/partial updates.
  • Marcel worked on daemon reload docs.
  • Chandra, Maxim, Jesse, and Freddy worked on a prototype to back up router configs.
  • Stefan worked on some performance improvements to the poller.
  • I released updated Catheter and Nephron packages.
  • Dustin worked on the Kafka implementation of the Twin API.
Web, ReST, UI, and Helm
  • Sagar did more work on provisiond configuration editing in the new UI.
  • Jane continued her work on implementing the vue-based geomap.
  • Freddy did more work on the configuration ReST API.
Contributors

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

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Freddy Chu
  • Jane Hou
  • Jesse White
  • Marcel Fuhrmann
  • Mark Mahacek
  • Maxim Brener
  • Patrick Schweizer
  • Sagar Salunkhe
  • Shankar Suman
  • Stefan Wachter
  • Tikayat Mohanta
  • Tripti Bansal

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.

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 a Meridian 2021 update.

Next Horizon: 29 (Q4 2021)

The next major Horizon release will be Horizon 29.

The current roadmap for Horizon 29 includes the following goals:

  • running as non-root by default
  • refactor the Minion's communication to get rid of out-of-band ReST calls to the OpenNMS core
  • add support for persistence of flows to Cortex
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-4951: Provisiond never generates nodeCategoryMembershipChanged events
  • NMS-13463: Implement Kafka broker for Object replication ( Twin)
  • NMS-13542: Geo-Map: implement the Acknowlege/Unackowlege... on Alarm grid page
  • NMS-13590: The implementation of HealthCheck.performAsyncHealthCheck is not async
  • NMS-13595: Geo-Map: move map center to selected node while double click the row in the Node grid
  • NMS-13620: geo-map: swap the position of "Alarms" and "Nodes" tab and fix typo "label"
  • NMS-13623: Move Admin Web UI section under Horizon Administration
  • NMS-13625: Move "search" topic under "Administrative Web Interface"
  • NMS-13626: Move Enabling RMI to Horizon Administration section
  • NMS-13628: Move system properties under Horizon Administration
  • NMS-13630: geo-map: Have default sort column
  • NMS-13631: geo-map: disable the hidden filter beside the column name
  • NMS-13655: Lock contention when processing large volume of REST API requests
  • NMS-13666: Handle Publisher Restart for Grpc
  • NMS-13687: Fix JtiTelemetryIT smoke test

by RangerRick at October 25, 2021 07:02 PM

October 18, 2021

OpenNMS On the Horizon – Docs, CI, Health Check, Twin API, LLDP, Config API, TLSv1.3, SNMP, Karaf, Time-Series, GeoIP, Flows, Web UI, Geomaps, ReST

Since last time, we worked on docs, CI automation, health check, the Twin API, LLDP in Enlinkd, the new config api, TLSv1.3 support, SNMP metadata handling, SNMPv3 user settings, Karaf 4.3, time-series processing, user code performance, trapoid handling, GeoIP provisioning, flow templates, web redirects, the new feather UI, geomaps, and ReST.

Github Project Updates

Internals, APIs, and Documentation
  • Mark continued to work on refactoring provisioning documentation.
  • I did a bunch of work cleaning up CircleCI stuff to use newer/recommended ubuntu images for tests.
  • Stefan did more work on improvements to the health-check core.
  • Stefan continued working on changes to optimize flow documents.
  • Chandra worked on optimizations in the Twin API.
  • Jesse worked on updating Enlinkd/topology documentation.
  • Antonio worked on some updates to Enlinkd LLDP handling.
  • Freddy continued his work on the config management backend.
  • Dustin updated some backend API code to use TLSv1.3.
  • Patrick did more work on loading existing configs into the database.
  • Christian did more work on refactoring and improving hardware metadata handling for SNMP.
  • Chandra worked on adding JMS support to the Twin API.
  • Dustin added a Kafka implementation for Twin IPC.
  • Jesse worked on supporting multiple SNMPv3 settings per user.
  • Yang Li wrapped up his work updating the embedded Karaf to 4.3.
  • Alejandro worked on some fixes to time-series processing.
  • Jesse fixed a locking performance issue accessing user info.
  • Chandra did some more work on a trapoid handling bug.
  • Christian worked on a GeoIP provisioning adapter.
  • Christian updated flow option template handling to be thread-safe.
  • Bonnie made some updates to the search documentation.
Web, ReST, UI, and Helm
  • Upendra worked on cleaning up redirect handling in some web controller code.
  • Mike did more work on updating the UI proof-of-concept to FeatherDS.
  • Tripti worked on notification support in the new UI.
  • Jane worked on sorting improvements in the Vue geomap.
  • Sagar worked on more configuration editing improvements in the new UI.
  • Christian fixed the V1 monitoring location ReST API sorting defaults to match V2.
  • Farid worked on updating the Vue geomap to use the AwesomeMarker library for map marker improvements.
Contributors

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

  • Alejandro Galue
  • Antonio Russo
  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dino Yancey
  • Dustin Frisch
  • Farid Ahmad
  • Freddy Chu
  • Jane Hou
  • Jesse White
  • Mark Mahacek
  • Mike Rose
  • Patrick Schweizer
  • Sagar Salunkhe
  • Stefan Wachter
  • Tripti Bansal
  • Upendra Guggilam

Breaking Changes 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.

Release Roadmap

Completed October 2021 Releases - Horizon 28.1.1, Meridians 2021.1.5, 2020.1.13, 2019.1.24

In October, we released updates to all OpenNMS Meridian versions under active support, as well as an update for Horizon 28.

Horizon 28.1.1

Release 28.1.1 contains a number of bug fixes and enhancements, including web UI, Minion, Docker, and documentation improvements.

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

The codename for Horizon 28.1.1 is Mikaela Banes.

Meridian Point Releases

Meridians 2019 and 2020 included some fixes in how Docker containers are generated, plus an enhancement to queries used by Helm to support more fields in queries.

Meridian 2021.1.5 also contains a number of other bug fixes and enhancements, including web UI and documentation improvements.

For a list of changes, see the release notes:

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 a Meridian 2021 update.

Next Horizon: 29 (Q4 2021)

The next major Horizon release will be Horizon 29.

The current roadmap for Horizon 29 includes the following goals:

  • running as non-root by default
  • refactor the Minion's communication to get rid of out-of-band ReST calls to the OpenNMS core
  • add support for persistence of flows to Cortex
Next Meridian: 2022 (Q? 2022)

With Meridian 2021 recently out, we do not yet have a specific timeline for Meridian 2022.

Expect it to include -- at the very least -- the JDK11 requirement and flow aggregation improvements from Horizon 28.
Ideally it will contain work going into Horizons 29 (and probably 30) if our timeline holds. 😅

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-12999: Update adapters documentation
  • NMS-13316: Location dropdown on Add Node does not sort/filter
  • NMS-13461: Implement ActiveMQ broker for Object replication ( Twin)
  • NMS-13501: IFTTT integration not working anymore
  • NMS-13539: Minion stops processing flows with "Invalid packet: null" until restart
  • NMS-13565: Upgrade Karaf to v4.3.2
  • NMS-13594: Provide basic implementation for patch support for Twin
  • NMS-13607: Migrate Import Handlers documentation to Reference
  • NMS-13619: Show Link State when viewing links on the Enlinkd topology maps
  • NMS-13648: Hardware information not displayed for some devices (SnmpMetadataProvisioningAdapter)
  • NMS-13657: Clean unused data in srv001.txt and srv002.txt

by RangerRick at October 18, 2021 07:28 PM

October 14, 2021

October 2021 Releases – Horizon 28.1.1, Meridians 2021.1.5, 2020.1.13, 2019.1.24

In October, we released updates to all OpenNMS Meridian versions under active support, as well as an update for Horizon 28.

Note: Breaking Changes Coming in Horizon 29

We are currently planning on releasing Horizon 29 next month.

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.

Horizon 28.1.1

Release 28.1.1 contains a number of bug fixes and enhancements, including web UI, Minion, Docker, and documentation improvements.

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

The codename for Horizon 28.1.1 is Mikaela Banes.

Meridian Point Releases

Meridians 2019 and 2020 included some fixes in how Docker containers are generated, plus an enhancement to queries used by Helm to support more fields in queries.

Meridian 2021.1.5 also contains a number of other bug fixes and enhancements, including web UI and documentation improvements.

For a list of changes, see the release notes:

by RangerRick at October 14, 2021 05:14 PM

October 12, 2021

OpenNMS On the Horizon – Karaf, Flows, Minion, Docker, Non-Root, Health Check, Config Management, Scriptd, SNMP, JMX, Twin API, IFTTT, Traps, Enlinkd, Provisioning, Geomaps, FeatherDS UI, OpenAPI

Since last time, we worked on documentation, Karaf, the classification engine, the Minion, Docker, running as non-root, health check, config management, CircleCI, Scriptd, SNMP, JMX, the Twin API, IFTTT, flows, traps, Enlinkd, requisitions, Provisiond, Geomaps, the Vue/FeatherDS UI, and OpenAPI ReST updates.

Github Project Updates

Internals, APIs, and Documentation
  • Mark, Bonnie, and Marcel continued to work on refactoring and cleaning up a bunch of documentation, plus adding missing data types and plugins.
  • Yang worked no wrapping up updating our embedded Karaf to 4.3.
  • Stefan did a bit more work on improving performance of classification engine updates.
  • I fixed how minion docker image versions are generated to be more useful in snapshot builds.
  • I fixed a few bugs in setup when running as non-root.
  • Stefan updated the health-check Karaf CLI to support querying by tag.
  • Patrick, Tikayat, Shankar, and Freddy continued to work on the config management backend.
  • Stefan worked on caching/passive health checks and making them asynchronous.
  • I worked on updating some of our CircleCI infrastructure.
  • Alejandro fixed the Scriptd example to match current APIs.
  • Christian worked on additional ways to collect hardware entities from SNMP.
  • Christian fixed an issue with JMX counting in SNMP.
  • Chandra worked on Karaf tools for dealing with the Twin API.
  • Christian updated the IFTTT integration to use the TrustManager.
  • Alejandro fixed a bug in timeseries evaluation.
  • Chandra worked on the JMX twin implementation plus refactoring.
  • Christian fixed some thread safety issues in flow option handling.
  • Chandra worked on some V1 trap handling fixes.
  • Jasper Vandemalle fixed a bunch of typos and such in the docs.
  • Antonio worked on Enlinkd support for TIMETETRA-LLDP-MIB.
  • Stefan did some optimizations for flow data.
  • Chandra worked on updating the Twin API for supporting passing only changes down the wire.
Web, ReST, UI, and Helm
  • Sagar, Jesse, and Maxim worked on requisition handling in the Vue UI.
  • Jane, Farid, and I did more work on the port of the geomap to Vue.
  • Tripti worked on editing provisiond config in the Vue UI.
  • Pushkar and Upendra added OpenAPI docs for the Event, IfService, and Minion ReST services.
  • Mike updated the Vue proof-of-concept to use FeatherDS for UI.
Contributors

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

  • Alejandro Galue
  • Antonio Russo
  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Farid Ahmad
  • Freddy Chu
  • Jane Hou
  • Jasper Vandemalle
  • Jesse White
  • Marcel Fuhrmann
  • Mark Mahacek
  • Maxim Brener
  • Mike Rose
  • Patrick Schweizer
  • Pushkar Suthar
  • Sagar Salunkhe
  • Shankar Suman
  • Stefan Wachter
  • Tikayat Mohanta
  • Tripti Bansal
  • Upendra Guggilam
  • Yang Li

Release Roadmap

Upcoming October Releases

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

The next OpenNMS release day is October 13th, 2021.

We currently expect a Horizon 28 release, as well as all supported Meridians.

Next Horizon: 29 (Q4 2021)

The next major Horizon release will be Horizon 29.

The current roadmap for Horizon 29 includes the following goals:

  • running as non-root by default
  • refactor the Minion's communication to get rid of out-of-band ReST calls to the OpenNMS core
  • add support for persistence of flows to Cortex
  • start the groundwork for replacing the topology UI with a pure-javascript version
Next Meridian: 2022 (Q? 2022)

With Meridian 2021 recently out, we do not yet have a specific timeline for Meridian 2022.

Expect it to include -- at the very least -- the JDK11 requirement and flow aggregation improvements from Horizon 28.
Ideally it will contain work going into Horizons 29 (and probably 30) if our timeline holds. 😅

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-10476: Document data types in collectd
  • NMS-12034: non-root user:group file permissions
  • NMS-13271: Fix example configuration for Scriptd
  • NMS-13458: Nephron: Document Cortex related functionality in Confluence
  • NMS-13489: SNMPv3 traps are not counted correctly in JMX metrics
  • NMS-13510: Merge the Operations/Operations documentation section into Operations/Administration
  • NMS-13514: Geo-map: investigate leaflet marker cluster in vue3
  • NMS-13521: Add OpenAPI docs for EventRestService
  • NMS-13524: Move monitors docs to the Reference section
  • NMS-13525: Move detectors to reference section
  • NMS-13526: Move collectors to reference section
  • NMS-13527: Move telemetryd (streaming telemetry) to reference section
  • NMS-13529: Move ticketing docs to reference section
  • NMS-13547: Minion: Health ReST API: Lightweight/passive health check for broker/OpenNMS
  • NMS-13562: Move provisioning policies to the reference section
  • NMS-13575: Implement HW inventory Provisioning adapter API to support Juniper HW
  • NMS-13577: Optimize ip address handling in flow classification engine
  • NMS-13578: Nephron: Remove FlowSummaryData
  • NMS-13580: optimize repeated reloads of the flow classification engine
  • NMS-13586: Add full trapoid for Snmp V1
  • NMS-13587: Signed Minion container bleeding image shows revision as meridian-foundation-2021.1.4-1-487
  • NMS-13591: Meridian Minion images do not include release
  • NMS-13592: Add 'tag' argument to health-check command
  • NMS-13604: Research on Display different colors on map base on alarm severity
  • NMS-13609: Horizon release-28.x builds fail with a certificate error
  • NMS-13611: Geolocator Doc Clarification

by RangerRick at October 12, 2021 03:11 PM

September 27, 2021

OpenNMS On the Horizon – Config Management, Docs, Karaf, SNMP Metadata, Minion, JMS, Twin API, ReST, Vue, Geomaps, Flows

Since last time, we worked more on the config management API and importer, thresholding and monitor docs, updating Karaf to 4.3, SNMP metadata provisioning, Minion health check, JMS in the twin API, ReST cleanups and docs, Vue geomap and UI PoC, and flow processing.

Github Project Updates

Internals, APIs, and Documentation
  • Freddy and Tikayat did more work on the config management API.
  • Bonnie worked on some cleanup of the thresholding docs.
  • Jesse and Yang Li did some more work on updating our embedded Karaf to 4.3.
  • Christian worked on a provisioning adapter for processing SNMP metadata.
  • Stefan worked on improving the Minion health check.
  • Patrick continued his work on import/validation and upgrading XML files to the database.
  • Chandra added JMS support to the twin API.
  • Jesse worked on a Karaf interface to the config management API.
  • Mark worked on cleaning up/splitting up monitors in the reference docs.
  • Stefan worked on some performance improvements to flow processing.
Web, ReST, UI, and Helm
  • Sonukumar worked on cleaning up some of our Spring ReST API annotations.
  • Farid and I did some work on marker clusters in the new vue geomap API.
  • Upendra did more work on adding OpenAPI annotations to our ReST interfaces.
  • Stefan wrapped up some work on the flow deep dive dashboard.
  • Tripti did more work on the new vue UI.
  • Jane worked on implementing more features/parity in the vue goemap.
Contributors

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

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Farid Ahmad
  • Freddy Chu
  • Jane Hou
  • Jesse White
  • Marcel Fuhrmann
  • Mark Mahacek
  • Patrick Schweizer
  • Sagar Salunkhe
  • Shankar Suman
  • Sonukumar Gupta
  • Stefan Wachter
  • Tikayat Mohanta
  • Tripti Bansal
  • Upendra Guggilam
  • Yang Li

Release Roadmap

Upcoming October Releases

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

The next OpenNMS release day is October 13th, 2021.

We currently expect a Horizon 28 release, as well as all supported Meridians.

Next Horizon: 29 (Q4 2021)

The next major Horizon release will be Horizon 29.

The current roadmap for Horizon 29 includes the following goals:

  • running as non-root by default
  • refactor the Minion's communication to get rid of out-of-band ReST calls to the OpenNMS core
  • add support for persistence of flows to Cortex
  • start the groundwork for replacing the topology UI with a pure-javascript version
Next Meridian: 2022 (Q? 2022)

With Meridian 2021 recently out, we do not yet have a specific timeline for Meridian 2022.

Expect it to include -- at the very least -- the JDK11 requirement and flow aggregation improvements from Horizon 28.
Ideally it will contain work going into Horizons 29 (and probably 30) if our timeline holds. 😅

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-295: Add a flow deep dive dashboard that gets its data from Cortex
  • NMS-13374: Implement to show aggregation display on Grafana using data from Cortex
  • NMS-13475: Split thresholding file into smaller files
  • NMS-13505: Geo-Map: customize the filter for the severity in alarm page
  • NMS-13530: Fix Spring @RequestMapping to use explicit method types
  • NMS-13566: Some of the tests of ClassificationRulePageIT are flaky
  • NMS-13567: Publish Minion image for Meridian to DockerHub
  • NMS-13568: Backport docker content trust for signed images to meridian 2021
  • NMS-13573: Backport confd support for minion config

by RangerRick at September 27, 2021 04:31 PM

September 23, 2021

OpenNMS joins Hacktoberfest 2021

hacktoberfest 2021 logo

There will be just one Hacktoberfest 2021 and it is coming soon!

The OpenNMS community will participate and we are looking for contributors who want to join us in October.

Hacktoberfest is an annual, month-long celebration of open source software driven by Digital Ocean. During this event everyone can support open source by contributing changes, and earn some limited-edition swag.

We would like to invite you to participate and contribute to the OpenNMS project. There are many ways to contribute: you can work on code or documentation. Generally speaking, any pull request in our GitHub repositories qualifies.

Where to contribute

Our software is developed under AGPLv3 on GitHub. You are welcome to contribute to any repository in this organization. The procedure on how we manage and track issues and deal with pull requests is described in our how to contribute guide in our Discourse forum. You will also find information on how to connect with people in our community for further questions and help.

You can freely create an account in our JIRA. We have collected some issues that are reasonable candidates to claim for the event. The filter is called Hacktoberfest - Quickwin. Claim a ticket by assigning it to your user name and click the "Start Progress" button.

If you have any further questions, please don't hesitate to ping us on Mattermost.

Hack the planet!

by Ronny at September 23, 2021 02:30 PM

September 20, 2021

OpenNMS On the Horizon – Docs, Cortex, Flows, Tests, Twin API, Trapd, Docker, Karaf, Config Management, Vue

Since last time, we worked on updated provisioning, datacollection, event, and monitor/detector docs, logging improvements, Cortex support, flow model updates, flow classification engine improvements, smoke tests, SNMP trap counts, twin API implementation for Trapd, DCT in foundation 2021, Karaf 4.3.3, config management, Vue UI, Vue geomap, ReST mappings, and OpenAPI docs.

Github Project Updates

Internals, APIs, and Documentation
  • Mark continued to work on datacollection documentation.
  • Bonnie added documentation for the send-event.pl tool.
  • Christian worked on some fixes for logging storms.
  • Chandra made some changes to Kafka producer node generation to improve performance.
  • Christian cleaned up some handling of flow options data in some situations.
  • Stefan worked on some optimizations/simplification of the Cortex Nephron code,
    as well as some fixes to a flapping test.
  • Stefan worked on improvements to the flow classification engine.
  • Patrick continued his work on converting provisiond-configuration.xml to be in the database.
  • I reworked the smoke test build to put "flaky" tests into a separate build to ease restarts.
  • Christian fixed a bug in how JMX tracks SNMP trap counts.
  • Dustin worked on using the twin API for Trapd configuration.
  • Stefan remode some unnecessary/redundant fields from the flow summary
    and flow summary data model.
  • I worked on backporting our Docker Content Trust implementation for Minion to foundation-2021.
  • Yang Li worked on updating our embedded Karaf to 4.3.3.
  • Freddy did some work on the config management test framework.
  • Marcel did more doc updates for provisioning, collection, and HTTP-related monitors/detectors.
Web, ReST, UI, and Helm
  • Sagar, Tripti, Shankar and Maxim worked on the new Vue-based UI and backend.
  • Jane did more work on the Vue geomap.
  • Sonukumar worked on fixing some of our @RequestMapping annotations on ReST calls.
  • Sonukumar added some OpenAPI docs for the alarm ReST service.
Contributors

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

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Freddy Chu
  • Jane Hou
  • Jesse White
  • Marcel Fuhrmann
  • Mark Mahacek
  • Maxim Brener
  • Mike Rose
  • Patrick Schweizer
  • Sagar Salunkhe
  • Shankar Suman
  • Sonukumar Gupta
  • Stefan Wachter
  • Tripti Bansal
  • Yang Li

Release Roadmap

Upcoming October Releases

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

The next OpenNMS release day is October 13th, 2021.

We currently expect a Horizon 28 release, as well as Meridian 2021 update.

Next Horizon: 29 (Q4 2021)

The next major Horizon release will be Horizon 29.

The current roadmap for Horizon 29 includes the following goals:

  • running as non-root by default
  • refactor the Minion's communication to get rid of out-of-band ReST calls to the OpenNMS core
  • add support for persistence of flows to Cortex
  • start the groundwork for replacing the topology UI with a pure-javascript version
Next Meridian: 2022 (Q? 2022)

With Meridian 2021 recently out, we do not yet have a specific timeline for Meridian 2022.

Expect it to include -- at the very least -- the JDK11 requirement and flow aggregation improvements from Horizon 28.
Ideally it will contain work going into Horizons 29 (and probably 30) if our timeline holds. 😅

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-13428: Strings with URL arguments are truncated in the eventdescr field
  • NMS-13467: Nephron: Test if pane accumulation has a positive effect on performance
  • NMS-13512: Web-based SNMP config UI does not pass through proxy-host if a value is provided
  • NMS-13539: Minion stops processing flows with "Invalid packet: null" until restart
  • NMS-13540: Add search term highlight functionality in documentation
  • NMS-13545: Nephron: Remove unnecessary fields from FlowSummary / FlowSummaryData
  • NMS-13546: Nephron: FlowAnalyzerIT flaps on Flink 1.13
  • NMS-13571: Nephron: RandomFlowIT.testRatesWithClockSkew is still flaky

by RangerRick at September 20, 2021 07:20 PM

September 13, 2021

OpenNMS On the Horizon – Docs, trapOid, Nephron, Cortex, Karaf, Flow Classification, Config Manager API, ReST, Vue UI and Geomaps

Since last time, we worked on documentation, trapoid/hwEntity handling, Nephron and Cortex, Karaf 4.3, classification rules, config manager upgrade and ReST API, and vue-based UI and geomaps.

Github Project Updates

Internals, APIs, and Documentation
  • Bonnie worked on updates to the admin documentation.
  • Chandra did some wrapping up of the work on trapoid/hwentity handling.
  • Stefan did more work on cleanups to flow handling in Nephron as part of his Cortex work.
  • Jesse worked on updating our embedded Karaf to 4.3.
  • Stefan updated the classification rule tree processing to be asynchronous.
  • Patrick worked on updating XML-based provisiond configs to be pulled into the database.
  • Marcel did more work on cleaning up daemon reload docs.
  • Mark worked on updating the datacollection type documentation.
  • I cleaned up the build/trees on a couple of older projects.
  • I removed the outdated opennms-tools project from the source tree.
  • Stefan did more work on tuning memory vs. correctness in Nephron processing.
  • Freddy worked on fixing some smoke tests.
Web, ReST, UI, and Helm
  • I finished the addition of missing search properties in the model ReST APIs used by Helm.
  • Sagar, Jesse, and Tripti worked on the new Vue-based UI proof-of-concept.
  • Jane worked more on filling out the vue geomap implementation.
  • Tikayat continued the work on updating OpenAPI docs.
  • Freddy worked on implemeting the ReST config manager API.
Contributors

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

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Freddy Chu
  • Jane Hou
  • Jesse White
  • Marcel Fuhrmann
  • Mark Mahacek
  • Patrick Schweizer
  • Sagar Salunkhe
  • Stefan Wachter
  • Tikayat Mohanta
  • Tripti Bansal

Release Roadmap

Completed September 2021 Releases - Horizon 28.1.0, Meridians 2021.1.4, 2020.1.12, 2019.1.23

In September, we released updates to all OpenNMS Meridian versions under active support, as well as an update for Horizon 28.

Horizon 28.1.0

Release 28.1.0 contains a bunch of bug fixes and enhancements, including a dependency update related to a CVE.

Note that we bumped the minor version on the release because of the changes made in NMS-13479 — in order to optimize the flow classification processing, some significant changes were made behind the scenes. There shouldn’t be any change from a user perspective, but we bumped the version just in case.

The codename for Horizon 28.1.0 is Bumblebee

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

Meridian Point Releases

All Meridian releases this month contained minor security updates, so it is recommended that you upgrade.

2021.1.4 adds a fix for additional node metadata showing in syslog events, plus documentation improvements.

For a list of changes, see the release notes:

Upcoming October Releases

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

The next OpenNMS release day is October 13th, 2021.

We currently expect a Horizon 28 release, as well as Meridian 2021 update.

Next Horizon: 29 (Q4 2021)

The next major Horizon release will be Horizon 29.

The current roadmap for Horizon 29 includes the following goals:

  • running as non-root by default
  • refactor the Minion's communication to get rid of out-of-band ReST calls to the OpenNMS core
  • add support for persistence of flows to Cortex
  • start the groundwork for replacing the topology UI with a pure-javascript version
Next Meridian: 2022 (Q? 2022)

With Meridian 2021 recently out, we do not yet have a specific timeline for Meridian 2022.

Expect it to include -- at the very least -- the JDK11 requirement and flow aggregation improvements from Horizon 28.
Ideally it will contain work going into Horizons 29 (and probably 30) if our timeline holds. 😅

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-13256: Kafka Producer - Enabling causes Trap Processing to halt
  • NMS-13373: Provide the ability in Nephron to write to Cortex
  • NMS-13453: Nephron: CortexIo GC global state
  • NMS-13479: Review classification rules in the flow pipeline
  • NMS-13503: Geo-Map: Convert vuex module code to typescript
  • NMS-13516: Update "Develop Documentation" section to describe table formatting
  • NMS-13519: Installing opennms-plugin-protocol-dhcp fails
  • NMS-13535: Nephron: Support running on Flink 1.13
  • NMS-13541: Geo-Map: Convert the nodes, alarms grid and map page to typescript and use vue SFC
  • NMS-13552: Add JVM option to the minion startup script
  • NMS-13563: delete the opennms-tools directory

by RangerRick at September 13, 2021 07:04 PM

September 08, 2021

September 2021 Releases – Horizon 28.1.0, Meridians 2021.1.4, 2020.1.12, 2019.1.23

In September, we released updates to all OpenNMS Meridian versions under active support, as well as an update for Horizon 28.

Horizon 28.1.0

Release 28.1.0 contains a bunch of bug fixes and enhancements, including a dependency update related to a CVE.

Note that we bumped the minor version on the release because of the changes made in NMS-13479 — in order to optimize the flow classification processing, some significant changes were made behind the scenes. There shouldn’t be any change from a user perspective, but we bumped the version just in case.

The codename for Horizon 28.1.0 is Bumblebee

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

Meridian Point Releases

All Meridian releases this month contained minor security updates, so it is recommended that you upgrade.

2021.1.4 adds a fix for additional node metadata showing in syslog events, plus documentation improvements.

For a list of changes, see the release notes:

by RangerRick at September 08, 2021 09:49 PM

September 07, 2021

OpenNMS On the Horizon – Config API, OIA, Time-Series, Netflow, Telemetryd, Flows, Traps, WSman, Docs, Syslog, Kafka, UI, ReST, Vue, Geomaps, Cortex, Helm, OpenAPI

Sorry for the missing OOH last week, I was on vacation.

Since last time, we worked on the config API, OIA, the time-series API, Netflow debugging, Telemetryd config, the flow classification rule parser, trap OID handling, WSman config validation, documentation, syslog hostname resolution, asynchronous node processing in Kafka, UI cleanups, opennms.js, ReST fixes and updates, Vue gomaps and UI proof-of-concept, Cortex flows in Helm, and OpenAPI documentation.

Github Project Updates

Internals, APIs, and Documentation
  • Freddy and Patrick continued the work on the new configuration API.
  • Chandra updated OIA to build with JDK 11 by default.
  • Patrick continued his work on improvements to the time-series API.
  • Chandra did more work updating our Guava dependency.
  • Christian worked on some improved debugging in the netflow parser.
  • Chritian fixed an issue with handling extraneous whitespace in the telemetry config.
  • Stefan reworked the classification rule parser for performance.
  • Chandra worked on optimizing the loading of the HwEntity tree.
  • Chandra did more work on adding the full trap OID to the list of parameters.
  • David added support for validation of the WSman config.
  • Mark worked on more Provisiond doc updates.
  • Chandra did more work on properly resolving hostnames for incoming Syslog messages.
  • Marcel did a bunch of updates in the daemon reference docs.
  • Bonnie did more work on structure cleanup in the docs.
  • Chandra worked on updating the Kafka producer to process nodes asynchronously.
Web, ReST, UI, and Helm
  • Jeff worked on cleanup of inputs in the path outage page.
  • I released an updated version of opennms.js that supports new entities in the entity datasource.
  • I did more work updating the search properties ReST API to support more properties.
  • Jane continued to work on the new Vue-based geomaps.
  • Sagar, Tripti, and Mike worked on the Vue-based UI PoC.
  • Stefan made some updates to the Cortex version of the flow deep dive dashboard.
  • Tikayat, Sonukumar, Shankar, and Upendra worked on adding OpenAPI documentation for some of the ReST services.
  • Christian updated the service status page to show parsed patterns.
  • Yang Li did more work on ReST APIs to support the new Vue UI.
Contributors

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

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • David Schlenk
  • Freddy Chu
  • Jane Hou
  • Jeff Gehlbach
  • Marcel Fuhrmann
  • Mark Mahacek
  • Maxim Brener
  • Mike Rose
  • Patrick Schweizer
  • Ronny Trommer
  • Sagar Salunkhe
  • Shankar Suman
  • Sonukumar Gupta
  • Stefan Wachter
  • Tikayat Mohanta
  • Tripti Bansal
  • Upendra Guggilam
  • Yang Li

Release Roadmap

September Releases

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

The next OpenNMS release day is September 8th, 2021.

We currently expect a Horizon 28.0.3 release and updated Meridians 2019 through 2021.

Next Horizon: 29 (Q4 2021)

The next major Horizon release will be Horizon 29.

The current roadmap for Horizon 29 includes the following goals:

  • running as non-root by default
  • refactor the Minion's communication to get rid of out-of-band ReST calls to the OpenNMS core
  • add support for persistence of flows to Cortex
  • start the groundwork for replacing the topology UI with a pure-javascript version
Next Meridian: 2022 (Q? 2022)

With Meridian 2021 recently out, we do not yet have a specific timeline for Meridian 2022.

Expect it to include -- at the very least -- the JDK11 requirement and flow aggregation improvements from Horizon 28.
Ideally it will contain work going into Horizons 29 (and probably 30) if our timeline holds. 😅

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-188: Entity DS does not fetch SNMP Primary IP or ifIndex for Nodes
  • HELM-228: Add IP- and SNMP-interface, ifService, outage support to Helm Entity DS
  • NMS-13422: Add the full trap oid for v2 snmp event
  • NMS-13446: Update Provisiond Docs
  • NMS-13455: Geo-map: work with Ben designing RESTful API for Geo-map page
  • NMS-13468: validate wsman-config.xml
  • NMS-13473: Migrate VMware config from wiki to docs
  • NMS-13477: Trailing whitespace breaks flow listener config
  • NMS-13480: Enhance exception handling for parse error in flows
  • NMS-13506: Geo Map: make use of modules for vuex store so that the code can be easily integrated into larger project
  • NMS-13509: Bump Apache Ant version to 1.10.11 (CVE-2021-36373, CVE-2021-36374)
  • NMS-13511: Use Karaf shell commands to secure Minion SSH Karaf access
  • NMS-13515: Reformat tables (again)
  • NMS-13517: Service Parameters box misses Poller Patterns
  • NMS-13518: missing fields in search autocomplete
  • NMS-13533: geo-map: initiate geo-map typescript project
  • NMS-13536: Update abuse e-mail address in CONTRIBUTING.md of OpenNMS repo
  • OIA-20: Integration API should be able to compile on JDK11

by RangerRick at September 07, 2021 09:12 PM

September 02, 2021

How to: Contribute to OpenNMS

Submitting issues, fixing bugs, contributing features, enhancements, and extensions, writing documentation, or reporting security issues are all valuable ways that our community helps make OpenNMS a better monitoring platform.

OpenNMS uses Jira to manage issue tracking and development. Once you have a Jira account and have signed the OpenNMS Contribution Agreement (OCA), you can start contributing. The basic workflow is as follows:

  • Identify the issue
  • Create a Jira ticket
  • Develop, develop, develop
  • Submit the patch to GitHub
  • Create a pull request (PR)
  • PR review by another developer/community member
  • Update patch based on review
  • Approve and merge PR

CircleCI, our continuous integration system, takes over, checking code for compile errors, running tests, and building and publishing all the packages for a release.

Learn more about how you can contribute in this Discourse article.

Jira-GitHub development workflow

by Bonnie Robinson at September 02, 2021 06:51 PM

August 23, 2021

OpenNMS.js v2.2.0

This release bumps a bunch of dependencies, plus it adds support for the api/v2/ipinterfaces API.

by RangerRick at August 23, 2021 09:03 PM

OpenNMS.js v2.1.1

This is a rerelease of 2.1.0 with a fix for documentation generation.

by RangerRick at August 23, 2021 09:03 PM

OpenNMS On the Horizon – Elasticsearch, Docs, Syslog, Flows, Cortex, Time-Series, Config Management, gRPC, Liquibase, Vue, Helm

Since last time, we worked on Elasticsearch bulk updating, tons of documentation improvements, syslog message processing, flow classification, Cortex in Nephron, time-series tag handling, the new config management API, gRPC support in the twin API, tests, internal stats, Liquibase, Vue UI and geomap, scheduled outages, and Helm.

Github Project Updates

Internals, APIs, and Documentation
  • Dustin did more work on bulk updating in Elasticsearch
  • Mark did more work on provisioning doc cleanups
  • I did a couple of dependency updates
  • Chandra worked on fixing syslog message hostname resolution
  • Stefan worked on improvements to the flow classification engine
  • Stefan continued his work on Cortex support in Nephron
  • Patrick did some work on improving tag handling in the time-series API
  • Freddy did more work on handling schemas and validation in the new config management API
  • Chandra worked on the gRPC implementation for the new twin API
  • Chandra fixed some timing issues in OpenConfig tests
  • Ronny updated the Minion docs to show how to configure SSL on the Karaf CLI
  • Yang Li worked on providing some additional information in the MBean stats collector
  • Marcel worked on cleaning up and rearranging the demon reload code
  • Patrick worked on moving to Liquibase 4 and using it for implementing config management updates
  • Bonnie and Mark did more work on table cleanups in the docs
  • Christian added some extra debug logging to the telemetry listeners
Web, ReST, UI, and Helm
  • Mike, Yang Li, Jesse, Sagar, and Tripti worked on the Vue PoC UI
  • Jane did more work on the Vue geomap
  • I added IP interface, SNMP interface, service, and outage support to the Helm entity datasource
  • Christian worked on some input validation in the web UI
  • Christian fixed a bug where you could create the same scheduled outage multiple times
  • Stefan added a Cortex-based flow deep-dive dashboard to Helm
Contributors

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

  • Benjamin Reed
  • Bonnie Robinson
  • Chandra Gorantla
  • Christian Pape
  • Dustin Frisch
  • Freddy Chu
  • Jane Hou
  • Jesse White
  • Marcel Fuhrmann
  • Mark Mahacek
  • Mike Rose
  • Patrick Schweizer
  • Ronny Trommer
  • Sagar Salunkhe
  • Stefan Wachter
  • Tripti Bansal
  • Yang Li

Release Roadmap

September Releases

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

The next OpenNMS release day is September 8th, 2021.

We currently expect a Horizon 28.0.3 release.

Next Horizon: 29 (Q4 2021)

The next major Horizon release will be Horizon 29.

The current roadmap for Horizon 29 includes the following goals:

  • running as non-root by default
  • refactor the Minion's communication to get rid of out-of-band ReST calls to the OpenNMS core
  • add support for persistence of flows to Cortex
  • start the groundwork for replacing the topology UI with a pure-javascript version
Next Meridian: 2022 (Q? 2022)

With Meridian 2021 recently out, we do not yet have a specific timeline for Meridian 2022.

Expect it to include -- at the very least -- the JDK11 requirement and flow aggregation improvements from Horizon 28.
Ideally it will contain work going into Horizons 29 (and probably 30) if our timeline holds. 😅

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-845: Notification/Outage Notes
  • NMS-5350: Add comment field to discovery range
  • NMS-8968: OpenNMS Admin Guide HostResourceSwRunMonitor service-name not exact match string
  • NMS-13219: No warning message thrown when more than one Duplicate entry time applied during Outage creation
  • NMS-13366: Migrate VMware instructions from Wiki to Docs
  • NMS-13440: Update table formatting in detectors section of docs
  • NMS-13460: Implement gRPC broker for Object replication (Twin)
  • NMS-13471: GeoMap: Investigate the Vue3 reactivity in geomap page to sync the map, nodes and alarms subpages.
  • NMS-13472: Update table formatting in docs.
  • NMS-13482: Migrate foreign source content from Discourse to docs
  • NMS-13485: Syslog messages missing nodelabel, location, and interface
  • NMS-13502: Geo-Map: Nodes, Alrarm Grid and Leaflet map need to listen to the change of the Monitored Nodes

by RangerRick at August 23, 2021 07:28 PM