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

[Michael Wilde]

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