Re: [Freeipmi-devel] IPMI power control utility description

[Albert Chu]

Hey AB,

> Question:
> Should ipmipower be maintained a separate utility apart from fish?

Initially, I would say it should be separate for several reasons
(which I'll discuss below).  I think it would be best to integrate into
fish at a later time, if ipmipower evolves into something that can be
easily integrated.

> Fish provides an interactive command interface and scheme based
> scripting interface.
>
> Question:
> How important it is to have additional command-line interface apart
> from the above two interfaces?

When dealing specifically with power control, my opinion is that most
users would be far more interested in a command line interface rather
than an interactive command interface.  The reason for this is:

A) The command line interface gives users the ability to script power
control commands seemlessly into their current (i.e. perl) scripts.

B) The command line interface is more natural and intuitive for users.
   For example:

   command line:

   >ipmipower -h node1,node2,node3 --reset
   node1: ok
   node2: ok
   node3: ok
   >

   interactive prompt:

   >ipmipower -h node1,node2,node3
   ipmipower> reset
   node1: ok
   node2: ok
   node3: ok
   ipmipower> quit
   >

   The difference in minimal, but I think the former is far more
   natural.  Its what users expect.  This is one reason I think
   ipmipower should be separate from fish, atleast initially.

Atleast with ipmipower, I believe that very few people would ever
want to use the interactive command prompt.  The interactie mode was
implemented primarily so that it can operate with powerman.

> Much of my time is spent only in this area. Though I have working code
> already, I want to abstract all these details in to the framework
> itself (mostly into libfreeipmi). I'm foreseeing lot of trouble in
> this area like you do. UDP is stateless, but that also invites
> trouble. Remember the other end of connection is a dumb BMC firmware
> and not enterprise class management agent software.

This is another reason why I think ipmipower should be separate from
fish initially.  I've encountered a number of "funny issues" when
dealing with power control with the BMC.  I'm afraid of these issues
coming up if we integrate ipmipower into fish, and due to the
abstraction between fish and libfreeipmi, we won't be able to handle
the issues (cleanly atleast).

By the way, since I'm on this topic, perhaps you've discovered better
ways to handle some "funny issues" I've encountered.

When trying to establish a session using "Get Authentication
Capabilities", "Get Session Challenge", and "Activate Session" it
seems that several types of errors (i.e. bad username, bad password,
bad privilege request) will sometimes "lock up" to the BMC.  It makes
it so that a new "Get Authentication Capabilities" or "Get Session
Challenge" command does not get a response from the BMC (for some
period of time > period of time I'd be happy with).

Since there is no IPMI specification for dealing with errors from
session initiation commands, I'm thinking this may be a security
feature in the BMC that protects against brute force username/password
hacking.

Have you figured out a clean way to get around this??  Its so annoying
...

> Give me your savannah.gnu.org user id. I think you will be a good
> contributor to this project.

Just registered as "chu11" ...

Al

----- Original Message -----
From: Anand Babu <address@hidden>
Date: Wednesday, October 22, 2003 3:02 pm
Subject: Re: [Freeipmi-devel] IPMI power control utility description

> Hi Al,
> ,---- Albert Chu <address@hidden> writes:
> | AB, I couldn't find too much IPMI code on the FreeIPMI website, for
> | the most part, I wrote an IPMI library from scratch (of course 
> caring| only for those packets and functionality I required for power
> | control).  The API allows the user to:
> | 
> | - set data in individual packets
> | - get packet data values from packet responses
> | - dump packet data to stderr
> | - check packets for correct completion code, network function 
> response,  
> |   command type, checksums, outbound sequence numbers, and 
> requester  
> |   sequence numbers.
> `----
> All the blame goes to me. I still have all the code in my laptop and
> hesitant to check-in without freezing the framework. I promise I will
> do it in a day or two. Compare your library and the libfreeipmi
> library and submit a patch for the enhancements.
> 
> ,----
> | Based on the library, the tool creates appropriate packets, checks
> | responses for correctness, deals with errors, polls/sends 
> packets, and
> | gives a snazzy command line interface.  Due to lack of 
> creativity, I
> | called the tool ipmipower too.
> `----
> Question:
> Should ipmipower be maintained a separate utility apart from fish?
> 
> Fish shell provides an interface to achieve the same what ipmipower
> can do, but it may be too heavy. Most of the times while calling from
> other applications or scripts, ipmipower or direct libfreeipmi library
> will be faster and simple.
> 
> I think we can standardize on your implementation. Just wait for the
> libfreeipmi release. I want your ipmipower to be built on top of
> libfreeipmi as a FreeIPMI sub-project.
> 
> ,----
> | The tool has two "modes", interactive and non-interactive.  If you
> | specify some power command on the command line (--on, --off, --stat,
> | --reset, --cycle) ipmipower runs the command on specified remote 
> nodes| then exits.  
> | 
> | If no power commands are specified on the command line, an 
> "interactive| mode" is entered, where you get a command prompt and 
> can type in various
> | power commands.  This was specifically implemented for ipmipower 
> to work
> | with powerman.
> `----
> 
> Fish provides an interactive command interface and scheme based
> scripting interface. 
> 
> Question:
> How important it is to have additional command-line interface apart
> from the above two interfaces?
> 
> I think it will be nice to have command-line interface too, to most
> commonly used features. 
> 
> It was never considered that critical so far, because much of higher
> level stuff and user interface is written in scheme and currently
> there is no way to register dynamic command line interface from
> scheme. So doing it (interfacing the ipmi commands to command line
> argument processing) will require implementation in C inside fish core
> there by heavily limiting the extensibility.
> 
> I think this problem is solvable by easily capturing dynamically
> registered commands (from scheme) and throwing them as command line
> arguments as well.
> 
> 
> More info on how I implement UI for internal C ipmi functions:
> --------------------------------------------------------------
> For every new functionality that goes into Fish, I add a scheme
> procedure or hook or variable binding. Then I handle much of the UI
> from scheme as an extension module. 
> 
> Once scheme binding is available, it is very easy to make it available
> as a command.
> 
> Like this:
> 
> (define (discover args)
>  "discovers list of IPMI compatible systems and caches them"
>  (set! args (list->strlist args))
>  (if (= (length args) 2)
>      (fi-discover! (car args) (cadr args))
>      (display "discover: wrong number of arguments, type \"help
>      discover\" for more info\n")))
>                                                                    
>                        
> (fi-register-command!
> '("discover"
>   "discover IPADDR-START IPADDR-END \n\t- discover IPMI compatible 
> systems"))
> The above code will a shell command like this:
> 
> fish# discover 192.168.1.10 192.168.1.200
> 
> 192.168.1.10 -> IPMI v1.5
> 192.168.1.11 -> IPMI v1.5
> 192.168.1.12 -> No response
> 192.168.1.13 -> IPMI v1.5
> ...
> ...
> fish# help discover
> discover IPADDR-START IPADDR-END
>        - discover IPMI compatible systems
> 
> But the actual code behind this implementation is written in C inside
> libfreeipmi and fish core. 
> 
> You can also interface to the ipmi procedures by writing your own
> scripts and execute them as independent executables with
> #!/usr/bin/fish, or fish -s /path/to/myscript.scm 
> 
> It is also possible to evaluate scheme code from command line like
> this
> # fish -e "(fi-power-on '192.168.1.27)"
> 
> ,----
> | As for the actual IPMI protocol, I setup a session, run a power 
> command,| then close the session.  Due to various 
> design/implementation/time| reasons, I elected not to program our 
> tool to keep IPMI sessions open.
> `----
> Your choice is correct. libfreeipmi doesn't manage sockets. It lets
> the user to establish the session and just provide sockfd to the
> library. It is upto the user to choose between session per job and
> all in one session. By this way it ensures thread-safety also.
> 
> Handling all in one session needs session tracking, buffer flushing
> ..,  and is too cumbersome. Otherwise you will get unexpected results
> which are hard to debug. On the other hand, all in one session is
> faster. 
> 
> Debate between correctness and speed?
> Fish chose to use all in one session model, simply because of
> speed. One of the design goal of Fish is speed and
> scalability. Correctness can be achieved over time. But ipmipower
> should lean towards correctness and stability at this point just to
> ensure manageability of Thunder project from the very beginning.
> 
> It would be nice to evaluate how long it takes to 
>   for (i=0; i<1024; i++) {
>      socket(SOCK_DGRAM)
>      bind 
>     close 
>   }
> 
> ,----
> | Packet responses are checked for proper checksums, completion code,
> | network function, command, outbound sequence number, and requester
> | sequence number.  Right now, I use the requester sequence number to
> | store both a "transaction id" and a "sequence number", although I'm
> | debating if this should be changed.  Old packets or corrupted 
> packets| are ignored and assumed to be junk.  Error codes are handled
> | appropriately when possible.
> |  
> | Packets will be resent if a proper response doesn't arrive within a
> | certain timeout.  The overall power control attempt times out 
> after a
> | much larger time period.
> `----
> Much of my time is spent only in this area. Though I have working code
> already, I want to abstract all these details in to the framework
> itself (mostly into libfreeipmi). I'm foreseeing lot of trouble in
> this area like you do. UDP is stateless, but that also invites
> trouble. Remember the other end of connection is a dumb BMC firmware
> and not enterprise class management agent software. 
> 
> I'm getting varying results while trying to tune between timeout and
> retry count. I left that parameter as a configurable value.
> 
> libfreeipmi provides a nice errno type of error handling. Every call
> should set appropriate errno value and you can get the string
> description of the error using ipmi_strerror_r (...) call.
> 
> ,----
> | That's a general overview, but perhaps not so general b/c this
> | e-mail is way long.
> `----
> I think we will be coding more than we talk once the framework is
> established :D. 
> 
> Give me your savannah.gnu.org user id. I think you will be a good
> contributor to this project.
> 
> Happy Hacking
> -- 
> _.|_ 
> (_||_)
> Free as in Freedom <www.gnu.org>
> 
> 
> _______________________________________________
> Freeipmi-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/freeipmi-devel
>