NMS-13784: Disable multiprotocol listener for flows by default

[indigo423]

All Contributors

• [x] Have you read our Contribution Guidelines?
• [x] Have you (electronically) signed the OpenNMS Contributor Agreement?

Contribution Checklist

• Please make an issue in the OpenNMS issue tracker if there isn't one already.
  Once there is an issue, please:
  1. update the title of this PR to be in the format: ${JIRA-ISSUE-NUMBER}: subject of pull request
  2. update the JIRA link at the bottom of this comment to refer to the real issue number
  3. prefix your commit messages with the issue number, if possible
  4. once you've created this PR, please link to it in a comment in the JIRA issue Don't worry if this sounds like a lot, we can help you get things set up properly.
• If this is a new or updated feature, is there documentation for the new behavior?
• If this is new code, are there unit and/or integration tests?
• If this PR targets a foundation-* branch, does it try to avoid changing files in $OPENNMS_HOME/etc/?

Disable the multiprotocol listener by default which gives you a faulty state. You need Elasticsearch and Helm installed and configured to be able to enable the listener.

External References

• JIRA (Issue Tracker): http://issues.opennms.org/browse/NMS-13784

[indigo423]

@dino2gnt yes it would make sense to disable telemetryd by default, cause we have external dependencies which need to be installed and deployed first before we can enable telemetryd.

[fooker]

@dino2gnt yes it would make sense to disable telemetryd by default, cause we have external dependencies which need to be installed and deployed first before we can enable telemetryd.

That is only true for the flow-related part of telemetryd. BMP, NxOS, Graphite, JTI, OpenConfig and parts of SFlow all work without external resources.

[dino2gnt]

That is only true for the flow-related part of telemetryd. BMP, NxOS, Graphite, JTI, OpenConfig and parts of SFlow all work without external resources.

Right. Is there also an expectation that the future in-memory thresholding engine for flows that is currently in development be separated from and not dependent on the ES persistence layer, or am I dreaming?

In case it isn't clear, I'm arguing from the position that having this listener in place adds value and it should be left enabled.

[indigo423]

@dino2gnt yes it would make sense to disable telemetryd by default, cause we have external dependencies which need to be installed and deployed first before we can enable telemetryd.

That is only true for the flow-related part of telemetryd. BMP, NxOS, Graphite, JTI, OpenConfig and parts of SFlow all work without external resources.

Should we enable then just "the parts" which really can be used by default?

[fooker]

@dino2gnt yes it would make sense to disable telemetryd by default, cause we have external dependencies which need to be installed and deployed first before we can enable telemetryd.

That is only true for the flow-related part of telemetryd. BMP, NxOS, Graphite, JTI, OpenConfig and parts of SFlow all work without external resources.

Should we enable then just "the parts" which really can be used by default?

There is no harm in having telemetryd enabled by default (beside slightly longer startup time). On the other hand, opening ports indeed can cause harm. Therefore we should have all listeners disabled by default.

I'm uncertain about the adapters. Some of them are enabled by default, some not. I think, we should disable them, too. But, at least, all should have the same default config.

In addition, docs specify that these must be enabled.

@indigo423 Could you disable the adapters, too? Then this is good to merge, IMO.

[j-white]

Oh no, disabling the adapters too. I have to say, it's been nice having these enabled by default and only needing to setup/configure Elasticsearch to get flows going.

Can we elaborate on what problems we're actually fixing with this change?

[indigo423]

The problem is someone can push your OpenNMS into unpredictable behavior by just enabling flows and sending it to OpenNMS. This happens pretty easily, especially if you have OpenNMS running in an environment with more than one system/network administrator :) I would prefer to be defensive and have a predictable monitoring system and behavior not relating to external processes and be stable and predictable by default and not requiring someone to troubleshoot for hard stuff. To solve this problem as @j-white would like to see it, we would need a neutral NOOP strategy for our non-existing external dependencies.

[indigo423]

The problem is someone can push your OpenNMS into unpredictable behavior by just enabling flows and sending it to OpenNMS. This happens pretty easily, especially if you have OpenNMS running in an environment with more than one system/network administrator :) I would prefer to be defensive and have a predictable monitoring system and behavior not relating to external processes and be stable and predictable by default and not require someone to troubleshoot for the hard stuff. To solve this problem as @j-white would like to see it, we would need a neutral NOOP strategy for our non-existing external dependencies.

[indigo423]

To solve this problem as @j-white would like to see it, we would need a neutral NOOP strategy for our non-existing external dependencies.

I would vote -0 for this behavior cause it is not best practice to run things robust and secure by default. I would prefer a mode where just enable actively what you really use and need.

[indigo423]

An example of unwanted behavior if you have unused open ports:

https://www.youtube.com/watch?v=qFR8weCbMTM

[dino2gnt]

An example of unwanted behavior if you have unused open ports:

https://www.youtube.com/watch?v=qFR8weCbMTM

Does this problem not occur when flows are configured with the external dependencies in place, or is this a bug in the listener/parser/adapter that should be addressed separately?

[indigo423]

Does this problem not occur when flows are configured with the external dependencies in place, or is this a bug in the listener/parser/adapter that should be addressed separately?

Probably it does the same, but it doesn't matter. IMHO there is a difference if you willingly provide a service you are aware of vs. unwillingly providing a service you have no idea about it. Especially when it comes to very specific services, such as flows, BMP, streaming telemetry.

[RangerRick]

regardless of the relative merits of doing it or not, this currently didn't build, and was against an old branch; let's see what happens if I update it :)