Re: Problems with resolving MIB names/enums

Gandalf <[email protected]> Thu, 26 Apr 2012 19:55:41 +0200
Newsgroups	gmane.network.cacti.user
Message-ID	<[email protected]>
Hmm,

my findings are different. This is F16 using php 5.3.10 and net-snmp 5.7.1

By default, Cacti uses php-snmp. You can force it to use net-snmp by either
uninstalling php-snmp or changing lib/snmp.php function snmp_get_method.

My finding when using php-snmp is, that enumerated values are both displayed
with string and numeric value, in your case "ambient(11)".
When using net-snmp, display is governed by "-O" option. Cacti uses "-O Qn",
which suppresses the string values for enumerated OIDs, resulting in "11".
Omitting the "Q" will produce an output very similar to the output of php-snmp.
See "man snmpcmd" to find the meaning of the "-O" options.

So discussion is,
- whether net-snmp should be used without "-O Q" to get results similar to php-snmp
- or we should configure the option to use "-O Q" via a global setting
- and then struggle with the problem, that php-snmp does not have an equivalent
to "-O Q" in case users WANT TO SUPPRESS

Reinhard

On 26.04.2012 10:06, [email protected] wrote:
> Hello Gandalf,
> 
> I dug a bit and found the solution - at least for the version Ubuntu ships 
> with Lucid.
> cacti uses php-snmp by default, which has only few options for (selective) 
> use of MIBs and cacti disables them. If you force it to use the external 
> net-snmp, you get the enums resolved:
> 
> + Executing SNMP walk for data @ '.1.3.6.1.4.1.232.6.2.6.8.1.3'
> + Found item [hpHealthTempLocale='ambient'] index: 1.1 [from value]
> + Found item [hpHealthTempLocale='cpu'] index: 1.2 [from value]
> + Found item [hpHealthTempLocale='memory'] index: 1.4 [from value]
> + Found item [hpHealthTempLocale='memory'] index: 1.5 [from value]
> + Found item [hpHealthTempLocale='memory'] index: 1.6 [from value]
> + Found item [hpHealthTempLocale='memory'] index: 1.7 [from value]
> + Found item [hpHealthTempLocale='memory'] index: 1.9 [from value]
> + Found item [hpHealthTempLocale='memory'] index: 1.11 [from value]
> + Found item [hpHealthTempLocale='powerSupply'] index: 1.12 [from value]
> + Found item [hpHealthTempLocale='powerSupply'] index: 1.13 [from value]
> + Found item [hpHealthTempLocale='memory'] index: 1.14 [from value]
> + Found item [hpHealthTempLocale='cpu'] index: 1.15 [from value]
> + Found item [hpHealthTempLocale='cpu'] index: 1.16 [from value]
> + Found item [hpHealthTempLocale='memory'] index: 1.17 [from value]
> + Found item [hpHealthTempLocale='cpu'] index: 1.18 [from value]
> + Found item [hpHealthTempLocale='system'] index: 1.19 [from value]
> + Found item [hpHealthTempLocale='system'] index: 1.20 [from value]
> + Found item [hpHealthTempLocale='system'] index: 1.21 [from value]
> + Found item [hpHealthTempLocale='system'] index: 1.22 [from value]
> + Found item [hpHealthTempLocale='system'] index: 1.23 [from value]
> + Found item [hpHealthTempLocale='system'] index: 1.24 [from value]
> + Found item [hpHealthTempLocale='system'] index: 1.25 [from value]
> + Found item [hpHealthTempLocale='system'] index: 1.26 [from value]
> + Found item [hpHealthTempLocale='storage'] index: 1.27 [from value]
> + Found item [hpHealthTempLocale='system'] index: 1.28 [from value] 
> 
> 
> 
> 
> From:
> Gandalf <[email protected]>
> To:
> Support requests/questions about cacti <[email protected]>
> Date:
> 25.04.2012 20:29
> Subject:
> Re: [cacti-user] Problems with resolving MIB names/enums
> 
> 
> 
> The name resolving via MIBs rely on
> - the MIBs
> - the MIB PATH they are living in
> - the way snmpwalk is used (suppressing the replacement of numbers by 
> their
> meaning or not)
> 
> In general, Cacti does not use any MIBs explicitely. And currently, we do 
> not
> provide means to provide those strings. This will change in future 
> versions of
> Cacti; the code is already there. But then, you will have to use an 
> explicit
> rewrite function that has to be defined within the XML file.
> 
>>From time to time we receive request to replace those numbers with 
> strings
> automatically and then, a few days later, we usually receive the opposite
> request by different users. So, from our point of view, providing an 
> optional
> rewrite function will provide maximum flexibility
> Reinhard
> 
> On 25.04.2012 12:00, [email protected] wrote:
>> Hello List, 
>>
>> I'm trying to use the Proliant templates from the forum (
>> http://forums.cacti.net/viewtopic.php?f=12&t=20298&hilit=proliant) to 
>> monitor the temperature of a few servers. 
>>
>> The Data Query XML seems to rely on cacti resolving the temperature 
> sensor 
>> names correctly - this seems to be a problem on my installation (0.8.7e 
>> from ubuntu lucid) 
>>
>> MIBS are installed and activated correctly. a manual snmpwalk works 
>> correctly: 
>> $ snmpwalk -v2c -c cmt host .1.3.6.1.4.1.232.6.2.6.8.1.3 
>> ... ignore a few warnings 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.1 = INTEGER: ambient(11) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.2 = INTEGER: cpu(6) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.4 = INTEGER: memory(7) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.5 = INTEGER: memory(7) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.6 = INTEGER: memory(7) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.7 = INTEGER: memory(7) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.9 = INTEGER: memory(7) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.11 = INTEGER: memory(7) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.12 = INTEGER: powerSupply(10) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.13 = INTEGER: powerSupply(10) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.14 = INTEGER: memory(7) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.15 = INTEGER: cpu(6) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.16 = INTEGER: cpu(6) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.17 = INTEGER: memory(7) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.18 = INTEGER: cpu(6) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.19 = INTEGER: system(3) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.20 = INTEGER: system(3) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.21 = INTEGER: system(3) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.22 = INTEGER: system(3) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.23 = INTEGER: system(3) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.24 = INTEGER: system(3) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.25 = INTEGER: system(3) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.26 = INTEGER: system(3) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.27 = INTEGER: storage(8) 
>> CPQHLTH-MIB::cpqHeTemperatureLocale.1.28 = INTEGER: system(3) 
>>
>> but the data query only gets the index ID, not the friendly names: 
>> + Executing SNMP walk for data @ '.1.3.6.1.4.1.232.6.2.6.8.1.3'
>> + Found item [hpHealthTempLocale='11'] index: 1.1 [from value]
>> + Found item [hpHealthTempLocale='6'] index: 1.2 [from value]
>> + Found item [hpHealthTempLocale='7'] index: 1.4 [from value]
>> + Found item [hpHealthTempLocale='7'] index: 1.5 [from value]
>> + Found item [hpHealthTempLocale='7'] index: 1.6 [from value]
>> + Found item [hpHealthTempLocale='7'] index: 1.7 [from value]
>> + Found item [hpHealthTempLocale='7'] index: 1.9 [from value]
>> + Found item [hpHealthTempLocale='7'] index: 1.11 [from value]
>> + Found item [hpHealthTempLocale='10'] index: 1.12 [from value]
>> + Found item [hpHealthTempLocale='10'] index: 1.13 [from value]
>> + Found item [hpHealthTempLocale='7'] index: 1.14 [from value]
>> + Found item [hpHealthTempLocale='6'] index: 1.15 [from value]
>> + Found item [hpHealthTempLocale='6'] index: 1.16 [from value]
>> + Found item [hpHealthTempLocale='7'] index: 1.17 [from value]
>> + Found item [hpHealthTempLocale='6'] index: 1.18 [from value]
>> + Found item [hpHealthTempLocale='3'] index: 1.19 [from value]
>> + Found item [hpHealthTempLocale='3'] index: 1.20 [from value]
>> + Found item [hpHealthTempLocale='3'] index: 1.21 [from value]
>> + Found item [hpHealthTempLocale='3'] index: 1.22 [from value]
>> + Found item [hpHealthTempLocale='3'] index: 1.23 [from value]
>> + Found item [hpHealthTempLocale='3'] index: 1.24 [from value]
>> + Found item [hpHealthTempLocale='3'] index: 1.25 [from value]
>> + Found item [hpHealthTempLocale='3'] index: 1.26 [from value]
>> + Found item [hpHealthTempLocale='8'] index: 1.27 [from value]
>> + Found item [hpHealthTempLocale='3'] index: 1.28 [from value] 
>>
>> As those new HP servers really have a lot of sensors, I'm a bit 
> unwilling 
>> of having to rename every sensor. I searched the forum and it seems MIB 
>> resolving only works for some users, but no solution for those where it 
>> doesn't work. Can anybody help? As mentioned before, MIBs are installed, 
> 
>> active (via snmp.conf) and commandline snmpwalk resolves them correctly 
>> and without any extra arguments - just cacti doesn't get them. 
>>
>> Mit freundlichen Grüßen / Best regards,
>>
>> Heiko Helmle
>> Software Development
>> _______________________________________________________
>> HORIBA Europe Automation Division GmbH
>> Zabergäustr. 3
>> 73765 Neuhausen (Germany)
>> Phone:   +49 7158-933-415
>> Fax:         +49 7158-933-615
>> E-mail:    [email protected]
>> www:        http://www.ats.horiba.com
>> Geschäftsführer: Thomas E. Ehmann, Hiroshi Kawamura, Takashi Nagano
>> Amtsgericht Stuttgart, HRB 213200
>>
> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and 
>> threat landscape has changed and how IT managers can respond. 
> Discussions 
>> will include endpoint security, mobile security and the latest in 
> malware 
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> cacti-user mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/cacti-user
>>
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> cacti-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/cacti-user
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> cacti-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/cacti-user
> 

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/