I noticed that distro uses a “custom OID” (for lack of a better term) to transfer information to LibreNMS. I have found other occurences of this - it’s fine, but is a list of these OID’s captured somewhere? Asking because I can see that conflicts could easily arise, want to avoid that.
A conflict isn’t very likely unless you use the same extend name. distro is a bit older and uses the old ucd-snmp mib tree. I don’t why 184.108.40.206.4.1.2021.7890 was used instead of the 220.127.116.11.4.1.2021.8 extTable but even so, because it uses extend the name is built into the OID.
extend .18.104.22.168.4.1.2021.7890.1 distro /usr/bin/distro
$ snmpwalk HHHHHHHH -On -v2c -c CCCCCCCC .22.214.171.124.4.1.2021.7890.1
UCD-SNMP-MIB::ucdavis.78126.96.36.199 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.78188.8.131.52.184.108.40.206.220.127.116.11 = STRING: “/usr/bin/distro”
UCD-SNMP-MIB::ucdavis.7818.104.22.168.22.214.171.124.126.96.36.199 = “”
UCD-SNMP-MIB::ucdavis.78188.8.131.52.184.108.40.206.220.127.116.11 = “”
UCD-SNMP-MIB::ucdavis.7818.104.22.168.22.214.171.124.126.96.36.199 = INTEGER: 5
UCD-SNMP-MIB::ucdavis.78188.8.131.52.184.108.40.206.220.127.116.11 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.7818.104.22.168.22.214.171.124.126.96.36.199 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.78188.8.131.52.184.108.40.206.220.127.116.11 = INTEGER: 4
UCD-SNMP-MIB::ucdavis.7818.104.22.168.22.214.171.124.126.96.36.199 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.78188.8.131.52.184.108.40.206.220.127.116.11 = STRING: “RedHat 7.6”
UCD-SNMP-MIB::ucdavis.7818.104.22.168.22.214.171.124.126.96.36.199 = STRING: “RedHat 7.6”
UCD-SNMP-MIB::ucdavis.78188.8.131.52.184.108.40.206.220.127.116.11 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.7818.104.22.168.22.214.171.124.126.96.36.199 = INTEGER: 0
UCD-SNMP-MIB::ucdavis.78188.8.131.52.184.108.40.206.220.127.116.11.1 = STRING: “RedHat 7.6”
decimal value character
Application monitoring scripts that use SNMP extend in LibreNMS will work the same way but use the newer more standard net-snmp-extend-mib (18.104.22.168.4.1.8072.1.3) instead of ucd-snmp.
Yes, agreed. But, I am finding several devices that don’t support extend … rather only exec. Then, using your example line, modified for exec,
exec .22.214.171.124.4.1.2021.7890.1 /usr/bin/distro
Now I have to be careful not to reuse that OID. I just found an app using an OID that I was about to use.
Sure, but it’s unlikely anything else is using UCD-SNMP-MIB::ucdavis.7890.1, so that may work for distro. For other applications, the documentation specifically says snmpd extend. I wouldn’t expect exec to be supported. I think your options there are to upgrade snmpd (if possible) or use the check_mk agent.
Yes, agreed - won’t be an issue outside of LibreNMS, those aren’t used OID’s (I think). I found this on a Tomato based router I have - snmp there is too old for extend, only has exec.