Coder Social home page Coder Social logo

renproject / darknode-cli Goto Github PK

View Code? Open in Web Editor NEW
53.0 15.0 23.0 83.14 MB

Tool for deploying and managing Darknodes

Home Page: https://renproject.io

License: GNU General Public License v3.0

Go 95.39% Shell 4.61%
darknode golang ren cli darknode-cli digital-ocean

darknode-cli's Introduction

Darknode CLI

The Darknode CLI is a command-line interface for managing Darknodes on Ren. It is installed on your local workspace, and will automatically create and update machines for you. Currently it supports macOS, Linux and Window(see Windows Instructions).

Getting Started on AWS

To jump straight into running your first Darknode on AWS, checkout our Getting Started on AWS tutorial.

Getting Started on Digital Ocean

Checkout the instructions for Creating a Personal Access Token on Digital Ocean.

Installing the tool

To download and install the Darknode CLI, open a terminal and run:

curl https://www.github.com/renproject/darknode-cli/releases/latest/download/install.sh -sSfL | sh

This will download the required binaries and install them to the $HOME/.darknode directory. Open a new terminal to begin using the Darknode CLI.

Updating the tool

Before updating the Darknode CLI, please make sure you do not have the CLI running in any terminal.

To update your Darknode CLI, open a terminal and run:

curl https://www.github.com/renproject/darknode-cli/releases/latest/download/update.sh -sSfL | sh

Note: make sure you are using Terraform version 0.12! To upgrade Terraform, download the executable for your operating system from https://www.terraform.io/downloads.html and copy it to $HOME/.darknode/bin/terraform.

This will update your Darknode CLI to the latest version without affecting any of your deployed nodes.

Usage

Here there be dragons!

These guidelines are for advanced users. If you just want to see what deploying a Testnet Darknode is like, checkout our Getting Started on AWS tutorial.

Deploy a Darknode

AWS

To deploy a Darknode on AWS, open a terminal and run:

darknode up --name my-first-darknode --aws --aws-access-key YOUR-AWS-ACCESS-KEY --aws-secret-key YOUR-AWS-SECRET-KEY

The Darknode CLI will automatically use the credentials available at $HOME/.aws/credentials if you do not explicitly set the --access-key and --secret-key arguments. By default it will use the credentials of default profile,but you can specify which profile you want to use for deployment by:

darknode up --name my-first-darknode --aws --aws-profile PROFILE-NAME

You can also specify the region and instance type you want to use for the Darknode:

darknode up --name my-first-darknode --aws --aws-access-key YOUR-AWS-ACCESS-KEY --aws-secret-key YOUR-AWS-SECRET-KEY --aws-region eu-west-1 --aws-instance t2.small

The default instance type is t3.micro and region will be random. You can find all available regions and instance types at AWS.

Digital Ocean

Follow the steps in the tutorial to create a API token. To deploy a Darknode on Digital Ocean, open a terminal and run:

darknode up --name my-first-darknode --do --do-token YOUR-API-TOKEN

You can also specify the region and droplet size you want to use for the Darknode:

darknode up --name my-first-darknode --do --do-token YOUR-API-TOKEN --do-region nyc1 --do-droplet s-2vcpu-2gb

The default droplet size is s-1vcpu-1gb and region will be random. Be aware some region and droplet size are not available to all users.

You can find all available regions and droplet size slug by using the digital ocean API.

Showing register page

The darknode-cli will show a link for registering your darknode after finish deploying. Don't panic if you lose the url. Simply run

darknode register YOUR-DARKNODE-NAME

which prints the registering link in the terminal and tries to open the url using your default browser.

Destroy a Darknode

WARNING: Before destroying a Darknode make sure you have de-registered it, and withdrawn all fees earned! You will not be able to destroy your darknode if it's not fully deregistered. The CLI will guide you to the page where you can deregister your node

Destroying a Darknode will turn it off and tear down all resources allocated by the cloud provider. To destroy a Darknode, open a terminal and run:

darknode destroy my-first-darknode

To avoid the command-line prompt confirming the destruction, use the --force argument:

darknode destroy my-first-darknode --force

We do not recommend using the --force argument unless you are developing custom tools that manage your Darknodes automatically.

Resize a Darknode

To resize the instance type your Darknode is using, open a terminal and run:

darknode resize YOUR-DARKNODE-NAME NEW_INSTANCE_TYPE

If you are using AWS, you will need to replace the NEW_INSTANCE_TYPE field with the AWS EC2 instance type you wish to use, e.g. t3.micro or t2.medium."

darknode resize YOUR-DARKNODE-NAME t3.small

You can find all available instance types at AWS.

If you are using DigitalOcean, you will need to replace the NEW_INSTANCE_TYPE field with the DigitalOcean droplet slug you wish to use, e.g. s-1vcpu-2gb or s-1vcpu-1gb.

darknode resize YOUR-DARKNODE-NAME s-1vcpu-2gb

Changing droplet size will not change the storage volume of the instance, this allows user to resize down to a lower plan in the future. You can find all available droplet slugs at Digital Ocean Standard plans and DigitalOcean API Slugs

If you accidentally try to resize to a invalid instance, the darknode will be stopped. You need to run the command again with a valid instance type to restart the darknode.

List all Darknodes

The Darknode CLI supports deploying multiple Darknodes. To list all available Darknodes, open a terminal and run:

darknode list

Start/Stop/Restart Darknode

To turn off your darknode, open a terminal and run:

darknode stop my-first-darknode

Note this won't shut down the cloud instance so you will still be charged by your cloud provider. If it is already off, stop will do nothing.

To turn on your darknode, open a terminal and run:

darknode start my-first-darknode

If it is already on, start will do nothing.

To restart your darknode, open a terminal and run:

darknode restart my-first-darknode

SSH into Darknode

To access your Darknode using SSH, open a terminal and run:

darknode ssh my-first-darknode

Update a Darknode

To update your Darknode to the latest stable version, open a terminal and run:

darknode update YOUR-DARKNODE-NAME

To update the configuration of your darknode, first edit the local version of config, by running:

nano $HOME/.darknode/darknodes/YOUR-DARKNODE-NAME/config.json

and now run:

darknode update my-first-darknode --config

Withdraw balance from the Darknode

To withdraw any ETH left in the darknode address, open a terminal and run:

darknode withdraw YOUR-DARKNODE-NAME --address RECEIVER-ETHEREUM-ADDRESS

Note: This will also withdraw any REN in the darknode address. Keep in mind this will only withdraw the ETH and REN the address holds directly, not the rewards it receives by matching orders.

Running commands(script) on your darknode

If you want to run a specific command on your darknode. open a terminal and run:

darknode exec YOUR-DARKNODE-NAME --script "whoami"

or a script file

darknode exec YOUR-DARKNODE-NAME --file test.sh

Github rate limiting

You can set the GITHUB_TOKEN environment variable to increase your github rate limit.

darknode-cli's People

Contributors

0x31 avatar divyakoshy avatar jazg avatar loongy avatar negaex avatar pega88 avatar tok-kkk avatar vinceau avatar yangchenyun avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

darknode-cli's Issues

Make code self-contained and runnable

Currently when you build and run the source code, some additional steps are required.

Ideally, one should be able to checkout the code and $go run. Currently, you need to create the ~/.darknode folders and more importantly, manually copy over the shell scripts and terraform templates before the checked-out code can run.

CLI should validate any Darknodes provided as inputs

Currently if I run darknode stop non-existent-darknode I get:

failed to systemctl --user stop darknode [non-existent-darknode]: open ~/.darknode/darknodes/non-existent-darknode/ssh_keypair: no such file or directory
open ~/.darknode/darknodes/non-existent-darknode/ssh_keypair: no such file or directory

And if I run darknode ssh non-existent-darknode I just get:

exit status 1

Might be better to return something like:

[non-existent-darknode] not found

Support -devnet and -testnet suffixes for release versions

Currently, our versioning system does not differentiate between Devnet, Testnet, and Mainnet releases. This has been fine during internal development, but is very likely to cause issues when community members are managing their own Darknodes.

This issue proposes the -devnet and -testnet suffixes to versions. For example, running darknode update 0.2.8-devnet4 would look at https://github.com/renproject/darknode-release for a release labelled 0.2.8-devnet4, download it, and deploy it to the Darknode.

Design

Format

All versions must match the following regex: [0-9]+\.[0-9]+\.[0-9]+(-(devnet|testnet)[0-9]+)?.

Rules

  • Versions with no suffix are considered stable enough for Mainnet. Only commits that are merged into the master branch are allowed to be tagged for stable release.
  • Versions with the -testnet[0-9]+ suffix are considered to be beta releases that are stable enough for Testnet, but not Mainnet.
  • Versions with the -devnet[0-9]+ suffix are considered to be alpha releases that are not stable enough for Testnet, or Mainnet, but are stable enough for Devnet.
  • Version x.y.z is greater than x.y.z-testnet* which is greater than x.y.z-devnet*. The suffix number determines ordering within the -testnet and -devnet for the same release version.

Examples

  • 0.2.8 is stable and usable on Mainnet.
  • 0.3.0-testnet1 is the 1st release of 0.3.0 for Testnet
  • 0.3.1-devnet4 is the 4th release of 0.3.1 for Devnet

Tagging

Commits in https://github.com/renproject/darknode should be tagged with their release version. This should prompt GitHub Actions to automatically build it, and release it to the https://github.com/renproject/darknode-release repo.

Tagging will be done manually for now, but if this process is working well for the team then we can look into automate it.

darknode up fails for legacy AWS accounts in some regions

Old AWS Accounts may not have a default VPC in all regions. See

https://aws.amazon.com/blogs/aws/amazon-ec2-update-virtual-private-clouds-for-everyone/
https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/default-vpc.html

I was able to work around by bringing a node up in a region I've never used before, however, I would like to run nodes in many regions including first and foremost us-east-1. There's no way to convert an account from classic to VPC-only, so I would need to create a new AWS account. Can you add a flag --aws-vpc-id and --aws-subnet-id so that users can specify what VPC to launch their instance into? This makes sense from a security perspective, too, since there might be other stuff running within default VPC which is not properly connected to darknodes.

Improve CI/CD for the repo.

Object

We want to have a test suite build into our CI system which helps us reduce the amount of manual testing. The test suite should cover most of the CLI command and tests on different VPSs and systems.

Design

Testing Accounts

We should create separate accounts or sub-users of our main account and limit the service access. This ensures the safety of our VPS main account. We also need to make sure the account credential is private. (i.e. set up as Github secrets or environment variables)

Testing cases

CI should be triggered on every new commit. Both CircleCI and GitHub Actions allow you to skip certain commits if you have [skip ci] in the title or description. source.It should cover both positive and negative test cases. And tests against different VPS should be running parallel if that's possible. It should test the following cases:

  • Test the CLI binary is working and returns the expected version.
  • up a couple of nodes with different options and destroy them with different options.
  • Deploy a node, testing following cases before destroy
    • check start, stop and restart commands are able to control the darknode status.
    • check list command show the correct info of the darknode
    • check update command is able to compare the versions and do an update when outdated.
    • try resize the darknode to an upper tier and a lower tier and check the darknode status
    • check exec command with different options

Discussion

  • Github Actions VS CircleCI
    I personally favour CircleCI as we already have everything set up in CircleCI and it has some features which Github Actions doesn't have. Github Action is also good in terms of github integration, the setup should be more easy and friendly than CircleCi. We can achieve the same result with Github Actions, but with more developing time.

  • Not sure how can we test the ssh command in CI.

Backup a running darknode and restore it.

Object

  • We want the CLI to be able to backup a darknode from its current status to a single file with password encryption.
  • We want the CLI to be able to restore a darknode from the backup file by providing the correct password.
    These will give us the ability to migrate darknode to another VPS.

Design

We'll introduce a new command backup to backup the current status of a darknode.
It should take a string parameter which is the darknode name and

  1. SSH into the darknode and stop the darknode service.
  2. Create a copy for the database and config file
  3. Compress the files into a tarball and encrypt it using openssl enc command
  4. Clean up those temporary files.
  5. Download the encrypted file to the provided location.

Reason we don't use zip is that it's not pre-installed in ubuntu. Source for using openssl

When restoring the backup, we can

  1. Integrate it with current up command.

Or

  1. have a new restore command.

We'll introduce a new flag which takes a backup file.
It should

  1. Check existence of the backup file and try to decrypt it with given password.
  2. Deploy the instance as normal
  3. Copy backup file to the instance.
  4. Extract files from the tarball.
  5. Setup service and start darknode as normal.
  6. Clean up

We should also let the user know the darknode will be stopped by running the backup command.

Discussion

  • Do we want to have a new command when restoring the darknode?
  • Do we want to restart the darknode service after finishing backup?
  • Do we want to support batch operation for the backup command? (i.e. allow --tags option)

Does not work on Raspberry PI

I tried to install on Raspberry pi, but got an error:
unsupported os type or architecture

I used PI 3 and Ubuntu:

root@DarknodePi:~# uname -a
Linux DarknodePi 5.3.0-1008-raspi2 #9-Ubuntu SMP Fri Oct 18 13:26:35 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux

manual installation

Is the CLI command using api key the only supported installation method currently or is there any manual installation and setup documentation?

Documentation for manual installation

I cannot find a documentation for "regular installation", that is, one that is not automated.

I would like to install a node on one of my servers, but I want to understand each step involved. That is so I can feel confident about my understand of what is running on my server, also so I can troubleshoot any issues as necessary.

Help to install DarkNode in a private cloud

Hello guys

I'm interesting in deploy a DarkNode but reading the documentation i realized that the "darknode up" command requires an Google Cloud/AWS/Digital Ocean API Key to deploy a darknode. How can i deploy it in my own Generic VPS? Is this possible? Does have a doc/tutorial with the steps for this?

Marc

darknode DO-setup fails

I'm trying to set up a darknode with the latest cli but have runned in a problem.

I have an access key setup on DO and when I follow the instructions for setting up a darknode on DO and run

darknode up --name {darknodename} --do --do-token {do-api-token}

the process exits with the following output:

digitalocean_droplet.darknode (remote-exec): + get_latest_release linux-amd64
digitalocean_droplet.darknode (remote-exec): + + wget -qi -
digitalocean_droplet.darknode (remote-exec): tr -d "
digitalocean_droplet.darknode (remote-exec): + cut -d : -f 2,3
digitalocean_droplet.darknode (remote-exec): + grep browser_download_url.*darknode-linux-amd64.zip
digitalocean_droplet.darknode (remote-exec): + curl -s https://api.github.com/repos/republicprotocol/darknode-cli/releases/latest
digitalocean_droplet.darknode (remote-exec): + mv darknode-linux-amd64.zip darknode.zip
digitalocean_droplet.darknode (remote-exec): mv: cannot stat 'darknode-linux-amd64.zip': No such file or directory
digitalocean_droplet.darknode (remote-exec): + unzip darknode.zip
digitalocean_droplet.darknode (remote-exec): unzip:  cannot find or open darknode.zip, darknode.zip.zip or darknode.zip.ZIP.
digitalocean_droplet.darknode (remote-exec): + mkdir -p ./.darknode
digitalocean_droplet.darknode (remote-exec): + mv ./darknode-config.json ./.darknode/config.json
digitalocean_droplet.darknode (remote-exec): + cd darknode
digitalocean_droplet.darknode (remote-exec): /tmp/terraform_1510456658.sh: 21: cd: can't cd to darknode
digitalocean_droplet.darknode (remote-exec): + chmod +x install.sh

Error: Error applying plan:

1 error(s) occurred:

* digitalocean_droplet.darknode: error executing "/tmp/terraform_1510456658.sh": Process exited with status 1

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.


exit status 1

I'm on arch linux with manjaro 18.1 if it matters.

Greatful for any help

Renaming a darknode name doesn´t get implemented properly

My darknode name is node1 and later I decided to change it to powernode1.
In the darknode command center it looks correct and showing my newly renamed node.

However when I withdraw my eth through terminal and run this:
darknode withdraw powernode1 --address myaddress

I get this error:
node with the name doesn't exist

By checking my node list, I realize it is still using the original darknode name which was node1.
It should use my new defined name... otherwise I have to remember the first darknode I used when I first register. Its fine for the techy people but not very user friendly for the average Joe.

Rename darknode-cli to nodectl

  • Rename the repo to nodectl
  • Update the install/update URLs
  • Update the documentation
  • Update the codebase to reflect the change

Offering help for Google Cloud integration

At the moment the CLI only allows deployments on AWS and DO. As a Google Cloud expert, I'm offering my assistance in integration with GCP. I could not find a branch nor PR relating to GCP deployment of the darknode, so not sure at what stage that development is, since it says "coming soon".

Rate Limiting of api.github.com requests

darknode up hits a rate limited github API; I would like to be able to do

export GITHUB_TOKEN=${my_secret_github_token}

and have the CLI use this token if present in the environment so that I get the benefit of a higher rate limit.

$ darknode up --do --do-token ${TOKEN} --do-region $REGION --name ${NAME}
GET https://api.github.com/repos/renproject/darknode-release/releases?per_page=25:
403 API rate limit exceeded for REDACTED.
(But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)
[rate reset in 5m46s]

It looks like by convention this token is called GITHUB_TOKEN, see github docs

Can’t add gas to Command center

I cannot add ETH via the UI.

Whenever I click on Deposit I receive a message that says "Unable to complete transaction: [Chaosnet-production] Invalid ETH amount - please try again"

I wonder does this have anything to do with the fact that Ren VM hasn't released Mainnet yet.

I was just watching an interview on Nuggets News and Loong Wang was saying something about not wanting people to lose their money etc.,

I may be jumping the gun.

I knew I would have an initial waiting period for my darknode to be registered but now it's saying I am registered but it also gives a notification that I have a low gas balance and that the node won't earn fees if it runs out of ETH.

Deploying dark nodes failure

Deploying dark nodes ...

Error: Missing required argument

on main.tf line 55, in resource "digitalocean_droplet" "darknode":
55: connection {

The argument "host" is required, but no definition was found.

exit status 1

Help installing Darknode CLI- command not found

I installed Darknode CLI
curl https://www.github.com/renproject/darknode-cli/releases/latest/download/install.sh -sSfL | sh

and saw the green text
export PATH=$PATH:$HOME/ .darknode/bin Done! Restart terminal and run the command below to begin. darknode up --help

I opened new terminal and ran

darknode --version
darknode up --help

getting command not found: darknode

Darknode on k8s

Hey everyone! How i can run darknode on k8s? Is there any docs for run it in a docker container?

install of darknode failed for digital ocean

I just tried to install a darknode using digital ocean.
Transcript here:
~ % darknode up --name darknode_1 --do --do-token <MY_TOKEN>

Initializing the backend...

Initializing provider plugins...

  • Checking for available provider plugins...
  • Downloading plugin for provider "digitalocean" (terraform-providers/digitalocean) 2.8.0...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

  • provider.digitalocean: version = "~> 2.8"

Warning: registry.terraform.io: This version of Terraform has an outdated GPG key and is unable to verify new provider releases. Please upgrade Terraform to at least 0.12.31 to receive new provider updates. For details see: https://discuss.hashicorp.com/t/hcsec-2021-12-codecov-security-event-and-hashicorp-gpg-key-exposure/23512

Warning: registry.terraform.io: For users on Terraform 0.13 or greater, this provider has moved to digitalocean/digitalocean. Please update your source in required_providers.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
Deploying darknode ...
digitalocean_ssh_key.darknode: Creating...

Error: Provider produced inconsistent result after apply

When applying changes to digitalocean_ssh_key.darknode, provider
"registry.terraform.io/-/digitalocean" produced an unexpected new value for
was present, but now absent.

This is a bug in the provider, which should be reported in the provider's own
issue tracker.

exit status 1

Rebuild .darknode directory

To connect back to the already deployed and running darknode (running and fully funded)..

What are the recovery steps for a user to freshly re-build / configure the .darknode folder if it is lost or deleted? SSH URLs and connection files + details about the darknodes should be recovered in some way if the user loses this .darknode folder.

Again, this is assuming the user has already deployed the darknode and later accidentally lost the critical folder to allow the user to connect back to the darknode.

422 Region is not available

after running "deploying darknode" command
darknode up --network testnet --name my-first-darknode --do --do-token YOUR-API-TOKEN

got error message
"digitalocean_droplet.darknode: Error creating droplet: POST https://api.digitalocean.com/v2/droplets: 422 Region is not available"

solved it by running the next command on the user guide, selecting the region.

using digital ocean with macOSX

Disk is not encrypted in AWS?!

The disk / volume of the t3.micro AWS instance is not encrypted? I guess all REN related data on the disk is encrypted - but why not also encrypt the entire disk? Better safe - than sorry in this crypto world - right?!

If you think it is a good idea - you should update the terraform script and/or add some manually steps to the guide. How to make a snapshot, create a new and encrypted volumen from the snapshot and attach it to the EC2 instance instead of the old one.

Besides this: Thank you for a great idea and Amazon work! Bravo Team REN! 🤓🙌🏼🚀

access darknode ui from a different client machine

how do i access my darknode from a different client machine than the one i used to create it; in other words, how to connect darknode cli on other client to preexisting darknode?

i still have access to cloud server and api key.

basically, i would like to separate out server management and custody.

thanks.

Migration function between cloud providers.

We need a function similar to "resize".
Only difference will be that "migration" - will transfer already registered Darknode, to another provider. Without loss of registration of the dark node. This can be useful if one of the providers is experiencing global problems, for example if AWS has a massive failure (or service degradation) and Darknode owner quickly notices failure, they should be able to migrate the Darknode to another provider.

Examle:
# darknode migrate YOUR-DARKNODE-NAME --do --do-token YOUR-API-TOKEN
or
# darknode migrate YOUR-DARKNODE-NAME --aws --aws-access-key YOUR-AWS-ACCESS-KEY --aws-secret-key YOUR-AWS-SECRET-KEY

This will not only reduce the technical risks, but also protect us from the risks of changing license agreements against cryptocurrencies.
And it would be good if the command "darknode list" showed on what cloud provider Darknode works.

Show darknode version

Object

  • We want the CLI to be able to show the version of each darknode.
  • (Optional)We want the CLI to be able to show if the darknode is running. We can show it from the command center or we can do it in both.

Design

Status

To check if a darknode is running, we can simply send a queryStat request to darknode and check the status code in the response. It's a bit heavy for the list command to check if the darknode is running properly(i.e progress in hyperdrive, participate in execution...). We might need a separate command for that or show these info from via the command centre. The output should be one of Yes or No or N/A(no internet connection)

VERSION

Current darknode has an issue with its version system, so the CLI uses a version file inside the darknode instance (~/.darknode/version) to keep tracking its version. The version file is created when user runs the up command and successfully deploy a node. The version file will be set to the latest version number when created and will be updated when user runs the update command.
If we want to implement this issue before the darknode version system gets fixed. We can always rely on the content of the ~/.darknode/version file.

Nothing we can do if user modifies the version manually.

If we want to wait for a fix of the darknode version system, there are two ways we can get the version from darknode binary.

  1. Sending a queryStat request and extract the version from the response. This approach requires the darknode to be running.
  2. SSH into the darknode and run ~/.darknode/bin/darknode --version. This approach requires the binary is valid and exists at expect location.

The (1) approach is faster than (2) and can get the status information from the same request.

Implementation

The implementation will depend on which approach we choose(or use both) and whether we want to show the status.
Some things we must have.

  • Checks should be done in parallel and have a reasonable context.
  • If the implementation involves sending requests or ssh, it should handle situations when internet connection is disabled.

Add update subcommand

It is no longer necessary to have Darknodes automatically update themselves. It is now preferable to allow Darknode operators to explicitly decide that they want to accept an update. To this end, the automatic update services have been stripped from the Darknode and we need to add an update subcommand to the CLI.

It should look like:

$ darknode update -version x.y.z

It should do the following:

  • Update to latest version when there is no -version option.
  • Update Darknodes by name.
  • Update Darknodes by tag.
  • Cannot update to version lower than the current Darknode version.
  • SSH into Darknode and download binary from GitHub Release, install, and restart service.

Update dependencies to newer stable version

Object

Some of our dependencies haven't been updated for a long time.
We should update them to newer stable version to include those bug fixes and performance improvement.

Design

  • We use v1 of urfave/cli since v2 was still in beta at the time we started. v2 is the recommended version than v1. We should migrate our code from v1 to v2.
  • The latest go-ethereum stable version is v1.9.15. This also upgrades the minimum go version to 1.13 which we should put in our docs.
  • Remove unused dependencies and clean up the go module

Implementation

  • Follow the migration guide to upgrade urfave/cli to v2
  • Upgrade go-ethereum to 1.9.15 and update minimum required go version
  • Run go mod tidy to clean up our go module

Allow darknode migration across cloud provider regions

Summary

Allow a migration of darknodes across cloud provider regions - this is related to #22 - but staying with the currently selected provider.

Basic example (aws)

darknode migrate YOUR-DARKNODE-NAME --source-aws-region sa-east-1 --target-aws-region eu-west-1

Motivation

  • allow an "internal" migration and avoid the lengthy deregister/destroy process - saving time, money, fees...
  • react to issues within the current region, e.g. longer downtimes, instance type unavailability changes etc.
  • potentially save cost since pricing across "random" regions differ

Help finding functioning darknode on my machine

My darknode is functioning correctly according to command center but when I type the command darknode list into terminal on my mac it says command not found... no darknode commands work on terminal and the only files I am able to find are my backup files which are being stored on dropbox.

I am wondering if I should one of the following...

  • Reinstall CLI and see if my existing node appears
  • Restore my node from my backup

As I mentioned this is currently functioning correctly and accruing rewards, I only discovered this issue because I was trying to withdraw my remaining ETH after the update.

Any help is much appreciated. Thank you.

Darknode creation fails on DigitalOcean

darknode up --name dark2 --do --do-token XXX

Initializing the backend...

Initializing provider plugins...
- Finding latest version of hashicorp/digitalocean...
╷
│ Error: Failed to query available provider packages
│ 
│ Could not retrieve the list of available versions for
│ provider hashicorp/digitalocean: provider registry
│ registry.terraform.io does not have a provider named
│ registry.terraform.io/hashicorp/digitalocean
│ 
│ Did you intend to use digitalocean/digitalocean? If so, you
│ must specify that source address in each module which
│ requires that provider. To see which modules are currently
│ depending on hashicorp/digitalocean, run the following
│ command:
│     terraform providers
╵

exit status 1

Make AWS SSH security group CIDR configurable

Hi, i noticed the below in the Terraform template:

// SSH
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}

If there is no other use apart from the initial setup and maintenance, SSH should not be exposed to the wider internet.

It would be nice to have an option to change that to another custom CIDR block.

Thank you

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.