Great little program, thanks! I would love to see the grab script if you can
send; every byte is sacred, I say ;) If there are things in it that really
aren't appropriate I can remove them (<3 BIOS data, though.)
dan
^..^
On Oct 29, 2012, at 2: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
