| Summary: | "snmpwalk: Unknown engine ID" as result from snmpwalk. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Bimal Chollera <bcholler> |
| Component: | ovirt-node | Assignee: | Ryan Barry <rbarry> |
| Status: | CLOSED WONTFIX | QA Contact: | Wei Wang <weiwang> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 3.6.8 | CC: | bcholler, cshao, dguo, fdeutsch, gklein, lsurette, mgoldboi, ycui, ykaul |
| Target Milestone: | --- | Keywords: | ZStream |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-12-20 09:59:17 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Node | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Bimal Chollera
2016-09-28 00:48:44 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` 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. |