On Fri, 2008-05-02 at 12:09 -0700, Carol Hebert wrote: > On Thu, 2008-05-01 at 18:54 -0700, Al Chu wrote: > > Hey Carol, > > > > > I might be missing something here. But how would the watchdog commands > > be any more dangerous than ipmi commands for a power cycle or changing > > boot configuration? Is the feeling a user would have a greater > > likelihood of not knowing how to properly use it? > > > > > The code this patch replaces was not in any released version of ipmitool > > > nor was it complete/ready, so we wouldn't be eliminating functionality > > > that folks are generally using now > > > > Understood. Functionally the patch is fine. My comments are more of a > > general "design" comment. > > > > Al > > > > Hi Al, > > I believe the concerns are pretty much what they were in our discussions > on the topic last May (the discussions are in the mailing list archives > for 5/23/07 and 5/24/07 I think).
Hey Carol, > Concerns went beyond that of a remote user unintentionally wreaking > havoc (although that was brought up ;-}. One main issue is that the > watchdog timer is simply not safe to be used in the remote manner > suggested -- that resetting the timer remotely is unreliable. I agree that it's not safe to be used remotely. So instead of eliminating the set watchdog command, how about just not allowing it to be run when the interface is 'lan' or 'lan20'?? Just my 2 cents. Al > If what's > desired is a way to simply reset a box remotely, then the chassis power > commands should be used instead (and they're mandatory). > > Some folks said that some (old/noncompliant) boxes didn't support these > mandatory chassis power commands and so there was no alternative method > to reset a box remotely other than to use the watchdog. The suggestions > made in our earlier discussion were that this type of noncompliant > implementation should be discussed with the vendor for resolution and/or > that there should be OEM commands that could be used. > > However, if this is still an issue, here's an alternate idea: Maybe we > could also add a "watchdog powercycle" command? It would be obvious by > the name what it would do so there should be no cockpit surprises. We > could set the timeout to be 0 (immediate powercycle) or even include an > optional <time> field although adding this could make the powercycle > less reliable since it could be stopped. We'd probably also have to > check to see if the timer was already running on the system and, if so, > fail out (suggest they run "watchdog off" first maybe). So there would > be no remote watchdog "poke" expected (although the "watchdog reset" > command in my patch would do that if desired). > > Anyway, just an idea -- I haven't investigated whether there may be any > gotchas yet. Given how folks feel about the watchdog, I thought I'd > throw the idea out first to see if folks thought it would be worth > pursuing. > > Any comments pro/con on any of this? > > Thanks very much, > > Carol > > > > > -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
