Planet OpenNMS

December 05, 2023

Splunk Acquisition Brings Cloud Software Costs into Focus

Rather than pay the Splunk bill, Cisco just bought the company."

Cisco’s planned acquisition of Splunk has caused ripples across the network and security ecosystem since it was announced in September 2023. It may be a win for both by bringing together Splunk’s cybersecurity with Cisco’s network data, but as with any merger, there are some questions.

In this case, I’ve seen concerns around the potential culture clash, the pace of innovation, and especially how this could affect costs for Splunk users.

Observability costs can already spiral, surprisingly, out of control as demonstrated by Datadog’s shocking $65M/year customer bill (hint: it was Coinbase). Unfortunately, when budgets are tight and customer-facing services are sacrosanct, observability might be first on the chopping block when companies are looking to shave 10% off quarterly expenses.

Some vendors have reacted to the issue of steeply rising spending on observability metrics by introducing a way to pull together unused and partly used metrics into lower cardinality versions to reduce costs.

In this blog, I’m going to take a look at what’s driving these growing cloud software costs and how they can be curbed so monitoring doesn’t have to be sacrificed.

The Hazy Costs of Cloud Software

When services like Splunk and Datadog and others first launched, one of the key promises of the cloud-delivery model was scalability – companies could use as little or as much of the service as they needed. But as the model has expanded over time, we’re starting to see some cracks along with the benefits:

alt

Complex Contracts
You may run into a menu that offers hundreds of ways the services can be priced and combined – by user, feature, device, or more – and end up paying more for the “flexibility” of buying a la carte. It's like a new car purchase where you choose the model, the trim, the colors, and the add-on features as packages or priced separately. It’s not always easy to compare the options: you might find that the price is different for each feature depending on which base model you select, or you even forget to include cruise control!

alt

Per Metric Pricing
Cruise control is a no-brainer, but how can you be sure which optional metrics you should include to track with your monitoring service? How can you know where the problem will crop up? How can you know what data you need to collect before you collect and review the data? Without the ability to see the whole picture, you can end up with blind spots that just happen to be the source of a network-crashing crisis. You could choose to monitor everything, but with a la carte pricing, can you afford it? Or maybe you realize after you’ve signed the contract that you missed critical metrics and adding them requires going back for more budget each time. How flexible is that?

alt

Unpredictable consumption costs
Once you choose your options, the price can still vary. Again, this can be one of the advantages of a cloud-based service, but as we’ve seen in the last few years, this can become a drawback instead. Imagine the same car, but your monthly payment changes based on how much you drive. Cost conscience organizations want to keep spend under control and predictable. As we reach year-end, this is especially important for companies trying to lock in budgets for next year. A cloud-based service loses its scalability advantage if the only way to make the cost predictable is to lock in the usage and not scale to the usage you actually need.

The Predictability of OpenNMS

Before joining OpenNMS, I was in the position to make the decision on which network monitoring solution to utilize. The non-profit I worked for was very budget-conscious, so having a predictable cost for network monitoring was critical but so was the scope of coverage. To avoid the blind spots and surprises listed above, we chose the on-premises implementation of OpenNMS Meridian.

With OpenNMS, everything is included, and the pricing is straightforward – there’s no piecemeal solution, no picking and choosing between metrics, no consumption-based costs. I never had to justify what I was measuring, why, or how much. We could plan and predict the cost and coverage.

When something happened, this let me turn the conversation from “The network is broken” to “The network isn’t broken, and I have the data to prove it. Do you?”

Conclusion

As cloud software usage has grown, most companies have run into the nasty shock of a surprisingly large bill at the end of the month. Elasticity is, in effect, gone when you have to justify additional budget to expand the solution, or you simply can't because the planned budget doesn't allow it. This is scale in name only.

The first line of this blog is a joke but with a painful, realistic point: even the best-funded companies can feel the burn of scaling cloud software costs.

For organizations requiring more predictability without sacrificing visibility (and can't afford to just buy the company!), it's worth exploring other options.

The post Splunk Acquisition Brings Cloud Software Costs into Focus appeared first on The OpenNMS Group, Inc..

by Mike Huot at December 05, 2023 03:34 PM

November 30, 2023

Ask a Network Monitoring Expert

Find yourself stuck in the maze of network issues? Frustrated by monitoring problems you just can't seem to untangle? Not sure how to take your network monitoring to the next level? We get it!

While ChatGPT can give you the answers to some of life’s big questions, there are still key insights you can only get from real people – like our OpenNMS experts.

With our “Ask an Expert” sessions, you can schedule time with real OpenNMS gurus to have a real conversation with an experienced network monitoring professional. No jargon, no tech-heavy mumbo-jumbo—just friendly advice, suggestions, and solutions to your network monitoring dilemmas.

Solve Complex Network Monitoring Challenges

Just fill out the contact form. Choose a date and time that works for you (we'll provide calendar links and an email for your convenience). Come to the session prepared with your questions, issues, and concerns.

Final step: have a fun, engaging, enlightening chat with people who have deep domain expertise.

Our Experts

alt

Dr. Craig Gallen
Business Development Manager, OpenNMS

Dr Craig Gallen has been a committer to OpenNMS for over 10 years. He has worked as an engineer in broadcasting, telecommunications, and academia where his doctoral research explored the role of Open Source in the Telecommunications industry. Presently Craig splits his time between teaching at Solent University Southampton and influencing the strategic direction of OpenNMS.

alt

Mike Huot
Principal Product Strategist, OpenNMS

Mike offers a blend of strategic leadership and technical expertise, with a focus on monitoring and infrastructure management. As Principal Product Strategist and Infrastructure Architect, he’s led diverse initiatives, overseeing deployment and automation across networking, computing, virtualization, storage, and cloud, emphasizing monitoring and observability. At OpenNMS, he shares expertise, advocates for open-source solutions, and engages in community collaboration. He balances hands-on technical work with strategic input, driving product direction and enhancing network performance management, while contributing to the OpenNMS community.

What to Expect

alt

Friendly chats: Nothing formal here, just relevant information and inspiring conversation with some knowledgeable people from OpenNMS.

alt

Live demos: See how OpenNMS Meridian works and how you can use it to address your most challenging network needs.

alt

Sneak peeks: Be the first to glimpse behind the curtains. We might just share some upcoming features and projects we're excited about.

Want to learn on your own? That works too!

If your schedule doesn’t allow you to carve a specific time out of your day for a conversation, no problem. As an open-source solution, OpenNMS has a community of users ready and willing to lend a helping hand. You can dig through the available resources on your own or join our community to connect with other users facing the same issues.

Explore our resources

Visit our website to access a wealth of informative content, including product documentation, resources, and customer testimonials.

Join the community

Connect with like-minded professionals and OpenNMS users on our community forums or chat to share insights and experiences.

The post Ask a Network Monitoring Expert appeared first on The OpenNMS Group, Inc..

by Jen Fekin at November 30, 2023 04:16 PM

November 08, 2023

OpenNMS Horizon 32.0.5 (Deep Swedish Rock)

Release 32.0.5

Release 32.0.5 contains a bunch of security updates to Drools, Hibernate, Jetty, and more, plus a number of other bug fixes and a slew of documentation updates.

The codename for Horizon 32.0.5 is Deep Swedish Rock.

Enhancement
  • BMP docs could use some TLC (Issue NMS-13891)
  • Provisiond threads description discrepancies (Issue NMS-14766)
  • OpenShift: Documentation (Issue NMS-16108)
  • Backport Drools 8.x to foundation 2023 to address a couple of CVEs (Issue NMS-16179)
  • Integrate hibernate-core related patch from Debian (Issue NMS-16181)
  • Version bump of json for CVE-2023-5072 (Issue NMS-16191)
  • Version bump of jetty to 9.4.53 version (Issue NMS-16192)
  • Bump to the latest netty 4 version (Issue NMS-16193)
  • Version bump of snappy java (Issue NMS-16194)
  • Docs: Remove deprecated resourcecli section (Issue NMS-16216)
  • Post install/upgrade instructions on how to join OpenNMS Community (Issue NMS-16213)
Bug
  • Local Geo Map (using gwt.openlayers.url) working in version 29.0.1 is not anymore in 31.0.3-1 (Issue NMS-15400)
  • Access Denied when deleting a node with admin user (Issue NMS-15746)
  • Map dashlet for Ops Boards references old map systems (Issue NMS-16044)
  • Reports → Chart page does not load graphs (Issue NMS-16085)
  • Event parameters with <> not rendering in event/alarm views (Issue NMS-16157)
  • Add Basic Auth to OpenConfig gNMI for Call Credentials (Issue NMS-16158)

by mershad-manesh at November 08, 2023 04:14 PM

November 2023 Releases – Horizon 32.0.5, 2023.1.9, 2022.1.22, 2021.1.33

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

Meridian Stable Updates

Meridians 2023.1.9, 2022.1.22, 2021.1.33 contains a bunch of security updates to Drools, Hibernate, Jetty, and more, plus a number of other bug fixes and a slew of documentation updates.

For a list of changes, see the release notes:

Horizon 32.0.5

Release 32.0.5 contains a bunch of security updates to Drools, Hibernate, Jetty, and more, plus a number of other bug fixes and a slew of documentation updates.

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

For a complete list of changes, see the changelog.

The codename for Horizon 32.0.5 is Deep Swedish Rock.

The post November 2023 Releases – Horizon 32.0.5, 2023.1.9, 2022.1.22, 2021.1.33 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at November 08, 2023 04:10 PM

October 24, 2023

An Interview with Horizon User, Jesus Palacio: Part 2

We're highlighting Jesus Palacio, CTO of Urbalink Networks, and an OpenNMS Horizon user for more than 20 years.

In the first part of our interview, we got to know Jesus and how he got started using OpenNMS.

In the second, and final, part of our interview, we'll learn how he chose OpenNMS and the benefits he's seen from using Horizon as his preferred network monitoring platform.

What were the criteria you used to choose OpenNMS?

"When I decided to choose OpenNMS, I used the following criteria:

  • Open source: This is important to me because I wanted to be able to customize OpenNMS to meet the specific needs of my organization.
  • Scalability: I wanted to be able to use OpenNMS to monitor my network as it grows in the future.
  • Features: I wanted a software that could monitor all aspects of my network.
  • Community: OpenNMS has a large and active community of users and developers you can interact with in forums and mailing lists to get help.
  • Cost: Last, but not least, saving costs."
Jesus Palacio of Urbalink Networks standing

Why do you continue to you choose OpenNMS?

"For me, the most important aspect of OpenNMS is its customizability. It is an enterprise-grade solution, but it still allows you to define exactly what and how to monitor, and to establish under which conditions you will receive an alert when something happens in your network. It has a wide range of features that makes it suitable for almost every need and situation.

This is why I describe it as the "Swiss Army Knife" of network monitoring. Other important aspects I took into account when choosing OpenNMS over other solutions include:

  • It has a large and helpful community
  • It can monitor large networks, it can grow with your company
  • No hidden costs or fees to enable features ,you can maintain it completely on your own.
  • The solution has been evolving constantly and adding very helpful features."
alt

Urbalink Network's OpenNMS Horizon dashboard

How does OpenNMS help you achieve your objectives?

"Network monitoring software should be flexible enough to provide an at-a-glance overview of the current status of your network, with critical metrics from routers, switches, firewalls, servers, services, application, URLs, printers, UPS, and other infrastructure devices. We’ve provided solutions using OpenNMS and helped them adjust the platform to monitor the required specifics that can help administrators quickly troubleshoot problems and overview metrics metrics to make decisions proactively in order to avoid unnecessary downtime in their services.

Some of the most common metrics we used to track are:

  • Device uptime: The most straightforward, high-level KPI is uptime, which measures the fundamental goal: how often the service is available.
  • Network traffic: In our actual use case this metric tracks the amount of network traffic that is flowing through a device or a network. This help us to identify devices that are experiencing congestion and make adjustments on the fly.
  • Packet loss and re-transmissions: Packet loss often signals interference or congestion on the network. A common symptom of this issue is data transferring from one device to another but not entirely reaching its destination. Monitoring packet loss is vital because it's a surrogate for the wireless network's overall health.

By tracking these metrics, we gain valuable insights into the performance of our network and business."

alt

OpenNMS Horizon maps Urbalink Network's network

Can you measure any reduced costs, thanks to OpenNMS?

"Since the average cost of a license for a network monitoring solution goes from more than $2,000 for the first year of use up to $30,000 or $50,000, there is a clear reduction in costs when you use OpenNMS Horizon. Of course, you have to keep in mind that you need to have the skills to maintain the solution adapted to your needs. Even when there’s an active and supportive community, skills are required.

In some cases you need to weigh the possibility of acquiring an OpenNMS Meridian subscription, which is the best cost-effective solution for an enterprise-grade monitoring system—and you'll still be able to reduce costs, directly or indirectly."

Can you measure any improvements in productivity or time savings?

"Using OpenNMS has made our business more efficient by helping us track network performance quickly and accurately. OpenNMS can instantly gather information from every part of a network, ensuring that each part is performing its function. This helps us to identify and resolve issues before they cause downtime, which in turn increases productivity and less support tickets to solve ;-) …

One of the major advantages of using OpenNMS is that it gives us the ability to identify issues before our customers do. This allows us to take proactive measures to resolve the issues, which helps to improve customer satisfaction.

As a result of using OpenNMS, Urbalink Networks has built a very stable customer base without the need of aggressive marketing. We have a reputation for excellent customer service and reliability, which has helped us to increase our customer satisfaction, reduce our costs, and improve our profitability."

alt

Monitoring the regional status of Urbalink Network's network

What are you looking forward to for the future of OpenNMS?

"One of the things I look forward to is the continued growth of the OpenNMS community. I am excited to see the community continue to grow and to see what new and innovative things they come up with.

I am also excited to see how OpenNMS Horizon evolves and how it becomes more accessible to a wider range of users. In this regard, I think that the learning curve could be improved by making the interface more intuitive and by providing more wizards and other tools to help new users get started."

alt

What is your advice to others who might be considering OpenNMS?

"My humble advice to anyone considering using OpenNMS would be:

  • Get involved in the community: Getting involved in the community is a great way to learn more about OpenNMS and to get help from other users.
  • Start small: OpenNMS can be a complex platform. It is a good idea to start small and to gradually enable features and functionalities as you need them.
  • Be patient: Learning OpenNMS takes time. Be stubborn, don't give up, and don't be discouraged if you don't understand everything right away. Just keep learning and experimenting, and you will eventually get the hang of it."

Learn more

Special thanks to Jesus Palacio for his time and insight—as well as his support for OpenNMS over the past two decades.

Learn more about OpenNMS Horizon and OpenNMS Meridian, our supported enterprise network monitoring platform.

The post An Interview with Horizon User, Jesus Palacio: Part 2 appeared first on The OpenNMS Group, Inc..

by Colby Hoke at October 24, 2023 01:00 PM

October 17, 2023

An Interview with OpenNMS Horizon User, Jesus Palacio: Part 1

We're highlighting Jesus Palacio, CTO of Urbalink Networks, and an OpenNMS Horizon user for more than 20 years.

In the first part of our interview, we'll get to know Jesus, how he got started with OpenNMS, and why he's stayed with the network monitoring platform after all these years.

How did you first get started with OpenNMS?

"I first interacted with OpenNMS in 2003, when I was a network analyst at my first job after college. My boss, who was very involved in open-source initiatives, introduced me to the project. He had implemented OpenNMS as an alternative to HP OpenView. The company we worked for at the time was a value-added provider to cellular carriers, both domestic and international. We had very strict SLAs with our customers, so one of our main tasks was to ensure compliance with those SLAs. OpenNMS was a perfect fit for our needs because it enabled us to do early warning and comprehensive monitoring, which were key aspects of our roles.

Later on, my then-boss and I became business partners. We offered a wide range of technology solutions together and founded a company called Codexware (2007-2010). Unfortunately, the company is no longer in business as we moved on to different projects."

Jesus Palacio of Urbalink Networks standing

Jesus Palacio of Urbalink Networks

Can you give us a few examples of the type of companies you've collaborated with and instances where you assisted in deploying Horizon?

"I proudly remember two deployments of OpenNMS during my time as an open source solutions provider for Codexware from 2007 to 2010:

  • Eleval: In this project OpenNMS was used to monitor the performance and early warning of a wireless microwave network that was used to monitor a complex electrical power grid serving Valencia city in Carabobo state, Venezuela.
  • Genesis Telecom: This was one of the first Internet service providers (ISPs) oriented to business clients in Venezuela. At the time, their network was completely wireless and composed of a diverse range of technologies, each with its own monitoring solution. This made it difficult for their NOC (network operations center) personnel to troubleshoot and resolve problems.

We offered them OpenNMS because its agentless monitoring concept was a perfect fit for their needs. OpenNMS was able to unify the monitoring process into a single, comprehensive solution, which made it much easier for the NOC personnel to track and manage their network."

You mentioned that Codexware is no longer in business. What are you doing now?

"I’m the Chief Technology Officer of Urbalink Networks, but—beyond the title of the position—I am responsible of the technology strategy and execution of the organization.

As part of my job, I also:

  • Oversee the development and implementation of new technologies, as well as the maintenance and security of existing network infrastructure.
  • Ensure network performance and availability as our goal is to deliver reliable and high-quality services to our customers.
  • Manage the IT & Customer Support Team who are stationed in the network operations center (NOC), with the help of team leaders. This includes hiring and training new staff, as well as setting performance goals and managing the team's budget.
  • Oversee compliance with legal regulations and working with the marketing team to develop new products and services is a integral part of my position."
alt

Jesus Palacio at his desk with OpenNMS Horizon

Can you tell us more about Urbalink Networks?

"Urbalink Networks is a Venezuelan company that provides internet access, network solutions, specialized on the business segment. Through the years we have built a strong track record of providing reliable and secure services to our customers. We have a team of experienced professionals who are dedicated to providing solutions that meet the specific needs of our clients. Urbalink Networks now operates a hybrid network of fiber optic and high capacity wireless links servicing over 400 locations.

In addition, we offer the following services to our clients:

  • Network solutions: We specialize in designing, deploying, and managing networks and Wi-Fi managed access.
  • Consultancy: We offer help designing and implementing telecommunications solutions. This is a great option for businesses that are not sure where to start.

Most of the companies we help are looking for ways to reduce the cost of their monitoring solution without having to give up the possibility of customizing according to their needs. In general, we are able to work anywhere in which solutions that are tailored to fit any customer’s unique requirements are needed."

alt

What do you love about your job?

"One of the things I love about my position as CTO of Urbalink Networks is the bird's-eye view of the entire organization and the ability to help shape its future. I get to make decisions that will impact the company's success, I get to see the fruits of my labor as the company grows and evolves.

The technology industry is constantly changing, so I need to be a lifelong learner. I try my best to stay up-to-date on the latest trends and technologies, and I like to apply my knowledge to solve real-world problems. Urbalink Networks is the perfect place for this because I have the opportunity to make a real difference in the world. Our products and services are used by people every day, and we help businesses succeed.

Of course, there are also challenges. Some days can be demanding and stressful, and you need to be able to handle a lot of responsibility. However, I believe that the rewards of this role far outweigh the challenges."

What's kept you engaged with OpenNMS after all these years?

"First, I am a strong believer in the DIY (do it yourself) philosophy and open source software aligns well with that. Being able to modify and adapt a product to my needs, if I have the capacity to do so, is an amazing benefit. Additionally, OpenNMS has a large and active community of users and developers who are always willing to help, so I am never alone or helpless.

I have been able to implement and adapt OpenNMS to meet our own needs and those of our clients who've requested a network monitoring solution. No matter what type of network or devices need to be monitored, OpenNMS has always been a perfect fit. That's why I implemented OpenNMS for Urbalink when I got the position in 2009. To this day, OpenNMS is a foundational part of my daily work.

OpenNMS aligns with my values of open collaboration and sharing of knowledge. I believe that open source software will play an important role is the future of software development, and I am excited to be a part of the OpenNMS community and of course to give back. OpenNMS also has a clear mission and vision to "be the leading open source network management platform in the world." This aligns with my own goals of using the best technology available and evolving with it. I believe that OpenNMS is well-positioned to achieve this goal, and I am excited to be a part of the journey."

Part 2, coming October 24

In the next part of our interview, we'll learn more about how Jesus chose OpenNMS and the benefits he's seen from implementing the network monitoring solution for clients—as well as Urbalink Networks.

In the meantime, you can learn more about OpenNMS Horizon and Meridian.

The post An Interview with OpenNMS Horizon User, Jesus Palacio: Part 1 appeared first on The OpenNMS Group, Inc..

by Colby Hoke at October 17, 2023 01:00 PM

October 11, 2023

October 2023 Releases – Horizon 32.0.4, 2023.1.8, 2022.1.21, 2021.1.32, 2020.1.40

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

Meridian Stable Updates

Meridians 2023.1.8, 2022.1.21, 2021.1.32, 2020.1.40 contains documentation updates as well as a number of bug fixes and enhancements including Sentinel fixes, improvements to running in containers, and some other small changes.

For a list of changes, see the release notes:

Horizon 32.0.4

Release 32.0.4 contains documentation updates as well as a number of bug fixes and enhancements including Sentinel fixes, improvements to running in containers, metadata support improvements, and some other small changes.

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

For a complete list of changes, see the changelog.

The codename for Horizon 32.0.4 is Classic Eurovision.

The post October 2023 Releases – Horizon 32.0.4, 2023.1.8, 2022.1.21, 2021.1.32, 2020.1.40 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at October 11, 2023 05:26 PM

OpenNMS Horizon 32.0.4 (Classic Eurovision)

Release 32.0.4

Release 32.0.4 contains documentation updates as well as a number of bug fixes and enhancements including Sentinel fixes, improvements to running in containers, metadata support improvements, and some other small changes.

The codename for Horizon 32.0.4 is Classic Eurovision.

Bug
  • login.jsp page is still visible/accessible after being authenticated by pre-authentication (Issue NMS-14078)
  • Fix Event documentation formatting (Issue NMS-15603)
  • Sentinel depends on unpackaged /opt/sentinel/etc/datacollection-config.xml (Issue NMS-15695)
  • Container ignores environment variable OPENNMS_DATABASE_CONNECTION_MINPOOL or confd opennms/database/connection/minpool configuration (Issue NMS-16141)
  • Postgres error when creating a database from source database template1 (Issue NMS-16143)
  • Container’s java binary is missing cap_net_raw capability (Issue NMS-16145)
  • SENTINEL_HOME points to wrong location in fix-permissions (Issue NMS-16159)
  • Update Core confd database with new schema (Issue NMS-16163)
Enhancement
  • Basic BMP Setup (Issue NMS-13893)
  • BMP set up with Minion (Issue NMS-13894)
  • BMP Setup with Sentinel (Issue NMS-13895)
  • Quick install script for first time evaluator and training (Issue NMS-14811)
  • Expand flow thresholding documentation (Issue NMS-15276)
  • Add link to configure SNMP Community strings from node admin page (Issue NMS-15772)
  • Make pool size configurable per data source. (Issue NMS-16051)
  • Monitored Service Rest API Updates for OPG (Issue NMS-16160)
  • opennms-js updates for Monitored Services for OPG (Issue NMS-16161)
  • Metadata DSL: Add effective values of service parameters in Karaf poll command (Issue NMS-16119)
  • Add language to docs for how to find schema to Kafka Producer (Issue NMS-16133)
  • Remove availability monitor content from documentation (Issue NMS-16135)
  • Migrate Tl1 docs from wiki (Issue NMS-16150)

by mershad-manesh at October 11, 2023 04:45 PM

October 10, 2023

OpenNMS.js v2.5.8

Just a minor update with some dep updates and a few small enhancements.

  • many dependency updates
  • moved from tslint to eslint
  • added fields to the monitored service object:
    • ipInterfaceId
    • ipAddress
    • nodeId
    • nodeLabel

Full Changelog

  • build(deps-dev): bump @commitlint/config-conventional from 17.6.3 to 17.6.5 by @dependabot in #606
  • build(deps-dev): bump typedoc from 0.24.7 to 0.24.8 by @dependabot in #614
  • build(deps): bump core-js from 3.30.2 to 3.31.0 by @dependabot in #626
  • build(deps-dev): bump @babel/plugin-transform-runtime from 7.22.4 to 7.22.5 by @dependabot in #624
  • build(deps): bump @babel/runtime-corejs3 from 7.22.3 to 7.22.5 by @dependabot in #627
  • build(deps-dev): bump @babel/preset-env from 7.22.4 to 7.22.5 by @dependabot in #625
  • build(deps-dev): bump webpack from 5.86.0 to 5.87.0 by @dependabot in #628
  • build(deps): bump commander from 10.0.1 to 11.0.0 by @dependabot in #629
  • build(deps-dev): bump eslint from 8.42.0 to 8.43.0 by @dependabot in #630
  • build(deps-dev): bump webpack from 5.87.0 to 5.88.0 by @dependabot in #631
  • build(deps-dev): bump @commitlint/cli from 17.6.5 to 17.6.6 by @dependabot in #632
  • build(deps-dev): bump @commitlint/config-conventional from 17.6.5 to 17.6.6 by @dependabot in #633
  • build(deps-dev): bump typescript from 5.1.3 to 5.1.5 by @dependabot in #634
  • build(deps-dev): bump typescript from 5.1.5 to 5.1.6 by @dependabot in #635
  • build(deps-dev): bump webpack from 5.88.0 to 5.88.1 by @dependabot in #636
  • build(deps-dev): bump ts-jest from 29.1.0 to 29.1.1 by @dependabot in #637
  • build(deps-dev): bump eslint from 8.43.0 to 8.44.0 by @dependabot in #638
  • build(deps): bump @babel/runtime-corejs3 from 7.22.5 to 7.22.6 by @dependabot in #639
  • build(deps-dev): bump @babel/cli from 7.22.5 to 7.22.6 by @dependabot in #640
  • build(deps-dev): bump @babel/preset-env from 7.22.5 to 7.22.6 by @dependabot in #641
  • build(deps-dev): bump @babel/core from 7.22.5 to 7.22.6 by @dependabot in #642
  • build(deps-dev): bump @babel/plugin-transform-runtime from 7.22.5 to 7.22.6 by @dependabot in #643
  • build(deps-dev): bump jest from 29.5.0 to 29.6.0 by @dependabot in #644
  • build(deps-dev): bump @babel/core from 7.22.6 to 7.22.8 by @dependabot in #646
  • build(deps-dev): bump @babel/plugin-transform-runtime from 7.22.6 to 7.22.7 by @dependabot in #645
  • build(deps-dev): bump jest from 29.6.0 to 29.6.1 by @dependabot in #649
  • build(deps-dev): bump @babel/preset-env from 7.22.6 to 7.22.7 by @dependabot in #648
  • build(deps): bump core-js from 3.31.0 to 3.31.1 by @dependabot in #647
  • build(deps-dev): bump babel-loader from 9.1.2 to 9.1.3 by @dependabot in #650
  • build(deps-dev): bump @types/jest from 29.5.2 to 29.5.3 by @dependabot in #651
  • build(deps-dev): bump @babel/preset-env from 7.22.7 to 7.22.9 by @dependabot in #652
  • build(deps-dev): bump @babel/plugin-transform-runtime from 7.22.7 to 7.22.9 by @dependabot in #653
  • build(deps): bump @xmldom/xmldom from 0.8.8 to 0.8.9 by @dependabot in #654
  • build(deps-dev): bump @babel/cli from 7.22.6 to 7.22.9 by @dependabot in #655
  • build(deps-dev): bump @babel/core from 7.22.8 to 7.22.9 by @dependabot in #656
  • build(deps-dev): bump eslint from 8.44.0 to 8.45.0 by @dependabot in #657
  • build(deps-dev): bump webpack from 5.88.1 to 5.88.2 by @dependabot in #658
  • build(deps-dev): bump @commitlint/config-conventional from 17.6.6 to 17.6.7 by @dependabot in #659
  • build(deps-dev): bump @commitlint/cli from 17.6.6 to 17.6.7 by @dependabot in #660
  • build(deps): bump @xmldom/xmldom from 0.8.9 to 0.8.10 by @dependabot in #661
  • build(deps-dev): bump jest from 29.6.1 to 29.6.2 by @dependabot in #662
  • build(deps): bump core-js from 3.31.1 to 3.32.0 by @dependabot in #663
  • build(deps-dev): bump eslint from 8.45.0 to 8.46.0 by @dependabot in #664
  • build(deps-dev): bump @babel/preset-env from 7.22.9 to 7.22.10 by @dependabot in #665
  • build(deps-dev): bump @babel/core from 7.22.9 to 7.22.10 by @dependabot in #667
  • build(deps-dev): bump @babel/cli from 7.22.9 to 7.22.10 by @dependabot in #668
  • build(deps-dev): bump @babel/plugin-transform-runtime from 7.22.9 to 7.22.10 by @dependabot in #669
  • build(deps): bump @babel/runtime-corejs3 from 7.22.6 to 7.22.10 by @dependabot in #666
  • build(deps-dev): bump @commitlint/cli from 17.6.7 to 17.7.1 by @dependabot in #672
  • build(deps-dev): bump @commitlint/config-conventional from 17.6.7 to 17.7.0 by @dependabot in #671
  • build(deps-dev): bump @types/object-hash from 3.0.2 to 3.0.3 by @dependabot in #673
  • build(deps-dev): bump eslint from 8.46.0 to 8.47.0 by @dependabot in #674
  • OPG-410: Add 'down' field to MonitoredService by @synqotik in #675
  • build(deps): bump core-js from 3.32.0 to 3.32.1 by @dependabot in #676
  • build(deps-dev): bump jest from 29.6.2 to 29.6.3 by @dependabot in #677
  • build(deps-dev): bump @types/jest from 29.5.3 to 29.5.4 by @dependabot in #678
  • build(deps): bump @babel/runtime-corejs3 from 7.22.10 to 7.22.11 by @dependabot in #680
  • build(deps-dev): bump chai from 4.3.7 to 4.3.8 by @dependabot in #679
  • build(deps-dev): bump @babel/preset-typescript from 7.22.5 to 7.22.11 by @dependabot in #681
  • build(deps-dev): bump jest from 29.6.3 to 29.6.4 by @dependabot in #682
  • build(deps-dev): bump @babel/core from 7.22.10 to 7.22.11 by @dependabot in #683
  • build(deps-dev): bump typescript from 5.1.6 to 5.2.2 by @dependabot in #684
  • build(deps-dev): bump standard-changelog from 3.0.0 to 4.0.0 by @dependabot in #687
  • build(deps): bump axios from 1.4.0 to 1.5.0 by @dependabot in #688
  • build(deps-dev): bump typedoc from 0.24.8 to 0.25.0 by @dependabot in #686
  • build(deps-dev): bump eslint from 8.47.0 to 8.48.0 by @dependabot in #685
  • convert from chalk to picocolors by @RangerRick in #689
  • build(deps-dev): bump @babel/preset-env from 7.22.10 to 7.22.14 by @dependabot in #690
  • build(deps-dev): bump @types/urijs from 1.19.19 to 1.19.20 by @dependabot in #691
  • build(deps-dev): bump @babel/plugin-transform-runtime from 7.22.10 to 7.22.15 by @dependabot in #692
  • build(deps): bump @babel/runtime-corejs3 from 7.22.11 to 7.22.15 by @dependabot in #693
  • build(deps-dev): bump @babel/preset-env from 7.22.14 to 7.22.15 by @dependabot in #694
  • build(deps-dev): bump @babel/core from 7.22.11 to 7.22.15 by @dependabot in #695
  • build(deps-dev): bump @babel/preset-typescript from 7.22.11 to 7.22.15 by @dependabot in #696
  • build(deps-dev): bump @babel/cli from 7.22.10 to 7.22.15 by @dependabot in #697
  • build(deps-dev): bump typedoc from 0.25.0 to 0.25.1 by @dependabot in #698
  • build(deps-dev): bump @types/object-hash from 3.0.3 to 3.0.4 by @dependabot in #699
  • build(deps): bump core-js from 3.32.1 to 3.32.2 by @dependabot in #700
  • build(deps-dev): bump @babel/core from 7.22.15 to 7.22.17 by @dependabot in #701
  • build(deps-dev): bump @typescript-eslint/parser from 6.6.0 to 6.7.0 by @dependabot in #704
  • build(deps-dev): bump jest from 29.6.4 to 29.7.0 by @dependabot in #705
  • build(deps-dev): bump @typescript-eslint/eslint-plugin from 6.6.0 to 6.7.0 by @dependabot in #706
  • build(deps-dev): bump @types/jest from 29.5.4 to 29.5.5 by @dependabot in #708
  • build(deps-dev): bump @babel/preset-env from 7.22.15 to 7.22.20 by @dependabot in #709
  • build(deps-dev): bump @babel/core from 7.22.17 to 7.23.0 by @dependabot in #713
  • build(deps-dev): bump @typescript-eslint/parser from 6.7.0 to 6.7.4 by @dependabot in #716
  • build(deps-dev): bump @typescript-eslint/eslint-plugin from 6.7.0 to 6.7.4 by @dependabot in #717
  • build(deps): bump axios from 1.5.0 to 1.5.1 by @dependabot in #718
  • NMS-16161: Add fields to Monitored Services by @synqotik in #723
  • build(deps): bump @babel/runtime-corejs3 from 7.22.15 to 7.23.1 by @dependabot in #719
  • build(deps-dev): bump @babel/preset-typescript from 7.22.15 to 7.23.0 by @dependabot in #721
  • build(deps-dev): bump chai from 4.3.8 to 4.3.10 by @dependabot in #722
  • build(deps-dev): bump typedoc from 0.25.1 to 0.25.2 by @dependabot in #724
  • build(deps-dev): bump eslint from 8.49.0 to 8.51.0 by @dependabot in #725
  • build(deps-dev): bump rimraf from 5.0.1 to 5.0.5 by @dependabot in #727
  • build(deps): bump ip-address from 8.1.0 to 9.0.5 by @dependabot in #726
  • build(deps): bump core-js from 3.32.2 to 3.33.0 by @dependabot in #720

Full Changelog: v2.5.7...v2.5.8

by RangerRick at October 10, 2023 02:20 PM

October 03, 2023

Modern Integration: Event-Driven Ansible & OpenNMS

Integrating systems from two different vendors can be a challenging endeavor.

However, these challenges often present unique opportunities for problem-solving. With today's innovative tools such as Red Hat Event-Driven Ansible and OpenNMS, we now have more robust and sustainable solutions at our disposal for such issues.

I'd like to share a personal experience from my previous job where we dealt with a Network Attached Storage (NAS) system issue.

Check out this Ansible demo:

https://www.youtube.com/watch?v=aqQq5vD8-n0

Story Time

Our NAS setup featured a policy server that scrutinized every operation to prevent protected data from ending up in incorrect locations within our drive shares. This process was managed synchronously via a TCP connection initiated by the policy server. Every operation on the NAS required either approval or rejection from this server.

However, an unexpected bug brought this smooth process to a standstill when the policy server would set its TCP window size to zero. The notorious 'zero window' condition means the receiver, in this case the policy server, is no longer able to receive data. The NAS will respect this request of a zero window and stop sending operations for approval. Under normal operations, this is a good thing. A receiver like the policy server maybe temporarily overloaded unfortunately, in this case it never recovered. As the connection appeared alive from both the policy server and NAS neither end would reset it to restore the window, leading to inaccessible drive shares and subsequently halting users' work.

Finding a Fix

Resolving this issue swiftly became a critical priority. Our immediate fix involved manually resetting the connection for the policy server. We probably lost some transactions during this, but the alternative of a full stop to everything was far worse. To automate this process, we crafted several bespoke scripts. However, these were problem-specific and led to a duplication of effort. Thankfully, with the advent of modern solutions, we can now address such situations in a more efficient, reliable, and sophisticated manner.

Integrate & Automate

Red Hat Event-Driven Ansible is a fantastic tool that enables instant responses to events detected by OpenNMS. In the context of our NAS system issue, the policy server traffic remained above 1 megabit per second under normal circumstances, but when the bug appeared, the traffic plunged to less than 100 kilobits per second. OpenNMS was already collecting network interface data via SNMP from the policy server, and we could simply configure this as a low threshold event.

The amalgamation of Ansible's real-time automation and OpenNMS's comprehensive monitoring and event management capabilities provides a powerful solution for network system issues. When OpenNMS triggers an event like a traffic drop below a set threshold, this information is sent to Ansible. Ansible then springs into action, running a playbook that resets the TCP connection, validates service restoration, and sends an all-clear signal.

In conclusion, modern tools and technology have revolutionized how we address complex problems, simplifying our work and providing elegant solutions. With the power of Red Hat Event-Driven Ansible and OpenNMS at your fingertips, you're well-prepared to tackle any system issues head-on!

The post Modern Integration: Event-Driven Ansible & OpenNMS appeared first on The OpenNMS Group, Inc..

by Mike Huot at October 03, 2023 01:00 PM

September 13, 2023

September 2023 Releases – Horizon 32.0.3, 2023.1.7, 2022.1.20, 2021.1.31, 2020.1.39

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

Meridian Stable Updates

Meridians 2023.1.7, 2022.1.20, 2021.1.31, 2020.1.39 contains a few security fixes, as well as a couple other improvements.

For a list of changes, see the release notes:

Horizon 32.0.3

Release 32.0.3 contains a bunch of documentation updates, as well as a number of bug fixes and enhancements including improvements to the Karaf core startup, polling and node search fixes, IPv6 support in ILR, and a fix for loading the Cortex timeseries plugin.

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

For a complete list of changes, see the changelog.

The codename for Horizon 32.0.3 is Acid Techno.

The post September 2023 Releases – Horizon 32.0.3, 2023.1.7, 2022.1.20, 2021.1.31, 2020.1.39 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at September 13, 2023 05:52 PM

OpenNMS Horizon 32.0.3 (Acid Techno)

Release 32.0.3

Release 32.0.3 contains a bunch of documentation updates, as well as a number of bug fixes and enhancements including improvements to the Karaf core startup, polling and node search fixes, IPv6 support in ILR, and a fix for loading the Cortex timeseries plugin.

The codename for Horizon 32.0.3 is Acid Techno.

Enhancement
  • documentation enhancement for discard-uei (Issue NMS-3552)
  • BMP Introduction (Issue NMS-13892)
  • newts set OPENNMS_CASSANDRA_DC using template (Issue NMS-16025)
  • Minion Container Documentation updates (Issue NMS-16088)
  • Update help text on import-requisition Karaf command (Issue NMS-16100)
  • Docs are missing a ValueMappingPropertyExtender example (Issue NMS-16106)
Bug
  • Intermittent error starting Telemetryd: No adapter found for class: org.opennms.netmgt.telemetry.protocols.netflow.adapter.netflow5.Netflow5Adapter (Issue NMS-15345)
  • Polling fails when rrd-status is set to true (Issue NMS-15806)
  • Provisioning policies do not apply (Issue NMS-16031)
  • Prevent Invalid Node Filter Search from revealing SQL query (Issue NMS-16057)
  • Unable to install alarm history feature on Kubernetes (Issue NMS-16070)
  • Minion and Sentinel just run with Java 1.8 - 11.x instead 11 to 17 (Issue NMS-16090)
  • Cortex-tss-plugin 2.0.1 does not work on v32 (Issue NMS-16104)
  • Update Instrumentation Log Reader to parse IPv6 addresses (Issue NMS-16114)

by mershad-manesh at September 13, 2023 05:37 PM

September 12, 2023

OpenNMS.js v2.5.7

Just a minor update with dependency changes, an update targeting Horizon 33 and Foundation 2024, and a change to internal color handling.

  • dependency updates
  • down property added to monitored service model
  • converted CLI from chalk to picocolors

by RangerRick at September 12, 2023 02:52 PM

August 09, 2023

August 2023 Releases – Horizon 32.0.2, 2023.1.6, 2022.1.19, 2021.1.30, 2020.1.38

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

Meridian Stable Updates

Meridians 2023.1.6, 2022.1.19, 2021.1.30, 2020.1.38 contains several important security fixes, one fix for a potential DOS vulnerability, and two general bugfixes.

For a list of changes, see the release notes:

Horizon 32.0.2

Release 32.0.2 contains several important security fixes, one fix for a potential DOS vulnerability, and a handful of general bugfixes and enhancements.

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

For a complete list of changes, see the changelog.

The codename for Horizon 32.0.2 is Anime Lo-fi.

The post August 2023 Releases – Horizon 32.0.2, 2023.1.6, 2022.1.19, 2021.1.30, 2020.1.38 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at August 09, 2023 06:59 PM

OpenNMS Horizon 32.0.2 (Anime Lo-fi)

Release 32.0.2

Release 32.0.2 contains several important security fixes, one fix for a potential DOS vulnerability, and a handful of general bugfixes and enhancements.

Thanks to the following researchers for responsibly disclosing security issues in this release:

  • Moshe Appelbaum reported issue NMS-15699.
  • Jordi Morales reported issues NMS-15703, NMS-15782, and NMS-15783.
  • OSS Fuzz reported issue NMS-15877.

The codename for Horizon 32.0.2 is Anime Lo-fi.

Breaking changes
  • This release removes the "3d" variation from the JFreeChart integration, because that style has been removed upstream.
Bug
  • Document the function hiding Meta-Data values with keynames containing "password" or "secret" (Issue NMS-12808)
  • Prevent Angular evaluation of strings enclosed by two curly braces in non-Angular form-fields and output (Issue NMS-15504)
  • backport fixes from Spring Security 5.x to custom Spring Security 4.2.20.RELEASE (Issue NMS-15663)
  • XXE injection via  /rtc/post using the default rtc credentials (Issue NMS-15699)
  • ROLE_REST can be used to escalate to ROLE_ADMIN via /rest/users (Issue NMS-15703)
  • Stored XSS in multiple JSP files in opennms/opennms (Issue NMS-15782)
  • Reflected XSS in multiple JSP files in opennms/opennms (Issue NMS-15783)
  • POSTINSTALL scriptlet may fail if data/tmp/ is present but empty (Issue NMS-15809)
  • PostgreSQL shows too many clients error with a minimal setup (Issue NMS-15852)
  • java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0 at org.opennms.netmgt.timeseries.samplewrite.MetaTagDataLoader.getNodeCriteriaFromResource(MetaTagDataLoader.java (Issue NMS-15854)
  • Kafka Producer incapable of using SSL (Issue NMS-15859)
  • Fix incorrect resource types for F5 datacollection (Issue NMS-15862)
  • Build fails due to binary file filtered resource copy (Issue NMS-15869)
  • Corrected Keystore setup instructions for minion on docker (Issue NMS-16017)
  • OpenNMS Search Bar does not retrieve nodes without foreignsource and foreignid (Issue NMS-16030)
  • Error on startup with Invalid CEN header exception (Issue NMS-16034)
Story
  • Provide option to disable Kafka Offset Provider (Issue NMS-15336)
  • Document additional details for BMP integration (Issue NMS-15853)
Enhancement
  • Improve Kafka section of message broker docs in the deployment section (Issue NMS-15632)
  • Disable BeanShell interpreter remote server mode (Issue NMS-15793)
  • Include Node metadata in Measurement API query responses even if no resource data exists (Issue NMS-15839)
  • Extend filter syntax to include isSnmpPrimary (Issue NMS-15842)
  • Add docs to describe the default RRD storage retention (Issue NMS-16033)
Task
  • Document the note to increase the maximum connection when pool size is increased (Issue NMS-16050)

by mershad-manesh at August 09, 2023 06:57 PM

August 08, 2023

Secure OpenNMS Meridian: Get started with the reference architecture

Secure your Meridian deployment

Simply deploying a monitoring solution, like OpenNMS Meridian, opens up new security challenges and implications. Fortunately, there are steps, precautions, best practices, and a guide, to help you make Meridian as secure as possible.

The OpenNMS Meridian security reference architecture presents the structural components of the monitoring solution and gives you recommendations for a more secure network monitoring implementation.

This document describes out-of-the-box components and typical use patterns for OpenNMS Meridian. Of course, your implementation may vary, but this is a great place to start—or a resource to double check that you've got your security basics under control.

From the reference architecture: A typical OpenNMS deployment

What it covers

The reference architecture describes everything from a minimal deployment of Meridian (simply Meridian Core, a PostgresSQL database, and the networked devices you with to monitor) all the way to a more advanced deployment with Kafka, visualization through Grafana, load balancers, a reverse proxy, and more.

It also addresses:

  • Roles vs. permissions vs. groups within OpenNMS
  • Authentication and authorization, including default passwords and where to change them
  • SSO integration and recommendations
  • How to secure your communications
  • Zero-trust vs. protected networks
  • Java KeyStore and TrustStore, to securely store certificates and private keys

What it doesn't cover

The reference architecture is all about securing your Meridian installation. It doesn't specifically address how to install or customize the OpenNMS software.

Thankfully, that's why you also have OpenNMS documentation to lean on. If you're just getting started with OpenNMS, that's the best place to go to learn more.

Need support or consulting?

Want to take the next step, or need a helping hand with your OpenNMS deployment or implementation?

We're here to help—contact us to get the most out of your monitoring.

The post Secure OpenNMS Meridian: Get started with the reference architecture appeared first on The OpenNMS Group, Inc..

by Colby Hoke at August 08, 2023 07:41 PM

July 12, 2023

July 2023 Releases – Horizon 32.0.1, 2023.1.5, 2022.1.18, 2021.1.29, 2020.1.37

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

Meridian Stable Updates

Meridians 2023.1.5, 2022.1.18, 2021.1.29, 2020.1.37 contains a bunch of bug fixes, and a couple of small enhancements.

For a list of changes, see the release notes:

Horizon 32.0.1

Release 32.0.1 includes several general bug fixes and documentation improvements.

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

For a complete list of changes, see the changelog.

The codename for Horizon 32.0.1 is A Cappella.

The post July 2023 Releases – Horizon 32.0.1, 2023.1.5, 2022.1.18, 2021.1.29, 2020.1.37 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at July 12, 2023 07:45 PM

OpenNMS Horizon 32.0.1 (A Cappella)

Release 32.0.1

Horizon 32.0.1 includes several general bug fixes and documentation improvements.

The codename for Horizon 32.0.1 is A Cappella.

Bug
  • Database threads stuck idle_in_transaction (Issue NMS-15108)
  • Use UNKNOWN direction when not set in Netflow 9 or IPFIX template (Issue NMS-15134)
  • Minion connectivity config docs start the user in the wrong directory (Issue NMS-15618)
  • Docs need an update on what a Minion is able to do (Issue NMS-15620)
  • Various corrections/clarifications needed in Sentinel install/configure docs (Issue NMS-15708)
  • Memory leak when using Groovy scripts in provisiond ScriptPolicy (Issue NMS-15798)
  • Polling fails when rrd-status is set to true (Issue NMS-15806)
  • ALEC stopped working in 32.0.0 (Issue NMS-15808)
  • Database deadlock triggered by NodeRestService (Issue NMS-15816)
  • Some services do not persist the status (Issue NMS-15820)
Enhancement
  • Update to alarm docs (Issue NMS-15584)
  • Update Minion Docker install keystore instructions (Issue NMS-15803)

by mershad-manesh at July 12, 2023 07:41 PM

June 27, 2023

Introducing OpenNMS Horizon 32

Horizon 32.0.0

Release 32.0.0 features a slew of bug fixes and a number of major improvements, most notably the introduction of JDK17 support, and a major uplift in the Newts backend.

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

For a complete list of changes, see the changelog.

The codename for Horizon 32.0.0 is Cavernous Death Metal.

See the differences between Horizon and Meridian.

The post Introducing OpenNMS Horizon 32 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at June 27, 2023 10:06 PM

OpenNMS Horizon 32.0.0 (Cavernous Death Metal)

Release 32.0.0

Horizon 32 features a slew of bug fixes and a number of major improvements, most notably the introduction of JDK17 support, and a major uplift in the Newts backend.

The codename for Horizon 32.0.0 is Cavernous Death Metal.

Enhancement
  • Add lldpRemLocalPortNum in LldpLink Table (Issue NMS-7775)
  • dependabot: JasperReports from 6.3.0 to 6.20.0 (Issue NMS-14588)
  • Enhanced Linkd supports Network-Routers Map (Issue NMS-14678)
  • Destination Path Test Button (Issue NMS-14692)
  • Node Properties REST endpoint doesn’t include asset location data (Issue NMS-14785)
  • fix/re-merge additional changes to password validation (Issue NMS-14898)
  • Provide a method to verify topology capability (Issue NMS-14909)
  • Special-case CounterBasedGauge64 in MIB compiler (Issue NMS-15210)
  • Remove contrib from OpenNMS (Issue NMS-15268)
  • Upgrade Groovy to 3.x (Issue NMS-15315)
  • Create an Apache mina-sshd based ssh client service poller. (Issue NMS-15431)
  • Add a method for finding and clearing alarms by TTicketID to OPA’s AlarmDAO (Issue NMS-15439)
  • Upgrade Spring Security (Issue NMS-15506)
  • Doc: PersistRegexSelectorStrategy only works on string attributes (Issue NMS-15595)
  • Enable AmbientCapabilities=CAP_NET_RAW CAP_NET_BIND_SERVICE in shipped opennms.service systemd file (Issue NMS-15596)
  • Remove legacy lsb info from Minion initialization script (Issue NMS-15604)
  • Asynchronous polling engine (Issue NMS-15623)
  • Update documentation (or implementation) for newer Slack API (Issue NMS-15652)
  • Make usage statistics sharing notice dialog non-modal (Issue NMS-15677)
  • Docs: Add info about XSLT to XmlCollector (Issue NMS-15693)
  • Doc: Update DNS provisioning import adapter docs (Issue NMS-15694)
  • KSC report "details" should go directly to the related graph, rather than "all" (Issue NMS-15711)
  • Add more collection for selfmonitor node out of box (Issue NMS-15742)
Task
  • TrivialTimeMonitor & detector (Issue NMS-11063)
  • Rework NMS0123EnIT test (Issue NMS-14743)
  • Multiple CVEs for Axis 1.4 (Issue NMS-15061)
  • Make test for Admin page footer Copyright year (Issue NMS-15220)
  • Fix coverage test containers after we resolve NMS-15401 (Issue NMS-15444)
  • Poll Status History: Enable Poll Status RRD for all services (Issue NMS-15641)
  • Poll Status History: Change documentation to reflect the changes (Issue NMS-15642)
  • Poll Status History: Add RRD graph definitions for all services in a default poller-configuration.xml (Issue NMS-15643)
  • Document async polling settings (Issue NMS-15680)
  • Update docs to capture additional details on BMP config (Issue NMS-15713)
  • Tweak usage statistics sharing notice copy (Issue NMS-15740)
  • Call out usage statistics consent changes in Horizon 32.0.0 release notes (Issue NMS-15796)
Bug
  • Multiple OpenNMS feature stop working when the Events Forwarder cannot push content to Elasticsearch (Issue NMS-13019)
  • rest api wrong LinkdTopologyProvider graphs (Issue NMS-14329)
  • Inconsistent references to JMXCollect/Monitor for "password-clear"/"password_clear" (Issue NMS-14884)
  • Docker images for Horizon 30.0.4 and later no longer have an editor or a modern pager (Issue NMS-14946)
  • CVE-2014-2228 for org.restlet 1.1.10 (Issue NMS-15193)
  • Page footer missing from Feather / Vue UIs (Issue NMS-15262)
  • Dead transaction in flow thresholding on sentinel (Issue NMS-15340)
  • Event Datetime element parsing changed between M2018 and M2021 (Issue NMS-15471)
  • Backshift graph’s Data tab shows incorrect / phantom data when using STACK (Issue NMS-15495)
  • Status Overview box calculation included the alarms and outages from nodes outside of the assigned categories (Issue NMS-15526)
  • When upgrading Minion from an older version on RHEL based systems, the service file doesn’t point to the main installation, but rather to /etc/init.d/minion which doesn’t exist (Issue NMS-15600)
  • When upgrading Sentinel from an older version, the service file doesn’t point to the main installation, but rather to /etc/init.d/sentinel which doesn’t exist (Issue NMS-15601)
  • send-events-to-elasticsearch karaf command passes username/password in reverse (Issue NMS-15638)
  • Doc: File name syslog-grok-patterns.txt is wrong (Issue NMS-15684)
  • Stop packaging activemq-web-console.war (Issue NMS-15686)
  • Database deadlock caused by JdbcFilterDao (Issue NMS-15696)
  • Karaf SSH locks up if connections are terminated improperly (Issue NMS-15714)
  • Vue menubar logo link should go to homeUrl (Issue NMS-15721)
  • https redirection is partially broken (Issue NMS-15732)
  • Startup taking > 10 minutes on fresh 32.0.0 builds (Issue NMS-15751)
  • Docs need updating to include support for Kafka 3 (Issue NMS-15777)
  • Add /usr/lib64/jvm to find-java.sh search paths (Issue NMS-15784)
Research
  • Investigate using trivy to scan containers (Issue NMS-14781)
Story
  • New REST endpoint provides textual description given a top-level usage statistics KPI key name (Issue NMS-15476)
  • Data choices modal dialog removed from first admin user login (Issue NMS-15478)
  • New usage statistics sharing notice dialog (Issue NMS-15479)
  • Usage Statistics Sharing UI (Issue NMS-15481)
  • Data Choices link removed in favor of Usage Statistics Sharing UI (Issue NMS-15482)
  • Data Choices modal dialog removed entirely (Issue NMS-15483)
  • Fresh installs assume usage statistics sharing consent (Issue NMS-15485)
  • Usage statistics sharing UI includes control to revoke sharing consent (Issue NMS-15486)
  • Docs explicitly state that statistics sharing consent is assumed and how to revoke it (Issue NMS-15490)
  • Official documentation describes how to uninstall and block "datachoices" feature (Issue NMS-15491)
  • Existing opted-out installs stay opted out of usage statistics sharing (Issue NMS-15492)
  • Existing opted-out installs never show the Sharing Notice Dialog (Issue NMS-15493)
  • Existing opted-out install Usage Statistics Sharing UI behaves like a revoked install (Issue NMS-15494)
  • Upgrade to Newts 3.0.0 (Issue NMS-15514)
  • Native support for Holt-Winters forecast (no dep on R) (Issue NMS-15622)
  • Review and adjust default and example startup settings (Issue NMS-15635)
New Feature
  • update opennms build and runtime to support JDK17 (Issue NMS-15609)

by mershad-manesh at June 27, 2023 09:52 PM

June 14, 2023

June 2023 Releases – Horizon 31.0.9, 2023.1.4, 2022.1.17, 2021.1.28, 2020.1.36

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

Meridian Stable Updates

Meridians 2023.1.4, 2022.1.17, 2021.1.28, 2020.1.36 contains a bunch of bug fixes, and several small enhancements.

For a list of changes, see the release notes:

Horizon 31.0.9

Release 31.0.9 contains one CVE-related security fix, a generous helping of other bug fixes, and a several small enhancements intended to improve supportability.

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.9 is Ballokume.

The post June 2023 Releases – Horizon 31.0.9, 2023.1.4, 2022.1.17, 2021.1.28, 2020.1.36 appeared first on The OpenNMS Group, Inc..

by Morteza Ershad-Manesh at June 14, 2023 04:06 PM

OpenNMS Horizon 31.0.9 (Ballokume)

Release 31.0.9

Release 31.0.9 contains one CVE-related security fix, a generous helping of other bug fixes, and a several small enhancements intended to improve supportability.

The codename for Horizon 31.0.9 is Ballokume.

Breaking changes
  • This release has moved to a newer major version of Spring Security to address a number of CVEs, which necessitated changes to the $OPENNMS_HOME/jetty-webapps/opennms/WEB-INF/applicationContext-spring-security.xml file, so if you have modified this file in your installs, be sure to note your changes so you can re-apply them to the updated version.
  • The script $OPENNMS_HOME/bin/install checked whether $myser equals $RUNAS before sourcing $OPENNMS_HOME/etc/opennms.conf, which caused startup to fail every time unless the script were run as root; if you have patched that file on your system, watch out for a .rpmsave or .dpkg-new file.
Enhancement
  • Codify code copyright conventions and guidelines (Issue NMS-13908)
  • Add diagnostic commands to Karaf shell for various internal schedulers (Issue NMS-14526)
  • Node Properties REST endpoint doesn’t include asset location data (Issue NMS-14785)
  • Add a method for finding and clearing alarms by TTicketID to OPA’s AlarmDAO (Issue NMS-15439)
  • Upgrade Spring Security (Issue NMS-15506)
  • Simplify the installation docs (Issue NMS-15518)
  • Docs: Add info about XSLT to XmlCollector (Issue NMS-15693)
  • Doc: Update DNS provisioning import adapter docs (Issue NMS-15694)
Task
  • Remove unsupported configuration from documentation on Cortex Plugin (Issue NMS-14969)
  • Multiple CVEs for Axis 1.4 (Issue NMS-15061)
Bug
  • Fixing typo for event uei.opennms.org/internal/schedOutagesChanged (Issue NMS-15421)
  • Sentinels need local copy of thresholding config. (Issue NMS-15422)
  • Event Datetime element parsing changed between M2018 and M2021 (Issue NMS-15471)
  • install script checks for equality of myuser and RUNAS before sourcing opennms.conf (Issue NMS-15610)
  • timeout is using DEFAULT_TIMEOUT value instead of the value from properties file when no -t option is specified (Issue NMS-15664)
  • Stop packaging activemq-web-console.war (Issue NMS-15686)
  • Database deadlock caused by JdbcFilterDao (Issue NMS-15696)
  • Karaf SSH locks up if connections are terminated improperly (Issue NMS-15714)
Story
  • Need a way to get a heap dump in a Docker container — no jstack/jmap/jcmd (Issue NMS-15532)
  • Docs section about startup configuration and opennms.conf (Issue NMS-15634)
  • OpenAPI docs for Requisition REST service (Issue NMS-15639)

by mershad-manesh at June 14, 2023 03:52 PM

June 09, 2023

OpenNMS.js v2.5.6

OpenNMS.js v2.5.6 is a minor release with just dependency updates and some internal changes to the CI pipeline.

Dependency Updates

  • build(deps-dev): bump @commitlint/cli from 17.4.4 to 17.5.0 by @dependabot in #537
  • build(deps-dev): bump webpack from 5.76.2 to 5.76.3 by @dependabot in #538
  • build(deps-dev): bump rimraf from 4.4.0 to 4.4.1 by @dependabot in #539
  • build(deps-dev): bump @commitlint/cli from 17.5.0 to 17.5.1 by @dependabot in #540
  • build(deps-dev): bump eslint from 8.36.0 to 8.37.0 by @dependabot in #541
  • build(deps-dev): bump webpack from 5.76.3 to 5.77.0 by @dependabot in #542
  • build(deps-dev): bump @babel/core from 7.21.3 to 7.21.4 by @dependabot in #543
  • build(deps-dev): bump @babel/plugin-transform-runtime from 7.21.0 to 7.21.4 by @dependabot in #544
  • build(deps): bump @xmldom/xmldom from 0.8.6 to 0.8.7 by @dependabot in #545
  • build(deps-dev): bump @babel/preset-typescript from 7.21.0 to 7.21.4 by @dependabot in #546
  • build(deps-dev): bump typescript from 5.0.2 to 5.0.3 by @dependabot in #547
  • build(deps-dev): bump @babel/preset-env from 7.20.2 to 7.21.4 by @dependabot in #548
  • build(deps-dev): bump ts-jest from 29.0.5 to 29.1.0 by @dependabot in #549
  • build(deps-dev): bump @antora/cli from 3.1.2 to 3.1.3 by @dependabot in #550
  • build(deps-dev): bump @antora/site-generator-default from 3.1.2 to 3.1.3 by @dependabot in #551
  • build(deps): bump core-js from 3.29.1 to 3.30.0 by @dependabot in #552
  • build(deps-dev): bump webpack from 5.77.0 to 5.78.0 by @dependabot in #553
  • build(deps): bump axios from 1.3.4 to 1.3.5 by @dependabot in #554
  • build(deps-dev): bump typedoc from 0.23.28 to 0.24.1 by @dependabot in #555
  • build(deps-dev): bump eslint from 8.37.0 to 8.38.0 by @dependabot in #556
  • build(deps-dev): bump rimraf from 4.4.1 to 5.0.0 by @dependabot in #557
  • build(deps-dev): bump typescript from 5.0.3 to 5.0.4 by @dependabot in #558
  • build(deps-dev): bump webpack from 5.78.0 to 5.79.0 by @dependabot in #560
  • build(deps-dev): bump @commitlint/cli from 17.5.1 to 17.6.1 by @dependabot in #562
  • build(deps-dev): bump @commitlint/config-conventional from 17.4.4 to 17.6.1 by @dependabot in #563
  • build(deps): bump core-js from 3.30.0 to 3.30.1 by @dependabot in #564
  • build(deps): bump commander from 10.0.0 to 10.0.1 by @dependabot in #565
  • build(deps-dev): bump typedoc from 0.24.1 to 0.24.4 by @dependabot in #566
  • build(deps-dev): bump @types/jest from 29.5.0 to 29.5.1 by @dependabot in #567
  • build(deps-dev): bump webpack from 5.79.0 to 5.80.0 by @dependabot in #568
  • build(deps): bump axios from 1.3.5 to 1.3.6 by @dependabot in #569
  • build(deps-dev): bump typedoc from 0.24.4 to 0.24.6 by @dependabot in #570
  • build(deps-dev): bump webpack-cli from 5.0.1 to 5.0.2 by @dependabot in #571
  • build(deps-dev): bump eslint from 8.38.0 to 8.39.0 by @dependabot in #572
  • build(deps-dev): bump webpack from 5.80.0 to 5.81.0 by @dependabot in #573
  • build(deps): bump axios from 1.3.6 to 1.4.0 by @dependabot in #574
  • build(deps-dev): bump @babel/cli from 7.21.0 to 7.21.5 by @dependabot in #575
  • build(deps-dev): bump @babel/core from 7.21.4 to 7.21.5 by @dependabot in #576
  • build(deps-dev): bump @babel/preset-typescript from 7.21.4 to 7.21.5 by @dependabot in #577
  • build(deps-dev): bump @babel/preset-env from 7.21.4 to 7.21.5 by @dependabot in #578
  • build(deps): bump @babel/runtime-corejs3 from 7.21.0 to 7.21.5 by @dependabot in #579
  • build(deps-dev): bump @babel/core from 7.21.5 to 7.21.8 by @dependabot in #580
  • build(deps-dev): bump @commitlint/cli from 17.6.1 to 17.6.3 by @dependabot in #581
  • build(deps-dev): bump webpack from 5.81.0 to 5.82.0 by @dependabot in #582
  • build(deps-dev): bump @commitlint/config-conventional from 17.6.1 to 17.6.3 by @dependabot in #583
  • build(deps-dev): bump eslint from 8.39.0 to 8.40.0 by @dependabot in #584
  • build(deps-dev): bump webpack-cli from 5.0.2 to 5.1.0 by @dependabot in #585
  • build(deps-dev): bump typedoc from 0.24.6 to 0.24.7 by @dependabot in #586
  • build(deps-dev): bump terser-webpack-plugin from 5.3.7 to 5.3.8 by @dependabot in #587
  • build(deps): bump core-js from 3.30.1 to 3.30.2 by @dependabot in #588
  • build(deps-dev): bump webpack-cli from 5.1.0 to 5.1.1 by @dependabot in #589
  • build(deps-dev): bump webpack from 5.82.0 to 5.82.1 by @dependabot in #590
  • build(deps): bump qs from 6.11.1 to 6.11.2 by @dependabot in #591
  • build(deps-dev): bump rimraf from 5.0.0 to 5.0.1 by @dependabot in #592
  • build(deps-dev): bump webpack from 5.82.1 to 5.83.1 by @dependabot in #593
  • build(deps-dev): bump terser-webpack-plugin from 5.3.8 to 5.3.9 by @dependabot in #594
  • build(deps-dev): bump eslint from 8.40.0 to 8.41.0 by @dependabot in #595
  • build(deps-dev): bump webpack from 5.83.1 to 5.84.0 by @dependabot in #596
  • build(deps-dev): bump @babel/preset-env from 7.21.5 to 7.22.0 by @dependabot in #597
  • build(deps-dev): bump @babel/core from 7.21.8 to 7.22.0 by @dependabot in #598
  • build(deps-dev): bump webpack from 5.84.0 to 5.84.1 by @dependabot in #600
  • build(deps-dev): bump @babel/plugin-transform-runtime from 7.21.4 to 7.22.0 by @dependabot in #601
  • build(deps-dev): bump @babel/core from 7.22.0 to 7.22.1 by @dependabot in #602
  • build(deps): bump @babel/runtime-corejs3 from 7.21.5 to 7.22.3 by @dependabot in #603
  • build(deps-dev): bump @babel/plugin-transform-runtime from 7.22.0 to 7.22.4 by @dependabot in #605
  • build(deps-dev): bump @babel/preset-env from 7.22.0 to 7.22.4 by @dependabot in #604
  • build(deps-dev): bump @commitlint/cli from 17.6.3 to 17.6.5 by @dependabot in #607
  • build(deps): bump @xmldom/xmldom from 0.8.7 to 0.8.8 by @dependabot in #608
  • build(deps-dev): bump @types/jest from 29.5.1 to 29.5.2 by @dependabot in #610
  • build(deps-dev): bump webpack from 5.84.1 to 5.85.0 by @dependabot in #609
  • build(deps-dev): bump typescript from 5.0.4 to 5.1.3 by @dependabot in #611
  • build(deps-dev): bump eslint from 8.41.0 to 8.42.0 by @dependabot in #615
  • build(deps-dev): bump standard-changelog from 2.0.27 to 3.0.0 by @dependabot in #616
  • build(deps-dev): bump webpack from 5.85.0 to 5.86.0 by @dependabot in #617
  • build(deps-dev): bump @antora/cli from 3.1.3 to 3.1.4 by @dependabot in #618
  • build(deps-dev): bump webpack-cli from 5.1.1 to 5.1.4 by @dependabot in #619
  • build(deps-dev): bump @antora/site-generator-default from 3.1.3 to 3.1.4 by @dependabot in #620
  • build(deps-dev): bump @babel/preset-typescript from 7.21.5 to 7.22.5 by @dependabot in #621
  • build(deps-dev): bump @babel/cli from 7.21.5 to 7.22.5 by @dependabot in #622
  • build(deps-dev): bump @babel/core from 7.22.1 to 7.22.5 by @dependabot in #623

Full Changelog: v2.5.5...v2.5.6

by RangerRick at June 09, 2023 06:48 PM

June 07, 2023

Introducing Lōkahi by OpenNMS

What is Lōkahi?

Lōkahi by OpenNMS is a new open source project focused on turning OpenNMS Horizon into a cloud-native application, built on a microservices-based architecture.

Lōkahi, pronounced [loh-KAH-hee], is the Hawaiian word for "unity." (As you may or may not know, one of The OpenNMS Group's founders, David Hustace, is of Hawaiian descent.)

The underlying objective is very much about unifying everything the OpenNMS community has been building for the past 20+ years and reimagining it as an orchestrated, elastic service.

The Lōkahi project is the next generation of open source network monitoring.

You might have noticed activity in GitHub recently, referring to this project as "Horizon Stream." You may have recently found the repository for it and poked around.

"With Lōkahi, we have the opportunity to unify decades of experience and community development to build something that not only monitors the cloud, but that you can deploy natively, in the cloud, to support your organization's initiatives, holistically. It's a chance to use the advantages of cloud infrastructure to achieve—not only your organization's network monitoring challenges of scale and reliability—but also your organization's infrastructure and resource objectives of the future. As always, OpenNMS is built out in the open. So you get the innovative power of the community and the stability of business continuity, which you just can't get with closed-source SaaS solutions."
David Hustace, Founder & Chief Visionary Officer
Why Lōkahi?

The general arc of software development unfortunately bends toward code debt. As flexible and as powerful as the OpenNMS codebase is, being on the leading edge of large Java™ projects since 1999 means a number of past decisions makes it difficult to move the platform forward today.

Lōkahi came about when it became obvious that efforts to convert OpenNMS Horizon into a containerized, cloud-native architecture were riskier than creating this new migration project. This allows development to not only move more quickly, but also address some of that unreachable code debt at the same time.

Where's Lōkahi Today?

Right now, it's focused on cloud-native architecture, along with a few key feature sets for network monitoring. The intention is to encourage a design that brings immediate value by enabling elastic computing through cloud infrastructure deployment.

One of the first initiatives was to improve the design of the stateless OpenNMS Minion to be more autonomous. This allows for remote handling of active polling schedules, thereby reducing the communication chatter between Minions in remote sites and the cloud core. Another focus for Minion is industry-defining security—in-line with zero-trust architecture—Minion uses encrypted and authenticated communications to ensure no unintended sources can inject, fake, or extract your network data.

What's next?

Feature-wise, the priority now is around Flow technologies and advanced traffic analysis and migrating these and other capabilities from Horizon while greatly improving the user experience. Naturally, this requires inventory (network discovery and provisioning) and SNMP capabilities to fully support these features.

Just like Horizon, Lōkahi is open source and encourages all contribution. If you want to submit code, ask design questions, or make recommendations to the project, you can chat with the community developers in the project's Mattermost development channel and the Discourse community.

We believe this is an important, fun project—and we can't wait to see where it takes the OpenNMS community.

The post Introducing Lōkahi by OpenNMS appeared first on The OpenNMS Group, Inc..

by Colby Hoke at June 07, 2023 02:15 PM

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.

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