Please join our public test network

Product Discussions STORJLINGS
1

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Any questions?

8 Likes
2

Can it be any size storagenode for the test network?

3

We might have to add a few more config settings for that. Since the test network is unpaid anyway we can run 0 byte nodes with no issues.

1 Like
4

I can probably afford to miss a TB or 2. I’ll look into setting this up tomorrow. Is there any expectation of the amount of storage that might go through this sat?

5

I would say you can set the expectation here and the QA satellite will have to respect that. We can keep the storage cost low. I am usually storing a few hundert MB on the QA satellite. We can scale that up or down any time.

6

Got my test node up and running. Pretty cool to see when im upoading and downloading from the network again.

2 Likes
7

Also got a 5 TB dedicated SN up and running on the public test network.

2021-11-03T06:24:00.109+0100    INFO    Node 12jPRVrJi3tQQJH7e7AEx8kQ7SQY854ymv3o5HCxauf52A4h7bx started
2021-11-03T06:24:00.345+0100    DEBUG   version Allowed minimum version from control server.    {"Minimum Version": "1.24.0"}
2021-11-03T06:24:00.345+0100    DEBUG   version Running on allowed version.     {"Version": "1.41.3"}
2021-11-03T06:24:00.997+0100    DEBUG   contact:endpoint        pinged  {"by": "1GGZktUwmMKTwTWNcmGnFJ3n7rjE58QnNcRp98Y23MmbDnVoiU", "srcAddr": "34.133.69.92:39154"}
2021-11-03T06:24:01.251+0100    DEBUG   contact:endpoint        pinged  {"by": "1GGZktUwmMKTwTWNcmGnFJ3n7rjE58QnNcRp98Y23MmbDnVoiU", "srcAddr": "34.133.69.92:53306"}

Th3Van.dk

2 Likes
8

Hi, I would like to make a contribution but I am inexperienced. For the testnet, do I need to open a new node with a new identity? I already have a working docker node on the mainnet.

1 Like
9

Yes at the moment it’s better to setup a separate node with a new identity and use a separate external port. This identity may not be signed, you will disable the signatures check anyway:

1 Like
10

Alright, test node up and running. Bring in the data!

Of course, but I wouldn’t really want to limit it unless I have to. Though given what you just said I think the 2TB I assigned at the moment is probably going to be plenty. :slight_smile:

2 Likes
11

@littleskunk You need to have a separate tag for QA docker images, otherwise the watchtower would be unable to update to the correct QA version.

12

Isn’t that kind of the point of the test? When community satellites start popping up, my nodes won’t be on their schedule, they’ll update when they always do. Using a separate update process kind of negates that part of the test.

13

Yes, but why @littleskunk mentioned this?

The current docker version still can’t use the same updater mechanism to follow the versions server.

1 Like
14

I suppose pre-release binaries might be created more often then the real releases.

15

Technically we do have the same rollout mechanism for docker nodes. The problem is that it doesn’t work on ARM nodes. I hope we can solve that issue one day. For that reason, it would be great if docker nodes would also add the config change as preparation.

If one of you has an idea here is the corresponding bug: storagenode/docker: investigate certificate issue on RPI · Issue #4176 · storj/storj · GitHub

1 Like
16

Good point, I overlooked that. I guess it can’t hurt to test the behavior on QA with a mix of storagenode versions. I think this will still be quite representative of what community satellites can eventually expect.

Is there already a way to enable this on AMD64 docker nodes? I would love to give that a try on my test node as well.

17

The image is missing the storagenode-updater. And also it’s not trivial to run both binaries as a service.

1 Like
18

also started a 1TB test node. Happy testing!

1 Like
19

Stood up a test node. Bring on the mayhem!

1 Like
20

You guys putting me to shame adding 1TB to the testnet to my 6gigs…

3 Likes