Thanks for the pointer (and for further encouragement, hank)… the documentation is … well, it is what it is (to their credit they've put together some great other-than-openipmi info on IPMI itself, I'll note, and the code even has comments that are useful, how unusual.)
So based on what you and hank said I went back and took another look… their perl example program doesn't even work, the python one has me installing many packages before I even get to test it (it too ultimately failed, once I had the dependencies all installed). I can probably spend a bit more time and finally get it to work… but it didn't work on ubuntu and centos/red hat out of the box (and it also doesn't support the mac). This doesn't bode well if I ever want my own tool to see any use; dependencies suck. If you want to get people to use your stuff make it simple and well documented, which is just what you folks have done both with ipmitool; it just works, and works well (I've used ipmiutil pretty extensively and it's a great tool, but it doesn't work on the mac either, and doesn't seem to offer any game-winning additional benefits that I can see on linux.) As you said about openipmi "unfortunately, it's not so well documented, and its really not a tool designed to be run from scripts. It's really designed for software that does continuous real-time monitoring of systems." So perhaps I'll just be a happy user at the /dev layer. In sum ipmitool still seems the winner for my needs, at least. I applaud the intellectual generousness of all you ipmitool devs and friends-o-ipmitool trying to convince me not to use it ;) As a once-in-awhile auditing tool performance isn't really much of an issue; the data and results are far more important than speedy delivery. dan p.s. All IMHO, and subject to change and capriciousness. I might be cursing your tool soon enough, but so far so good! ^..^ On Oct 29, 2012, at 1:26 PM, Corey Minyard <tcminy...@gmail.com> wrote: > openipmi may do what you want. It's really more of a programming API, and it > has C, perl and python interfaces. You can dump pretty much anything you > want; an unbelievable amount of information. There is sample code in all > languages, a GUI written in python, and a command-line interface written in C. > > It should be a lot faster than ipmitool for this particular job because it's > not making a connection for each thing you dump. > > Unfortunately, it's not so well documented, and its really not a tool > designed to be run from scripts. It's really designed for software that does > continuous real-time monitoring of systems. It's also event-driven, and if > you haven't done event-driven programming it can be a little hard to wrap > your head around it. > > -corey > > On 10/29/2012 10:24 AM, ^..^ wrote: >> >> Hey folks - first, thanks for a tremendous tool and all the effort put into >> this over the years (the documentation is really stellar as well, something >> that is both rare and apparently under-appreciated in open source.) I've a >> couple of questions that I hope are suited this venue; if not please forgive >> me, and if you could suggest a better forum I'd appreciate it. >> >> I'm doing a bit of research on IPMI and BMC security (more like IPMI++, >> since I'm doing work with some of the various offshoots; iDRAC, iLO, etc.) >> Currently I'm pulling various bits of data from the IPMI interface - ideally >> I'd like to *remotely* get as much as possible about the configuration and >> state of the BMC and IPMI configuration, and I plan to use your tool along >> with nmap, SMASH/CLP (don't laugh too much, at least its modestly cross >> platform ;)), and some duct tape and bailing wire to gather data. Think of >> it more as a snapshot or audit effort rather than any sort of continuous >> monitoring. >> >> Q-1) I'm familiar with the nagios and other folks who are all about >> gathering BMC sensor data… but I can't find a general IPMI data sucker (e.g. >> get all the stuff that ipmitool will get me in one fell swoop, even though >> under the hood it might be doing lots of queries) anywhere; has anyone >> written such a thing? (It'd have to be non-commercial, or at least free to >> distribute.) >> >> [meta note: the README file in the contrib subdirectory has a broken url: >> http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/ >> <http://people.ee.ethz.ch/%7Eoetiker/webtools/rrdtool/> - seems as though >> the user moved on. As such one can't see any sample output to the scripts or >> what they really collect without perusing the source or hunting around. In >> particular the file "oem_ibm_sel_map" is pretty opaque and not referenced by >> anything but the makefile in the contrib… is this used anywhere except in >> comments (and if so, a one-liner somewhere explaining would be great)? :) ] >> >> >> Q-2) In the absence of someone else having something I can steal, my current >> thought would be to simply toss all the various ipmitool gathering options >> (e.g. fru, sel, pef, etc.) in a file, exec them all, and stash the resultsin >> something like JSON for safekeeping and post-processing. So again… has >> anyone done anything like this? Assuming that what I'm looking is all that >> data, even if you think I'm foolish wanting it, is that a reasonable way to >> collect it? It'd be great to have any tricks or tips. (Size of output is not >> an issue. Heck, I'd snarf up BMC flash storage and RAM as well, if I could >> find a reasonable way of doing so remotely!) I'd be happy to share >> pre-distributed versions if anyone is burning with curiosity, has a use for >> such a thing, or would be willing to discuss various ways to build a better >> mousetrap. >> >> Q-3) Finally - I'm writing up a bit of an analysis on IPMI/BMC/++ security; >> if there is a person or two here who are interested in such things I would >> love a real IPMI expert to give feedback (I'm not an IPMI expert by any >> stretch of the imagination, though I might have some unusual thoughts on >> IPMI security); I'll just say as a warning I'll be asking for no one to >> redistribute it prior to my putting it out, which will hopefully be in about >> 30-60 days or so. >> >> Thanks again (mac support in particular is greatly appreciated as well.) >> >> dan >> >> p.s. Also - if anyone has any thoughts or scripts or tools or anything on >> how to remotely identify systems running IPMI I've yet another simple tool >> to start doing this (obviously if they answer to an RMCP ping that's a win, >> but I'm talking about on a larger network scale where firewalls and network >> topologies), and would welcome any conversations on that also. >> >> p.p.s. For context some of my earlier work may be found at >> http://fish2.com/security >> >> ^..^ >> >> >> >> ------------------------------------------------------------------------------ >> The Windows 8 Center - In partnership with Sourceforge >> Your idea - your app - 30 days. >> Get started! >> http://windows8center.sourceforge.net/ >> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ >> >> >> _______________________________________________ >> Ipmitool-devel mailing list >> Ipmitool-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel > ------------------------------------------------------------------------------ The Windows 8 Center - In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
