[ofa-general] OpenSM Console Ideas?

[Ira Weiny]

On Tue, 26 Feb 2008 09:59:08 -0800
Hal Rosenstock <hrosenstock at xsigo.com> wrote:

> Hi Tim,
> 
> On Tue, 2008-02-26 at 08:46 -0800, Timothy A. Meier wrote:
> > Hi Hal,
> >    I haven't had very much feedback yet.  Do you have any idea how many people
> > use the console?
> 
> No idea.

I will chime in; here at LLNL we use the console extensively.  Perhaps this is
just because I was so involved in the development of it, but one of the first
things I do when we are having IB problems is check the "status" of OpenSM via
the console.

The two most useful things you can do are:

   1) get "status"  (sweeping, idle, etc.)
   2) change the log level

We have found it is _very_ useful to find out how OpenSM views the fabric.  As
well as using the diag tools.  Furthermore as OpenSM improves we can use this
interface for faster and less "fabric invasive" information gathering than the
diags can provide.

Finally, we like the ability to control the SM.  Changes such as log level,
forcing a "resweep", changing SM priority, or turning the perfmgr on and off
have been used for a variety of testing.

This ties into what I asked in Boomtown; Do users just "hope IB works"?
Perhaps IB does "just work" for many installations but as IB grows I think we
will see a need for more _live_ network debugging techniques.  That is one of
the needs we have here.

As such, we are always coming up with ideas for commands and diags which could
benefit from a secure console interface.  However, we hesitate to go forward
without a secure and "standard" (read on by default) way to access this
information.

> 
> -- Hal
> 
> > Hal Rosenstock wrote:
> > > Hi Tim,
> > > 
> > > On Thu, 2008-02-21 at 16:27 -0800, Timothy A. Meier wrote:
> > >> LLNL uses the remote console feature in OpenSM.  We have a need to secure
> > >> this remote connection with authentication/authorization and encryption
> > >> (specifically PAM and OpenSSL).  I have a working prototype, and would
> > >> like to formalize it and share/include this with OpenSM.
> > >>
> > >> Before I go down this path too far, I would like to solicit ideas from
> > >> others who use the console.
> > >>
> > >> Currently, the console can be used in local, loopback, or remote modes.
> > >> If security is added, should it replace other modes, or be an additional mode?
> > > 
> > > IMO the old modes should be preserved and I would view
> > > authentication/authorization and encryption as an orthogonal dimension
> > > to be supported with any of those modes.
> > > 
> > This was my initial instinct as well.  Honestly, however, once we have
> > a secure connection, we will probably use it exclusively.  I suppose the
> > local console would also be necessary.  I can preserve all modes.

Personally, I think we should support only local and secure.  Local is useful
for debug and development, while the secure connection can be used to connect to
a live system.

> > 
> > >> The intention is to use PAM for the AA framework, and OpenSSL for secure
> > >> sockets.  Are there any serious objections to this implementation plan?
> > > 
> > > Is the license compatible with OpenFabrics ?
> > >
> > Well I am not a lawyer, but I believe that it is.  OpenSSL has a dual license,
> > both are BSD-style open source licenses (one for the toolkit, one for openssl).
> > An alternate to OpenSSL is GNU TLS.  GNU TLS is not as widely used, and has
> > the GNU Lesser GPL which is supposed to be extremely lax.
> > 
> > The PAM libraries are included with most linux distros, (RH, Debian, etc.) and
> > have BSD style and GNU GPL licenses.

I would like to provide an interface into OpenSM which can be on by default
(compile and runtime).

   (Sasha already said this but...)
My belief is; if we provide this interface to the users "by default" I think it
will cause A) more users to use it and B) more development of uses/ideas for
the interface.  But this means making the connection secure.

> > 
> > >> The console feature has always been a configuration/command line option,
> > >> but should the secure console be conditionally compiled/linked as well?
> > >> (eliminate dependency on the PAM and OpenSSL libs, pam, pam_misc, cryto, ssl).
> > > 
> > > This might depend on the licensing. Also, on one hand, it would be nice
> > > to minimize the build options, but for those where space is an issue,
> > > the separate configurability of this would be useful. (Not knowing the
> > > additional size of this but it sounds like it will be large enough to
> > > not make this a mandatory requirement of the console).
> > > 
> > > -- Hal
> > >
> > Agreed.  Should it NOT include the security stuff into the build, by default?
> > And the Console be disabled by default, and if enabled, default to "local"?

See above; I would really like to have this stuff enabled by default.  I think
a lot of users don't use the tools because they don't know about them or they
take too much effort to configure.  Having to recompile OpenSM with the
--enable-console is really too much trouble for some users.  Perhaps the
license issues will not allow this to happen but I don't think that is true.

> > 
> > >> The secure console would require a relatively primitive client application,
> > >> which I will probably package under opensm, just like osmtest.  Make sense?
> > >>
> > >> Do you have any other ideas or suggestions for the remote console?
> > >>

A couple of things I can think of off the top of my head:

   1) More ability to control OpenSM without restart.
   2) ability to read OpenSM's routing information

Thanks,
Ira