Planet OpenNMS

May 23, 2023

May 10, 2023

May 2023 Releases – Horizon 31.0.8, 2023.1.3, 2022.1.16, 2021.1.27, 2020.1.35

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

Meridian Stable Updates

Meridians 2023.1.3, 2022.1.16, 2021.1.27, 2020.1.35 contains a bunch of bug fixes, along with a fix for a security vulnerability.

For a list of changes, see the release notes:

Horizon 31.0.8

Release 31.0.8 contains four security vulnerability fixes and a generous helping of other bug fixes. It also includes a few small enhancements to the startup scripts and other components.

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

For a complete list of changes, see the changelog.

The codename for Horizon 31.0.8 is Spritzgebäck.

The post May 2023 Releases – Horizon 31.0.8, 2023.1.3, 2022.1.16, 2021.1.27, 2020.1.35 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at May 10, 2023 04:27 PM

OpenNMS Horizon 31.0.8 (Spritzgebäck)

Release 31.0.8

Release 31.0.8 contains four security vulnerability fixes and a generous helping of other bug fixes. It also includes a few small enhancements to the startup scripts and other components.

The codename for Horizon 31.0.8 is Spritzgebäck.

Bug
  • POW Arithmetic Operator Does not work with Backshift Graphing Engine (Issue NMS-14779)
  • Cacheable HTTPS Responses - Cache Control Directive Missing or Misconfigured (Issue NMS-14936)
  • REST API: Deleting nodes fails with "could not insert: [org.opennms.netmgt.model.OnmsAssetRecord]" error message (Issue NMS-15033)
  • Plaintext Password Present in the Web logs (Issue NMS-15305)
  • Stored XSS on Quick-Add Node (Issue NMS-15308)
  • Geographical Map map search capability is not as described in the docs (Issue NMS-15426)
  • Foundation-2020: Snmp4JValueFactory: getOctetString displayable should be true (Issue NMS-15599)
  • Jetty CVE-2023-26048/CVE-2023-26049 (Issue NMS-15612)
  • Update to latest groovy 2.x (Issue NMS-15633)
  • $OPENNMS_HOME/etc/THIRD-PARTY.txt has gone missing with Horizon 31.0.6 and onwards (Issue NMS-15636)
  • SNMPv3 support for AES256 appears broken (Issue NMS-15637)
New Feature
  • Add a CLI mechanism to set the admin password (Issue NMS-15221)
Story
  • Add KPI for boolean containerization status (Issue NMS-15368)
  • Add REST endpoint exposing usage analytics KPIs (Issue NMS-15371)
  • Usage statistics docs updated to include containerization status (Issue NMS-15627)
Enhancement
  • Smoke test improvements and small tweaks to help developers (Issue NMS-15387)
Task
  • DOC: Pull changes into foundation branch (Issue NMS-15658)

by mershad-manesh at May 10, 2023 03:53 PM

April 27, 2023

Celebrating International Girls in ICT Day 2023

Happy International Girls in ICT Day 2023!

OpenNMS celebrates the importance of girls, women, and non-binary folk in Information and Communications Technology (ICT). Last year, people on our team shared stories about the importance of access and safety in ICT. This year's theme is "Digital Skills for Life."

Looking around OpenNMS, this theme is especially meaningful. We have people from many different walks of life, paths into the technology industry, and unique experiences. Despite differing backgrounds, those who shared their stories this year had some common observations: learn through experimentation and always be open to new ideas.

Digital skills for life at OpenNMS

How has the digital world shaped your career?
Did your education path lead you to this career?
What role did confidence and support play in getting to where you are now? Did you have role models or mentorship along the way?

Zoë

My parents were very supportive of my interests in tech and always encouraged me and bought things that I needed. My high school CS teacher saw potential and put me in charge of the school network and lab computers after he found me hacking root on them. I helped out the other students with their lab assignments.

Sandy

Well, I was a C-level executive about 10 years ago and I worked directly with the CEO. We went through the downturn of 2009, lost more than half of our staff, and had some software that was extremely difficult to use. We were paying hefty, hefty consulting bills to answer simple questions about the software. So, I taught myself how to use it. They actually ended up visiting us because they wanted to find out why we stopped racking up all of those charges. I was walking by the CEO's office one day and he says, "That's the reason why we're not paying your fees anymore."

Veena

My mother used to be a science teacher while I was growing up and always referred to science, logic, and reasoning during everyday activities. She is one of my role models. In addition, there were many women around me (family, friends, colleagues, etc.) that I have observed and learned many things from over the years that I apply or practice.

What advice do you have for someone who is young and interested in a future in information and communications technology?

Amanda

I tend to shy away from giving advice. I feel like it implies I know what I’m doing. But I guess if I have to give any advice it would be to keep an open mind and to not be afraid to explore all of the different career choices that might interest you!

Jen

Prioritize your personal goals and see how they can align to a professional career. Too often many people are driven into jobs for all the wrong reasons instead of taking advantage of every opportunity when you are younger to try things out. Be inquisitive, talk to people you meet, ask them what they really do for work every day and start to piece together your own dream job.

Nicole

Learn as much as you can and take advantage of the opportunities you have now. If you have access to specialized courses take them. If you don’t, there are a lot of great online resources and tutorials to help you learn the basics of the tools of the trade.

Veena

Stay curious and never stop learning. Don’t be afraid of change.

Resources

Whether it's your neighborhood, open source software, or helping with an International Girls in ICT Day celebration—all communities thrive on support.

Here are a few resources that you can use to, hopefully, help spark joy for Information and Communications Technology:

The post Celebrating International Girls in ICT Day 2023 appeared first on The OpenNMS Group, Inc..

by Bonnie Robinson at April 27, 2023 01:00 PM

April 21, 2023

April 2023 Releases – Horizon 31.0.7

Horizon 31.0.7

Release 31.0.7 is an off-cadence release containing several small bug fixes. Most notably, it upgrades the OpenNMS Plugin API host to version 1.4.0, enabling OPA plugins targeting that version to load successfully.

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

For a complete list of changes, see the changelog.

The codename for Horizon 31.0.7 is Snickerdoodle.

The post April 2023 Releases – Horizon 31.0.7 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at April 21, 2023 08:20 PM

OpenNMS Horizon 31.0.7 (Snickerdoodle)

Release 31.0.7

Release 31.0.7 is an off-cadence release containing several small bug fixes. Most notably, it upgrades the OpenNMS Plugin API host to version 1.4.0, enabling OPA plugins targeting that version to load successfully.

The codename for Horizon 31.0.7 is Snickerdoodle.

Bug
  • Adding new thresholds to an existing group often throws an IndexOutOfBoundsException (Issue NMS-15334)
  • A small typo in plugin.sh prevents artifacts from GitHub to be included in containers (Issue NMS-15592)
  • Syslog Northbounder maxMessageSize config option is not used (Issue NMS-15606)
Task
  • Visualization of database-report templates in docs (Issue NMS-15423)
  • Add Velocloud plugin in our core and minion containers (Issue NMS-15567)
Story
  • Implement collector config extensions – NMS side (Issue NMS-15585)

by mershad-manesh at April 21, 2023 08:09 PM

April 19, 2023

What is Network Segmentation?

Network segmentation is the process of dividing a network into smaller, more manageable pieces (segments) to improve its security posture. Network segmentation creates secure zones (subnetworks or subnets) within your larger network to help mitigate the impact of a security breach. By breaking the network into smaller pieces, you limit the spread of malicious events and activities within the contained segment and provide additional protections for insecure devices.

Modern networks facilitate essential operations, communication, and data transfer. And networks continue to get more complex, growing in scope with more services, more devices, more locations, and a more mobile workforce. Administrators have to constantly improve security standards, controlling what happens, where, on the network—while also being able to monitor and understand it all.

Benefits of network segmentation

Network segmentation is a critical piece of an overall cybersecurity / network security model. It's used to help you:

  • Improve your security posture. Network segmentation improves the security posture of an organization by limiting the potential attack surface. By dividing the network into smaller segments, businesses can control access to different areas of the network and limit the exposure of sensitive data.
  • Mitigate risk. Network segmentation helps businesses mitigate the risks associated with data breaches and malware. If a breach occurs in one segment of the network, it will not impact other segments, thereby reducing the overall risk of data loss.
  • Meet compliance requirements. It's crucial to industry standards such as PCI DSS, HIPAA, and GDPR. These standards require strict control over storage and access to sensitive data.

How does network segmentation work?

You can accomplish network segmentation through the use of firewalls, ACLs (Access Control Lists), and VLANs (Virtual Local Area Networks). Your approach depends on how you break down your datacenter and networked infrastructure into subnetworks: physical vs. virtual (logical).

Physical segmentation works exactly how it sounds—you use physical hardware (firewalls, routers, etc) to divide your network. Oftentimes, the location of your networked infrastructure becomes a segment.

Virtual (logical) segmentation uses software to define the segment. This approach can be easier, since you aren't limited by access to physical devices and can build virtual networks or use ACLs to separate networked devices.

Is this the same as microsegmentation?

Not exactly. Network segmentation and microsegmentation are very similar in approach, but differ in capability and execution. While network segmentation relies on a single constraint to govern access (for example, physical location), microsegmentation goes a bit further, isolating each device or application into its own segment. For organizations looking to adhere to a zero-trust architecture approach, microsegmentation is essential. Since you separate each entity from all others, access and traffic must be explicitly granted, regardless of whether it originated within the same segmented network.

Think of your network as a city block, full of apartment buildings. Each building has a locked front door and only the people living there have the code, so you trust them with access to the building itself. That's a segment on your network. Microsegmentation is each locked apartment. You trust entities with access to the building, but not the apartment. So, only the owner of each apartment, or microsegment, has the ability to enter—or grant entry—to their apartment.

How to segment your network

The typical steps in segmenting networks include:

1. Identify critical assets. The first step is to identify the critical assets on your network that need protection. These could include sensitive data, critical applications, and components that control network access.

2. Map your network. Once you've defined your critical assets, map the network to identify the different segments or subnets that need to exist. This includes physical network devices such as routers, switches, and firewalls.

3. Define access policies. Now that you know your assets and have laid out the segmentation approach, you need to configure firewalls, access controls, and other security measures to define what gets access to each segment.

4. Implement security controls. Here's where you bring it all online. You're ready to implement your security policies and controls. From here, you'll also set up intrusion detection systems and other measures to protect each network segment.

5. Monitor and adapt. Network segmentation isn't a "set it and forget it" process. You'll need to continuously monitor the network to ensure it acts as expected and remains secure. Regular security audits and vulnerability assessments are also essential to the ongoing health and efficacy of your network segmentation project.

Common issues in network segmentation strategies

The Gartner® report, "The 6 Principles of Successful Network Segmentation Strategies" covers common strategy pitfalls—and how to avoid them.

From the report:

  • "The failure rate for network segmentation projects is high, and most projects last longer than the average tenure of a CISO.
  • “Broad scope” and “segment everything” mindsets will inevitably lead to a network segmentation project failure.
  • Implementation constraints and “shiny new technology” driving the network segmentation strategy inevitably lead to suboptimal and inefficient architectures."

Industry use cases

Different industries have very similar issues where segmentation can help—whether it's devices with insufficient security protections or which hold sensitive data (or both). Creating a microsegment for each of these devices, or for all of a type of device, to protect them is critical to keeping them safe. The microsegmentation becomes a compensating control for devices with limited protections.

  • Healthcare. There has been a recent proliferation in network-connected medical devices. Devices include radiology modalities, lab analyzers, blood glucose meters, IV pumps, patient monitors, or nurse call systems, just to name a few. These devices often use outdated security practices—making them vulnerable. In many cases, you won't be able to deploy the usual endpoint protections, such as anti-malware and anti-virus software. And the criticality of these devices make them likely targets for cyberattacks. Bad actors know they contain valuable patient data. In extreme cases disruption of patient care is a concern.
  • Manufacturing. As production lines grow in complexity, with more automation and speed, the number of network-connected monitoring devices also grows. In many cases, these devices sit alongside older devices that are running on outdated, unsecure operating systems. Oftentimes, we measure downtime in lost revenue.
  • Retail. Internal systems, including point-of-sale systems, manage card holder data (CHD). Segmenting or microsegmenting these systems is necessary to comply with PCI requirements.

Controlling what these devices can communicate with—and what can communicate with the devices—reduces the risk of malicious software or people from accessing them. Furthermore, you limit attack spread in cases of a compromised device.

How OpenNMS can help

Your job doesn't end at building a segmented network. You're need to be able to monitor these segments, find issues, and continue to adapt as your environment changes. But, an outside-in approach to monitoring (where your monitoring system connects to, and monitors, from outside of the segment) creates holes in your security—the very thing you were limiting by implementing network segmentation. OpenNMS is able to collect relevant data from within the segment itself, an inside-out view, through the use of OpenNMS Appliance.

A photo of OpenNMS Appliance hardware in mini form factor.
What's an Appliance?

OpenNMS Appliance is physical hardware, or virtual machines, that reliably and securely collect network monitoring data from hard-to-access areas of your infrastructure.

Appliances are the network monitoring data collectors for OpenNMS. They run lightweight services that enable OpenNMS to communicate with devices and services on your network. By deploying Appliances, you also gain better control and management capabilities.

Appliances let you:

  • Configure your entire fleet of Appliances in one action.
  • Define groups of Appliances and apply batch configurations to specific groups, as needed.
  • Schedule or automate updates for your Appliances—ensuring they have the latest bug and security fixes.
  • Keep your fleet of Appliances in sync with the core OpenNMS platform. This guarantees monitoring data continuity through updates.
How Appliance works with segmentation

OpenNMS Appliance fits best in this model through network overlays—a virtual layer, or abstraction, that sits over your network. Within network segmentation, a network overlay is part of the logical approach to defining segments, with VLANs playing a prominent role as your overlay. Add an Appliance to specific segments to provide a secure way to monitor the segment from inside, rather than permitting external monitoring a view into the segment.

Diagram: Traditional Segmentation vs. Using OpenNMS Appliance
alt

An example:

Let's say you're a network engineer at a hospital. Some of the devices on the hospital network include MRI machines. So, you place all of the MRIs into a segment. Now, you could externally monitor the health of these devices, increasing the risk of the devices being compromised due to more opening in your firewall, for example. Or, you use OpenNMS Appliance, placed as part of the segment, without any outside connections needed to monitor the devices. The Appliance talks out to your central OpenNMS Meridian network monitoring platform, but no communication into the Appliance is necessary.

You get the data you need, without unnecessarily exposing sensitive equipment to attacks.

OpenNMS Appliance can be quickly integrated into your existing network infrastructure—deploying Appliance hardware or deploying a virtual Appliance. The Meridian platform supports various network protocols and standards, including SNMP, NetFlow, sFlow, IPFIX, and more.

Additionally, OpenNMS offers numerous integrations with third-party applications and services, such as Grafana, Elasticsearch, and Slack, providing additional functionality and enhancing overall network management capabilities.

Enhance network segment visibility

OpenNMS offers several tools and features designed to improve network segment visibility, including:

  • Discovery and provisioning. OpenNMS can automatically discover network devices, allowing for a complete and up-to-date inventory. This process can be customized to match specific network segments, ensuring you discover and monitor relevant devices.
  • Performance monitoring. OpenNMS provides detailed performance data for network devices, including bandwidth usage, latency, and packet loss. This information allows administrators to quickly identify potential bottlenecks or issues within network segments.
  • Alerts and notifications. The platform offers a customizable alerting system, enabling administrators to set thresholds and receive notifications when issues arise. This feature allows for rapid identification and resolution of network segment problems.
  • Visualization tools. OpenNMS includes various visualization tools, such as topology maps, geographical maps, and customizable dashboards. These tools provide administrators with an easy-to-understand visual representation of their network segments, improving overall visibility and facilitating quick decision-making.
  • Log and event management. The platform collects and stores logs and events from network devices, allowing administrators to review historical data and identify trends or recurring issues within network segments.

Conclusion

Enhanced network segment visibility is crucial for maintaining an efficient and reliable network infrastructure. OpenNMS Appliance offers a comprehensive solution for managing and monitoring networks, providing administrators with the tools they need to keep their networks running smoothly.

Use OpenNMS Appliance to optimize network performance, reduce downtime, and improve your overall operational efficiency.

The post What is Network Segmentation? appeared first on The OpenNMS Group, Inc..

by Colby Hoke at April 19, 2023 02:02 PM

April 12, 2023

April 2023 Releases – Horizon 31.0.6, 2023.1.2, 2022.1.15, 2021.1.26, 2020.1.34

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

Meridian Stable Updates

Meridians 2023.1.2, 2022.1.15, 2021.1.26, 2020.1.34 contains a bunch of bug fixes, along with a fix for a security vulnerability.

For a list of changes, see the release notes:

Horizon 31.0.6

Release 31.0.6 contains a bunch of bug fixes, along with fixes for several security vulnerabilities. It also upgrades the embedded Drools library from v7.x to v8.x, so be sure to test any custom rules that you depend on before moving to production.

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

For a complete list of changes, see the changelog.

The codename for Horizon 31.0.6 is Coyotas.

The post April 2023 Releases – Horizon 31.0.6, 2023.1.2, 2022.1.15, 2021.1.26, 2020.1.34 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at April 12, 2023 05:06 PM

OpenNMS Horizon 31.0.6 (Coyotas)

Release 31.0.6

Release 31.0.6 contains a bunch of bug fixes, along with fixes for several security vulnerabilities. It also upgrades the embedded Drools library from v7.x to v8.x, so be sure to test any custom rules that you depend on before moving to production.

The codename for Horizon 31.0.6 is Coyotas.

Bug
  • DOC: Document Newts fetch step / heartbeat settings in opennms.properties (Issue NMS-10155)
  • Document the function hiding Meta-Data values with keynames containing "password" or "secret" (Issue NMS-12808)
  • Scriptd consumes CPU even when it does nothing (Issue NMS-13216)
  • dependabot: upgrade Apache POI to at least 4.1.1 (CVE-2019-12415) (Issue NMS-14589)
  • POW Arithmetic Operator Does not work with Backshift Graphing Engine (Issue NMS-14779)
  • Form Can Be Manipulated with Cross-Site Request Forgery (CSRF) (Issue NMS-14865)
  • Multiple CVEs for cxf 3.2.8 (Issue NMS-15065)
  • The management of alarms (escalation, and acknowledge) on the new MAP UI does not work for user without ROLE_REST. (Issue NMS-15080)
  • Concurrent requests to rrd summary endpoint fails (Issue NMS-15086)
  • Statistics Reports → Export Excel fails with exception (Issue NMS-15148)
  • No health check for the OpenNMS Core container (Issue NMS-15291)
  • Inconsistent expectations on TimeseriesStorageManager.get() with null return values (Issue NMS-15323)
  • Polling and metrics storage can hard fail if opennms-timeseries-api is reloaded (Issue NMS-15325)
  • Destroying container for blueprint bundle org.opennms.features.org.opennms.features.timeseries leads to downstream problems (Issue NMS-15326)
  • The various SNMP extenders to not work with ifIndex-indexed resources (Issue NMS-15342)
  • SNMP Interfaces Endpoint returns multiple values [duplicates] when there are multiple "IP Interfaces" pointing to same SNMP-IfIndex "ipAdEntIfIndex". (Issue NMS-15352)
  • Missing XML Validation in Apache Xerces2 (Issue NMS-15373)
  • Adding or editing a schedule outage doesn’t reload the configuration for Threshd (Issue NMS-15420)
  • M2022 Minions > 2022.1.8 Cannot use SCV credentials (Issue NMS-15450)
  • Event Datetime element parsing changed between M2018 and M2021 (Issue NMS-15471)
  • Minimum system requirements does not enumerate RHEL9 support (Issue NMS-15499)
  • Cortex plugin has no LICENSE.md (Issue NMS-15521)
  • upgrade Xalan to 2.7.3 (CVE-2022-34169) (Issue NMS-15578)
Enhancement
  • Deploy Release Jars to Maven Central (Issue NMS-14727)
  • DOC: Create documentation for vacuumd (Issue NMS-15440)
  • Upgrade Drools to 8.34.0.Final (from 7.31.0.Final) (Issue NMS-15459)
  • Update docs to include RHEL9 and Rocky/Alma compatability (Issue NMS-15500)
  • re-enable license maven plugin as a separate job (Issue NMS-15572)
Task
  • DOC: Update replacement tokens documentation (Issue NMS-15045)
  • Vulnerable c3p0 0.9.1.1 packaged in Meridian 2021 (Issue NMS-15072)
  • DOC: Restructure Alarm History documentation (Issue NMS-15287)

by mershad-manesh at April 12, 2023 04:41 PM

March 21, 2023

OpenNMS.js v2.5.5

This release fixes Antora documentation versioning, and includes some minor dependency updates plus a bump to use TypeScript 5.0.

by RangerRick at March 21, 2023 04:46 PM

March 15, 2023

OpenNMS.js v2.5.4

This is a code-identical release to 2.5.3, with some build cleanups under the covers.

by RangerRick at March 15, 2023 03:50 PM

OpenNMS.js v2.5.3

This release contains only dependency updates and a very minor compile fix to make TypeScript happy.

by RangerRick at March 15, 2023 03:13 PM

OpenNMS.js v2.5.2

This release updates a number of dependencies, notably Axios, which required a few small changes to the AxiosHTTP adapter.

by RangerRick at March 15, 2023 03:12 PM

March 08, 2023

March 2023 Releases – Horizon 31.0.5, 2023.1.1, 2022.1.14, 2021.1.25, 2020.1.33

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

Meridian Stable Updates

Meridians 2023.1.1, 2022.1.14, 2021.1.25, 2020.1.33 contains a handful of bug and security fixes.

For a list of changes, see the release notes:

Horizon 31.0.5

Release 31.0.5 is a bugfix release that also incorporates several documentation improvements, upgrades a couple of library dependencies, improves how plugins are included in the container images, and adds one small enhancement to the web UI.

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

For a complete list of changes, see the changelog.

The codename for Horizon 31.0.5 is Macaron.

The post March 2023 Releases – Horizon 31.0.5, 2023.1.1, 2022.1.14, 2021.1.25, 2020.1.33 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at March 08, 2023 06:14 PM

OpenNMS Horizon 31.0.5 (Macaron)

Release 31.0.5

Release 31.0.5 is a bugfix release that also incorporates several documentation improvements, upgrades a couple of library dependencies, improves how plugins are included in the container images, and adds one small enhancement to the web UI.

The codename for Horizon 31.0.5 is Macaron.

Story
  • Upgrade ActiveMQ to 5.15 (Issue NMS-12089)
  • Add documentation for using Scheduled Outages (Issue NMS-12621)
Enhancement
  • Replace wiki links across all codebase (Issue NMS-13912)
  • dependabot: mockito 3.4.6 to 4.6.1 (Issue NMS-14586)
  • DOC: Timeseries Documentation (Issue NMS-14959)
  • DOC: Configuration Manager API for External Requisitions is not documented (Issue NMS-15019)
  • Update dual write docs to clarify configuration (Issue NMS-15425)
  • Add collection package information to web UI (Issue NMS-15429)
  • PersistRegexSelectorStrategy is not where the docs say it should be (Issue NMS-15461)
Bug
  • Minion on Ubuntu fails to start (Issue NMS-15160)
  • Upgrade HikariCP to 5.x (Issue NMS-15171)
  • Docs: The "Housekeeping Tasks" page should not tell the user to always run fix-karaf-setup.sh on upgrade (Issue NMS-15296)
  • Elevation on Feather nav bar header casts undesirable shadow (Issue NMS-15367)
  • Docs: Update path reference for PostgreSQL config files (Issue NMS-15381)
  • opennms-karaf-health is not last in featuresBoot — might miss status for a few features (Issue NMS-15407)
  • Add Jdbc graph definitions for default collection set (Issue NMS-15419)
  • Invalid syntax due to typo in provisiond snmp graph (Issue NMS-15434)
Task
  • Number examples in service monitor chapters (Issue NMS-15215)
  • Document the breaking changes done as part of Limit script file locations for GpDetector and ScriptPolicy (Issue NMS-15288)
  • Move the logic for downloading plugins into the Dockerfile (Issue NMS-15401)

by mershad-manesh at March 08, 2023 05:51 PM

February 22, 2023

OpenNMS Releases OpenNMS Meridian 2023 with New Cloud-Enabled Capabilities

Meridian 2023 is a look into the future of network monitoring, centered around simplification

MORRISVILLE, N.C. – February 22, 2023 – The OpenNMS Group, Inc., a subsidiary of NantHealth, Inc. (NASDAQ: NH), today announced the release of OpenNMS Meridian 2023. With this major release, the fully open source Meridian product, which is the optimized and supported version of the OpenNMS platform curated by The OpenNMS Group, Inc. (OpenNMS) for production environments, now features cloud services, containerization benefits, and other advancements.

"The cloud capabilities we're launching with Meridian 2023 bring us a huge step closer to our vision of a world where monitoring just happens," said David Hustace, President, Founder at OpenNMS.

"Monitoring at the edge has been simplified—our hardware appliance solution can be installed and configured from our cloud portal in minutes. And customers can deploy and orchestrate Meridian as a container, then store their monitoring data in our new cloud-based Time Series DB, a massively scalable, multi-tenant storage solution."

Major new functionality in this Meridian update includes:
  • Time series database service. Time Series DB is a hosted cloud service that quickly scales with workloads as your needs change. No need to fight with complex storage requirements and maintain complicated infrastructure.
  • Containerized Meridian. Deploy consistently and predictably with containerized Meridian. Get the power and flexibility you require with minimal complexity.
  • Flows thresholding. Analyze your flow data against threshold computations to detect and alert you to anomalies and changes in your network environment.
  • Device configuration backup. Manage network device configuration backups natively within Meridian. Filter, search, and compare configurations at different points in time for specific devices.
  • Custom plugin development API. Extend the functionality of Meridian through our new official plugin API. Build plugins that utilize outputs, expand on configurations, and add new integrations to connect with your existing tools.
  • New hardware appliance. Minions, the distributed monitoring component for Meridian, are now able to run on dedicated, physical hardware—the OpenNMS Appliance. With the OpenNMS Appliance, you simplify your Minion deployment and save time by being able to manage, configure, and update an entire fleet of Minions with a single action. OpenNMS Appliance is built with security in mind and employs zero-trust architecture principles for communications and software integrity.

"We require the Appliance to use security features such as Trusted Platform Module (TPM), secure boot, and disk encryption to help prevent tampering and backdoors as part of our greater zero-trust initiative," says Jeff Jancula, CISO of OpenNMS.

While Meridian is open source, it's available through a subscription-based service that maximizes the platform with the most stable and secure features from OpenNMS Horizon, the community-driven distribution. The Meridian platform features inventory monitoring as well as performance, fault, and traffic management. Beyond that, Meridian offers business service monitoring, distributed data collection, support for BGP Monitoring Protocol (BMP), and application perspective monitoring. Known for its reliability and adaptability at scale, Meridian users can customize the monitoring platform to fit their unique needs. A major version of Meridian is released annually, with monthly updates, to maximize the platform’s value and minimize the effort required to maintain it.

OpenNMS has adopted penetration testing as a key component of our development and release processes for both the current products and forthcoming cloud services. In addition, OpenNMS 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. OpenNMS is also 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 2023, please visit https://www.opennms.com/meridian/.

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). 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

The post OpenNMS Releases OpenNMS Meridian 2023 with New Cloud-Enabled Capabilities appeared first on The OpenNMS Group, Inc..

by Colby Hoke at February 22, 2023 02:05 PM

February 13, 2023

Security update: Mandatory GPG key rotation for Meridian and Horizon

In the wake of the CircleCI breach, we have been reviewing policies and updating keys and tokens used in our automation for anything that could potentially be affected.

While we have no evidence of any of specific credentials being leaked, we've needed to document procedures for rotating keys anyway, so now was the perfect time to put it into practice.

On February 27, 2023, we will be rotating our GPG keys used to sign packages and repositories. To be prepared for the change in keys and avoid errors when updating packages, perform the following steps:

OpenNMS Meridian

All Meridian users should already be configured to use the updated OPENNMS-GPG-KEY by URL. After we start using the new key for signing, you will be asked to confirm it when you run a yum or dnf update.

If you'd like to import the new key now, run:

sudo rpm --import https://yum.opennms.org/OPENNMS-GPG-KEY

OpenNMS Horizon (RPM-Based)

For Red Hat Enterprise Linux and CentOS, re-run the instructions to add the repository and import the key, like so (where X is your version number):

sudo yum -y install https://yum.opennms.org/repofiles/opennms-repo-stable-rhelX.noarch.rpm

sudo rpm --import https://yum.opennms.org/OPENNMS-GPG-KEY

These repo files have been updated to contain the new key. After we start using the new key for signing, you'll be asked to confirm when you run a yum of dnf update.

OpenNMS Horizon (Debian-Based)

For Debian distributions, re-run the instructions to save the key for apt-get and apt:

curl -fsSL https://debian.opennms.org/OPENNMS-GPG-KEY | sudo gpg --dearmor -o /usr/share/keyrings/opennms.gpg

If it asks whether to overwrite the opennms.gpg file, say yes.

Questions?

If you have any issues, please reach out to us or visit the support portal.

The post Security update: Mandatory GPG key rotation for Meridian and Horizon appeared first on The OpenNMS Group, Inc..

by RangerRick at February 13, 2023 04:08 PM

February 08, 2023

February 2023 Releases – Horizon 31.0.4, 2022.1.13, 2021.1.24, 2020.1.32

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

Meridian Stable Updates

Meridians 2020.1.32 , 2021.1.24 and 2022.1.13 contains a handful of bug and security fixes, and a cosmetic change to the web UI.

For a list of changes, see the release notes:

Horizon 31.0.4

Release 31.0.4 introduces one breaking change (see below). It also brings a handful of containerization improvements, fixes several security vulnerabilities, upgrades many potentially vulnerable dependency libraries, fixes one bug in the BSM daemon, and fixes many non-security bugs.

Breaking changes
  • The GpDetector and ScriptPolicy now require that their scripts be located beneath $OPENNMS_HOME and beneath $OPENNMS_HOME/etc/script-policies, respectively. If you are using either of these classes in your foreign-source definitions, please address this requirement before upgrading to this release.

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

For a complete list of changes, see the changelog.

The codename for Horizon 31.0.4 is Otap.

The post February 2023 Releases – Horizon 31.0.4, 2022.1.13, 2021.1.24, 2020.1.32 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at February 08, 2023 04:47 PM

OpenNMS Horizon 31.0.4 (Otap)

Release 31.0.4

Release 31.0.4 introduces one breaking change (see below). It also brings a handful of containerization improvements, fixes several security vulnerabilities, upgrades many potentially vulnerable dependency libraries, fixes one bug in the BSM daemon, and fixes many non-security bugs.

Breaking changes
  • The GpDetector and ScriptPolicy now require that their scripts be located beneath $OPENNMS_HOME and beneath $OPENNMS_HOME/etc/script-policies, respectively. If you are using either of these classes in your foreign-source definitions, please address this requirement before upgrading to this release.
Known issues

The following known issues impact Horizon 31.0.4; we expect all to be fixed in the next micro-version release:

  • Regular users are unable to acknowledge or clear alarms from the geographical map’s integrated alarm browser. Until we identify a fix, it is possible to work around this problem by adding ROLE_REST to a user’s set of assigned roles. See NMS-15080 for details. Thanks to Ricardo Monteiro for bringing this problem to our attention.
  • On systems where dual-write time series persisting is enabled, an intermittent startup problem may cause either a delay in data starting to be persisted, or a hard failure necessitating a restarting of the core. See NMS-15326 for details.
  • The ALEC plugin currently cannot be successfully installed on a Sentinel node. At release time, it is unclear whether the problem lies in Sentinel or in ALEC. Some details are captured in NMS-15396.
Shout-outs and errata
Story
  • Add search term highlight functionality in documentation (Issue NMS-13540)
  • Geo Map node groups should split into individual markers (Issue NMS-15150)
  • Meridian container images are signed (Issue NMS-15341)

The codename for Horizon 31.0.4 is Otap.

Enhancement
  • remove image related defaults from Docker container makefile (Issue NMS-13583)
  • Add documentation for SELinux as a requirement to run OpenNMS (Issue NMS-14210)
  • No way to know the alarm type (as type 1, 2 or 3) from web UI (Issue NMS-14578)
  • Deploy Release Jars to Maven Central (Issue NMS-14727)
  • Make the cloud connect plugin available in container images (Issue NMS-15012)
  • Data collection and graph definitions for provisiond performance (Issue NMS-15018)
  • DOC: Configuration Manager API for External Requisitions is not documented (Issue NMS-15019)
  • Update docs with steps to activate Path Outage feature (Issue NMS-15218)
  • Container: output some details when we copy files into the container in entrypoint.sh (Issue NMS-15226)
  • Update VMware provisiond handler docs (Issue NMS-15270)
  • Make the ALEC plugin available in container images (Issue NMS-15349)
  • Make the Cortex TSS plugin available in container images (Issue NMS-15350)
  • Smoke test improvements and small tweaks to help developers (Issue NMS-15387)
Bug
Task
  • CVE in Jolokia 1.3.3 dependency (Issue NMS-15068)
  • CVE-2021-37714 for jsoup (multiple versions) (Issue NMS-15069)
  • vulnerable Junit dependency (Issue NMS-15074)
  • RHEL9 installation documentation tab (Issue NMS-15079)
  • Document deviceconfig tftp maximumReceiveSize (Issue NMS-15121)
  • JAVA_KEYALIAS Variable needs to be updated (Issue NMS-15239)
  • JAVA_KEYSTORE Variable needs to be updated (Issue NMS-15240)
  • JAVA_STOREPASS Variable needs to be updated (Issue NMS-15241)
  • Document the breaking changes done as part of Limit script file locations for GpDetector and ScriptPolicy (Issue NMS-15288)
  • Release notes / wart: ALEC not installable on M2023.1.0 / H31.0.4 Sentinel (Issue NMS-15403)
  • Release notes / wart: dual-write TS delay on startup (Issue NMS-15404)
  • Release notes / wart: Geo map alarms and ROLE_REST (thank Ricardo Monteiro for the report) (Issue NMS-15406)
Epic
  • Publish container images to a container registry other than DockerHub (Issue NMS-15091)
Unexpected Behavior
  • Link on Netflow9 to main Netflow doc is broken (Issue NMS-15144)

by mershad-manesh at February 08, 2023 04:18 PM

January 12, 2023

How to Monitor Processes With SNMP

Monitoring processes that don't provide network services is a default use case in network monitoring. Because they aren't providing network services, black box testing won't work- you need an agent on your system providing an inside view of your operating system. The Net-SNMP agent is easy to install and configure on Linux or Unix. It's compatible with any monitoring solution that supports SNMP, such as OpenNMS.

By default, there are basically two methods utilizing Net-SNMP:

  1. Using the HOST-RESOURCES-MIB
  2. Using the UCD-SNMP-MIB. Both are supported by the Net-SNMP agent.

Both methods produce the same result, but each will impact your monitoring system configuration and maintenance differently.

To help you decide which method to use, this article will discuss the costs and benefits for each. In this example, we'll discuss different monitoring solutions for two single processes as well as a multiprocess application.

Using the Host Resources MIB

When you're using the Host Resources MIB, the key information is in two tabular objects: the hrSWRunName and the according hrSWRunStatus.

In OpenNMS, you can use the HostResourceSwRunMonitor.

The key parameters are:

  • service-name: The name of the process you want to monitor from the hrSWRunName object
  • match-all: In case there are multiple processes running, all processes need to be in the named run-level state
  • run-level: The status of the process status, by default it is set to 2 and does not need to be changed

A typical SNMP output:

snmpwalk -v 2c -c useVersion3 localhost .1.3.6.1.2.1.25.4.2.1.2

.1.3.6.1.2.1.25.4.2.1.2.895 = STRING: "dockerd"

.1.3.6.1.2.1.25.4.2.1.2.938 = STRING: "tincd"

.1.3.6.1.2.1.25.4.2.1.2.1416 = STRING: "docker-proxy"

.1.3.6.1.2.1.25.4.2.1.2.1428 = STRING: "docker-proxy"

.1.3.6.1.2.1.25.4.2.1.2.1635 = STRING: "docker-proxy"

.1.3.6.1.2.1.25.4.2.1.2.1761 = STRING: "docker-proxy"

.1.3.6.1.2.1.25.4.2.1.2.1880 = STRING: "docker-proxy"

.1.3.6.1.2.1.25.4.2.1.2.1902 = STRING: "docker-proxy"

.1.3.6.1.2.1.25.4.2.1.2.1916 = STRING: "docker-proxy"

.1.3.6.1.2.1.25.4.2.1.2.1928 = STRING: "docker-proxy"

.1.3.6.1.2.1.25.4.2.1.2.1941 = STRING: "docker-proxy"

.1.3.6.1.2.1.25.4.2.1.2.1954 = STRING: "docker-proxy"

.1.3.6.1.2.1.25.4.2.1.2.1972 = STRING: "docker-proxy"

snmpwalk -v 2c -c useVersion3 localhost .1.3.6.1.2.1.25.4.2.1.7

.1.3.6.1.2.1.25.4.2.1.7.895 = INTEGER: runnable(2)

.1.3.6.1.2.1.25.4.2.1.7.938 = INTEGER: runnable(2)

.1.3.6.1.2.1.25.4.2.1.7.1416 = INTEGER: runnable(2)

.1.3.6.1.2.1.25.4.2.1.7.1428 = INTEGER: runnable(2)

.1.3.6.1.2.1.25.4.2.1.7.1635 = INTEGER: runnable(2)

.1.3.6.1.2.1.25.4.2.1.7.1761 = INTEGER: runnable(2)

.1.3.6.1.2.1.25.4.2.1.7.1880 = INTEGER: runnable(2)

.1.3.6.1.2.1.25.4.2.1.7.1902 = INTEGER: runnable(2)

.1.3.6.1.2.1.25.4.2.1.7.1916 = INTEGER: runnable(2)

.1.3.6.1.2.1.25.4.2.1.7.1928 = INTEGER: runnable(2)

.1.3.6.1.2.1.25.4.2.1.7.1941 = INTEGER: runnable(2)

.1.3.6.1.2.1.25.4.2.1.7.1954 = INTEGER: runnable(2)

.1.3.6.1.2.1.25.4.2.1.7.1972 = INTEGER: runnable(2)

For each process you want to monitor, you have to create a service monitor named something like Process-docker-proxy, Process-tincd and Process-dockerd.

Pros: It allows you to set up granular monitoring for every process. The service monitors can be used in "Service Level Management" on the start page for availability calculation and notifications for each process.

Cons: You have to configure and maintain a service monitor for each process you want to monitor in OpenNMS. It is not possible to configure something like: "At least a number x of y processes need to be running to have the service to be ok."

Using the UCD-SNMP-MIB

Net-SNMP has a mechanism to monitor processes on the system with the proc directive in the configuration file. The proc directive is pretty easy to configure:

proc docker-proxy 20 5

The first argument is the name of the process you want to monitor—in this case the process named docker-proxy. To be safe, you should run at least 5, but not more than 20 processes named docker-proxy. The maximum and minimum number of processes is optional. And when they don't exist, at least one process should be running to be okay.

If you'd like to use a configuration management tool to configure your SNMP agent, in snmpd.conf, you can use the:

includeDir /etc/snmp/conf.ddirective

That way you can drop a .conf file with the proc directive for each application you want to monitor, and each will be included.

An example for monitoring tincd, dockerd, and docker-proxy with the configured proc looks like the following:

Name of the process

snmpwalk -v 2c -c useVersion3 localhost .1.3.6.1.4.1.2021.2.1.2
iso.3.6.1.4.1.2021.2.1.2.1 = STRING: "tincd"
iso.3.6.1.4.1.2021.2.1.2.2 = STRING: "dockerd"
iso.3.6.1.4.1.2021.2.1.2.3 = STRING: "docker-proxy"

Number of instances

snmpwalk -v 2c -c useVersion3 localhost .1.3.6.1.4.1.2021.2.1.5
iso.3.6.1.4.1.2021.2.1.5.1 = INTEGER: 3
iso.3.6.1.4.1.2021.2.1.5.2 = INTEGER: 1
iso.3.6.1.4.1.2021.2.1.5.3 = INTEGER: 13

Error messages

snmpwalk -v 2c -c useVersion3 localhost .1.3.6.1.4.1.2021.2.1.101
iso.3.6.1.4.1.2021.2.1.101.1 = ""
iso.3.6.1.4.1.2021.2.1.101.2 = ""
iso.3.6.1.4.1.2021.2.1.101.3 = ""

Error flags

snmpwalk -v 2c -c useVersion3 localhost .1.3.6.1.4.1.2021.2.1.100
iso.3.6.1.4.1.2021.2.1.100.1 = INTEGER: 0
iso.3.6.1.4.1.2021.2.1.100.2 = INTEGER: 0
iso.3.6.1.4.1.2021.2.1.100.3 = INTEGER: 0

The PrTableMonitor uses the tables above to monitor the status of running processes. There are no specific configuration parameters necessary, because the configuration of how and which processes are monitored is located in the Net-SNMP configuration.

In OpenNMS, configure just one monitor named something like Process-Table. As soon as the Net-SNMP agent identifies a process is not running in the specified boundaries, the Error Flag table is updated and is changed from 0 to 1. The OpenNMS monitor will populate a list of names with the processes that are not in a desired state.

Pros: You have only to configure one PrTable Monitor in OpenNMS, regardless of how many processes you want to monitor. The detailed configuration of which process needs to be monitored is configured on the monitored system itself; the SNMP agent needs to be configured anyway, and configuration management tools are in place in larger environments. It is possible to configure in detail how many processes and which processes need to be monitored. Only one service goes down if multiple processes fail.

Cons: There is only one service in OpenNMS for all services, it is not possible to notify different people for specific processes. In case you have one process that fails and the monitor goes down and a second process fails, the event reason in OpenNMS documents only the event reason for the initial process failure.

The post How to Monitor Processes With SNMP appeared first on The OpenNMS Group, Inc..

by Ronny at January 12, 2023 12:00 AM

January 11, 2023

January 2023 Releases – Horizon 31.0.3, Meridian 2022.1.11, 2021.1.23, 2020.1.31

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

Meridian Stable Updates

Meridians 2020.1.31 , 2021.1.23 , and 2022.1.11 contains a handful of bug and security fixes, and a cosmetic change to the web UI.

For a list of changes, see the release notes:

Horizon 31.0.3

Release 31.0.3 is a minor release which fixes a number of UI and backend bugs, brings one small UI enhancement, patches two potential security vulnerabilities, and formalizes support for RHEL 9 and PostgreSQL 15.

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

For a complete list of changes, see the changelog.

The codename for Horizon 31.0.3 is Biscotti.

The post January 2023 Releases – Horizon 31.0.3, Meridian 2022.1.11, 2021.1.23, 2020.1.31 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at January 11, 2023 04:01 PM

OpenNMS Horizon 31.0.3 (Biscotti)

Release 31.0.3

Release 31.0.3 is a minor release which fixes a number of UI and backend bugs, brings one small UI enhancement, patches two potential security vulnerabilities, and formalizes support for RHEL 9 and PostgreSQL 15.

The codename for Horizon 31.0.3 is Biscotti.

Task
  • Geo Map: Add content to the map marker pop up (Issue NMS-13698)
  • Uncontrolled Resource Consumption in Jackson-databind (Issue NMS-15030)
  • Add flow version table to Flow Introduction (Issue NMS-15158)
  • Change OpenNMS Copyright from 2022 to 2023 (Issue NMS-15211)
  • Change OpenNMS Copyright from 2022 to 2023 in the documentation footer (Issue NMS-15212)
Enhancement
  • Include Minion version on "Manage Minions" page (Issue NMS-14493)
  • Update docs to include RHEL 9 install instructions (Issue NMS-15147)
  • Test and Document Support for PostgreSQL 15 (Issue NMS-15151)
Bug
  • RRD persistence with default configs in our Horizon OCI points to wrong libjrrd2.so (Issue NMS-14778)
  • Chrome/Edge Web Browser : Geographical Map Node Counters are wrong (Issue NMS-14792)
  • Form Resubmission From Cache (Issue NMS-14933)
  • Web UI menu item "Endpoints" not in best location (Issue NMS-15004)
  • Incorrect labels on OpenNMS-JMX collection resource types (Issue NMS-15044)
  • Snmp collect reversing to unticked after a few hours (Issue NMS-15117)
  • Log Out does not work from new nav-bar menu (Issue NMS-15119)
  • reloading BSM daemon causes the state of serviceProblem alarm to be reset (Issue NMS-15124)
  • Vue Menubar items obscured by Geo Map (Issue NMS-15149)
  • Flows adapters don’t start on Sentinel running as a container. (Issue NMS-15161)
Epic
  • Formalize support for RHEL 9 and its derivatives (Issue NMS-14897)
Story
  • Fix smoke test for new UI (Issue NMS-14910)
  • Add JSON support (in additional to GBP) to the Kafka producer for flows (Issue NMS-15027)
  • publish opennms-plugin-cloud 1.0.6 (Issue NMS-15142)

by mershad-manesh at January 11, 2023 03:48 PM

December 17, 2022

December 14, 2022

December 2022 Releases – Horizon 31.0.2, Meridian 2022.1.10, 2021.1.22, 2020.1.30

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

Meridian Stable Updates

Meridians 2020.1.30 , 2021.1.22 , and 2022.1.10 contains a handful of bug and security fixes, and a couple of back-ported enhancements.

For a list of changes, see the release notes:

Horizon 31.0.2

Release 31.0.2 is a minor release which fixes a great many bugs and security vulnerabilities, updates the versions of many library dependencies, and introduces some enhancements related to Minion Appliances.

The official documentation has also received significant improvements.

NOTE: The documentation for enabling JAAS encryption for Minion and Sentinel has changed. If you have enabled encryption previously and wish to enable stronger Jasypt-based encryption, you need to reset any existing user passwords.

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

For a complete list of changes, see the changelog.

The codename for Horizon 31.0.2 is Stroopwafel.

The post December 2022 Releases – Horizon 31.0.2, Meridian 2022.1.10, 2021.1.22, 2020.1.30 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at December 14, 2022 04:12 PM

OpenNMS Horizon 31.0.2 (Stroopwafel)

Release 31.0.2

Release 31.0.2 is a minor release which fixes a great many bugs and security vulnerabilities, updates the versions of many library dependencies, and introduces some enhancements related to Minion Appliances. The official documentation has also received significant improvements.

The documentation for enabling JAAS encryption for Minion and Sentinel has changed. If you have enabled encryption previously and wish to enable stronger Jasypt-based encryption, you need to reset any existing user passwords.

The codename for Horizon 31.0.2 is Stroopwafel.

Bug
  • Failures when jaeger tracing is enabled on Core server and Minion (Issue NMS-14550)
  • Missing /run/opennms on Ubuntu (Issue NMS-14650)
  • javadoc not being generated in H31 (Issue NMS-14750)
  • OpenNMS opennms start fails on Ubuntu (Issue NMS-14838)
  • Regression: install script fails if an OpenNMS directory contains root-owned lost+found directory (Issue NMS-14919)
  • No /var/lib/opennms on 30.0.4 Docker image (Issue NMS-14976)
  • XML Entity Expansion Injection in geolocation API (Issue NMS-14988)
  • UI Preview: UI Plugins do not work if multiple are installed (Issue NMS-14996)
  • OIA Pollers non-functional (Issue NMS-15001)
  • Web UI menu item "Endpoints" not in best location (Issue NMS-15004)
  • Icon for admin menu items missing from some items (Issue NMS-15005)
  • Remove reference to remote pollers (Issue NMS-15017)
  • Lock contention in SnmpPeerFactory (Issue NMS-15042)
  • opennms rpm could get wrong jetty files (Issue NMS-15043)
  • Horizon Karaf container not healthy after installing opennms-timeseries-api with opennms-plugins-cortex-tss (Issue NMS-15078)
  • RHEL9/CentOS9/Rocky 9 need chkconfig package to enable service properly (Issue NMS-15093)
  • Default limit of 10 is not working for event queries (Issue NMS-15123)
Enhancement
  • Dependabot: leaflet from 1.7.1 to 1.8.0 (Issue NMS-14584)
  • Error compiling Cisco MIB (Issue NMS-14640)
  • Doc update: Enable salted hash passwords within Karaf for core/Minion/Sentinel (Issue NMS-14736)
  • Add "admin" disambiguation to Glossary (Issue NMS-14914)
  • simplify docker tags in H31+ (Issue NMS-14989)
  • Update Debian/Ubuntu Upgrade Instructions (Issue NMS-15087)
  • dependabot: Upgrade PostgreSQL dependency to 42.4.3 (or higher) (Issue NMS-15095)
  • Update style elements in Quick Start guide (Issue NMS-15106)
Unexpected Behavior
  • RPM packages fail to install when FIPS Enabled (Issue NMS-14628)
Story
  • Upgrade AngularJS to latest 1.x (Issue NMS-14715)
  • Apache Log4j 1.x Multiple Vulnerabilities (PB-2022, Sep 2022) (Issue NMS-14818)
  • Modify foreign source in HeartbeatConsumer to ignore docker interfaces and detect SNMP agent (Issue NMS-14855)
  • OpenShift test coverage (Issue NMS-14882)
  • SNMP Community retrieval through SCV on Minion (Issue NMS-15008)
  • Add JSON support (in additional to GBP) to the Kafka producer for flows (Issue NMS-15027)
  • Backport deploy-base update from develop to release-31.x (upgrades JRE minor version, adds vim-tiny, less) (Issue NMS-15046)
  • Add KPI for Appliance count by model (Issue NMS-15051)
Task
  • Quick Start: "Beyond Quick Start" chapter (Issue NMS-14735)
  • H31 Release testing (Issue NMS-14797)
  • Review enlinkd documentation (Issue NMS-14850)
  • Update Visualization topic in Quick Start guide (Issue NMS-15029)
  • Fix Antora version differences (Issue NMS-15088)
  • Update opennms-plugin-cloud to 1.0.4 (Issue NMS-15122)

by mershad-manesh at December 14, 2022 03:59 PM

November 16, 2022

November 2022 Releases – Horizon 31.0.1

Horizon 31.0.1

Release 31.0.1 is a small out-of-band release to address some issues found during 31.0.0 testing.

It contains a few small changes including a fix for unusually large docker images and some other small bug fixes,
as well as some updates to the new Quick Start Guide and a fix to the installation instructions for the Cortex plugin.

Please note there is a known issue that only one plugin entry shows up in the navigation bar's "Plugins" menu, even if multiple plugins are installed.
Only ALEC users who install the cloud connector are impacted.
ALEC users therefore should avoid the Cloud Services Connector plugin until a new release fixes the underlying bug.

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

For a complete list of changes, see the changelog.

The codename for Horizon 31.0.1 is Oreo.

See the differences between Horizon and Meridian.

The post November 2022 Releases – Horizon 31.0.1 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at November 16, 2022 09:51 PM

OpenNMS Horizon 31.0.1 (Oreo)

Release 31.0.1

Release 31.0.1 is a small out-of-band release to address some issues found during 31.0.0 testing.

It contains a few small changes including a fix for unusually large docker images and some other small bug fixes, as well as some updates to the new Quick Start Guide and a fix to the installation instructions for the Cortex plugin.

Please note there is a known issue that only one plugin entry shows up in the navigation bar’s "Plugins" menu, even if multiple plugins are installed. Only ALEC users who install the cloud connector are impacted. ALEC users therefore should avoid the Cloud Services Connector plugin until a new release fixes the underlying bug.

The codename for Horizon 31.0.1 is Oreo.

Bug
  • OpenAPI Validation Errors (Issue NMS-14408)
  • Snmp Polling Status shows Polled even though it’s actually not (Issue NMS-14653)
  • Duplicated message when alarm is not found (Issue NMS-14686)
  • Errors while installing opennms-timeseries-api from karaf shell (Issue NMS-14874)
  • When you delete/put memo or journal it always returns 204 even if alarm not exists (Issue NMS-14901)
  • NoSuchElementException errors thrown by EnhancedLinkd (Issue NMS-14912)
  • Docs for Cortex plugin are incorrect (Issue NMS-14945)
  • Horizon/Sentinel docker image size ballooned (Issue NMS-15006)
  • HZN 31: Ubuntu installation issues (Issue NMS-15007)
Story
  • Quick Start: Review entire quick start section when complete. (Issue NMS-14721)
  • New UI Preview: Ensure ALEC UI works (Issue NMS-14891)
Task
  • Update Quick Start login chapter (Issue NMS-14984)
  • Update notifications.adoc in Quick Start section (Issue NMS-14985)
  • Update Quick Start notifications configuration chapter (Issue NMS-14999)

by mershad-manesh at November 16, 2022 09:42 PM

November 09, 2022

November 2022 Releases – Horizon 31.0.0, Meridians 2022.1.9, 2021.1.21, 2020.1.29, 2019.1.40

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

Meridian Stable Updates

Meridians 2019.1.40, 2020.1.29 , 2021.1.21 , and 2022.1.9 contains a handful of bug and security fixes, and a couple of back-ported enhancements.

For a list of changes, see the release notes:

Horizon 31.0.0

Release 31.0.0 is a new major release.

It contains several new features, including the Cloud Services Connector with Time Series DB support and a new quick-start guide.

Notable enhancements include integration of the Horizon 30 "UI Preview" items into the main UI and performance improvements to network topology discovery.
It also includes an important bug fix correcting a regression that rendered Horizon 30 unable to run in OpenShift environments, besides many other important bug and security fixes.

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

For a complete list of changes, see the changelog.

The codename for Horizon 31.0.0 is Doppelkeks.

The post November 2022 Releases – Horizon 31.0.0, Meridians 2022.1.9, 2021.1.21, 2020.1.29, 2019.1.40 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at November 09, 2022 04:51 PM

October 27, 2022

2022 Cybersecurity Awareness Month

October’s Cybersecurity Awareness Month seems like a great time to discuss the improvements we are making at The OpenNMS Group to improve our security practices.

For almost 20 years, OpenNMS staff developers and the open source contributor community have partnered to create robust and secure network monitoring platforms available in community-driven (Horizon) and enterprise-ready (Meridian) distributions..

Because OpenNMS deployments have access to sensitive network data within organizations, our developers have always diligently watched for security issues and responded quickly to address significant problems when needed. Security at OpenNMS was collectively “owned” by everyone.

In 2021, I joined OpenNMS as Chief Information Security Officer and began formalizing our security program. Although I still want security as part of everyone’s job, I also wanted our new security team to align our security program to industry standard practices, by making the following improvements:

  • Adopt the ISO/IEC 27001/2 Information security, cybersecurity, and privacy protection framework for the OpenNMS Security Program.
  • Create new Information Security Standards (“rules”) aligned to ISO. We completed phase one in June 2022.
  • Revise our internal software development, operations, and business processes to better align to our new security standards and ISO. We expect to complete this phase two work by year-end 2022.
  • In 2023, we will conduct an audit of our security program to ensure alignment to security best practices as described in ISO 27001/2.
  • Updated our privacy practices to ensure compliance with GDPR and CCPA privacy regulations.
  • OpenNMS recently became a CVE numbering authority (CNA) so that we can now feed vulnerability remediation information into the global CVE database maintained by the non-profit MITRE Corporation. This allows our customers to use industry-standard tools to quickly detect and remediate reported vulnerabilities within our software.
  • Engaged an outside firm to increase security penetration testing for our products and services. Previously all security testing was in-house or by the open-source community, which remain valuable sources of security testing.

We welcome any questions or feedback regarding these security improvements via email (security@opennms.com) or our customer support team. And thank you for using and contributing to OpenNMS projects and products.

Jeff Jancula, Chief Information Security Officer

The post 2022 Cybersecurity Awareness Month appeared first on The OpenNMS Group, Inc..

by Jeff Jancula at October 27, 2022 05:03 PM

October 17, 2022

Celebrate Open Source during Hacktoberfest 2022

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.

How to contribute

First, visit the Hacktoberfest website to register for the event. Second, contribute to any open source project.

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 (marked quickwin or quickwindoc) in our issue tracker that are reasonable candidates to claim for the event. Claim a ticket by assigning it to your user name and click the "Start Progress" button.

Feel free to join our Mattermost chat server and pop in to the OpenNMS Development channel if you have any questions or want some guidance on where to start.

Hack the planet!

The post Celebrate Open Source during Hacktoberfest 2022 appeared first on The OpenNMS Group, Inc..

by Ronny at October 17, 2022 08:00 PM

October 12, 2022

October 2022 Releases – Horizon 30.0.4, Meridians 2022.1.8, 2021.1.20, 2020.1.28, 2019.1.39

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

Meridian Stable Updates

Meridians 2019.1.39, 2020.1.28 , 2021.1.20 , and 2022.1.8 contains a handful of bug and security fixes, and a couple of back-ported enhancements.

For a list of changes, see the release notes:

Horizon 30.0.4

Release 30.0.4 contains quite a few bug and security fixes and a number of enhancements.

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

For a complete list of changes, see the changelog.

The codename for Horizon 30.0.4 is Capybara.

The post October 2022 Releases – Horizon 30.0.4, Meridians 2022.1.8, 2021.1.20, 2020.1.28, 2019.1.39 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at October 12, 2022 03:18 PM

October 03, 2022

OpenNMS On the Horizon – October 3rd, 2022

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

Since last time, we worked on documentation (SNMP poller, Trapd, Enlinkd, requisitions, quick start guide), Enlinkd refactoring, Docker container scanning, Horizon Stream (Keycloak integration, operator config, port forwarding, metrics, PostgreSQL auth, CI, Minion gateway, Kafka, docs, PagerDuty, ignite tests, Helm charts, UI navigation), event improvements, Sonar and code coverage, ALEC (API, test coverage, UI), tests (CI improvements, device config backup, logging), time-series off-heap support, provisioning, cookies and CSRF, JavaScript dependencies, Helm (AngularJS to React transition), and UI preview integration.

Github Project Updates

Internals, APIs, and Documentation
  • Mark Mahacek worked on SNMP poller and Trapd documentation
  • Antonio refactored some Enlinkd scheduling classes out into core/daemon
  • Morteza worked on Docker container security scanning
  • I worked on backporting Docker changes to foundation-2022
  • Gerald did more work on the Keycloak integration in Horizon Stream
  • Dmitri continued his work on poller config support in OPA
  • Antonio added some test coverage for Enlinkd startup
  • Antonio made a bunch of updates to Enlinkd documentation
  • Emily worked on a bunch of cleanups to the requisition docs
  • Jeffrey-David Kapp did a bunch of simplifications to operator config and port forwarding for Stream
  • Thomas started implementing datachoices metrics in Stream
  • Gerald enabled configuring PostgreSQL authentication in Stream
  • Jason continued his work on a CI pipeline for Stream
  • Łukasz and Mark Frazier did more work on the Minion gateway in Stream
  • Mark Mahacek worked on a number of event formatting and reduction key improvements
  • I worked on fixing up Sonar runs in foundation-2022 including supporting code coverage from smoke tests
  • James fixed some Kafka-related test failures in Stream
  • Ronny worked on some doc changes in Stream
  • Benjamin Janssens worked on adding and removing alarms from situations in ALEC
  • Mike Rose worked on the PagerDuty integration in Stream
  • Arthur worked on ignite integration in Stream test infrastructure
  • Bonnie worked on service availability info in the quick start guide
  • Emily worked on baseline and notifications docs in the quick start guide
  • I fixed some CI fallout from recent integration test container changes
  • Alexander worked on creating a device config backup smoke test
  • I fixed maven signing in the ALEC release CI
  • Gerald worked on helm chart improvements in Stream
  • Morteza worked on speeding up smoke tests by combining them in a single CircleCI job
  • I changed a bunch of AbstractMockDao logging to trace-level, it's way too chatty when running tests
  • Freddy worked on some buffering improvements in time-series off-heap caching
  • Sean fixed an issue with an NPE in provisioning when the web UI is run independent of the backend
Web, REST, UI, and Helm
  • Christian made some changes to default cookie handling and CSRF tokens for forms
  • I worked on modernizing some of our javascript dependencies
  • Chinh Le reworked the Horizon Stream navigation
  • Benjamin Janssens worked on test coverage for the ALEC UI
  • Anya worked on pagination and search in the ALEC UI
  • Rob did more work on fixing an add issue with limits in the location REST API
  • Scott worked on converting Helm's AngularJS components to React
  • Scott did some initial work to integrate the new UI and menu bar
Contributors

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

  • Chinh Le
  • Scott Theleman
  • Łukasz Dywicki
  • Benjamin Reed
  • Mark Frazier
  • Dmitri Herdt
  • Christian Pape
  • Sean Torres
  • Gerald Humphries
  • Anya Rybalova
  • Bonnie Robinson
  • Morteza Ershad-Manesh
  • Freddy Chu
  • Emily Marsh
  • Benjamin Janssens
  • Alexander Chadfield
  • Thomas Bigger
  • Scott Thompson
  • Mark Mahacek
  • Jeffrey-David Kapp
  • Arthur Naseef
  • Mike Rose
  • Rob Ellis
  • Antonio Russo
  • Alberto Ramos
  • James Hutchinson
  • Ronny Trommer
  • Jason Berry

Coming Soon: JIRA Migration

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

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

Hacktoberfest

It's that time of year again!

Hacktoberfest 2022 has started, and it is once again time to make open source projects better and maybe get a t-shirt in the process. ;)

OpenNMS is participating and we've got a bunch of issues marked quickwin or quickwindoc in our issue tracker if you'd like to play along.

Feel free to join our Mattermost chat server and pop in to the OpenNMS Development channel if you have any questions or want some guidance on where to start.

Happy hacking!

Releases and Roadmap

Upcoming 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 12th, 2022.

We currently expect updates to all supported Meridians, plus Horizon 30.

Next Horizon: 31 (Q4 2022)

The next major Horizon release will be Horizon 31.

It will contain a number of improvements, including:

  • a refactoring of flow APIs including support for some flow hooks in the plugin API (plugin API 1.1.0+)
  • major improvements and refactoring in Enlinkd's bridge topology mapping and collection scheduling
  • a bunch of improved analytics in our datasources plugin
  • support for Hashicorp Vault in SCV
  • promoting a number of the "UI preview" enhancements to become part of the main UI
  • improvements to the requisitions REST API
  • a new Quick Start Guide in the documentation
Next Meridian: 2023 (Q1 2023)

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

Meridian 2019 EOL in November

Meridian releases are supported for 3 years.
The initial Meridian 2019 happened pretty late in the year, so its 3-year birthday will be November 6th, 2022.
The November 9th release cycle will be the final release as it rolls out of active support.

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.

Calendar of Events

All Things Open - Raleigh, NC - October 30th through November 2nd, 2022

All Things Open is local to our headquarters, and is a truly fantastic event.
We love it so much, we will be the exclusive live stream sponsor. 😉

We'll also have a booth in the exhibition hall.
A bunch of OpenNMS folks will be attending and/or helping out in the booth, so please be sure to say hi!

Open Source Monitoring Conference - Nuremberg, Germany - November 14th through 16th

The OpenNMS Group is a gold sponsor of OSMC this year, and will have a booth as well.
Stop by and say hello!

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-142: Situation Storage: Implement situation storage to definite location.
  • ALEC-178: Sonar Cloud Security Grade A - Figure out What We Need to Fix and Report the List
  • ALEC-180: Investigate MIMIC to test ALEC
  • ALEC-183: Fix visual bugs - release 2.1.x
  • ALEC-191: Backend - Create endpoint to add/remove alarms from situation
  • HS-117: Release tags for Docker Images and Github
  • HS-127: Ingress update for latest k8s versions
  • HS-129: Allow for instance specific SSL certs
  • HS-140: Cleanup UI yaml and entrypoint.sh for hs ui image
  • HS-234: Add notifications GQL mutation when service is available
  • HS-282: Elasticsearch pod stuck pending
  • HS-310: Remove manual steps from dev environment setup
  • HS-339: Stats: Implement Phase 1 Metrics collection
  • HS-344: Grafana test and config for operator
  • HS-354: Expose notifications endpoints through GQL
  • HS-368: Strimzi Kafka memory usage
  • HS-370: Get ingress to use port 80, https as well.
  • HS-380: FE - Add store unit tests
  • HS-382: Keycloak realm import from Keycloak operator sometimes fails when deployed into Kind
  • HS-384: Error from first Keycloak realm import: "Key (name)=(master) already exists."
  • HS-395: Dynamic imports only work in local dev
  • HS-397: Research/prototype with different charting libraries
  • HS-402: Update and fix Vitest config to handle latest Featherds versions
  • HS-403: Repo cleanup: remove local-sample
  • HS-407: AlarmKafkaConsumerIntegrationTest.testProducingAlarmWithConfigSetup fails intermittently
  • HS-409: Convert any ConfigMaps that store sensitive info to Secrets
  • HS-410: Enable Postgres authentication
  • HS-411: Allow Operator to generate passwords with special characters
  • HS-412: Handle TLS properly across Helm chart
  • HS-416: Keycloak password is showing in Core logs
  • HS-420: Allow configuration of ingress port numbers in Operator/CRD
  • HS-423: UX competitive analysis on 5 competitors
  • NMS-9334: BSMAdminIT flapping
  • NMS-14125: Discourage and optimize use of cci build workspace
  • NMS-14397: EnhancedLinkd Collection priority Scheduling
  • NMS-14450: VMware requisition import fail with "Problem getting input stream: '{}'"
  • NMS-14520: Build MOS dashboard and supporting components
  • NMS-14539: Identify web UI styling quick wins
  • NMS-14593: Populate Velocloud Partner Requisition with Gateway Nodes
  • NMS-14617: Quick Start: Set up a threshold
  • NMS-14660: MOS CDR: Grafana/Helm Integration, display MOS data
  • NMS-14671: Add documentation for partial configuration modification via REST
  • NMS-14716: Form Can Be Manipulated with Cross-Site Request Forgery (CSRF)
  • NMS-14717: Session Cookie (Authentication Related) Does Not Contain The "HTTPOnly" Attribute
  • NMS-14724: backport CircleCI and Docker enhancements from develop to release-30.x
  • NMS-14729: Add new handling options for the snmp provisioning metadata adapter
  • NMS-14731: Can the OG nav-bar coexist with a Feather / Vue app?
  • NMS-14740: Kafka Producer NPE causes collection failure overall
  • NMS-14763: Add Priority Executor Classes
  • NMS-14771: Move Common Adapter Enlinkd classes to Core
  • NMS-14772: Implement connection manager
  • NMS-14773: Provide SubNetwork Classes for Enhanced Linkd
  • OIA-45: OIA Add interface for poller-configuration

The post OpenNMS On the Horizon – October 3rd, 2022 appeared first on The OpenNMS Group, Inc..

by RangerRick at October 03, 2022 07:47 PM

September 26, 2022

OpenNMS On the Horizon – September 26th, 2022

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

Since last time, we worked on pyroscope profiling, CircleCI improvements, documentation (Grafana dashboard, Quick Start guide, Trapd, graphQL notification query, requisition REST), Horizon Stream (Minion gateway and heartbeat, operator improvements, JMX, Helm charts, PagerDuty, discovery), Sonar bug fixes, OPA (Poller Config and time-series offheap persistence), SNMPv3 traps, Enlinkd, Graphite time-series, smoke tests, flow classification, Provisiond config validation, SNMP metadata provisioning, Helm improvements, ALEC UI, startup progress bar, and web form fixes.

Github Project Updates

Internals, APIs, and Documentation
  • DJ worked on adding support for Pyroscope profiling
  • Morteza tested out reducing build container sizes for RPM/Debian builds
  • Morteza worked on cleaning up some output in the dynamic config scripts
  • Mark Mahacek worked on the grafana dashboard docs
  • Bonnie and Emily did more work on the quick start guide including performance data, system baseline, and thresholding info
  • Morteza fixed some issues in experimental build triggering in dynamic config
  • Mark Frazier did some more work on the Minion gateway in Horizon Stream
  • Yang Li worked on bringing some JMX code over to Stream
  • Gerald did some more work on Helm charts in Stream
  • I worked on cleaning up some leftover Sonar stuff from DevJam
  • Łukasz continued his work on twin/RPC for the Minion gateway
  • Arthur worked on some SNMP utility and testing code in Stream
  • Emily cleaned up the JDK references and some other formatting in the deployment guide
  • Jeffrey-David Kapp worked on some namespace code for the Keycloak operator in Stream
  • I fixed the ActiveMQ initialization to happen lazily so it doesn't yell if not configured
  • James updated the Stream PagerDuty integration to attach alarm details to the payload
  • Chandra continued his work on discovery in Stream
  • Dmitri worked on poller config support in OPA
  • Freddy continued to work on OPA time-series persistence
  • Arthur and Mark Frazier added Minion heartbeat processing in Stream
  • Alex implemented no-op message processors for ignoring spurious chunks in SNMPv3 traps
  • Bonnie added Trapd to the daemon reference
  • I did a bunch of optimization work in our CircleCI pipeline to reduce network usage
  • Antonio refactored the NetworkBuilder used in Enlinkd tests
  • Antonio worked on Enlinkd per-protocol scheduling intervals
  • Alexander worked on fixing the flapping BSM admin integration test
  • Thomas worked on usage statistics in Stream
  • Dustin did more work on flow classification improvements
  • Dmitri added some validation to Provisiond config loading
  • Scott improved the Graphite time-series adapter to support setting the node in groovy scripts
  • Antonio updated our InetAddress tools to include some Netmask-related utility functions
  • Gerald refactored a bunch of configs related to startup in Stream
  • Sean added support for keeping some metadata when the SNMP provisioning adapter runs
  • Jason Berry worked on a bunch of Horizon Stream CI/CD improvements
  • Morteza worked on security scanning our Docker images when we build them
  • DJ implemented a startup progress bar
  • Antonio worked on an improved bridge topology algorithm in Enlinkd
Web, REST, UI, and Helm
  • I cleaned up some branch merge and other CircleCI stuff in Helm
  • Chinh Le worked on the Horizon Stream events table
  • I worked on updating some dependencies in our JavaScript build
  • Anya worked on filtering in the ALEC UI, as well as some bug cleanup
  • Mike Rose fixed up some UI dynamic import code in Stream
  • Christian added CSRF tokens to a bunch of web forms
  • James added graphQL support for notification queries in Stream
  • Emily updated the requisition REST documentation
Contributors

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

  • Antonio Russo
  • DJ Gregor
  • Emily Marsh
  • Arthur Naseef
  • Benjamin Reed
  • Bonnie Robinson
  • Jason Berry
  • Morteza Ershad-Manesh
  • Yang Li
  • Łukasz Dywicki
  • Mark Frazier
  • Freddy Chu
  • Benjamin Janssens
  • Dmitri Herdt
  • James Hutchinson
  • Christian Pape
  • Chinh Le
  • Sean Torres
  • Dustin Frisch
  • Gerald Humphries
  • Chandra Gorantla
  • Scott Theleman
  • Anya Rybalova
  • Mark Mahacek
  • Mike Rose
  • Alexander Chadfield
  • Jeffrey-David Kapp
  • Thomas Bigger
  • Alex May
  • Rob Ellis
  • Patrick Schweizer

Coming Soon: JIRA Migration

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

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

Releases and Roadmap

Upcoming 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 October 12th, 2022.

We currently expect updates to Horizon 30.

Next Horizon: 31 (Q4 2022)

The next major Horizon release will be Horizon 31.

It will contain a number of improvements, including:

  • a refactoring of flow APIs including support for some flow hooks in the plugin API (plugin API 1.1.0+)
  • major improvements and refactoring in Enlinkd's bridge topology mapping and collection scheduling
  • a bunch of improved analytics in our datasources plugin
  • support for Hashicorp Vault in SCV
  • promoting a number of the "UI preview" enhancements to become part of the main UI
  • improvements to the requisitions REST API
  • a new Quick Start Guide in the documentation
Next Meridian: 2023 (Q1 2023)

Meridian 2023 is still reasonably 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.

Calendar of Events

All Things Open - Raleigh, NC - October 30th through November 2nd, 2022

All Things Open is local to our headquarters, and is a truly fantastic event.
We love it so much, we will be the exclusive live stream sponsor. 😉

We'll also have a booth in the exhibition hall.
A bunch of OpenNMS folks will be attending and/or helping out in the booth, so please be sure to say hi!

Open Source Monitoring Conference - Nuremberg, Germany - November 14th through 16th

The OpenNMS Group is a gold sponsor of OSMC this year, and will have a booth as well.
Stop by and say hello!

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-346: Docs for 8.0.1 did not publish
  • HS-249: Grafana support in the Operator
  • HS-252: Stabilize local-sample/ & Sync It with Skaffold Build
  • HS-318: GeoMap and Topology Contextual Actionable Intelligence LF Wireframes
  • HS-337: Stats: Create platform module for data choices
  • HS-338: Stats: Make REST call to post data choices to UsageStatsHandler
  • HS-362: FE - Add events and metric to device page
  • HS-363: FE - Use widget to display device event table
  • HS-364: Auto update config to subscribed modules
  • HS-366: Single Keycloak operator instance
  • HS-369: Once opennms/horizon-stream-notification repo has been added to Dockerhub, create a github actions pipeline to publish it
  • HS-379: Add Event Driven Discovery for Trapd
  • HS-394: Notifications: Add alarm to custom details
  • HS-396: Migrate and save JMX config in Json config store.
  • NMS-12629: Trapd is missing in the docs
  • NMS-14158: provide documentation for DCB feature
  • NMS-14220: Leaflet geo-map bug roundup
  • NMS-14221: H30 upgrades should not hurt
  • NMS-14222: Things that need updating to work well with Grafana 8.x
  • NMS-14223: Dependencies that need upgrading in H30
  • NMS-14241: Enable authorized web users to edit config files in OPENNMS_HOME/etc
  • NMS-14251: Make sure the DCB config files are in working order
  • NMS-14647: Cortex TSS release prep
  • NMS-14659: MOS CDR Processor: Tie to node
  • NMS-14670: DCB fails on newly provisioned nodes
  • NMS-14672: Velocloud API v1 / v2 support
  • NMS-14711: Release Work (September)
  • NMS-14718: Duplicate V3 trap security names causing spurious errors on non V3 traps
  • NMS-14752: On saving of the provisiond configuration must be ensured, that all requsition-def's have unique names
  • NMS-14756: Update QS based on ONMSU feedback
  • NMS-14762: Refactor Enlinkd Test NetworkBuilder Class
  • NMS-14764: Set Up Enlinkd schedule time interval based on protocols
  • NMS-14770: MOS CDR Processor: Send to multiple OpenNMS instances
  • NMS-14774: Add network/netmask tools to InetAddressUtils
  • NMS-14775: Ability to Assign Device Configuration Backup to Foreign Source

The post OpenNMS On the Horizon – September 26th, 2022 appeared first on The OpenNMS Group, Inc..

by RangerRick at September 26, 2022 10:18 PM

September 21, 2022

OpenNMS.js v2.5.1

2.5.1 is a small release with just dependency updates, most notably moment.js and moment-timezone, plus minor bumps to Grafana dependencies.

What's Changed

  • build(deps-dev): bump typescript from 4.8.2 to 4.8.3 by @dependabot in #402
  • build(deps-dev): bump eslint from 8.23.0 to 8.23.1 by @dependabot in #403
  • build(deps-dev): bump @babel/preset-env from 7.19.0 to 7.19.1 by @dependabot in #404
  • build(deps): bump core-js from 3.25.0 to 3.25.2 by @dependabot in #406
  • build(deps-dev): bump @babel/plugin-transform-runtime from 7.18.10 to 7.19.1 by @dependabot in #407
  • build(deps): bump @babel/runtime-corejs3 from 7.19.0 to 7.19.1 by @dependabot in #408
  • build(deps-dev): bump typedoc from 0.23.14 to 0.23.15 by @dependabot in #409
  • build(deps-dev): bump @babel/core from 7.19.0 to 7.19.1 by @dependabot in #410
  • build(deps-dev): bump @antora/cli from 3.1.0 to 3.1.1 by @dependabot in #411
  • build(deps-dev): bump @antora/site-generator-default from 3.1.0 to 3.1.1 by @dependabot in #412

Full Changelog: v2.5.0...v2.5.1

by RangerRick at September 21, 2022 02:51 PM

September 19, 2022

OpenNMS On the Horizon – September 19th, 2022

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

Last week was DevJam, so keep that in mind when you get excited about some of the projects you see. ;)
Plenty of these are proof-of-concept work that may or may not make it into a release.

Anayway, since last time, we worked on Horizon Stream (Minion RPC and gateway, operator improvements, hashicorp vault support, device UI and events), documentation (quick start guide, grafana, flows), OpenTelemetry, VNC integration, Sonar (CI workflow, bug fixes), Enlinkd scheduling and OSPF area support, and hashicorp vault SCV integration (including REST).

Github Project Updates

Internals, APIs, and Documentation
  • DJ continued his work on moving from OpenTracing to OpenTelemetry
  • Łukasz did more work on Minion RPC in Horizon Stream
  • Arthur, Łukasz, and Mark continued the work on the Minion gateway in Stream
  • Thomas worked on a proof-of-concept VNC integration
  • Dmitri started to add support to OPA for adding poller config
  • Dustin did more work on twin API filter improvements
  • I worked on cleaning up our Sonar CI workflows(s)
  • Maxim, Benjamin Janssens, Ivan, Kim, and I worked on fixing issues detected by Sonar
  • Antonio continued his work on improving Enlinkd collection scheduling
  • Dustin and Freddy worked on adding support for flow processing to the Minion
  • Gerald did more work on operator workflow with Skaffold/Tilt in Stream
  • Jerry switched a bunch of Stream's configs to use hashicorp vault storage
  • Chandra worked on hashicorp vault support in SCV
  • I fixed a bug in our CircleCI integration test "changed project" detection that could cause it to build more than it needed to
  • Bonnie continued to work on improving the Quick Start Guide
  • Mark Mahacek worked on updated Grafana documentation
  • Alberto worked on adding OSPF area support to Enlinkd
  • Dino updated flow documentation
Web, REST, UI, and Helm
  • Chinh Le continued his work on the device UI and event display in Horizon Stream
  • Alex worked on a REST endpoint for SCV and vault config
Contributors

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

  • Dustin Frisch
  • Antonio Russo
  • Łukasz Dywicki
  • Mark Frazier
  • Benjamin Reed
  • Chinh Le
  • Freddy Chu
  • Chandra Gorantla
  • Arthur Naseef
  • Alberto Ramos
  • Maxim Brener
  • DJ Gregor
  • Christian Pape
  • Benjamin Janssens
  • Alex May
  • Dmitri Herdt
  • Ivan Trechekas
  • Thomas Bigger
  • Jerry Beuree
  • Dino Yancey
  • Mark Mahacek
  • Bonnie Robinson
  • Gerald Humphries
  • Emily Marsh

Coming Soon: JIRA Migration

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

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

Releases and Roadmap

September 2022 Releases - Horizon 30.0.3, Meridians 2022.1.7, 2021.1.19, 2020.1.27, 2019.1.38

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

Meridian Stable Updates

Meridians 2019.1.38, 2020.1.27 , 2021.1.19 , and 2022.1.7 contains a couple of bug fixes.

For a list of changes, see the release notes:

Horizon 30.0.3

Release 30.0.3 contains quite a few bug fixes as well as number of small features and security fixes.

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

For a complete list of changes, see the changelog.

The codename for Horizon 30.0.3 is Chipmunk.

OpenNMS Helm 8.0.1

Helm 8.0.1 is primarily a bugfix release.

It contains a number of small fixes and enhancements to improve querying of nodes and interfaces.

It also contains a large number of node dependency updates.

Please note that Helm is still targeted to Grafana 8.
Work is underway to update to support Grafana 9.

Upcoming 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 October 12th, 2022.

We currently expect updates to Horizon 30.

Next Horizon: 31 (Q4 2022)

The next major Horizon release will be Horizon 31.

It will contain a number of improvements, including:

  • a refactoring of flow APIs including support for some flow hooks in the plugin API (plugin API 1.1.0+)
  • major improvements and refactoring in Enlinkd's bridge topology mapping and collection scheduling
  • more stuff, which I haven't had a chance to go back and enumerate yet, watch this space :D
Next Meridian: 2023 (Q1 2023)

Meridian 2023 is still reasonably 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.

Calendar of Events

Grace Hopper Celebration - Orlando, FL - September 20th through 23rd

In addition to our involvement in Open Source Day, Veena Kannan will be presenting a virtual lightning talk at the Grace Hopper Conference titled "Open Source 101 – Myth Buster Edition" at the Grace Hopper Celebration.

Her talk will be Thursday the 22nd, at 11:00am.

All Things Open - Raleigh, NC - October 30th through November 2nd, 2022

All Things Open is local to our headquarters, and is a truly fantastic event.
We love it so much, we will be the exclusive live stream sponsor. 😉

We'll also have a booth in the exhibition hall.
A bunch of OpenNMS folks will be attending and/or helping out in the booth, so please be sure to say hi!

Open Source Monitoring Conference - Nuremberg, Germany - November 14th through 16th

The OpenNMS Group is a gold sponsor of OSMC this year, and will have a booth as well.
Stop by and say hello!

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-12449: Remote Poller with Minion
  • NMS-13880: Deprecate Blackberry templates
  • NMS-14747: Error using javax.mail.* packages in plugins

The post OpenNMS On the Horizon – September 19th, 2022 appeared first on The OpenNMS Group, Inc..

by RangerRick at September 19, 2022 03:58 PM

September 14, 2022

September 2022 Releases – Horizon 30.0.3, Meridians 2022.1.7, 2021.1.19, 2020.1.27, 2019.1.38

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

Meridian Stable Updates

Meridians 2019.1.38, 2020.1.27 , 2021.1.19 , and 2022.1.7 contains a couple of bug fixes.

For a list of changes, see the release notes:

Horizon 30.0.3

Release 30.0.3 contains quite a few bug fixes as well as number of small features and security fixes.

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

For a complete list of changes, see the changelog.

The codename for Horizon 30.0.3 is Chipmunk.

The post September 2022 Releases – Horizon 30.0.3, Meridians 2022.1.7, 2021.1.19, 2020.1.27, 2019.1.38 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at September 14, 2022 02:58 PM

September 12, 2022

OpenNMS On the Horizon – September 12th, 2022

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

Since last time, we worked on documentation (quick start guide, ALEC, partial config updates, cortex time-series), Horizon Stream (notifications, unit/integration test, ignite detector client, operator, Minion gRPC, Grafana, Keycloak, map UI, widgets, trap processing), SNMP metadata provisioning, ALEC (release work and UI), dynamic CI config, datachoices (notifications and outages, poller fixes), Enlinkd collection scheduling, Docker, offheap storage, dependabot updates, filter rules, Sonar, OpenTelemetry, and Helm.

Github Project Updates

Internals, APIs, and Documentation
  • Sean updated the SNMP metadata provisioning adapter to support incremental changes in addition to replacing all metadata
  • Bonnie and Emily did more work on the quick start guide
  • Benjamin Janssens worked on prepping a new ALEC release, including doc build cleanups and fixing Sonar issues
  • Morteza made some tweaks to the circleci dynamic config
  • James continued his work on notifications support in Horizon Stream
  • I fixed some docker container images relating to ping capabilities
  • Pushkar worked on notifications and outages for datachoices telemetry
  • Mark worked on the ignite detector client in Stream
  • Antonio continued his work refactoring Enlinkd's collection scheduling
  • Gerald got the ignite detector integrated into Skaffold and worked on some other operator fixes in Stream
  • Łukasz refactored some service code for spring injection in Stream
  • Jeffrey-David Kapp did more work on operator startup config for Stream
  • I did some other tuning of docker images
  • Thomas added some asset fields to the database in Stream
  • Freddy did more work on offheap storage improvements
  • Dmitri worked on updating the documentation related to partial config updates
  • Bonnie wrapped up doc changes for the cortex time-series plugin
  • Mark Frazier worked on Minion gRPC routing in Stream
  • Dustin worked on support for generics in the twin API
  • Alexander worked on a fix for accessing the poller config in the device config service
  • Jason worked on enabling github action test runs in Stream
  • I cleaned up the default changes in a jsoup dependabot update
  • Jason tuned memory consumption in the default Stream setup to be less hungry
  • Jeffrey-David Kapp added Grafana and Keycloak to the Kubernetes CRD in Stream
  • I did more work on backporting circle and docker changes to H30 and Meridian 2022
  • Dustin refactored some of the code for how filter rules are tracked
  • I fixed some issues triggered by Sonar as I prepped to make sure sonar submissions are working properly
  • DJ continued his work on OpenTelemetry integration
Web, REST, UI, and Helm
  • Chinh Le continued his work on the map in Horizon Stream
  • Chinh Le started on a device status UI for Stream
  • Mike Rose did more work on improving widgets in the Stream UI
  • Alberto wrapped up a bunch of Helm improvements
  • Chandra worked on REST APIs for event-driven discovery from traps in Stream
  • Anya worked on tests and coverage in the ALEC UI
Contributors

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

  • DJ Gregor
  • Jason Berry
  • Mark Frazier
  • Chinh Le
  • Dustin Frisch
  • Łukasz Dywicki
  • Alexander Chadfield
  • Benjamin Reed
  • Bonnie Robinson
  • Morteza Ershad-Manesh
  • Chandra Gorantla
  • Antonio Russo
  • Jesse White
  • Thomas Bigger
  • Jeffrey-David Kapp
  • Benjamin Janssens
  • Emily Marsh
  • James Hutchinson
  • Dmitri Herdt
  • Gerald Humphries
  • Anya Rybalova
  • Pushkar Suthar
  • Freddy Chu
  • Sean Torres
  • Yang Li
  • Alberto Ramos
  • Rob Ellis
  • Mike Rose

Coming Soon: JIRA Migration

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

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

Releases and Roadmap

OpenNMS.js 2.5.0 Released

OpenNMS.js 2.5.0 contains a bunch of dependency updates including a move to core-js v3 for compatibility, as well as a few build system cleanups, fixes for querying SNMP interfaces by node ID and a query fix for 0-indexed enums.

Upcoming 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 14th, 2022.

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

Next Horizon: 31 (Q4 2022)

The next major Horizon release will be Horizon 31.

It will contain a number of improvements, including:

  • a refactoring of flow APIs including support for some flow hooks in the plugin API (plugin API 1.1.0+)
  • major improvements and refactoring in Enlinkd's bridge topology mapping and collection scheduling
  • more stuff, which I haven't had a chance to go back and enumerate yet, watch this space :D
Next Meridian: 2023 (Q1 2023)

Meridian 2023 is still reasonably 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.

Calendar of Events

Open Source Summit Europe - Dublin, Ireland - September 13th through 16th

We are a silver sponsor this year for Open Source Summit, and will be hosting a booth in the exhibition area.

Craig Gallen and some of the crew from Belfast will be there, so pop on by and say hello.

Open Source Day 2022 - September 16th

The OpenNMS Group is proud to support Grace Hopper Conference's Open Source Day (OSD) 2022, and our very own Sandy Skipper is serving on the OSD Steering Committee.

OSD is an all-day hackathon in which participants of all skill levels learn about open source while contributing to projects designed to solve real world problems.
The goal is to celebrate and encourage women in open source.

OSD will take place as a pre-event on Friday, September 16 from 8am - 3pm PDT. Participation is open to anyone who has a GHC registration ticket (in-person or virtual).

For more information, contact Sandy Skipper or see the OSD site.

Grace Hopper Celebration - Orlando, FL - September 20th through 23rd

In addition to our involvement in Open Source Day, Veena Kannan will be presenting a virtual lightning talk at the Grace Hopper Conference titled "Open Source 101 – Myth Buster Edition" at the Grace Hopper Celebration.

Her talk will be Thursday the 22nd, at 11:00am.

All Things Open - Raleigh, NC - October 30th through November 2nd, 2022

All Things Open is local to our headquarters, and is a truly fantastic event.
We love it so much, we will be the exclusive live stream sponsor. 😉

We'll also have a booth in the exhibition hall.
A bunch of OpenNMS folks will be attending and/or helping out in the booth, so please be sure to say hi!

Open Source Monitoring Conference - Nuremberg, Germany - November 14th through 16th

The OpenNMS Group is a gold sponsor of OSMC this year, and will have a booth as well.
Stop by and say hello!

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-179: Tests on Situation Detail and situation metrics
  • HELM-334: Entity Datasource does not provide node information
  • HELM-345: Alarm Details missing TroubleTicketState if state is 0
  • HS-201: Backend: New Notification Service
  • HS-203: DevOps: New Notification service
  • HS-241: Add Cucumber IT for validating minion end point
  • HS-286: Add Trapd support in Stream
  • HS-295: Integrate KeyValueStore ( PostgresJsonStore) into Horizon Stream
  • HS-296: Add Config Service
  • HS-299: Setup instructions for local-sample dir
  • HS-304: FE - Display list of devices in the geomap table
  • HS-329: Tag / Surveillance Category Membership View / Edit Panel and Add to Placeholder Device Status Page
  • HS-334: Add Grafana DB config to Devops and test default dashboard.
  • HS-335: FE - Widget component & grid layout
  • HS-336: Stats: Local Environment setup in Docker for HS Stats testing
  • HS-345: BFF: Impove the BFF performace
  • HS-346: FE - Add new device status route / container component
  • HS-347: Configure in memeory cache in BFF for backend request.
  • HS-352: Nonblock requst from BFF to platform core
  • HS-356: Propagate Skaffold --skip-tests flag into custom maven builds
  • HS-358: Use Liquibase for notification database
  • HS-360: UX competitive analysis board in Figjam on Kentik
  • HS-378: BFF migration to Webflux broke context path config
  • HS-383: Add all images we build to HS CRD
  • NMS-13864: Package description for Minion and Sentinel reference Wiki
  • NMS-14360: BmpIT flapping
  • NMS-14522: Add CAP_NET_BIND_SERVICE capability to the java binary to bind privileged ports
  • NMS-14582: Add KPI for DCB cumulative web UI entries
  • NMS-14615: Quick Start: Import inventory
  • NMS-14623: Add KPIs for open notifications and outages to datachoices telemetry
  • NMS-14624: Add KPI for application count to datachoices telemetry
  • NMS-14648: Rename OIA to OPA in git repo
  • NMS-14667: Official docs readiness for Cortex TSS plugin release
  • NMS-14728: Add Elasticsearch 7.17.6 to Drift plugin versions

The post OpenNMS On the Horizon – September 12th, 2022 appeared first on The OpenNMS Group, Inc..

by RangerRick at September 12, 2022 04:58 PM

OpenNMS.js v2.5.0

This release contains a bunch of dependency updates including a move to core-js v3 for compatibility, as well as a few build system cleanups, fixes for querying SNMP interfaces by node ID and a query fix for 0-indexed enums.

by RangerRick at September 12, 2022 02:20 PM

September 06, 2022

OpenNMS.js v2.5.0

OpenNMS.js 2.5.0 contains a bunch of dependency updates including a move
to core-js v3 for compatibility, as well as a few build system cleanups,
fixes for querying SNMP interfaces by node ID and a query fix for
0-indexed enums.

by RangerRick at September 06, 2022 08:40 PM