OpenNMS Meridian Foundation 2020.1.35
OpenNMS Meridian Foundation 2020.1.35
OpenNMS Meridian Foundation 2021.1.27
OpenNMS Meridian Foundation 2022.1.16
OpenNMS Meridian Foundation 2023.1.3
In May, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 31.0.8.
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:
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..
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.
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.
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.
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.
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..
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..
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.
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.
Network segmentation is a critical piece of an overall cybersecurity / network security model. It's used to help you:
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.
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.
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.
The Gartner® report, "The 6 Principles of Successful Network Segmentation Strategies" covers common strategy pitfalls—and how to avoid them.
From the report:
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.
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.
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.
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:
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.
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.
OpenNMS offers several tools and features designed to improve network segment visibility, including:
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..
In April, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 31.0.6.
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:
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..
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.
OpenNMS Meridian Foundation 2023.1.2
OpenNMS Meridian Foundation 2022.1.15
OpenNMS Meridian Foundation 2021.1.26
OpenNMS Meridian Foundation 2020.1.34
This release fixes Antora documentation versioning, and includes some minor dependency updates plus a bump to use TypeScript 5.0.
This is a code-identical release to 2.5.3, with some build cleanups under the covers.
This release contains only dependency updates and a very minor compile fix to make TypeScript happy.
This release updates a number of dependencies, notably Axios, which required a few small changes to the AxiosHTTP
adapter.
In March, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 31.0.5.
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:
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..
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.
OpenNMS Meridian Foundation 2023.1.1
OpenNMS Meridian Foundation 2022.1.14
OpenNMS Meridian Foundation 2021.1.25
OpenNMS Meridian Foundation 2020.1.33
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."
"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/.
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/.
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.
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.
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..
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:
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
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.
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..
In February, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 31.0.4.
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:
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.
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..
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.
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.The following known issues impact Horizon 31.0.4; we expect all to be fixed in the next micro-version release:
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.The codename for Horizon 31.0.4 is Otap.
OpenNMS Meridian Foundation 2023.1.0
OpenNMS Meridian Foundation 2022.1.13
OpenNMS Meridian Foundation 2021.1.24
OpenNMS Meridian Foundation 2020.1.32
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:
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.
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:
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."
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:
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"
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
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 = ""
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..
In January, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 31.0.3.
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:
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..
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.
OpenNMS Meridian Foundation 2022.1.12
OpenNMS Meridian Foundation 2021.1.23
OpenNMS Meridian Foundation 2020.1.31
OpenNMS Meridian Foundation 2022.1.11
In December, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 31.0.2.
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:
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..
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.
OpenNMS Meridian Foundation 2022.1.10
OpenNMS Meridian Foundation 2021.1.22
OpenNMS Meridian Foundation 2020.1.30
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.
The post November 2022 Releases – Horizon 31.0.1 appeared first on The OpenNMS Group, Inc..
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.
In November, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 31.0.0.
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:
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..
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:
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..
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.
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..
In October, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 30.0.4.
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:
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..
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.
core/daemon
foundation-2022
foundation-2022
including supporting code coverage from smoke testsAbstractMockDao
logging to trace-level, it's way too chatty when running testsThanks to the following contributors for committing changes since last OOH:
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.
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!
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.
The next major Horizon release will be Horizon 31.
It will contain a number of improvements, including:
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 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.
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.
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!
The OpenNMS Group is a gold sponsor of OSMC this year, and will have a booth as well.
Stop by and say hello!
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
The post OpenNMS On the Horizon – October 3rd, 2022 appeared first on The OpenNMS Group, Inc..
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.
Thanks to the following contributors for committing changes since last OOH:
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.
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.
The next major Horizon release will be Horizon 31.
It will contain a number of improvements, including:
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.
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.
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!
The OpenNMS Group is a gold sponsor of OSMC this year, and will have a booth as well.
Stop by and say hello!
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
The post OpenNMS On the Horizon – September 26th, 2022 appeared first on The OpenNMS Group, Inc..
2.5.1 is a small release with just dependency updates, most notably moment.js and moment-timezone, plus minor bumps to Grafana dependencies.
Full Changelog: v2.5.0...v2.5.1
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).
Thanks to the following contributors for committing changes since last OOH:
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.
In September, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 30.0.3.
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:
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.
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.
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.
The next major Horizon release will be Horizon 31.
It will contain a number of improvements, including:
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.
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.
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 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!
The OpenNMS Group is a gold sponsor of OSMC this year, and will have a booth as well.
Stop by and say hello!
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
The post OpenNMS On the Horizon – September 19th, 2022 appeared first on The OpenNMS Group, Inc..
In September, we released updates to all OpenNMS Meridian versions under active support, as well as Horizon 30.0.3.
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:
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..
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.
jsoup
dependabot updateThanks to the following contributors for committing changes since last OOH:
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.
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.
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.
The next major Horizon release will be Horizon 31.
It will contain a number of improvements, including:
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.
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.
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.
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.
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 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!
The OpenNMS Group is a gold sponsor of OSMC this year, and will have a booth as well.
Stop by and say hello!
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
The post OpenNMS On the Horizon – September 12th, 2022 appeared first on The OpenNMS Group, Inc..
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.
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.