Several Endpoint types can't autoactivate, may be a problem for hosted CLI transition

[sirosen]

There's at least a couple of types of activation other than S3 endpoints which can be done via the hosted CLI, but which we can't replicate.

GSI-SSH credentials aren't going to be supported. Do we have any fallback for endpoints which may still be using endpoint-activate -g? If not, the hosted CLI may need to drop endpoint-activate -g support prior to the transition.

MyProxy-activation can be done directly from the CLI. At the very least, there's the possibility of someone scripting with echo "..." | ssh ... endpoint-activate ... It also seems that there may be scenarios in which the MyProxy server may issue a fresh proxy cert without requiring username/password? I have one user story that suggests this to be the case, but cannot verify at present.

For MyProxy endpoints, should we consider reintroducing globus endpoint activate, consuming myproxy credentials?

cc @ranantha

---

EDIT: These are the activation types which we need to make decisions about:

• [ ] GSI SSH Activation
• [ ] MyProxy Activation

[sirosen]

I got a bit more information about the MyProxy server that I referred to, which may have been refreshing without user credentials. It turns out that the relevant user was actually talking about credentialed MyProxy activation, so we're no worse off than before.

I would say that raises that issue to the fore:

We have at least one (probably more) existing user doing ssh ... endpoint-activate calls with MyProxy credentials in order to script endpoint activation. We cannot provide a simple non-integrated helper script to do this because you need to authenticate against Transfer (which means it needs the tokens from globus login).

[sirosen]

An idea that just struck me, which may be of interest and which has several variants, is to produce a method of doing this via the CLI which is somehow segmented from the rest of the toolchain to mark it as a deprecated behavior which we do not want to encourage.

Examples:

• Add support for CLI plugins, and add a globus-cli-myproxy-activation package which adds its subcommand somewhere in the hierarchy
• Add a subcommand group, globus legacy which contains a variety of discouraged but necessary behaviors
• Add a second executable, globus-legacy, serving the same purpose
• Add a hidden --compatibility mode flag which enables several ports of Hosted CLI behaviors which we consider necessary

That first option is extremely attractive to me, and prompted me to write it all down in #155

[sirosen]

Closing as a duplicate of #242