status-im / nimbus-eth2

Nim implementation of the Ethereum Beacon Chain
https://nimbus.guide
Other
508 stars 214 forks source link

Publish a new Nimbus installation guide #3424

Open zah opened 2 years ago

zah commented 2 years ago

With the development of the Nimbus installer and the features described in https://github.com/status-im/nimbus-eth2/issues/3423, it would be possible to achieve the following simpler user experience:

Step 1) Install Nimbus through the package for your operating system

sudo apt install nimbus

Step 2) Observe that your local node is syncing

nimbus status # Prints one-line status for each running node
nimbus logs -f # Tails the logs produced by all running nodes
nimbus logs -f cl --network=prater # Tails the logs produced by the beacon nodes connected to the Prater network

Step 3) Add validator keystores

nimbus validators import <deposit-data-dir> 

Step 4) Enable metrics and REST API

nimbus config set metrics=true # Enable metrics on all local nodes
nimbus config --cl set rest=true # Enables the REST API on all beacon nodes
nimbus config --network=prater --node-name=2 set rest-port=9090 # Change the REST port on the Prater node with the nick name "2"

Step 5) Profit

We'll need to contact all authors of existing guides for Nimbus and help towards updating them.

stefantalpalaru commented 2 years ago

nimbus logs -f # Tails the logs produced by all running nodes

It's easier for us to log to syslog (through a service file redirection of stdout/stderr) than maintain our own logging infrastructure, so that command needs to be OS/distro dependent.

nimbus config set metrics=true # Enable metrics on all local nodes

Easy to do the in-memory config updating, but we also need to update a configuration file. We shouldn't even try to update the nimbus-beacon-node command line, wherever that's stored.

So we need machine-readable/writable config files. Maybe the good ol' INI format.

Change the REST port on the Prater node with the nick name "2"

It's a bit hard detecting all the nodes running on the host, because there are multiple ways to start them. Maybe we could limit support to a single deployment scenario needed by the GUI setup docs.