Are we talking mass collection of ipmi data with respect to type of IPMI data, number of IPMI elements aggregated into one thing, or data as it changes over time? For example, the hardware management piece of xCAT does many-server ipmi data gathering in one swoop, but generally feeds into something like rrdtool for things like fan tach or temperature over time.
For discovery, your best bets of getting an enumeration of IPMI devices on a network, your likely set of tools would be: -SLP multicasts. Here you'd have to recognize the fingerprint of various vendor SLP attributes that implement IPMI. xCAT's slpdiscover.pm recognizes IBM systems as an example, and tries to place them relative to some infrastructure equipment like switches or chassis management modules. -RMCP ping pong against a set of candidate addresses identified by multicast/broadcast ipcm echo request. Generally the IPv6 ones will *tend* to fare better at appearing as a candidate on this list. Obviously, the SLP approach is going to be a lot more robust when available. All these tend to be fickle, require same-subnet topology, and are likely to miss things (particularly in large subnets where the previous-responder list in SLP cannot fit a substantial fraction of the BMCs). For security, when used correctly, IPMI has very strong security characteristics. The challenges I see are: -IPMI cipher suite 0 should never have existed. Most do not realize that you do not even need to know the password to get into an IPMI device that allows cipher suite 0. -Default remote credentials. Less risky so long as the user knows what they are doing, but it does prevent security concious companies from doing things like allowing IPMI access over a shared port by default for fear of customers not understanding the implications of management connecting devices. In such a configuration, you have to start the deployment process in-band and no amount of remote discovery to initiate through BMC will work. One not well known benefit is that both client and server may authenticate each other. The implication isn't immediately obvious to some, but if the BMC doesn't know the password, a strict client implementation can detect this and refuse to communicate. (e.g. xCAT requires a patch to work with some older IPMI devices that did *not* do this mutual authentication, but usually requires the management processor pass). One controversial downside is that in order to accomplish the mutual authentication, the 'password' must be stored in the clear on the BMC persistent storage. This downside can be completely eliminated through use of machine-specific credentials (e.g. xCAT has a mode to autogenerate such secrets), but most people get reluctant to do that because they want consistent login data when they manually run ipmitool and use cli or web interfaces and use some other management software and its hard to leave xCAT out of it if xCAT is generating random passwords for everything. I personally tihnk the best answer for that is LDAP optionally with Kerberos for things like SSH and HTTPs for that sort of access and letting software like xCAT manage the locally stored IPMI secrets. From: "^..^" <zenf...@gmail.com> To: Hank Bruning <h...@jblade.com>, Cc: ipmitool-devel@lists.sourceforge.net Date: 10/29/2012 03:27 PM Subject: Re: [Ipmitool-devel] scriptasaurus rex Thanks for the response… if I understand the licensing of Hemi it's a commercial product ( http://www.jblade.com/products/hemi/license/HemiLicenseOverview.jsf), which immediately counts it out (not to mention I wouldn't be caught dead using java, but I might make an exception for extreme circumstances ;)) since I can't redistribute it. I'm fine writing it myself, I simply didn't want to reinvent anything. Also, I don't need something to RMCP ping something; as I said that's an obvious win, and I'm looking at other methods of IPMI discovery. Think discovery in broad terms; knowing an IPMI server is there even if you can't communicate over UDP 623 is still very interesting. dan ^..^ On Oct 29, 2012, at 11:53 AM, Hank Bruning <h...@jblade.com> wrote: I don't know if this meets your requirements but if you want to replace IPMITool with an Java IPMI library take a look at Hemi. It's well documented, over 475 pages for the JavaDoc. http://www.jblade.com/products/hemi/HemiOverview.jsf I think you want the Hemi DC version. The RMCP Ping methods your after are at found at http://www.jblade.com/JbDoc1/products/hemi/hemiCX/doc/programmers/HemiDiscoverer.html Hank Bruning On Mon, Oct 29, 2012 at 11:24 AM, ^..^ <zenf...@gmail.com> 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/ - 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
<<inline: graycol.gif>>
------------------------------------------------------------------------------ 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
