Dan,
Corey's opeipmi is a good option. He has done a really good job.
hank bruning
On Mon, Oct 29, 2012 at 5:39 PM, Andy Cress <andy.cr...@us.kontron.com>wrote:
> Dan,****
>
> ** **
>
> For discovery, I have a bit of code that uses RMCP ping, or alternatively
> GetChanAuthCap packets to discover some systems that don’t answer pings
> reliably. See
> http://ipmiutil.svn.sourceforge.net/viewvc/ipmiutil/trunk/util/idiscover.c?revision=269
> ****
>
> ** **
>
> To gather all the ipmi data from a system, I have a ‘grab’ script that we
> use to gather that for support purposes, but it also has lots of other
> stuff in it for BIOS data, storage configuration, etc., etc.****
>
> ** **
>
> Andy****
>
> ** **
>
> *From:* ^..^ [mailto:zenf...@gmail.com]
> *Sent:* Monday, October 29, 2012 3:26 PM
> *To:* Hank Bruning
> *Cc:* ipmitool-devel@lists.sourceforge.net
> *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****
>
> ** **
>
> ** **
>
> WARNING - This e-mail or its attachments may contain controlled technical
> data or controlled technology within the definition of the International
> Traffic in Arms Regulations (ITAR) or Export Administration Regulations
> (EAR), and are subject to the export control laws of the U.S. Government.
> Transfer of this data or technology by any means to a foreign person,
> whether in the United States or abroad, without an export license or other
> approval from the U.S. Government, is prohibited. The information contained
> in this document is CONFIDENTIAL and property of Kontron. Any unauthorized
> review, use, disclosure or distribution is prohibited without express
> written consent of Kontron. If you are not the intended recipient, please
> contact the sender and destroy all copies of the original message and
> enclosed attachments.
>
------------------------------------------------------------------------------
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
