Bug 1379874 - "snmpwalk: Unknown engine ID" as result from snmpwalk.
Summary: "snmpwalk: Unknown engine ID" as result from snmpwalk.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-node
Version: 3.6.8
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
: ---
Assignee: Ryan Barry
QA Contact: Wei Wang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-28 00:48 UTC by Bimal Chollera
Modified: 2022-04-16 08:50 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-20 09:59:17 UTC
oVirt Team: Node
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-45696 0 None None None 2022-04-16 08:50:19 UTC

Description Bimal Chollera 2016-09-28 00:48:44 UTC
Description of problem:

Unknown engine ID reported as result from snmpwalk command.

~~~
# snmpwalk -v3 -u root -l authPriv -a SHA -A <password> -x AES -X <password> localhost sysDescr
snmpwalk: Unknown engine ID (Sub-id not found: (top) -> sysDescr)
~~~

Version-Release number of selected component (if applicable):

~~~
Red Hat Enterprise Virtualization Hypervisor release 7.2 (20160711.0.el7ev)
vdsm-4.17.33-1.el7ev.noarch
net-snmp-5.7.2-24.el7_2.1.x86_64
~~~

~~~
rhevm-3.6.8.1-0.1.el6.noarch
~~~
How reproducible:

On end-user system.

Steps to Reproduce:
1.
2.
3.

Actual results:

snmpwalk command should complete without any errors.

Expected results:


Additional info:

Comment 3 Ryan Barry 2016-09-28 13:43:35 UTC
I can't reproduce this on the most recent (3.6.9) build, or on a clean install of the version reported by the customer.

The reported workaround (unpersist/persist /var/lib/net-snmp/snmp.conf) is not correct. There was a behavior change in net-snmp around 7.2 or so, and snmp now expects to be able to edit a temporary file and rename it. This is the cause of:

Sep 12 07:08:24 localhost snmpd[51871]: Cannot rename /var/lib/net-snmp/snmpd.conf to /var/lib/net-snmp/snmpd.0.conf
Sep 12 07:08:24 localhost snmpd[51871]: Cannot unlink /var/lib/net-snmp/snmpd.conf

This change was reflected in RHV-H for 3.6.2 (see https://bugzilla.redhat.com/show_bug.cgi?id=1261424)

Looking at the sosreport, I see in all 3 that /var/lib/net-snmp/snmp.conf is persisted.

This file should be unpersisted, and the entire path (/var/lib/net-snmp) should be persisted.

The RHV-H TUI does this automatically when configuring SNMP from a clean install, or when disabling/re-enabling SNMP (to catch upgraded installations which have the file persisted). Is there something else modifying the customer's environment?

Please ask the customer to:

* unpersist /var/lib/net-snmp/snmpd.conf

Then:
* disable/re-enable SNMP from the TUI (or change the password)
* Or do this manually with `net-snmp-create-v3-user -A password -a SHA -x AES root && persist /var/lib/net-snmp`

Comment 6 Wei Wang 2016-10-27 08:35:14 UTC
Test Version
rhev-hypervisor7-7.2-20160711.0.el7ev
vdsm-4.17.33-1.el7ev.noarch
net-snmp-5.7.2-24.el7_2.1.x86_64

Test Steps:
1. # systemctl stop snmpd
   # pgrep -fl snmp
   # unpersist /var/lib/net-snmp/snmpd.conf
File not explicitly persisted: /var/lib/net-snmp/snmpd.conf

2. disable/re-enable SNMP from the TUI (or change the password)
3. # unpersist /var/lib/net-snmp/snmpd.conf
/var/lib/net-snmp/snmpd.conf successully unpersisted
   # pgrep -fl snmp
18702 snmpd
   # snmpwalk -v3 -u root -l authPriv -a SHA -A 123qweasd -x AES -X 123qweasd localhost sysDescr
SNMPv2-MIB::sysDescr.0 = STRING: Linux dhcp-8-149.nay.redhat.com 3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 9 10:09:10 EDT 2016 x86_64

QE can reproduce the bug.

Comment 7 Fabian Deutsch 2016-12-20 09:59:17 UTC
Closing this bug because it was caused by running a command on the terminal (whis is unsupported) and because the bug was fixed with comment 4.

Please reopen this bug if necessary.


Note You need to log in before you can comment on or make changes to this bug.