opnsense-version vs net-snmpd vs librenms

[TotalGriffLock]

The net-snmpd plugin has an option to expose the version of OPNsense under a specific OID. This is a tickbox in the GUI provided by this plugin:



This adds the following line to the snmpd config file:

Code: [Select]

extend    version   /usr/local/sbin/opnsense-version

This has the effect of putting whatever the output is of that command, into that OID. LibreNMS, a 3rd party network monitoring system, is aware of OPNsense. Libre, and I would assume other NMS-type products, look in this OID to figure out the OS and version, using this regex:

Code: [Select]

(?<version>[\d._]+) \((?<hardware>[^)]+)\)
However at some point the output of the opnsense-version command has changed, and it no longer outputs the arch by default. This means the string in the OID no longer matches the regex the NMS is using to identify the OS version.

Old output:

Code: [Select]

root@x-y-z:~ # ./opnsense-version
OPNsense 24.10_7 (amd64/OpenSSL)

New output:

Code: [Select]

root@x-y-z:~ # /usr/local/sbin/opnsense-version
OPNsense 24.10_7

Current opnsense-version with parameters to replicate old behaviour:

Code: [Select]

root@x-y-z:~ # /usr/local/sbin/opnsense-version -NvA
OPNsense 24.10_7 amd64

Believe it or not, this was caused by a commit from 2019! Commit id c1f839e in relation to issue #4500 changed the default output of the command, by introducing the DEFAULTS variable and setting this to include product_name and product_version.

There are a number of ways this could be addressed:

• Modify the default output of the opnsense-version command so it behaves as it did in the past
• Modify the template for the snmpd.conf file so that it adds -NvA as a parameter to opnsense-version, restoring the original functionality
• Add more tickboxes to the net-snmp plugin to further customise what information is presented in that OID
• Submit a PR to LibreNMS to change their regular expression

What do we collectively think is the correct way to approach this? Fundamentally, a change was introduced in OPNsense which inadvertently changed the way a plugin worked. Is the correct fix to modify the plugin, modify OPNsense to restore the original intended behaviour, or accept it is how it is and fix the 3rd party tool? I'll do the PR, would just like some guidance as to the correct way to fix it.

[franco]

Interesting. We can flip back to "version (arch)" if that's what it wants. Up for another PR?


Cheers,
Franco

[TotalGriffLock]

Happy to, I have a few more for net-snmpd / lldpd waiting in the wings too! The question I guess is, do any changes that have been made in the last 5 years now rely on the new default output of the command?

[franco]

PR: Just for historic context LibreSSL and i386 went away eliminating the need to spew out redundant information here. These days aarch64 is a bit more prevalent so it makes sense to go half a step backwards.

[franco]

Happy to, I have a few more for net-snmpd / lldpd waiting in the wings too! The question I guess is, do any changes that have been made in the last 5 years now rely on the new default output of the command?

Looking forward to it, thanks!

[Patrick M. Hausen]

The net-snmpd plugin has an option to expose the version of OPNsense under a specific OID. This is a tickbox in the GUI provided by this plugin:



This adds the following line to the snmpd config file:

Code: [Select]

extend    version   /usr/local/sbin/opnsense-version

This has the effect of putting whatever the output is of that command, into that OID.

Observium uses .1.3.6.1.4.1.2021.7890.1 which is what you get when you enable Observium support in the current version of the plugin. Just for reference - I have no idea why there are (at least) two different OIDs. Also Observium does not use opnsense-version but relies on its own "distro" script for all Unix platforms.

[TotalGriffLock]

The net-snmpd plugin has an option to expose the version of OPNsense under a specific OID. This is a tickbox in the GUI provided by this plugin:



This adds the following line to the snmpd config file:

Code: [Select]

extend    version   /usr/local/sbin/opnsense-version

This has the effect of putting whatever the output is of that command, into that OID.

Observium uses .1.3.6.1.4.1.2021.7890.1 which is what you get when you enable Observium support in the current version of the plugin. Just for reference - I have no idea why there are (at least) two different OIDs. Also Observium does not use opnsense-version but relies on its own "distro" script for all Unix platforms.

What does it report in that OID? I don't get anything on my OPNsense querying that:

Code: [Select]

root@x-y-z:~ # snmpwalk -v3 -u xxx -a sha -x aes -A xxx -X xxx -l authPriv 127.0.0.1 .1.3.6.1.4.1.2021.7890.1
UCD-SNMP-MIB::ucdavis.7890.1 = No Such Object available on this agent at this OID


[Patrick M. Hausen]

Did you enable Observium support in the plugin settings?

Code: [Select]

root@nms:~ #  snmpwalk -v2c -c public opnsense .1.3.6.1.4.1.2021.7890.1
UCD-SNMP-MIB::ucdavis.7890.1.1.0 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.7890.1.2.1.2.6.100.105.115.116.114.111 = STRING: "/usr/local/opnsense/scripts/OPNsense/Netsnmp/distro.sh"
UCD-SNMP-MIB::ucdavis.7890.1.2.1.3.6.100.105.115.116.114.111 = ""
UCD-SNMP-MIB::ucdavis.7890.1.2.1.4.6.100.105.115.116.114.111 = ""
UCD-SNMP-MIB::ucdavis.7890.1.2.1.5.6.100.105.115.116.114.111 = INTEGER: 5
UCD-SNMP-MIB::ucdavis.7890.1.2.1.6.6.100.105.115.116.114.111 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.7890.1.2.1.7.6.100.105.115.116.114.111 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.7890.1.2.1.20.6.100.105.115.116.114.111 = INTEGER: 4
UCD-SNMP-MIB::ucdavis.7890.1.2.1.21.6.100.105.115.116.114.111 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.7890.1.3.1.1.6.100.105.115.116.114.111 = STRING: "FreeBSD|SMP|amd64|OPNsense|24.7.8||"
UCD-SNMP-MIB::ucdavis.7890.1.3.1.2.6.100.105.115.116.114.111 = STRING: "FreeBSD|SMP|amd64|OPNsense|24.7.8||"
UCD-SNMP-MIB::ucdavis.7890.1.3.1.3.6.100.105.115.116.114.111 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.7890.1.3.1.4.6.100.105.115.116.114.111 = INTEGER: 0
UCD-SNMP-MIB::ucdavis.7890.1.4.1.2.6.100.105.115.116.114.111.1 = STRING: "FreeBSD|SMP|amd64|OPNsense|24.7.8||"

The full set of OIDs specific for Observium is:

Code: [Select]

extend .1.3.6.1.4.1.2021.7890.1 distro /usr/local/opnsense/scripts/OPNsense/Netsnmp/distro.sh
extend .1.3.6.1.4.1.2021.7890.2 hardware /bin/kenv smbios.planar.product
extend .1.3.6.1.4.1.2021.7890.3 vendor /bin/kenv smbios.planar.maker
extend .1.3.6.1.4.1.2021.7890.4 serial /bin/kenv smbios.planar.serial


[TotalGriffLock]

Ah, no sorry I didn't see that bit. I've not installed that plugin because I'm not using Observium, however it is interesting they have chosen to do it that way, as the info about architecture, release, and OS name (e.g. the stuff I posted about above) is exposed by net-snmpd by ticking the 'Display Version in OID' tickbox without needing any additional plugins.

What else does that plugin do? It can't just be that! Off to investigate... shouldn't need to install a plugin to make an nms work

[Patrick M. Hausen]

I am referring to the os-net-snmp plugin. You need to install that if you want SNMP in OPNsense.
The latest version of os-net-snmp contains Observium specific extends authored by me. Just tick the "Observium support" checkbox.

[TotalGriffLock]

I understand now. That revision is far too new to be on my production systems I'm afraid - most are business edition! I will investigate it though because I would be keen to do this in such a way that would work any any NMS rather than specific 3rd party scripts for 1 product - e.g. some (most?) of the data from distro.sh is already provided by the net-snmp plugin in this other OID which is referenced by other 3rd party tools. And as mentioned I also have a bunch of work on the os-net-snmp and os-lldpd plugins in flight 

[Patrick M. Hausen]

Ah - I see. 24.10 has version 1.5 of os-net-snmp, not 1.6.

I updated this post with the full set of Observium specific OIDs in case you did not notice.

[TotalGriffLock]

Just from a quick view, the format Observium is expecting for OS info is:

${OS}|${KERNEL}|${ARCH}|${DISTRO}|${VERSION}|${VIRT}|${CONT}

We could easily modify the built-in opnsense-version script to add another parameter (say, -o) to output Observium format. You would then not need distro.sh which contains a large amount of irrelevant info (e.g. checking to see if we are running on Solaris). Then you haven't got to maintain Observium's distro.sh script inside an OPNsense plugin, bundle in the Observium license, etc etc.

[Patrick M. Hausen]

That would be awesome!

[TotalGriffLock]

That would be awesome!

Minimal mucking about:

Code: [Select]

./opnsense-version -o
FreeBSD|SMP|amd64|OPNsense|24.7.8|vmware|
That should mean you could add something into your snmpd.conf template like:

Code: [Select]

{% if OPNsense.netsnmp.general.enableobservium == '1' %}
extend .1.3.6.1.4.1.2021.7890.1 distro /usr/local/sbin/opnsense-version -o
extend .1.3.6.1.4.1.2021.7890.2 hardware /bin/kenv smbios.planar.product
extend .1.3.6.1.4.1.2021.7890.3 vendor /bin/kenv smbios.planar.maker
extend .1.3.6.1.4.1.2021.7890.4 serial /bin/kenv smbios.planar.serial
{% endif %}
And then not have to bundle the distro.sh from Observium. It's actually better than distro.sh which will never detect if you are running in a hypervisor - despite having logic to check if it is running in FreeBSD, it then tries to call the detectvirt binary which is a systemd tool that doesn't exist here.  My virtualisation detection is rudimentary though - it doesn't detect containers and I can only actually test it on vmware and hyper-v.

I will put this in a PR and see what Franco et al think