How does t2-cli work with hardcoded IPs of Tessel devices? about t2-cli HOT 22 OPEN

This is still a useful feature for anyone that would like to contribute it. The fix includes adding a command line option to the makeCommand function, parsing the option and attempting to connect to the provided IP within Tessel.get before starting the discovery process, then finally instantiating a Tessel object and returning it from Tessel.get as the first arg of a Promise resolution.

from t2-cli.

Edit: this method isn't sufficient because you need to add many more details like port, ssh key path, passphrase, password.

I think a command to add specific ip addresses should be easy to implement. We'll just keep a config file in .tessel with a list of these manually added Tessels and expose them to the rest of the CLI.

Commands:
tessel remote add ip name
tessel remote remove ip or name
tessel remote get [ip or name]

Example:
tessel remote add 192.168.1.1 vm


tessel remote remove vm
or
tessel remote remove 192.168.1.1

What do you think @tcr?

from t2-cli.

Alternatives are:

• just add optional flags to this command structure for every possible config setting
• have users create a JSON configuration file that specifies the config settings and register that file.

I prefer the first option.

from t2-cli.

This is a cool idea, but wondering how strong of an analogy we want to make to a git remote

from t2-cli.

Implementing this here.

from t2-cli.

Here is the current design of the API

tessel remote <method> <host>

<method> is one of 'add', 'remove', or 'get'. 'add' will create a new remote target, 'remove' will de-register that target so the CLI no longer attempts to list it or deploy to it, and 'get' simply prints out the details of the host.

<host> is the hostname or ip address of the remote device to modify. You can use 'localhost' for things like virtual machines.

Options:
-i / --keypath : path to the SSH key to use (defaults to HOME/.ssh/id_rsa)
-p / --port : port to connect to (defaults to 22)
-w / --password: password to connect with (defaults to none)
-h / --passphrase: the passphrase necessary to use the SSH key (defaults to none)

To modify a remote, just add it again with the same hostname and different options.

from t2-cli.

Have you tested whether mDNS works if you use a different network mode in VirtualBox? It's clear why it doesn't work in the default NAT mode, but I'd expect it to work in bridged mode.

Otherwise, would it work just to allow an IP address (or possibly also FQDN if a local network has a proper DNS setup) anywhere a name is allowed?

from t2-cli.

So after a little exploration, we've found that the CLI can detect VMs using mDNS under certain circumstances:

• Change the Network Mode from NAT to Bridged from the VirtualBox Settings window. This means that you will no longer be able to use vagrant ssh to access the machine.
• You still need some way to get your SSH key onto the vm or be able to specify a password to the CLI. You can theoretically create a Serial Port to the terminal using Virtual Box's settings and use socat to communicate with the device. That seems like a poor use experience. Otherwise, we need to add some other capability to the CLI to access passwords for specific devices.

All in all, it seems like more work to get that working rather than using the tessel remote add/remove/get command. Thoughts @tcr @kevinmehall ?

from t2-cli.

We might be able to get an insecure VM key into the VM at generation time (see the Packer script) though we'd have to ship the insecure key.

Or we can create a Vagrant script that searches (using mDNS) for a Tessel to advertise for and then does provisioning. I can't figure out how to run a provisioning script that runs on the host though

Or perhaps we can use a local script with mDNS to advertise for a local VM?

from t2-cli.

I guess the better question is: will we need this feature regardless of whether or not we can detect the VM over MDNS? If so, we should be critiquing the interface itself so we can get it merged. It's all implemented so if we need it (even if it's not critical) let's rope it in.

from t2-cli.

We would still have a need for the feature, I think.

I would be in favor of just concatenating all the options together:

-p / --port : port to connect to (defaults to 22)
-w / --password: password to connect with (defaults to none)

Instead, do:

tessel remote add localtessel 192.168.9.1 -u tim -p 222 -w tessel2

tessel remote add localtessel tim:[email protected]:222

Also note I swapped <name> and <ip>, much like git.

from t2-cli.

Essentially, this is of the form user:password@host:port, correct?

This sounds fine to me.

from t2-cli.

On second thought, I actually like the original design better.

I don't like the inconsistency that pops up when you add a remote like tessel remote add tim:[email protected]:222 and then remove it with tessel remote remove 192.168.9.1. tessel remote remove tim:[email protected]:222 is also too verbose.

I think passing flags is a much more clear way to go.

from t2-cli.

I took a second look at your design and noticed a detail about your suggestion that I didn't pick up on originally. I didn't have a name field as part of the API but your suggestion does. In that case, to add you would run tessel remote add localtessel tim:[email protected]:222 and to remove: tessel remote remove localtessel.

We're on the same page now - I can see why that's the best way to go.

from t2-cli.

It looks like Vagrant is supposed to support bridged networks, but maybe only if you set it up from the Vagrantfile instead of changing it in the VirtualBox UI. You could potentially run a slightly-modified USB daemon over the virtual serial port.

I question whether we want to allow specifying the username, when many of our actions require running as root. Same goes for passwords -- I plan to disable password authenticaion in the dropbear SSHd we ship.

Is the complexity of the remote command managing a config file necessary at all? My suggestion is to use names only with mDNS and simply accept an IP address or ip:port string anywhere that a name is allowed. That's only a little weird for tessel list, but we could allow tessel list --name 127.0.0.1:2222 (or whatever the flag is) for consistency with all other commands with that flag.

from t2-cli.

Sure enough, adding config.vm.network "public_network" to the Vagrantfile does allow mDNS to work. Unfortunately, it spits out a an error at the end of booting up. The error doesn't seem to do anything of consequence as I can still ssh in and, as I mentioned, detect the VM from the CLI.

from t2-cli.

@wprater I think it would be relatively simple to add the ability to deploy to a known IP Address to the CLI.

There are a ton of other tools for more advanced fleet management and in-the-field updating that generally require more "cloud infrastructure". Nobody at Tessel has been interested in building it thus far because there are so many other solutions. If you're interested, we can look into building a Tessel specific one but I think it might be easier to piggy back one other people's work in the space.

I once chatted with the Particle folks and they said their deployment software could be pretty easily adapted to deploy to Tessels.

from t2-cli.

@johnnyman727 this makes sense. I'll go another route for fleet management, and will refer back here if any of my work can help!

from t2-cli.

@HipsterBrown can you take a look at this?

from t2-cli.

@rwaldron Looking through it now.

from t2-cli.

Would this be an option specify an IP address of a remote tessel for communication?

from t2-cli.

@reconbot yes. This would be useful if mDNS is not working for whatever reason or if the Tessel is not on the local area network.

from t2-cli.