All:
Regarding the future of IPMI and SNMP, where do they intersect in the
evolution of enterprise free software (aka, BSD) ?
Specifically, the OpenBSD implementation we're seeing here seems to
provide sysctl style access to Sensor data, watchdog info, etc., but what
about other IPMI functions?
For those, you still need the ipmitool(8) from Sourceforge. A kernel
interface is nice, but "ipmitool -H 1.2.3.4 chassis reset" or "off" are
obviously beyond the scope of this implementation.
The problem is that the data is useless unless you can collect using
something like SNMP. From there you can feed to MRTG for simple graphing,
SNMP Traps for from the agent for events (case intrusion detection, etc.)
Perl modules for data archiving, etc.
What about more-practicle examples of IPMI -> Net-SNMP integration. Two
come to mind: Platform independent environmental sensor data and chassis
information. The latter isn't available via the kernel on any OS that I
know of, and the former isnt unified (various ways of talking to W83781D,
W83782D, W83783S, LM78, LM79 and the AS99127F) chips. But IPMI, could
standardize that.
For example, the ipmitool(8) values of "chassis status" or "sensor":
$ ipmitool -E sensor
[temperature, fans, voltages ommited]
Then 4 or 5 values that you simply cannot get from ISA based environmental
ICs are available:
OS Watchdog|0x0|discrete|0x0080|na|na|na|na|na|na
SEL
Intrusion
PSRedundancy
FanRedundancy
Also, these aren't showing up in my hardware, but:
Error reading sensor PCI Parity Err (#04)
Error reading sensor PCI System Err (#05)
Error reading sensor SCSI Connector A (#02)
Error reading sensor Drive (#01)
Error reading sensor ECC Corr Err (#01)
Error reading sensor ECC Uncorr Err (#02
Error reading sensor Memory Mirrored (#12)
Error reading sensor Memory RAID (#13)
Error reading sensor Memory Added (#14)
Error reading sensor Memory Removed (#15)
If that information was populated, that would be very exciting (For
example, Drive failure notificat via IPMI? Perhaps in RAID?)
Also:
$ ipmitool -E chassis status
System Power : on
Power Overload : false
Power Interlock : inactive
Main Power Fault : false
Power Control Fault : false
Power Restore Policy : always-off
Last Power Event :
Chassis Intrusion : inactive
Front-Panel Lockout : inactive
Drive Fault : false
Cooling/Fan Fault : false
Sleep Button Disable : allowed
Diag Button Disable : allowed
Reset Button Disable : allowed
Power Button Disable : allowed
Sleep Button Disabled: true
Diag Button Disabled : true
Reset Button Disabled: true
Power Button Disabled: true
It would be extremely useful to be able to map these values directly into
a Net-SNMP MIB's values as booleans then use "defaultMonitor" /
DISMAN-EVENT-MIB for the event-style bits and other integers for the
traditional sensor data (fan RPMs, thermometer).
In the mean time, it maybe possible to use Net-SNMP's built in Perl
support to read sysctl(2) data from OpenBSD and parse the output of
ipmitool(8) (ipmitool(8) has a "-c" flag to CSV output, but it doesn't
seem to work in combination with the 'sensor' command -- suks) on other
BSD's, but I'm not sure how that process would begin (an OID tree would
need to be assigned to IPMI?)
~BAS
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
