Let’s answer the most important question first. The test network is unpaid. You will not get any payout from the test satellite.
Now you might ask why should I join the satellite if you can’t earn money? Well, you should do it for several reasons:
- You can make sure your specific setup works with any new version. You will be able to identify possible problems early in the test network.
- You are welcome to cheat our system. Do you have an idea in mind about how to cheat our audit system but it is not worth the risk of getting disqualified and losing your payout? The test network is the perfect environment to try it out.
- Preparation for reviving the Stefan satellite or any other community satellite. Some of them will be paid. The test network will allow us to get started with some of the required config changes and also gain experience.
- Support the project. I know it’s boring but it will help us to run a more realistic test network and that means we can maintain better quality for mainnet as well.
Does one of these reason sounds good to you and do you want to join our test network? If so you will need a normal storage node setup with the 3 config changes below. Technically you can use your mainnet node but we are missing some important features for that. For now, let’s set up dedicated nodes and updater for the test network that work independently from the mainnet nodes. Later on we can still discuss which challenges we need to solve to support running both networks on the same node. Ok here are the config changes:
# if true, uses peer ca whitelist checking server.use-peer-ca-whitelist: false # list of trust sources storage2.trust.sources: 1GGZktUwmMKTwTWNcmGnFJ3n7rjE58QnNcRp98Y23MmbDnVoiU@satellite.qa.storj.io:7777,12ZQbQ8WWFEfKNE9dP78B1frhJ8PmyYmr8occLEf1mQ1ovgVWy@testnet.satellite.stefan-benten.de:7777 # server address to check its version against version.server-address: https://version.qa.storj.io # Interval to check the version version.check-interval: 5m0s # email for notifications (downtime, suspension or disqualification after installing the latest version) operator.email: <your email address>
The first config will disable the signed indentity. Yes you don’t need to sign your identify for the test network. If you have a signed identity you still need to add this config change because otherwise your node will refuse to talk to a satellite that can also not provide a signed idenity. The identity signature check works in both directions. This config change will disable it.
The second config will tell your storage node to trust the QA satellite. The QA satellite is currently behaving like production. We have full control over the config. Feel free to request any config change you want us to try out.
The third config will tell your storage node updater to install pre-release binaries early. On my system I am running a test node inclusive updater as systemd service. With this config, the test node will follow its own rollout cycle. If you are running a docker node please also add that config even if it currently doesn’t affect the docker rollout.
The fourth config will reduce the update interval from 15 minutes to 5 minutes. If there is a problem it is a bit painful to wait 15 minutes.