These files are not supported by any other part of the resin
infrastructure, and it could cause confusion with it not being
supported everywhere. The idea was originally added because we
thought we might need to make extensions on docker-compose, but
that hasn't happened.
Change-type: major
Signed-off-by: Cameron Diver <cameron@resin.io>
This commit brings in the ignore and dockerignore libraries, which when
provided with the patterns in the aforementioned files will ignore them.
Change-type: major
Closes: 889
Signed-off-by: Cameron Diver <cameron@resin.io>
Preload will now propose to preload any app that matches the image
architecture.
Change-type: major
Signed-off-by: Alexis Svinartchouk <alexis@resin.io>
Currently running the tests is painfully slow, this commit adds a task
which will run the bare minimum build, and then the tests, speeding up
the process by an order of magnitude.
I had to repeat `gulp test`, instead of reusing `npm run test`, so that
the pretest task isn't ran too.
Signed-off-by: Cameron Diver <cameron@resin.io>
The push command was relying on the output from the builder to indicate
the build status, but this isn't helpful for CI. This commit makes the
remote build module respect the `isError` flag which the builder sends
in any errors. Any errors which come from the builder indicate the
release will not be deployed.
Change-type: patch
Signed-off-by: Cameron Diver <cameron@resin.io>
This restores the behavior from before #911,
which is useful from some users.
Closes#966
Change-type: patch
Signed-off-by: Pablo Carranza Velez <pablocarranza@gmail.com>
If for whatever reason resin-image-fs is not importable — eg. if it’s built for another arch — any command that imports `helpers.ts` will just quit without any error/traceback.
Both commands work with local devices by remotely invoking the `os-config` executable via SSH. This requires an as of yet unreleased resinOS (that will most likely be v2.14) and the commands ascertain compatibility merely by looking for the `os-config` executable in the device, and bail out if it’s not present.
`join` and `leave` accept a couple of optional arguments and implement a wizard-style interface if these are not given. They allow to interactively select the device and the application to promote to. If the user has no apps, `join` will offer the user to create one. `join` will also offer the user to login or create an account if they’re not logged in already without exiting the wizard.
`resin-sync` (that's used internally to discover local devices) requires admin privileges. If no device has been specified as an argument, the commands will launch the device scanning process in a privileged subprocess via two new internal commands: `internal sudo` and `internal scanDevices`. This avoids having the user to invoke the commands with sudo and only request escalation if truly needed. This commit also removes the dependency to “president”, implementing “sudo” functionality within the CLI.
Change-Type: minor
It's awkward that error handling requires you to go to a different
package, it makes things more complicated, and there's nowhere else that
really should be reusing this logic. Let's inline it, so we can
deprecate the module entirely.
Change-Type: patch
This doesn't fix actual usage of image fs, just makes it possible to
stop commands that don't use it from failing entirely.
Connects-To: #869
Change-Type: patch
The status includes a description of how long the device has been in
this state (Up 6 weeks), which is frequently wrong as when the device
first starts up its clock isn't up to date. It's confusing and messy,
best to just remove it entirely.
Fixes#828
Change-Type: patch
This doesn't run a linter or any documentation generation, aiding in
quick development time.
Change-type: patch
Signed-off-by: Cameron Diver <cameron@resin.io>
This mostly reverts the removal of the legacy deploy code that pushed image tars via the builder. It’s needed for users to avoid having to switch between CLI versions in order to push to legacy apps as well.
Note: this pins resin-sdk to 9.0.0-beta14 as I couldn’t get it to install otherwise — npm would always install 9.0.0-beta9 instead.
Change-Type: minor
Our docs markdown renderer doesn't process explicit anchor tags, as it generates its own. The script that generates the markdown has been updated to not include these tags and to properly build the TOC links.
Change-type: patch
This makes sure build logs don’t leak escape sequences and new lines and they don’t break the output. Also improved “inline” logs by normalising the stream before passing it to “transpose build stream”.
Fixes: #808
Change-Type: patch
Legacy behaviour is mostly retained. The most notable change in behaviour is that invoking `resin deploy` without options is now allowed (see help string how it behaves).
In this commit there are also the following notable changes:
- Deploy/Build are promoted to primary commands
- Extracts QEMU-related code to a new file
- Adds a utility file to retrieve the CLI version and its parts
- Adds a helper that can be used to manipulate display on capable clients
- Declares several new dependencies. Most are already indirectly installed via some dependency
Change-Type: minor
New version is 3.1.0.
The updated version is not backwards compatible as it removes all *Async methods that are in wide use in the CLI. The workaround for now is to manually promisify the client and replace all `new Docker()` calls with a shared function that returns a promisified client.
There are very few plugins in real-world use, we're not actively working
on this at all, and the current approach won't work once we move to
standalone node-less binary installation anyway.
Change-Type: major
* require('resin-sdk') => multicontainer SDK
* require('resin-sdk-preconfigured') => 6.15.0 SDK
* all 'resin-sdk' requires replaced with 'resin-sdk-preconfigured'
* resin-sdk-preconfigured TS typings are copy pasted from the current resin-sdk master
The idea is to progressively replace all 'resin-sdk-preconfigured'
requires with 'resin-sdk' (multicontainer sdk) and eventually remove
resin-sdk-preconfigured from package.json.
Change-Type: patch
Use the `--host` (short `-H`) option in the ssh command to access
the host OS of the device.
Direct host OS is enabled for devices with Resin OS >= 2.7.5.
Change-Type: minor
Connects-To: #736
Signed-off-by: Andreas Fitzek <andreas@resin.io>
This has no native modules yet, which means it works on Linux,
but ignoring any ext4 image data. Drivelist will fail for
some windows operations, but most other things should work.
This is only building a folder with a runnable binary, this needs
packaging before it can be distributable.
Change-Type: minor
Before this point, if you had an invalid token, an expired token, or a
token for a different site, you couldn't log out to clear it properly.
Not a big deal, but awkward and messy, and easily fixed.
Change-Type: patch
This is part of a general push to demodularize any code that isn't
realistically reusable outside resin-cli, to make the codebase easier to
manage and understand. Once this is done, we'll deprecate the original
module itself.
Change-Type: patch
This moves to --app and --uuid options, and deprecates the previous
format, but doesn't immediately remove it so this is not a breaking
change.
Connects-To: #691
Change-Type: minor
This would be a major change if the command was ever successful, but it
appears it hasn't ever worked for any available published version of
ResinOS, so it's not possible that there are users relying on it.
Change-Type: patch
The backend server that handles `resin ssh` now supports it.
Also removed the option from local ssh connections to devices, where it
basically has no effect (dropbear on devices supports it)
change-type: minor
fixes#568
Before this commit, the docker daemon would recieve the filename of the
.pem files, which would be interpreted as the body and would fail. This
commit ensures that the actual body of the pem files are sent to the
daemon.
Change-type: patch
Connects-to: #562
Signed-off-by: Cameron Diver <cameron@resin.io>
This commit adds the ability to run a Docker build for an architecture
which is not the host architecture, using qemu-linux-user. Currently
this is only supported for linux.
Added:
* Installation of qemu which supports propagated execve flags
* Copying of qemu binary into the build context
* Transposing the given Dockerfile to use the qemu binary
* Intercepting of the build stream, so the output looks *almost* exactly
the same.
Change-type: minor
Signed-off-by: Cameron Diver <cameron@resin.io>
The command line arg was taking `devicetype`, but the rest of the code
uses `deviceType`. Thus it was impossible to specify a device type
in practice to build a `Dockerfile.template`.
Change-type: patch
Signed-off-by: Gergely Imreh <imrehg@gmail.com>
This gives the user enough notice to stay well updated, but won't spam
them if they're using resin-cli frequently.
Connects-to: #485
Change-type: patch
Signed-off-by: Cameron Diver <cameron@resin.io>
This commit will highlight the usage of the cache when doing a docker
build via `resin build`, which not only helps the user understand what
the build is doing, but also achieves more parity with the cloud
builder.
Change-type: patch
Signed-off-by: Cameron Diver <cameron@resin.io>
If build is ran through `resin deploy`, then logs will be stored and
uploaded to the database, where the dashboard can display them
Change-type: minor
Signed-off-by: Cameron Diver <cameron@resin.io>
`resin build` had access to the `--nocache` and `--tag` options for
building with docker, but `resin deploy` did not. This commit adds the
options to the shared dockerUtils.appendOptions function.
Change-type: patch
Signed-off-by: Cameron Diver <cameron@resin.io>
Upon changing the name of the source parameter from `context`, some
places weren't changed, this commit fixes that.
Change-type: patch
Signed-off-by: Cameron Diver <cameron@resin.io>
Using `resin build` a user can now build an image on their own docker
daemon. The daemon can be accessed via a local socket, a remote host and
a remote host over a TLS socket. Project type resolution is supported.
Nocache and tagging of images is also supported.
Using `resin deploy` a user can now deploy an image to their fleet. The
image can either be built by `resin-cli`, plain Docker, or from a remote
source.
Change-type: minor
Signed-off-by: Cameron Diver <cameron@resin.io>
This error was introduced as part of
`9cf42462c029e038e09efc961736946be8bfcb9b`, since the `forceUpdateLock`
option being used in the `reboot` command contains a `parameter`
property despite being declared a boolean.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
New images will ship a `device-type.json` file in the first partition,
which we can use instead of querying the API for certain configuration
and initialisation commands.
If the file is not found, or is malformed, we still fallback to the API.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This PR adds functionality to `resin sync` to try to infer what the
device uuid is as follows:
- If the argument to `resin sync` is an app, get all the devices from
that application. If there is only one, auto-select it, otherwise show
an interactive drive selection widget.
- If the argument to `resin sync` is a uuid, use it directly, without
trying to infer anything.
- If no argument is passed to `resin sync`, display an interactive
selection widget showing all your devices from all your applications.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
`resin-device-init`, which is used by the `os configure` command was
still running an older SDK version, that didn't support shorter uuids.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
Currently we log a CLI event with the passed command, however this might
include usr params, like a uuid, and therefore cause thousands of
different event names in Mixpanel.
Currently, `config generate` requires a device uuid. The command now
accepts either a uuid or an application name, and generates a
config.json accordingly.
Currently, such error will be thrown when
`resin.auth.twoFactor.challenge()` rejects, but an invalid code is not
the only thing this function can reject for.
If `updateCheckInterval` has any meanginful value, the alert will be
shown one out of ten times, or something like that, making the user
likely to miss updates.
The underlying issue is that `update-notifier`, if it detects a cached
update notification, it deletes it, and only attempts to show it back if
`updateCheckInterval` is greater than `Date.now() - lastUpdateCheck`.
A device resource needs to be registered with the API before being able
to create the `config.json` file that goes in a device.
This means thats the device image is configured and written to an
external drive (e.g: SDCard) *after* the device resource registered.
If any of the above operations fail, there will be an unitialized orphan
device living in the selected application that the user will have to
remove himself.
In my system (MBPr 13), printing the current version takes over 2
seconds:
```sh
$ time ./bin/resin version
2.4.0
./bin/resin version 1.37s user 0.19s system 73% cpu 2.130 total
```
The CLI takes almost all of these time to parse the dependency tree
before returning control over the actually called command.
To mitigate this problem, we only require the NPM dependencies a command
requires when executing such command, and thus prevent dependencies from
being required and parsed unnecessary.
After this improvement, printing the original example (`resin version`)
returns in less than a second (2x improvement):
```sh
$ time ./bin/resin version
2.4.0
./bin/resin version 0.88s user 0.09s system 102% cpu 0.938 total
```
This is useful in the scenario when the user is using the CLI in an
environment in which he/she doesn't have access to a web browser, like a
headless server or a Vagrant development environment.
Some CLI commans prompt to select an existing application, presending a
dropdown with all the application names, however it's hard to remember
which application belon to which device type, which makes it easier to
select the wrong application.
When you change the `resinUrl` config from time to time it can be
confusing to remember where you're logging in, or in which host you're
in.
Currently I have to check the configuration files/environment variables
manually or run `resin settings`.
This PR prints the detected resin url on `resin login` and `resin
whoami` so it's always clear where you are.
The command to get information about a device, `resin device` requires a
`uuid` as a parameter. Given that we don't show uuids in `resin
devices`, the user has no way to know what uuid to pass to get extra
information.
We also remove some non very used information columns from `resin
devices` to make space for the uuid.
The last part of `quickstart` feels weird. By consensus, we remove the
part that attempts to create a project directory and leave that step to
the user.
We get a weird error message from pine otherwise:
ResinRequestError: Request error: It is necessary that each app name
that is of a user (Auth), has a Length (Type) that is greater than or
equal to 4.
Current has the following problems:
- Our custom message gets printed even if the notifier doesn't contain
an update.
- The notifier box is deferred, therefore it's printed at the end of the
command. Since our custom message is printed at the beginning, it makes
no sense at all.
This allows the user to bypass the drive selection dialog.
This option can be used along with `--yes` to make the command
completely non-interactive. For example:
$ resin os initialize rpi.img 'raspberry-pi' --drive /dev/disk2 --yes
If the spinner message doesn't fit in your terminal, each spinner
position will be printed in different lines.
We mitigate this by dramatically shortenning the message.
Currently, the fact that `os initialize` requires elevated permissions
forced us to require calling commands that reuse it, such as `device
init` and `quickstart` with administrator permissions as well.
This ended up causing issues like saving images in the cache that belong
to root, or initializing git repositories that requires `sudo` to
commit.
The solution is to call `os initialize` as a child process preppending
`sudo` within `device init`.
Fixes: https://github.com/resin-io/resin-cli/issues/109
Currently, if `device init` was ran without an application argument, we
attempted to get the application name from the current directory, given
it was a git repository.
This approach led to confusions from time to time, so now we prompt the
user to select one of it's own applications from a dropdown instead of
checking the current directory in this edge case.
Fixes: https://github.com/resin-io/resin-cli/issues/197
This enforces all clients to use the Resin Settings Client version that
the SDK provides, reducing incompatibilities caused by different modules
requiring different Resin Settings Client versions.
Consider the following case:
The SDK is configured to point to staging, but the user passes a token
from production, or viceversa. Since the token is valid in a sense that
is valid JWT and contains real data, the CLI will report as a success.
The user will then get Unauthorized errors when using the API.
`update-notifier` persist its update check results in a file, which is
then read when running again the application.
If this file gets written when the application is being run as root, we
get ugly EPERM issues.
This script was used along with windosu as a workaround to call `device
init` with elevated permissions.
Since Windows elevation is not used anymore for now, this script can be
removed.
Since we're now forcing users to rely on `npm` directly for updates, we
can also get rid of plugin commands that attempt to
install/update/remove using npm programatically and require users to use
`npm` directly as well.
This commit removes the following commands:
- `plugins`
- `plugin install`
- `plugin update`
- `plugin remove`
Despite plugin related commands being removed, *the functionality that
scans for plugins and registers them remains intact*.
For this we use the `update-notifier` module with its default settings.
This module will print a nice banner prompting the user to run the
corresponding npm command to update.
We were currently building this path ourselves, hardcoding the place of
the resin local per user directory instead of relying on the foundations
that `resin-settings-client` give us.
There were two issues that prevented this command from working
correctly:
1- `Promise.delay()` is used, but `Promise` was not imported.
2- The following line had incorrect indentation (spaces instead of
tabs):
poll().nodeify(done)
Therefore CoffeeScript interpreted that the line had to be executed at
the end of the `poll()` function, causing `poll()` to never be called.
Since the public key string is long, it might wrap to lines below,
causing the table layout to break.
A quick solutio is to print the ssh key after the table.
Fixes:
- https://github.com/resin-io/resin-cli/issues/151
PubNub keeps the process alive after a history query for some reason, so
trying to print the logs history like:
$ resin logs <uuid>
Will result in the logs being printed correctly, but the process waiting
infinitely without ending.
The workaround consists in forcing `process.exit` to exit the process
with an error code zero.
Caveats:
- This workaround prevents this command to be used programatically.
Issue: https://github.com/resin-io/resin-cli/issues/14
Main changes:
- Use the `columnify` module to display the commands instead of using
manual parsing.
- Extract logic to create a string representation from an option
signature to Capitano, and reuse here.
See https://github.com/resin-io/capitano/pull/28
Some bugs were caught and fixes during the refactoring:
- In command help, if the command didn't exist, we reused default
Capitanos command not found function which uses `process.exit(1)`. This
was changed to pass a custom error to `done()`, so the command fails
correctly when using programatically.
- General help didn't call `done()` at all, thus causing problems if
using the command programatically someday.
- Add helpers.confirm() to abstract the process of asking for
confirmation.
- Add helpers.selectDeviceType() to abstract the form needed to ask for
device types.
The functions on this module are reused by app actions.
This functionality is outdated and not using anymore due to limitations
in the way it was addressed.
The module and dependencies are removed for now, and will be added back
in the future, once a better approach is planned.
We added this because we thought that knowledge of the supported device types, along with the configuration procedures was going to be encoded in the CLI.
With device specs, this is not longer the case.
If you want to install the CLI directly through npm, you'll need the below. If this looks difficult,
we do now have an experimental standalone binary release available, see ['Standalone install'](#standalone-install) below.
- [NodeJS](https://nodejs.org) (>= v6)
- [Git](https://git-scm.com)
- The following executables should be correctly installed in your shell environment:
-`ssh`: Any recent version of the OpenSSH ssh client (required by `resin sync` and `resin ssh`)
- if you need `ssh` to work behind the proxy you also need [`proxytunnel`](http://proxytunnel.sourceforge.net/) installed (available as `proxytunnel` package for Ubuntu, for example)
-`rsync`: >= 2.6.9 (required by `resin sync`)
##### Windows Support
Before installing resin-cli, you'll need a working node-gyp environment. If you don't already have one you'll see native module build errors during installation. To fix this, run `npm install -g --production windows-build-tools` in an administrator console (available as 'Command Prompt (Admin)' when pressing windows+x in Windows 7+).
`resin sync` and `resin ssh` have not been thoroughly tested on the standard Windows cmd.exe shell. We recommend using bash (or a similar) shell, like Bash for Windows 10 or [Git for Windows](https://git-for-windows.github.io/).
If you still want to use `cmd.exe` you will have to use a package manager like MinGW or chocolatey. For MinGW the steps are:
1. Install [MinGW](http://www.mingw.org).
2. Install the `msys-rsync` and `msys-openssh` packages.
3. Add MinGW to the `%PATH%` if this hasn't been done by the installer already. The location where the binaries are places is usually `C:\MinGW\msys\1.0\bin`, but it can vary if you selected a different location in the installer.
4. Copy your SSH keys to `%homedrive%%homepath\.ssh`.
5. If you need `ssh` to work behind the proxy you also need to install [proxytunnel](http://proxytunnel.sourceforge.net/)
Getting Started
---------------
### NPM install
If you've got all the requirements above, you should be able to install the CLI directly from npm. If not,
or if you have any trouble with this, please try the new standalone install steps just below.
This might require elevated privileges in some environments.
`--unsafe-perm` is only required on systems where the global install directory is not user-writable.
This allows npm install steps to download and save prebuilt native binaries. You may be able to omit it,
especially if you're using a user-managed node install such as [nvm](https://github.com/creationix/nvm).
In some environments, this process will need to build native modules. This may require a more complex build
environment, and notably requires Python 2.7. If you hit any problems with this, we recommend you try the
alternative standalone install below instead.
### Standalone install
If you don't have node or a working pre-gyp environment, you can still install the CLI as a standalone
binary. **This is experimental and may not work perfectly yet in all environments**, but it seems to work
well in initial cross-platform testing, so it may be useful, and we'd love your feedback if you hit any issues.
To install the CLI as a standalone binary:
* Download the latest zip for your OS from https://github.com/resin-io/resin-cli/releases.
* Extract the contents, putting the `resin-cli` folder somewhere appropriate for your system (e.g. `C:/resin-cli`, `/usr/local/lib/resin-cli`, etc).
* Add the `resin-cli` folder to your `PATH` ([Windows instructions](https://www.computerhope.com/issues/ch000549.htm), [Linux instructions](https://stackoverflow.com/questions/14637979/how-to-permanently-set-path-on-linux-unix), [OSX instructions](https://stackoverflow.com/questions/22465332/setting-path-environment-variable-in-osx-permanently))
* Running `resin` in a fresh command line should print the resin CLI help.
To update in future, simply download a new release and replace the extracted folder.
Have any problems, or see any unexpected behaviour? [Please file an issue!](https://github.com/resin-io/resin-cli/issues/new)
### Login
```sh
$ ./bin/resin
$ resin login
```
## Tests
_(Typically useful, but not strictly required for all commands)_
You can run the [Mocha](http://mochajs.org/) test suite, you can do:
### Run commands
```sh
$ gulp test
```
Take a look at the full command documentation at [https://docs.resin.io/tools/cli/](https://docs.resin.io/tools/cli/#table-of-contents
), or by running `resin help`.
## Development mode
### Bash completions
The following command will watch for any changes and will run a linter and the whole test suite:
Optionally you can enable tab completions for the bash shell, enabling the shell to provide additional context and automatically complete arguments to`resin`. To enable bash completions, copy the `resin-completion.bash` file to the default bash completions directory (usually `/etc/bash_completion.d/`) or append it to the end of `~/.bash_completion`.
```sh
$ gulp watch
```
FAQ
---
If you set `DEBUG` environment variable, errors will print with a stack trace:
### Where is my configuration file?
```sh
$ DEBUG=true resin ...
```
The per-user configuration file lives in `$HOME/.resinrc.yml` or `%UserProfile%\_resinrc.yml`, in Unix based operating systems and Windows respectively.
## Documentation
The Resin CLI also attempts to read a `resinrc.yml` file in the current directory, which takes precedence over the per-user configuration file.
You can renegerate the documentation with:
### How do I point the Resin CLI to staging?
```sh
$ npm run-script doc
```
The easiest way is to set the `RESINRC_RESIN_URL=resinstaging.io` environment variable.
## Manual pages
Alternatively, you can edit your configuration file and set `resinUrl: resinstaging.io` to persist this setting.
UNIX manual pages reside in `man/`
### How do I make the Resin CLI persist data in another directory?
You can regenerate UNIX `roff` manual pages from markdown with:
The Resin CLI persists your session token, as well as cached images in `$HOME/.resin` or `%UserProfile%\_resin`.
```sh
$ gulp man
```
Pointing the Resin CLI to persist data in another location is necessary in certain environments, like a server, where there is no home directory, or a device running resinOS, which erases all data after a restart.
If you add a new `man` page, remember to add the generated filename to the `man` array in `package.json`.
You can accomplish this by setting `RESINRC_DATA_DIRECTORY=/opt/resin` or adding `dataDirectory: /opt/resin` to your configuration file, replacing `/opt/resin` with your desired directory.
## Caveats
Support
-------
- Some interactive widgets don't work on [Cygwin](https://cygwin.com/). If you're running Windows, it's preferrable that you use `cmd.exe`, as `Cygwin` is [not official supported by Node.js](https://github.com/chjj/blessed/issues/56#issuecomment-42671945).
If you're having any problems, check our [troubleshooting guide](https://github.com/resin-io/resin-cli/blob/master/TROUBLESHOOTING.md) and if your problem is not addressed there, please [raise an issue](https://github.com/resin-io/resin-cli/issues/new) on GitHub and the resin.io team will be happy to help.
You can also get in touch with us in the resin.io [forums](https://forums.resin.io/).
License
-------
The project is licensed under the Apache 2.0 license.
This document contains common issues related to the Resin CLI, and how to fix them.
### After burning to an sdcard, my device doesn't boot
- The downloaded image is not complete (download was interrupted).
Please clean the cache (`%HOME/.resin/cache` or `C:\Users\<user>\_resin\cache`) and run the command again. In the future, the CLI will check that the image is not complete and clean the cache for you.
### I get a permission error when burning to an sdcard
- The SDCard is locked.
### I get EINVAL errors on Cygwin
The errors look something like this:
```
net.js:156
this._handle.open(options.fd);
^
Error: EINVAL, invalid argument
at new Socket (net.js:156:18)
at process.stdin (node.js:664:19)
at Object.Interface.createInterface (C:\cygwin\home\Juan Cruz Viotti\Projects\resin-cli\node_modules\inquirer\node_modules\readline2\index.js:31:43)
at PromptUI.UI (C:\cygwin\home\Juan Cruz Viotti\Projects\resin-cli\node_modules\inquirer\lib\ui\baseUI.js:23:40)
at new PromptUI (C:\cygwin\home\Juan Cruz Viotti\Projects\resin-cli\node_modules\inquirer\lib\ui\prompt.js:26:8)
at Object.promptModule [as prompt] (C:\cygwin\home\Juan Cruz Viotti\Projects\resin-cli\node_modules\inquirer\lib\inquirer.js:27:14)
```
- Some interactive widgets don't work on `Cygwin`. If you're running Windows, it's preferrable that you use `cmd.exe`, as `Cygwin` is [not official supported by Node.js](https://github.com/chjj/blessed/issues/56#issuecomment-42671945).
### I get `Invalid MBR boot signature` when configuring a device
This error, accompanied with something like: `Expected 0xAA55, but saw 0x29FE` usually indicates a corrupted device operating system image in the cache, due to bad a internet connection during the download process.
Try clearing the cache with the following command and trying again:
```sh
$ rm -rf $HOME/.resin/cache
```
Or in Windows:
```sh
> del /s /q %UserProfile%\_resin\cache
```
### I get `EACCES: permission denied` when logging in
The Resin CLI stores the session token in `$HOME/.resin` or `C:\Users\<user>\_resin` in UNIX based operating systems and Windows respectively. This error usually indicates that the user doesn't have permissions over that directory, which can happen if you ran the Resin CLI as `root`, and thus the directory got owned by him.
help:'Use this command to create a new resin.io application.\n\nYou can specify the application type with the `--type` option.\nOtherwise, an interactive dropdown will be shown for you to select from.\n\nYou can see a list of supported device types with\n\n $ resin devices supported\n\nExamples:\n\n $ resin app create MyApp\n $ resin app create MyApp --type raspberry-pi',
help:'Use this command to list all your applications.\n\nNotice this command only shows the most important bits of information for each app.\nIf you want detailed information, use resin app <id> instead.\n\nExamples:\n\n $ resin apps',
help:'Use this command to remove a resin.io application.\n\nNotice this command asks for confirmation interactively.\nYou can avoid this by passing the `--yes` boolean option.\n\nExamples:\n\n $ resin app rm 91\n $ resin app rm 91 --yes',
help:'Use this command to associate a project directory with a resin application.\n\nThis command adds a \'resin\' git remote to the directory and runs git init if necessary.\n\nExamples:\n\n $ resin app associate 91\n $ resin app associate 91 --project my/app/directory',
help:'Use this command to initialise a directory as a resin application.\n\nThis command performs the following steps:\n - Create a resin.io application.\n - Initialize the current directory as a git repository.\n - Add the corresponding git remote to the application.\n\nExamples:\n\n $ resin init\n $ resin init --project my/app/directory',
help:'Use this command to login to your resin.io account.\nYou need to login before you can use most of the commands this tool provides.\n\nYou can pass your credentials as `--username` and `--password` options, or you can omit the\ncredentials, in which case the tool will present you with an interactive login form.\n\nExamples:\n\n $ resin login --username <username> --password <password>\n $ resin login',
options:[
{
signature:'username',
parameter:'username',
description:'user name',
alias:'u'
},{
signature:'password',
parameter:'password',
description:'user password',
alias:'p'
}
],
action:function(params,options,done){
varhasOptionCredentials;
hasOptionCredentials=!_.isEmpty(options);
if(hasOptionCredentials){
if(!options.username){
returndone(newError('Missing username'));
}
if(!options.password){
returndone(newError('Missing password'));
}
}
returnasync.waterfall([
function(callback){
if(hasOptionCredentials){
returncallback(null,options);
}else{
returnvisuals.widgets.login(callback);
}
},function(credentials,callback){
returnresin.auth.login(credentials,callback);
}
],done);
}
};
exports.logout={
signature:'logout',
description:'logout from resin.io',
help:'Use this command to logout from your resin.io account.o\n\nExamples:\n\n $ resin logout',
permission:'user',
action:function(params,options,done){
returnresin.auth.logout(done);
}
};
exports.signup={
signature:'signup',
description:'signup to resin.io',
help:'Use this command to signup for a resin.io account.\n\nIf signup is successful, you\'ll be logged in to your new user automatically.\n\nExamples:\n\n $ resin signup\n Email: me@mycompany.com\n Username: johndoe\n Password: ***********\n\n $ resin signup --email me@mycompany.com --username johndoe --password ***********\n\n $ resin whoami\n johndoe',
help:'Use this command to remove a device from resin.io.\n\nNotice this command asks for confirmation interactively.\nYou can avoid this by passing the `--yes` boolean option.\n\nExamples:\n\n $ resin device rm 317\n $ resin device rm 317 --yes',
help:'Use this command to identify a device.\n\nIn the Raspberry Pi, the ACT led is blinked several times.\n\nExamples:\n\n $ resin device identify 23c73a12e3527df55c60b9ce647640c1b7da1b32d71e6a39849ac0f00db828',
help:'Use this command to rename a device.\n\nIf you omit the name, you\'ll get asked for it interactively.\n\nExamples:\n\n $ resin device rename 317 MyPi\n $ resin device rename 317',
permission:'user',
action:function(params,options,done){
returnasync.waterfall([
function(callback){
if(!_.isEmpty(params.name)){
returncallback(null,params.name);
}
returnvisuals.widgets.ask('How do you want to name this device?',null,callback);
help:'Use this command to download the OS image of a certain application and write it to an SD Card.\n\nNote that this command requires admin privileges.\n\nIf `device` is omitted, you will be prompted to select a device interactively.\n\nNotice this command asks for confirmation interactively.\nYou can avoid this by passing the `--yes` boolean option.\n\nYou can quiet the progress bar by passing the `--quiet` boolean option.\n\nYou may have to unmount the device before attempting this operation.\n\nYou need to configure the network type and other settings:\n\nEthernet:\n You can setup the device OS to use ethernet by setting the `--network` option to "ethernet".\n\nWifi:\n You can setup the device OS to use wifi by setting the `--network` option to "wifi".\n If you set "network" to "wifi", you will need to specify the `--ssid` and `--key` option as well.\n\nExamples:\n\n $ resin device init --application 91 --network ethernet\n $ resin device init /dev/disk2 --application 91 --network wifi --ssid MyNetwork --key secret',
help:'Use this command to list all environment variables for a particular application.\nNotice we will support per-device environment variables soon.\n\nThis command lists all custom environment variables set on the devices running\nthe application. If you want to see all environment variables, including private\nones used by resin, use the verbose option.\n\nExample:\n\n $ resin envs --application 91\n $ resin envs --application 91 --verbose',
help:'Use this command to remove an environment variable from an application.\n\nDon\'t remove resin specific variables, as things might not work as expected.\n\nNotice this command asks for confirmation interactively.\nYou can avoid this by passing the `--yes` boolean option.\n\nExamples:\n\n $ resin env rm 215\n $ resin env rm 215 --yes',
help:'Use this command to add an enviroment variable to an application.\n\nYou need to pass the `--application` option.\n\nIf value is omitted, the tool will attempt to use the variable\'s value\nas defined in your host machine.\n\nIf the value is grabbed from the environment, a warning message will be printed.\nUse `--quiet` to remove it.\n\nExamples:\n\n $ resin env add EDITOR vim -a 91\n $ resin env add TERM -a 91',
options:[commandOptions.application],
permission:'user',
action:function(params,options,done){
if(params.value==null){
params.value=process.env[params.key];
if(params.value==null){
returndone(newError("Environment value not found for key: "+params.key));
}else{
console.info("Warning: using "+params.key+"="+params.value+" from host environment");
help:'Use this command to clone an example application to the current directory\n\nThis command outputs information about the cloning process.\nUse `--quiet` to remove that output.\n\nExample:\n\n $ resin example clone 3',
help:'Use this command to remove a SSH key from resin.io.\n\nNotice this command asks for confirmation interactively.\nYou can avoid this by passing the `--yes` boolean option.\n\nExamples:\n\n $ resin key rm 17\n $ resin key rm 17 --yes',
help:'Use this command to associate a new SSH key with your account.\n\nIf `path` is omitted, the command will attempt\nto read the SSH key from stdin.\n\nExamples:\n\n $ resin key add Main ~/.ssh/id_rsa.pub\n $ cat ~/.ssh/id_rsa.pub | resin key add Main',
help:'Use this command to show logs for a specific device.\n\nBy default, the command prints all log messages and exit.\n\nTo limit the output to the n last lines, use the `--num` option along with a number.\nThis is similar to doing `resin logs <uuid> | tail -n X`.\n\nTo continuously stream output, and see new logs in real time, use the `--tail` option.\n\nNote that for now you need to provide the whole UUID for this command to work correctly,\nand the tool won\'t notice if you\'re using an invalid UUID.\n\nThis is due to some technical limitations that we plan to address soon.\n\nExamples:\n\n $ resin logs 23c73a12e3527df55c60b9ce647640c1b7da1b32d71e6a39849ac0f00db828\n $ resin logs 23c73a12e3527df55c60b9ce647640c1b7da1b32d71e6a39849ac0f00db828 --num 20\n $ resin logs 23c73a12e3527df55c60b9ce647640c1b7da1b32d71e6a39849ac0f00db828 --tail',
help:'Use this command to set or update a device note.\n\nIf note command isn\'t passed, the tool attempts to read from `stdin`.\n\nTo view the notes, use $ resin device <id>.\n\nExamples:\n\n $ resin note "My useful note" --device 317\n $ cat note.txt | resin note --device 317',
help:'Use this command to download the device OS configured to a specific network.\n\nEthernet:\n You can setup the device OS to use ethernet by setting the `--network` option to "ethernet".\n\nWifi:\n You can setup the device OS to use wifi by setting the `--network` option to "wifi".\n If you set "network" to "wifi", you will need to specify the `--ssid` and `--key` option as well.\n\nAlternatively, you can omit all kind of network configuration options to configure interactively.\n\nYou have to specify an output location with the `--output` option.\n\nExamples:\n\n $ resin os download 91 --output ~/MyResinOS.zip\n $ resin os download 91 --network ethernet --output ~/MyResinOS.zip\n $ resin os download 91 --network wifi --ssid MyNetwork --key secreykey123 --output ~/MyResinOS.zip\n $ resin os download 91 --network ethernet --output ~/MyResinOS.zip',
description:'write an operating system image to a device',
help:'Use this command to write an operating system image to a device.\n\nNote that this command requires admin privileges.\n\nIf `device` is omitted, you will be prompted to select a device interactively.\n\nNotice this command asks for confirmation interactively.\nYou can avoid this by passing the `--yes` boolean option.\n\nYou can quiet the progress bar by passing the `--quiet` boolean option.\n\nYou may have to unmount the device before attempting this operation.\n\nSee the `drives` command to get a list of all connected devices to your machine and their respective ids.\n\nIn Mac OS X:\n\n $ sudo diskutil unmountDisk /dev/xxx\n\nIn GNU/Linux:\n\n $ sudo umount /dev/xxx\n\nExamples:\n\n $ resin os install rpi.iso /dev/disk2',
help:'Use this command to remove a resin.io plugin.\n\nNotice this command asks for confirmation interactively.\nYou can avoid this by passing the `--yes` boolean option.\n\nExamples:\n\n $ resin plugin rm hello\n $ resin plugin rm hello --yes',
help:'Use this command to open the preferences form.\n\nIn the future, we will allow changing all preferences directly from the terminal.\nFor now, we open your default web browser and point it to the web based preferences form.\n\nExamples:\n\n $ resin preferences',
help:'Use this command to update the Resin CLI\n\nThis command outputs information about the update process.\nUse `--quiet` to remove that output.\n\nThe Resin CLI checks for updates once per day.\n\nMajor updates require a manual update with this update command,\nwhile minor updates are applied automatically.\n\nExamples:\n\n $ resin update',
"description":"This is a simple Hello, World project for node.js designed to act as a basis for future work. It demonstrates how to install native Linux packages and configure your application."
},
{
"name":"cimon",
"display_name":"Cimon",
"repository":"https://bitbucket.org/efwe/cimon",
"description":"A simple tool for reading temperatures from a USB-enabled thermometer. This project is used as the backend to efwe's awesome temperature visualisation at 123k.de.",
"description":"A Firebase-backed Digital Temperature Logger allowing you to connect devices with multiple temperature sensors to a central cloud-based datastore.",
returnconsole.log("> Major update available: "+update.current+" -> "+update.latest+"\n> Run resin update to update.\n> Beware that a major release might introduce breaking changes.\n");
};
exports.check=function(callback){
varnotifier;
notifier=updateNotifier({
pkg:packageJSON
});
if(notifier.update==null){
returncallback();
}
if(notifier.update.type==='major'){
exports.notify(notifier.update);
returncallback();
}
console.log("Performing "+notifier.update.type+" update, hold tight...");
\`--unsafe-perm\` is only required on systems where the global install directory is not user-writable.
This allows npm install steps to download and save prebuilt native binaries. You may be able to omit it,
especially if you're using a user-managed node install such as [nvm](https://github.com/creationix/nvm).
### Standalone install
Alternatively, if you don't have a node or pre-gyp environment, you can still install the CLI as a standalone
binary. **This is in experimental and may not work perfectly yet in all environments**, but works well in
initial cross-platform testing, so it may be useful, and we'd love your feedback if you hit any issues.
To install the CLI as a standalone binary:
* Download the latest zip for your OS from https://github.com/resin-io/resin-cli/releases.
* Extract the contents, putting the \`resin-cli\` folder somewhere appropriate for your system (e.g. \`C:/resin-cli\`, \`/usr/local/lib/resin-cli\`, etc).
* Add the \`resin-cli\` folder to your \`PATH\`. (
You can run this command as many times as you need, putting the new medium (SD card / USB stick) each time.
But before you can run it you need to collect the parameters and build the configuration file. Keep reading to figure out how to do it.
## Collect all the required parameters.
1.`DEVICE_TYPE`. Run
```bash
resin devices supported
```
and find the _slug_ for your target device type, like _raspberrypi3_.
1. `APP_ID`. Create an application (`resin app create APP_NAME --type DEVICE_TYPE`) or find an existing one (`resin apps`) and notice its ID.
1. `OS_VERSION`. Run
```bash
resin os versions DEVICE_TYPE
```
and pick the version that you need, like _v2.0.6+rev1.prod_.
_Note_ that even though we support _semver ranges_ it's recommended to use the exact version when doing the automated provisioning as it
guarantees full compatibility between the steps.
1. `DRIVE`. Plug in your target medium (SD card or the USB stick, depending on your device type) and run
```bash
resin util available-drives
```
and get the drive name, like _/dev/sdb_ or _/dev/mmcblk0_.
The resin CLI will not display the system drives to protect you,
but still please check very carefully that you've picked the correct drive as it will be erased during the provisioning process.
Now we have all the parameters -- time to build the config file.
## Build the config file
Interactive device provisioning process often includes collecting some extra device configuration, like the networking mode and wifi credentials.
To skip this interactive step we need to buid this configuration once and save it to the JSON file for later reuse.
Let's say we will place it into the `CONFIG_FILE` path, like _./resin-os/raspberrypi3-config.json_.
We also need to put the OS image somewhere, let's call this path `OS_IMAGE_PATH`, it can be something like _./resin-os/raspberrypi3-v2.0.6+rev1.prod.img_.
1. First we need to download the OS image once. That's needed for building the config, and will speedup the subsequent operations as the downloaded OS image is placed into the local cache.
Run:
```bash
resin os download DEVICE_TYPE --output OS_IMAGE_PATH --version OS_VERSION
```
1. Now we're ready to build the config:
```bash
resin os build-config OS_IMAGE_PATH DEVICE_TYPE --output CONFIG_FILE
```
This will run you through the interactive configuration wizard and in the end save the generated config as `CONFIG_FILE`. You can then verify it's not empty:
```bash
cat CONFIG_FILE
```
## Done
Now you're ready to run the command in the beginning of this guide.
Please note again that all of these steps only need to be done once (unless you need to change something), and once all the parameters are collected the main init command can be run unchanged.
But there are still some nuances to cover, please read below.
## Nuances
### `sudo` password on *nix systems
In order to write the image to the raw device we need the root permissions, this is unavoidable.
To improve the security we only run the minimal subcommand with `sudo`.
This means that with the default setup you're interrupted closer to the end of the device init process to enter your sudo password for this subcommand to work.
There are several ways to eliminate it and make the process fully non-interactive.
#### Option 1: make passwordless sudo.
Obviously you shouldn't do that if the machine you're working on has access to any sensitive resources or information.
But if you're using a machine dedicated to resin provisioning this can be fine, and also the simplest thing to do.
#### Option 2: `NOPASSWD` directive
You can configure the `resin` CLI command to be sudo-runnable without the password. Check [this post](https://askubuntu.com/questions/159007/how-do-i-run-specific-sudo-commands-without-a-password) for an example.
### Extra initialization config
As of June 2017 all the supported devices should not require any other interactive configuration.
But by the design of our system it is _possible_ (though it doesn't look very likely it's going to happen any time soon) that some extra initialization options may be requested for the specific device types.
If that is the case please raise the issue in the resin CLI repository and the maintainers will add the necessary options to build the similar JSON config for this step.
# Make sure the device resource is removed if there is an
# error when configuring or initializing a device image
.catch(error) ->
resin.models.device.remove(device.uuid).finally->
throwerror
.then(device) ->
console.log('Done')
returndevice.uuid
(confirmed, callback) ->
returndone()ifnotconfirmed
options.yes = confirmed
osAction.download.action(params,options,callback)
(outputFile, callback) ->
params.image = outputFile
osAction.install.action(params,options,callback)
],done)
.nodeify(done)
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
