Document a known-good configuration for full nodes

[faddat]

At present, our recommended documented deploy path (the .deb file) described in #194 does not result in a stable VSYS node.

I'm going to update our documentation so that when users follow our recommended deployment setup exactly, VSYS works perfectly, and this issue has been created to gather the needed information.

Changes planned currently:

1. Make these default:

add more in/out bound connections in conf (120 or larger)

network {
    # How many network inbound network connections can be made
    max-inbound-connections = 120

    # Number of outbound network connections
    max-outbound-connections = 120
}

add more outbound buffer size in conf (64M or larger)
network {
    # Network buffer size
    outbound-buffer-size = 64M
}

2. Document use of the JAR by default, stop shipping the .deb and stop referring to the .deb in documentation

use jar directly (may not use the .deb service one, the stable issue may cause by the service logic), in this case, I used
java -jar v-systems-v***.jar, vsys.conf

3. When the JAR is run, inform users that they should run it like this:

java -Xmx4096m -jar ***.jar **.conf
allocated more threads in

java -Dscala.concurrent.context.maxExtraThreads=1024 -jar ***.jar **.conf

Is there anything else that we need to include in a default configuration that should work flawlessly every time?

Peerchemist has made mention of using Docker. Should we?

[faddat]

https://github.com/virtualeconomy/v-systems/releases/tag/v0.3.1

Makes a number of usage suggestions, reflected above, including using the jar directly.

Is there anything else that should be included in an opinionated bash script that stands up a VSYS node in one line?

[faddat]

Here is the plan for the bash launch script:

• Assumes Debian 10 host
• openjdk-8
• Implements all settings described above
• disables wallet generation Private Keys in Log Files #208 and tells user how to generate a wallet if they'd like to do so
• Displayed prominently on readme.md as a curl command with a machine configuration so that users only need to spin up a virtual machine to run it.

[faddat]

#214 begins process by modifying the default configuration.

Per #208 , a commit can be added to #214 which removes the wallet section of vsys-mainnet.conf

When fully completed, this issue should result in the closure of

#208 - keys should no longer be automatically generated and printed to the log
#211 - I tend towards not shipping the debs anymore
#194 - stability issues should be resolved and the default shipped state of vsys should be stable.

[faddat]

After encountering apparent issues with the Java environment on my node, it's clear to me that the Docker route suggested by Peerchemist will make for the easiest known-good deployment of VSYS nodes. I am creating an automatic docker image generator for us on my gitlab, and will make a PR that includes the Dockerfile here.

https://gitlab.com/faddat/vsys-docker

images will be accessible at:

registry.gitlab.com/faddat/vsys-docker:latest

[faddat]

running like:

java -Xmx4096m -Dscala.concurrent.context.maxExtraThreads=1024 -jar vsys-all-0.3.1.jar ../vsys-mainnet.conf
2020-07-12 11:57:26 INFO  [main] vsys.Application$ - Starting...
2020-07-12 11:57:27 INFO  [main] kamon.Kamon$Instance - Initializing Kamon...
2020-07-12 11:57:27 INFO  [lt-dispatcher-3] a.event.slf4j.Slf4jLogger - Slf4jLogger started
2020-07-12 11:57:27 INFO  [main] vsys.Application$ - VSYS Core v0.3.1 Blockchain Id: M
2020-07-12 11:57:27 INFO  [main] v.b.s.BlockchainUpdaterImpl - Constructing BlockchainUpdaterImpl, total blocks: 0, persisted: 0, topMemDiff: 0, bottomMemDiff: 0
2020-07-12 11:57:27 INFO  [main] v.b.s.BlockchainUpdaterImpl - State rebuild started, total blocks: 0, persisted: 0, topMemDiff: 0, bottomMemDiff: 0
2020-07-12 11:57:27 INFO  [main] v.b.s.BlockchainUpdaterImpl - State rebuild finished, total blocks: 0, persisted: 0, topMemDiff: 0, bottomMemDiff: 0
2020-07-12 11:57:27 INFO  [main] v.wallet.Wallet$WalletImpl - Your randomly generated seed is 3HTZrvPuT6fGhYPAqszZQkS62jwF1ST48NGANikyLKZaJVGgDwEubUQU1ULN1vFWQNySUvtMokR7wnB4NCACcHMt
2020-07-12 11:57:28 INFO  [main] vsys.Application$$anon$1 - Genesis block has been added to the state
2020-07-12 11:57:28 INFO  [main] v.wallet.Wallet$WalletImpl - Added account #1
2020-07-12 11:57:28 INFO  [main] vsys.Application$$anon$1 - REST API was bound on 127.0.0.1:9922
2020-07-12 11:57:29 INFO  [ntLoopGroup-3-2] vsys.network.NetworkServer - [e170a63a 3.121.94.10:9921] Connection established
2020-07-12 11:57:29 INFO  [ntLoopGroup-3-2] v.n.HandshakeHandler$Client - [e170a63a 3.121.94.10:9921] Accepted handshake Handshake(V SYSTEMSM,(0,3,1),Node-259698,259698,Some(/3.121.94.10:9921))
^C2020-07-12 11:57:33 INFO  [ntLoopGroup-3-2] vsys.network.NetworkServer - [e170a63a 3.121.94.10:9921] Connection closed, 0 outgoing channel(s) remaining
^C^C^C^C2020-07-12 11:57:39 INFO  [shutdownHook1] vsys.Application$$anon$1 - Stopping network services
2020-07-12 11:57:39 INFO  [shutdownHook1] vsys.Application$$anon$1 - Closing db
2020-07-12 11:57:39 INFO  [shutdownHook1] vsys.Application$$anon$1 - Shutdown complete

VSYS runs successfully, but still creates a seed and prints it to the log, even when the wallet section is removed from vsys-mainnet.conf

[faddat]

Known-good run command:

java -Xmx4096m -Dscala.concurrent.context.maxExtraThreads=1024 -jar vsys-all-0.3.1.jar ../vsys-mainnet.conf

[faddat]

Gitlab has superior CI and integrated docker image hosting, allowing for jobs like this:

https://gitlab.com/faddat/vsys-docker/-/jobs/634764544

[faddat]

It is now possible to run VSYS in the recommended configuration like this:

docker run -d registry.gitlab.com/faddat/vsys-docker:latest

That'll allow outbound traffic and the node will be able to sync, but you may not be able to access the web UI.

To give only yourself access to the web UI, try:

docker run -d -p 127.0.0.1:9922:9922 registry.gitlab.com/faddat/vsys-docker:latest

To give the world access to your node's API / web UI:

docker run -d -p 9922:9922 registry.gitlab.com/faddat/vsys-docker:latest

this does not yet deal with volumes, which will be approached later.

Merging #214 and re-building the docker image would mean that VSYS runs with 100% of recommended settings using this approach.

[ncying]

All conf which in the release is for some high-performance usage, not for the default. If we need to change the default configuration, we will change the code level files.