Summary

ifconfig is outdated and no longer available on newer versions of Ubuntu.

Possible solution design or implementation

Make use of a different tool available on (future) LTS releases of Debian and Ubuntu, like ip.

Summary

If people upgrade with the current installer, their state would be reset.

Since we assume everyone is already synced up, for now we'll just get rid of the state reset.

Describe the bug
Node is stuck at height=86920

To Reproduce
Following the guide https://docs.dusk.network/itn/node-running-guide/

// Be exhaustive
// 

Expected behaviour
Height should be syncing and not stuck.

Logs/Screenshot

Platform
Fill as appropriate

• OS: Linux (VPS)

Describe the bug
Issue running service rusk start on a local setup.

To Reproduce

1. first installed latest stable ITN release through curl
2. configured rusk-wallet and exported consensus keys (had to manually open permissions to /opt through sudo chmod 775 /opt and sudo chown -R $USER:$USER /opt/dusk
3. set consensus pw successfully through /opt/dusk/bin/setup_consensus_pwd.sh
4. start rusk through service rusk start

Expected behaviour
expected node to start syncing after starting rusk service.

Logs/Screenshot
the logs of rusk (through tail -F /var/log/rusk.log) shows repeatedly:

Using CONSENSUS_KEYS in /opt/dusk/conf/consensus.keys
2024-02-16T15:32:51.206596Z  INFO rusk: Using state from "/opt/dusk/rusk/state"
2024-02-16T15:32:51.208971Z  INFO rusk: Rusk VM loaded
2024-02-16T15:32:51.209073Z  INFO node::databroker: DataBrokerSrv::new with conf: max_inv_entries: 100, max_ongoing_requests: 1000
2024-02-16T15:32:51.209113Z  INFO node::database::rocksdb: Opening database in "/opt/dusk/rusk/chain.db"

error logs through cat /var/log/rusk.err:

thread 'main' panicked at /home/docker/actions-runner/_work/rusk/ruskthread 'main' panicked at /home/docker/actions-runner/_work/rusk/ruskthread 'main' panicked at /home/docker/actions-runner/_work/rusk/rusk/node/src/database/rocksdb.rs:164:18:
should be a valid database in {path}: Error { message: "Failed to create RocksDB directory: `Os { code: 13, kind: PermissionDenied, message: \"Permission denied\" }`." }

Platform

• Architecture: ARM
• OS: Ubuntu 22.04.3 LTS
• ITN installer: both v0.1.0 and latest version show similar issue

Additional context
Add any other context about the problem here.

Summary

To make the node setup more straightforward and user-friendly, allow users to fetch configuration parameters from other nodes or endpoints.

Sane default endpoints should be provided for known networks.

Possible solution design or implementation

Nodes provide an info endpoint that provides parameters like network-id, bootstrapping addresses and genesis state.

Summary

The current installer is based on the old Golang node, combined with Rusk. To prepare the ITN installer for ITN2, we need to update the scripts.

Possible solution design or implementation

The installer no longer needs to use the dusk and rusk-recovery-state binary. We should remove these and replace the rusk binary with the latest version.

Given the blockchain is encapsulated into a single binary, the way services are structure in the installer also needs to change.

Describe the bug
Upgarded my node following the steps as described: https://docs.dusk.network/itn/node-upgrade/

To Reproduce
Upgrade node follwoing this steps

My Discord comment:

Just upgraded my node to the latest version. Followed the steps by the book, and see that my node is producing blocks again. Only when I want to open my wallet I get this error: Network not found, check config.toml, specify network with -n flag

Investigation shows that the config.toml file was empty so I added the data and node is running again.

Seems that this update clears this file.

Summary

With the upcoming release of Ubuntu LTS 24.04, and the upcoming mainnet release, we should test whether the installer works with the upcoming Ubuntu LTS.

Summary

Update the Rusk wallet CLI from v0.12 to v0.13 to incorporate some of the UX improvements we've made as of late.

Possible solution design or implementation

Simply update the WALLET_URL to point to the latest Rusk wallet release.

Summary

Currently, if the node software is installed, it gives you commands to run the node and view the logs. If you run the node, it'll always fail by default and tell you what steps to take next.

From a user experience point of view, it would be nice to give a number of pre-launch steps that need to be take before a node can be ran.

Possible solution design or implementation

Inform the user to place the CONSENSUS_KEYS file in /opt/dusk/conf/consensus.keys close to the launch the node instructions.

Also inform the user what command to run to set the CONSENSUS_KEYS password. Alternatively, they can also be told where to put the password OR be prompted for it during installation.

Summary

Instead of providing users with commands to query their node, it would be helpful to provide a script/bin that executes the commands for them.

Possible solution design or implementation

Provide a script/bin that can query the node for information like the current block height.

Summary

Release version 0.1.0 with the latest Rusk binary

This change requires an update to the Rusk binary in the bin folder and an update to the installer URL.

Summary

Provide a tool for users to easily reset the node state, chain DB and wallet cache. This is useful for users who want to start with a clean state on their nodes, and for us to provide both fresh network updates and multiple networks support.

Possible solution

Provide an executable script called ruskreset that prompts the user for confirmation if executed.

The script will stop Rusk, remove the rusk state and chain.db folders. It will also remove the wallet cache and logs.

add docker support for nodes

Summary

To support the installer for Nocturne, we need at least the following:

• Change network ID
• Remove migration height setting
• set generation_timeout
• Provide a state reset utility

Summary

Create a mechanism to check the users OS/arch, and use it to either stop the installer, or continue and install the correct binaries.

rusk.service: Main process exited, code=exited, status=101/n/a
rusk.service: Failed with result 'exit-code'.
rusk.service: Scheduled restart job, restart counter is at 159.

Rusk service cant start...

Need guide

Currently it only supports running on Ubuntu22 and cannot run on Centos.

After I updated to 0.1.7, why are there so few accepted blocks?

when i use the cmd "service rusk start", it returns "Job for rusk.service failed because the control process exited with error code.
See "systemctl status rusk.service" and "journalctl -xeu rusk.service" for details."

then i use the cmd "journalctl -xe", it returns the below message, why ？

Support: http://www.ubuntu.com/support
░░
░░ A start job for unit rusk.service has begun execution.
░░
░░ The job identifier is 30808.
Mar 11 21:53:43 VM-4-11-ubuntu sshd[393249]: pam_unix(sshd:auth): check pass; user unknown
Mar 11 21:53:43 VM-4-11-ubuntu sshd[393249]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=170.64.195.73
Mar 11 21:53:43 VM-4-11-ubuntu systemd[1]: rusk.service: Control process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ An ExecStartPre= process belonging to unit rusk.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 1.
Mar 11 21:53:43 VM-4-11-ubuntu systemd[1]: rusk.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit rusk.service has entered the 'failed' state with result 'exit-code'.
Mar 11 21:53:43 VM-4-11-ubuntu systemd[1]: Failed to start DUSK Rusk.
░░ Subject: A start job for unit rusk.service has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit rusk.service has finished with a failure.
░░
░░ The job identifier is 30808 and the job result is failed.
Mar 11 21:53:46 VM-4-11-ubuntu sshd[393249]: Failed password for invalid user awsgui from 170.64.195.73 port 52764 ssh2
Mar 11 21:53:48 VM-4-11-ubuntu sshd[393249]: Connection closed by invalid user awsgui 170.64.195.73 port 52764 [preauth]
Mar 11 21:53:49 VM-4-11-ubuntu sshd[393289]: Invalid user tom from 170.64.195.73 port 48060

Summary

Add a way for users to query the installer version, and retrieve what the latest version is, and if so, allow them to download the new version.

Possible solution design or implementation

On installation, place a version file on the system.

This version file can then be checked by the script, and by a ruskquery command, to check against any upstream new releases.

Summary

The state download tool currently only allows for a given state and no state.

It should provide the following extra functionality:

1. Download the latest state by default
2. Have a command to list all possible states
3. Return a proper error if the state is not available

Describe the bug
The password script does not accept special characters.

To Reproduce
Run the script, set a password with "?!~%&*", and check what the environment variable is set to.

Summary

Currently, the installer only allows for the installation of a single network.

It would be nice if the installer allowed you to pick between testnet, devnet and in the future mainnet.

Possible solution design or implementation

By default target testnet, but through a flag allow for the setting of a different target network.

Summary

Recovery-at-start should take over from what previously was rusk-recovery-keys and recovery-state. The node should not start if no valid state is available.

Possible solution design or implementation

Update the startup routine scripts to no longer use rusk-recovery-keys and recovery-state, but use Rusk directly.

Describe the bug
A clear and concise description of what the bug is.
Chain will not resync or connect once wallet upgraded to v0.1.5
Also wallet keys and consensus keys gone, won't load, have to reinitiate

To Reproduce
if applicable add a minimum reproducible example
Install v0.1.5
Can't run the node with service rusk start

// Be exhaustive
// 
Doesn't load```

But that being said, running this upgrade script on a node already on v0.1.5 doesn't seem to induce this error. I cannot confirm as none of my nodes is at the earlier version now

**Expected behaviour**
A clear and concise description of what you expected to happen.
I expected all my wallet and consensus keys to be intact and the service to run without issues like last upgrades

**Logs/Screenshot**
If applicable, add damning logs
Job for rusk.service failed because of unavailable resources or another system error. 

**Platform**
Fill as appropriate
 - Architecture: [ARM, 8086]
 - OS: [e.g. iOS, Linux]
 - Browser [e.g. chrome, safari]
AMD
Linux ubuntu 22.04
CLI

**Additional context**
Add any other context about the problem here.
Concerned chain is stuck and that we will not be able to proceed with 75% uptime with this issue.

Improvement ease-of-use of node setup guide

1. Create subcategories. So in the explanation for step 1, create point 1.1, 1.2, 1.3 etc for every separate step. This makes it much easier to follow each step, is easy for your own use while creating the guide and helps for users to backtrack and ask questions about a (then numbered) subject. Also it helps for receiving feedback and improves readability.

2. Implement pauses between some of the steps to make people wait. I noticed during setup that sometimes things were not updated on the server yet, which made me think I did something wrong or I did not follow the guide well and then I already started looking for errors or wanting to correct things, while all was actually done correctly and in good order after waiting a minute or so for the server to update.

Additions:

• At step 1.1 (unpacking tar) for me, using 7-zip, it was necessary to unpack the download and then unpacking the .tar file. So actually, with windows, it is necessary to unpack twice.

• At step 1.5 (creating .cpk and .key) it might be handy already renaming the .key file into consensus.keys? In that case, people don't have to backtrack to that step and the consensus.keys file is already there.

• At step 2.7 (or so, the one where Filezilla is used). It is easier to start with the download, install and running of Filezilla and after that, give the instructions. The way it is now it's kind of confusing. Also, if my second tip is good to implement, the consensus.keys file is already there so that would make it a very easy step.

One last suggestion: in the final edit, I would advise not using the fatprinted word every new alinea. It serves no purpose when using subcategories (1.1, 1.2 etc); multiple alineas can fall under under category which makes it way more uncluttered

Not much, just some small suggestions. Very well done guide @HDauven, very clear!

Summary

The current installer increases bandwidth for the node significantly.

Possible solution design or implementation

To reduce the bandwidth consumed by the nodes, we need to tune settings like autopropagate and the amount of repair blocks.

We also need to update the Rusk binary with the following fix included: dusk-network/rusk#1456

Summary

Given ITN is over and we want to reuse the installer going forward, the installer should be renamed to something more generic.

Summary

The scripts have changed by a decent amount. These changes have not been properly reflected in the current README.

Solution

Update the README with all the proper and up-to-date information.

Summary

The repository currently makes no mention of how to use the installer.

Possible solution design or implementation

Provide concise documentation on how to run and operate the ITN installer.

Summary

Update packages pre-installation of the installer to ensure the availability of all packages.