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

[Mihael Hategan]

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
> > 
> 
> 
>