Re: [Freeipmi-devel] FreeIPMI on unsupported Box

[Al Chu]

Hey Ricky,

On Thu, 2009-05-21 at 02:29 +0800, Ricky James Allam wrote:
> Hi Al,
> 
> On Thu, May 21, 2009 at 1:08 AM, Al Chu <address@hidden> wrote:
> > Hi Ricky,
> >
> > The problem you describe is indeed a problem.  Starting in FreeIPMI
> > 0.5.1 the KCS and OpenIPMI drivers would timeout after a while if inband
> > IPMI doesn't work.  That solved the issue for system administrators here
> > locally at LLNL [1].
> >
> > But of course, that just leads to needless spinning until the timeout.
> > I think you're looking for a more immediate answer for the user.  The
> > tough part about this is that not all systems report/store IPMI support
> > in dmidecode/smbios.  At the very end of the "discovery" phase, if it
> > cannot find IPMI, it will still try to use IPMI default values.
> >
> > Here's an idea.  How about an option like "--fail-if-ipmi-not-detected".
> > There would be an option in the freeipmi.conf file too, so it can be
> > defaulted to be on.  That way, if IPMI is not detected, the tool can
> > automatically fail out and report something like "IPMI in-band driver
> > not found".
> >
> > Sound like a good idea?
> 
> This sounds a good solution, so it can be set under the general options?

Yup, that would be the idea.

> However, one would still need to know when to default that as on, and
> the config file would differ from one machine to another.

That would be the downfall :-(

> What if the scenario is, the tool is integrated in an application that one
> would just need to install it and use it without having the need to
> look into the configs?

Ahhh.  I didn't think of that scenario.  Hmmmm.

I looked at the Linux IPMI kernel driver real quick.  It seems it
"solves" this problem doing some IPMI during driver initialization, so
it will fail out at some point if there's no response (thus the driver
won't load).

> Please do let me know if I misunderstood what you mean.

Nope, I think we're on the same page.

> I would be
> glad to try the solution you have mentioned, and if there are other
> good idea, please shed more.

Well, here's an idea.  It seems that you're using the default FreeIPMI
KCS in-band driver.  If there is an alternate driver available for BSD
(I don't know if there is) that's like the Linux IPMI kernel driver, you
can "dump" IPMI detection upon it.  Then you can configure FreeIPMI to
always work off that driver.  By the time your software runs, the OS
should have already decided if IPMI is available or not, and FreeIPMI
tools will run/fail appropriately???

Another idea.  It seems that you are doing a distribution of some
monitoring software + FreeIPMI at your organization??  I really can't
make it a default behavior to "fail out if you can't detect IPMI", but I
could perhaps make it a compile option?  That way you could build a
FreeIPMI that behaves this way for your organization?

Those are just some other ideas.  I think "--fail-if-ipmi-not-detected"
and the build-option above are both decent ideas, so I might implement
both anyways.  Would these work for you?

Al

> >
> > Al
> >
> > [1] - It was actually for BMC daughter cards that died, so a process
> > might spin forever not being able to do inband IPMI.  But same idea ...
> >
> > On Wed, 2009-05-20 at 15:30 +0800, Ricky James Allam wrote:
> >> Hello,
> >>
> >> I've been using FreeIPMI on several boxes (HP, IBM, and some others).
> >> On IPMI-unsupported boxes, the tools are unresponsive without any
> >> message at all. I've made the following ugly function to simply exit
> >> if the board is not IPMI compliant inserting it in one of the tools,
> >> and displays such useful message like below. While administrators
> >> should know when to use this package, it is advantageous too to have a
> >> similar mechanism especially when the package is integrated in an
> >> application that could run on any platform. Is there a better way to
> >> do this?
> >> Pls do let me know.
> >>
> >> Example,
> >>
> >> fbsd71r-rjavm64# uname -a
> >> FreeBSD fbsd71r-rjavm64 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan  1
> >> 08:58:24 UTC 2009
> >> address@hidden:/usr/obj/usr/src/sys/GENERIC  amd64
> >>
> >>
> >> In bmc-watchdog.c,
> >>
> >> ...
> >> /*
> >> 0: supported
> >> 1: unsuported
> >> */
> >>
> >> static int
> >> is_ipmi_not_supported()
> >> {
> >>   int ret = 0;
> >>   ret = system("/usr/local/sbin/dmidecode | /usr/bin/grep IPMI");
> >>   return ret;
> >> }
> >> ...
> >>
> >> int
> >> main(int argc, char **argv)
> >> {
> >>   _err_init(argv[0]);
> >>
> >>   if(is_ipmi_not_supported());
> >>   {
> >>     printf("IPMI is not supported on this machine. bmc-watchdog 
> >> exiting...\n
> >>     exit(1);
> >>   }
> >>
> >>   ipmi_disable_coredump();
> >>
> >> ...
> >> }
> >>
> >> Thank you very much.
> >>
> >> Ricky James Allam
> >>
> >>
> >> _______________________________________________
> >> Freeipmi-devel mailing list
> >> address@hidden
> >> http://  lists.gnu.org/mailman/listinfo/freeipmi-devel
> >>
> > --
> > Albert Chu
> > address@hidden
> > Computer Scientist
> > High Performance Systems Division
> > Lawrence Livermore National Laboratory
> >
> >
> 
> Thanks,
> 
> Ricky
> 
-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory