Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How does t2-cli work with hardcoded IPs of Tessel devices? #70

Open
tcr opened this issue May 2, 2015 · 22 comments

Comments

Projects
None yet
8 participants
@tcr
Copy link
Member

commented May 2, 2015

This should be a general solution. Ideally: I can add several hardcoded IPs and ports for remote tessels, or a local Tessel VM operating on port 222, and have them show up on tessel list and tessel select.

@johnnyman727

This comment has been minimized.

Copy link
Contributor

commented May 3, 2015

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?

@johnnyman727

This comment has been minimized.

Copy link
Contributor

commented May 4, 2015

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.

@Frijol

This comment has been minimized.

Copy link
Member

commented May 4, 2015

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

@johnnyman727

This comment has been minimized.

Copy link
Contributor

commented May 4, 2015

Implementing this here.

@johnnyman727

This comment has been minimized.

Copy link
Contributor

commented May 5, 2015

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.

@kevinmehall

This comment has been minimized.

Copy link
Member

commented May 5, 2015

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?

@johnnyman727

This comment has been minimized.

Copy link
Contributor

commented May 5, 2015

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 ?

@tcr

This comment has been minimized.

Copy link
Member Author

commented May 5, 2015

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?

@johnnyman727

This comment has been minimized.

Copy link
Contributor

commented May 5, 2015

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.

@tcr

This comment has been minimized.

Copy link
Member Author

commented May 5, 2015

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:secret@192.168.9.1:222

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

@johnnyman727

This comment has been minimized.

Copy link
Contributor

commented May 5, 2015

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

This sounds fine to me.

@johnnyman727

This comment has been minimized.

Copy link
Contributor

commented May 6, 2015

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:secret@192.168.9.1:222 and then remove it with tessel remote remove 192.168.9.1. tessel remote remove tim:secret@192.168.9.1:222 is also too verbose.

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

@johnnyman727

This comment has been minimized.

Copy link
Contributor

commented May 6, 2015

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:secret@192.168.9.1: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.

@kevinmehall

This comment has been minimized.

Copy link
Member

commented May 6, 2015

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.

@johnnyman727

This comment has been minimized.

Copy link
Contributor

commented May 6, 2015

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.

@johnnyman727

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2015

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

@wprater

This comment has been minimized.

Copy link
Member

commented Sep 10, 2015

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

@rwaldron

This comment has been minimized.

Copy link
Contributor

commented Nov 19, 2015

@HipsterBrown can you take a look at this?

@HipsterBrown

This comment has been minimized.

Copy link
Contributor

commented Nov 19, 2015

@rwaldron Looking through it now.

@reconbot

This comment has been minimized.

Copy link
Member

commented May 27, 2016

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

@johnnyman727

This comment has been minimized.

Copy link
Contributor

commented Jun 2, 2016

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

@johnnyman727

This comment has been minimized.

Copy link
Contributor

commented Aug 9, 2016

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.

@Frijol Frijol referenced this issue Mar 26, 2017

Open

Production Working Group #207

0 of 2 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.