[ofa-general] OpenSM Console Ideas?

[Hal Rosenstock]

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.

-- 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.
> 
> >> 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.
> 
> >> 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"?
> 
> >> 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?
> >>
> > 
> 
>