Comments (22)
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.
Related Issues (20)
- Crash report: It is unclear which device should be operated upon.
- Crash report: It is unclear which device should be operated upon.
- Crash report: Error: Bogus error
- Crash report: Error: Bogus error
- Crash report: TypeError: options.end is not a function
- Crash report: TypeError: Class constructor cannot be invoked without 'new'
- Crash report: TypeError: Class constructor cannot be invoked without 'new'
- Crash report: Error: kill ENOSYS
- Crash report: Error: No device found in bootloader mode
- Crash report: Error: No device found in bootloader mode
- '$t2 update' occurs error ' HOT 1
- Do you have pre-compiled binaries for @serialport/[email protected]
- Pre-compiled module is missing: @serialport/[email protected]. Warning when running 't2 run' on Mac HOT 2
- Crash report: TypeError: process.stdin.setRawMode is not a function
- Node version mismatch for USB drivers. HOT 1
- unable to run tessel 2 HOT 2
- Crash report: Error: self signed certificate in certificate chain
- Debugging the T2 CLI - no connection to device HOT 7
- Must pass -oKexAlgorithms=+diffie-hellman-group1-sha1 flag to ssh to tessel 2
- serialport issue trying to initiate 2 Tessel 2's - Pre-compiled module is missing: Could not locate the bindings file. HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from t2-cli.