<div dir="ltr">that makes it easy for Eric to connect to the environment.  Now ideally<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

where we'd like to get to is the following:<br>
<br>
   juju connect eric@<api-endpoint> [<env uuid>]<br>
<br>
</blockquote><div>...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
PROBLEM: right now all connections to the api server are secured with<br>
TLS and the client-cert.<br></blockquote><div><br></div><div>I'm pretty sure none of them use client certs. What they use is a certificate that is signed by a environment-specific CA. So we use the CACert to validate that the API server's certificate is valid, rather than just trusty any TLS connection.</div>
<div>However, we *could* just trust the remote site to identify itself if we wanted to.</div><div><br></div><div>...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

We do have the current issue of knowing which end points will be SSL<br>
protected and which are TLS with a client-cert, but for now, we know<br>
that we need a client cert for the connection.  In order to handle this<br>
behaviour now, I suggest we do the following:<br></blockquote><div><br></div><div>As mentioned, we just have regular TLS with server side certs, we just track the CA Cert so that we know if we can actually trust the cert.</div>
<div><br></div><div>John</div><div>=:-></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  $ juju connect <a href="mailto:eric@random-aws.com">eric@random-aws.com</a><br>
fb5a2570-e6f2-11e3-ac10-0800200c9a66 --client-cert ~/Downloads/cert.txt<br>
  password:<br>
  local environment name [foo-production]:<br>
<br>
This at least moves us in the right direction.<br>
<br>
<br>
Thoughts?<br>
Tim<br>
<br></blockquote><div><br></div><div>UUID are still pretty ugly to pass around. Versus having named environments at API servers. I like having UUIDs be unambiguous under the covers, but I wonder if it is actually nice UI to have people use it for connections.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[1] An alternative command name could be 'login'.  We should also have<br>
an equivalent 'logout' or 'disconnect' that removes the .jenv file (with<br>
sufficient warnings about the environment still running).<br></blockquote><div><br></div><div>We've talked about "juju forget-environment" as a way to get rid of a .jenv without actually tearing down the environment.</div>
<div><br></div><div>John</div><div>=:-></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</font></span></blockquote></div></div></div>