t2 provision

[Frijol]

command t2 provision T2 CLI spec: A silent command (not exposed in CLI): [ONLY WORKS OVER USB] creates a .tessel folder with ssh keys in your home directory and uses those ssh keys to authorize you to push code to the USB-connected Tessel

Current status:

• t2 setup is a callable command
• creates a .tessel folder in computer's home directory containing an ssh keypair
• copies public key from ~/.tessel into tessel's /etc/dropbear/authorized_keys, thus authorizing the given computer to program that tessel over SSH
• Change name to 'provision' t2 provision #101

Remaining issues:

• Needs to work on Windows as well (see ssh-keygen relies on a binary #147)
• Needs error message if you try to call it over SSH: "Connect via USB to use tessel provision" errors if you try to provision over LAN #111

[Frijol]

There is some contention about this in the spec. Summarizing the conversation:

1. Silent vs. callable
   I suggest that this should remain a callable command. I'm worried that if the command is silent, it's not obvious that a Tessel needs to be programmed over USB the first time it is used.
   @johnnyman727 agrees that it should be explicit.
   @nplus11 thinks it should be a silent command because it's an extra step for the user
   What is the best interaction for authorizing a computer to program a given Tessel for the first time?
2. Name
   The original name for the command was setup. @johnnyman727 suggests provision. I suggest auth. What is the most intuitive name?

[johnnyman727]

@tcr @kevinmehall @jiahuang @ekolker @HarleyKwyn @nplus11 do any of you have opinions on this?

[kevinmehall]

Explicitly called. What does deploying code have to do with manipulating network authentication credentials? You don't necessarily want to set up credentials just because you push once over USB, and you don't necessarily push over USB before wanting to push over WiFi.

[johnnyman727]

+1 @kevinmehall any naming preferences?

[rwaldron]

What is wrong with making it both callable and automatic?

• if I call it before a push, good: it's done
• if try to push and the requisite .tessel + keys, etc are not created, then call it before the push
• it's idempotent, so subsequent calls have same result.
• I can purge and start anew.

Naming...

• "setup" is too ambiguous
• "auth" could work
• "provision" is definitive

[Frijol]

Provision seems fine, if that's standard. I'll update above.

Re automation, I'm worried that if it's implicit, people don't know that it's something that needs to happen.

Say your friend has been using their Tessel 2, programming it over SSH. You get excited about it and decide to try it. You install tessel and try running the same tessel list your friend was using, but the T2 doesn't even show up until you run tessel list -a, at which point it shows as unauthorized. Your friend doesn't remember having to authorize (since the friend followed the first run experience to set up, and it authorized automatically). Then neither of you know why you can't access the Tessel. You will likely eventually get frustrated and try connecting directly over USB, at which point it will work. You don't know why it worked, and therefore don't know if it will stop working in the future– looks like a potential connectivity error.

Much simpler if it's standard to plug it in to USB when you first get it, explicitly call a command to authorize you, and know exactly why you are or aren't allowed to access the device.

[rwaldron]

Why can't tessel list show both authorized and unauthorized? Create some notation or even just (unauthorized) or (requires authorization, run: "tessel provision")

[nplus11]

We initially hid unauthorized devices because CLI will only work with authorized tessels (aka why show them something they cannot talk to?). However tessel provision is more clear now, and we want an easier way to "connect" to them. It makes a lot of sense to have list show all devices now; no flag needed.

[Frijol]

Seems reasonable. I'll update the tessel list command in spec.

I also like the idea of a more informative (use tessel provision to authorize). Along with that, we need an informative error message on tessel provision in case someone tries to use it over SSH. "Connect via USB to use tessel provision"

[Frijol]

On what commands should a USB-connected T2 automatically call tessel provision?

[rwaldron]

Along with that, we need an informative error message on tessel provision in case someone tries to use it over SSH. "Connect via USB to use tessel provision"

Definitely—this makes it clear to the user that they've made a mistake, but also includes the solution.

On what commands should a USB-connected T2 automatically call tessel provision?

Anything that would otherwise fail if tessel provision has not been explicitly called. Do the check: if the necessary local files are in place, then it's reasonably safe to assume that tessel provision has been run, otherwise run it.