[Swift-devel] How to adapt auto-ssl feature from ssh to persistent coasters?

[Michael Wilde]

Yes, that would work. I'll see if we can work around this for now with manual coasters.

- Mike

----- Original Message -----
> From: "Mihael Hategan" <hategan at mcs.anl.gov>
> To: "Michael Wilde" <wilde at mcs.anl.gov>
> Cc: "swift-devel" <swift-devel at ci.uchicago.edu>
> Sent: Monday, November 12, 2012 1:43:29 PM
> Subject: Re: How to adapt auto-ssl feature from ssh to persistent coasters?
> Shouldn't we fix the local:x version instead? I think it's both easier
> to use and easier to fix and faster and less demanding on resources.
> 
> On Mon, 2012-11-12 at 13:38 -0600, Michael Wilde wrote:
> > Mihael, All,
> >
> > Can we use parts of the ssh-based solution below for persistent
> > automatic coasters on a local machine?
> >
> > I was able to create the two local coaster worker pools I need for a
> > mixed MPI/Serial swift script by starting two coaster servers after
> > I created an x509 proxy using globus.
> >
> > Even though the servers were started with -nosec, I was not able to
> > get swift to use these servers with automatic workers. The swift
> > command complained about not finding a proxy file in /tmp. When I
> > created such a proxy manual using grid-proxy-init, everything worked
> > as desired.
> >
> > Now I want to hand this solution off to a user to test, and the user
> > does not have a suitable cert. Do the tools and/or temp certs exist
> > in the current swift release to create a suitable proxy manually?
> >
> > Or, is there a way to have the swift command not insist on a proxy -
> > as the servers and workers are all on the same local cluster?
> >
> > - Mike
> >
> > ----- Forwarded Message -----
> > From: "Mihael Hategan" <hategan at mcs.anl.gov>
> > To: "Michael Wilde" <wilde at mcs.anl.gov>
> > Cc: "Kyle Chard" <kyle at ci.uchicago.edu>, "David Kelly"
> > <davidk at ci.uchicago.edu>
> > Sent: Monday, August 6, 2012 11:45:24 PM
> > Subject: Re: Devel help needed for CMTS project
> >
> > There is a solution now in trunk. Whenever you use SSH as the
> > coaster
> > boot handler, a set of CA keys, user keys and a proxy are created.
> > The
> > SSH provider also now knows how to automatically forward both the
> > proxy
> > and the CA cert.
> >
> > The result is that when you use SSH you don't have to care about any
> > GSI
> > issue. It should just work.
> >
> > Right now there is a minimum lifetime of one week on the use of the
> > proxies (the CA certs have a lifetime of two weeks, but they will be
> > re-used if the have at least one week left). Point being that swift
> > stuff running for more than one week with these may have problems.
> > That
> > can be changed.
> >
> > Anyway, give it a try and let me know how it works.
> >
> > Mihael
> >
> > On Thu, 2012-08-02 at 22:33 -0500, Michael Wilde wrote:
> > > We're trying to not require the user to do either of these two
> > > things:
> > > as long as the user can ssh to the remote system, coasters sith
> > > say
> > > ssh:pbs should work with no other security setup by the user.
> > >
> > > So the problem could be solved (1) with the kind of shared-secret
> > > solution you have mentioned in the past, or (2) with making -nosec
> > > work for automatic remote coasters (assuming we determine that is
> > > sufficiently safe), or (3) we could include in Swift a single user
> > > cert/proxy and a CA signing cert for it, and automatically place
> > > that
> > > on the remote side as part of bootstrap. Eg, a SimpleCA cert, if
> > > anyone can get SimpleCA working, or just find a set of matching
> > > certs.
> > > Or (4) we require that the user create a valid proxy based on a
> > > known
> > > supported CA, before running Swift, and we grab that proxy and
> > > place
> > > it on the remote side at or before bootstrap. I *think* that David
> > > could implement this last solution on his own, as part of swiftrun
> > > or
> > > cmtsrun. It (4) might be the most reasonable for CMTS, given that
> > > their workflows will likely require access to at least one GridFTP
> > > server if any apps run remotely.
> > >
> > > Does that analysis and list of 4 alternatives seem sound?
> > >
> > > - Mike
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Mihael Hategan" <hategan at mcs.anl.gov>
> > > > To: "Michael Wilde" <wilde at mcs.anl.gov>
> > > > Cc: "Kyle Chard" <kyle at ci.uchicago.edu>, "David Kelly"
> > > > <davidk at ci.uchicago.edu>
> > > > Sent: Thursday, August 2, 2012 9:35:16 PM
> > > > Subject: Re: Devel help needed for CMTS project
> > > > On Fri, 2012-07-27 at 14:08 -0500, Michael Wilde wrote:
> > > >
> > > > > - Ability to run remote coasters jobs without an x509 user and
> > > > > ca
> > > > > cert. Alternatively as a stopgap: a pair of certs that either
> > > > > our
> > > > > scripts or users could install to solve the problem. Eg, from
> > > > > SimpleCA
> > > > > or some other source.
> > > >
> > > > What problem are we trying to solve here?
> > > >
> > > > 1. Said users not having a gsi certificate
> > > >
> > > > 2. Coasters and ssh requiring a proxy on the remote side
> > >
> >
> >
> >

-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory