On Thu, 2006-01-26 at 15:25 -0500, Brian A. Seklecki wrote: > Regarding the future of IPMI and SNMP, where do they intersect > in the evolution of enterprise free software (aka, BSD) ?
Hmmmm... IPMI isn't something that I've really looked at, so take the following with a generous pinch of salt. But from a quick browse, I think they are complementary technologies. The fundamental role of SNMP is to report and/or update various bits of management information. How that information is retrieved from the underlying system is irrelevant - SNMP and the management console don't care. > What about more-practicle examples of IPMI -> Net-SNMP integration. The obvious role for IPMI is in providing a mechanism for the agent to retrieve such management information. But this part of the agent internals - it shouldn't be visible from outside. The management console doesn't really care whether the agent uses IPMI to report what's happening, delving into the running kernel, or seeking divine inspiration. If SNMP provides the information, that's all that matters. > (an OID tree would need to be assigned to IPMI?) That feels the wrong approach, IMO. Bruce has already mentioned the LM-SENSORS-MIB, which was developed with a particular sensor in mind, and he's been struggling with the limitations of this. IPMI seems to be rather more general in aim, but an IPMI-MIB would still run the risk of being too specific, IMHO. > Two [examples] come to mind: Platform independent environmental sensor > data and chassis information. My advice would be to look at using the existing "Entity Sensor MIB" (RFC 3433) for the first, and view IPMI as the preferred mechanism for populating this. I believe that this MIB should be flexible enough to cope with most of the examples you list. Chassis information (IIUC) is very much the purpose of the "Entity MIB" (RFC 4133). So that would be the obvious way to report the physical configuration of a system. Though I'd probably suggest starting simply, and just concentrate on the physical group to begin with. That might also help Bruce's problems with the existing sensor reporting. Dave ------------------------------------------------------- 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
