You are here

OpsView REST API SNMPv3 AuthPriv - essential SNMPv3 host attributes absent from REST API submission in certain circumstances

3 posts / 0 new
Last post
Tom Ranson
tom_6's picture
OpsView REST API SNMPv3 AuthPriv - essential SNMPv3 host attributes absent from REST API submission in certain circumstances

Environment:

- Ubuntu 16.04.2 LTS
- OpsView Atom 5.3.0 (I have also encountered this same bug in previous OpsView versions, 5.0.2 also definitely affected (it probably affects all previous versions))
- Using SNMPv3 for monitoring of hosts

Issue:

Sometimes (exaction conditions which manifest this condition are not entirely clear, however it appears to mainly- but NOT exclusively- manifest when cloning existing host objects), when creating hosts in the WebUI to be monitored via SNMPv3 (version 3 specifically), the WebUI will report SNMPv3 communication failures with the host (Edit Host > SNMP > "Test SNMP Connection" returns "Cannot connect with SNMPv3"). If we correctly configure all SNMPv3 parameters and then test, the test will fail. This issue only affects SNMPv3 monitored hosts, and it is caused by the web interface failing to correctly submit the snmpv3_authpassword and snmpv3_privpassword host attributes when testing the SNMP connection (or, when enumerating SNMP interfaces to be added to the host for monitoring)

For example:
- Create a host (the problem always manifests when *cloning* from an existing host object, but also sometimes seems to occur when creating a new host from scratch), define the host IP address
- Enable SNMP: Checked
- SNMP Version: v3
- SNMP Port: 161
- Username: blah
- Authentication Protocol: sha
- Authentication Password: foo
- Privacy Protocol: aes128
- Privacy Password: bar
- Click "Test SNMP Connection" - the test will fail with error "Cannot connect with SNMPv3"

Debugging which has identified the issue:

- Enable debug logging in "/usr/local/opsview-web/etc/Log4perl.conf" (uncomment "log4perl.logger.Opsview.Web.ControllerBase.REST=DEBUG" and uncomment "log4perl.logger.Opsview.Web.Controller.Admin.Host=DEBUG")
- Watch logfile /var/log/opsview/opsview-web.log and you will observe something similar to the following:

hostid => 16,
ip => "10.10.10.10",
snmp_max_msg_size => 0,
snmp_port => 161,
snmp_use_ifname => 0,
snmp_version => 3,
snmpv3_authprotocol => "sha",
snmpv3_privprotocol => "aes128",
snmpv3_username => "blah",
testconnection => 1,
tidy_ifdescr_level => 0,

You will notice that the essential attributes "snmpv3_authpassword" and "snmpv3_privpassword" are totally absent from the REST API submission. Therefore, it is no surprise that the SNMPv3 host test communication fails.

A correct submission, which will work, should look like this. Note the presence of "snmpv3_authpassword => "foo"," and "snmpv3_privpassword => "bar",".

hostid => 16,
ip => "10.10.10.10",
snmp_max_msg_size => 0,
snmp_port => 161,
snmp_use_ifname => 0,
snmp_version => 3,
snmpv3_authpassword => "foo",
snmpv3_authprotocol => "sha",
snmpv3_privpassword => "bar",
snmpv3_privprotocol => "aes128",
snmpv3_username => "blah",
testconnection => 1,
tidy_ifdescr_level => 0,

This problem definitely manifests when host objects are cloned- the snmpv3_authpassword and snmpv3_privpassword host attributes will seemingly "disappear". N.B. even if you reset and reconfigure the Auth and Priv password values in the WebUI after cloning an object, they will still be missing from the API submission (even if you save and reload the OpsView config).

Please can someone investigate why in certain circumstances these attributes seem to be absent from the SNMP tests / interface enumeration? It's a very annoying and time consuming bug, requiring that large numbers of host objects have to be deleted and manually re-added. Very happy to provide further data/testing as this problem has wasted hours of my life!!

Tom Ranson
tom_6's picture
Clarification on when the

Clarification on when the issue manifests; it appears to occur whenever the "Host Name" attribute has been changed. i.e.

1. When a host object has been cloned
2. When a host object is renamed

Duncan Ferguson
dferguson's picture
Thank you for your bug report

Thank you for your bug report - I will take this up with Engineering

  Duncs