freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Freeipmi-devel] sun20 workaround doesn't


From: Al Chu
Subject: Re: [Freeipmi-devel] sun20 workaround doesn't
Date: Tue, 09 Jun 2009 16:13:52 -0700

Hey Dave,

Whew, I'm glad I have a relatively new sun board, this would have been
tough to figure out :-)

Effectively, the "opensesspriv" workaround is also needed for the Sun
boards.  I've wrapped that workaround in as an automatic one for the Sun
workaround, so it should work now.  Test tar.gz is here:

http://ftp.zresearch.com/pub/freeipmi/qa-release/freeipmi-0.7.10.beta2.tar.gz

It ends up I didn't see it before b/c the problem doesn't exist if you
default to the "admin" privilege level.  Some tools (such as bmc-info)
don't default to that.

Could you let me know if it works?  Thanks.

Al

On Tue, 2009-06-09 at 10:31 -0700, Al Chu wrote:
> Hey Dave,
> 
> > OK, appended.
> 
> Hmmm.  It seems the workaround just isn't working.  It's possible I have
> introduced a bug into the workaround.  Let me see if I can figure it
> out.
> 
> > I didn't mean to be critical, of course.  However, I find it's a real
> > practical problem with our heterogeneous HPC systems, and I guess I'm
> > not alone.  I notice there's a TODO item addressing workarounds per
> > host.  Is it clear what's involved if I give it a go?
> 
> Hehe.  It's funny you mention this.  I had a request/comment on this
> topic just last week.  First, please take a look at my original post on
> this for what I was thinking of supporting:
> 
> http:// www. mail-archive.com/address@hidden/msg00710.html
> 
> The work involved is somewhat deep (that I've naturally been putting
> off, but it is now higher priority b/c it came as a request from someone
> internal to my organization).  As far as I can tell, it would take:
> 
> A) re-work a lot of the config file parsing code to be able to take an
> additional argument.  Based on other people's requests, this would be
> for all the config file options.  It could be made easier if instead of
> modifying all config file options to take the additional argument, we
> made new config file options, like:
> 
> # default for all systems
> workaround intel20
> # default for some spsecific systems
> workaround-hosts node[0-11] sun20
> 
> I haven't decided which I will do at this moment.
> 
> B) modifying the tools to override it's defaults + the config file
> defaults w/ the host specific defaults.  This will require a fair amount
> of re-architecture b/c host-specific defaults need to be stored/passed
> around/parsed "deeper" into the hostrange code.
> 
> Al
> 
> On Tue, 2009-06-09 at 10:43 +0100, Dave Love wrote:
> > Al Chu <address@hidden> writes:
> > 
> > > Hey Dave,
> > >
> > > It's entirely possible there is another issue for your systems I never
> > > encountered before or a bug in the workaround code.  If you could send
> > > the --debug output, that'd be great.
> > 
> > OK, appended.
> > 
> > > Ipmitool also elects to "hide"
> > > workarounds in its tools more often, instead of making the user put them
> > > on the command line.  Pros and cons of both approaches, I don't think
> > > either of us is right or wrong.
> > 
> > I didn't mean to be critical, of course.  However, I find it's a real
> > practical problem with our heterogeneous HPC systems, and I guess I'm
> > not alone.  I notice there's a TODO item addressing workarounds per
> > host.  Is it clear what's involved if I give it a go?
> > 
-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory





reply via email to

[Prev in Thread] Current Thread [Next in Thread]