"Setting up the Storage Node": what exactly does this do?

Node Operators getting started
1

So was casually looking over the documentation some more and was in the “Setting up the Storage Node” section. While this documentation worked fine for me, I realized that the command I ran was no longer “valid” for my current configuration. I have since changed the mount point of my node. What was “/mnt/storj/storagenode” when I ran the Docker SETUP step (on Linux if it matters) is now “/mnt/storj1/storagenode1”. I made this change some days ago, removed and restarted my Docker container with the updated mount binds without redoing the setup step, and everything seems to be happily chugging along.

So can someone expand on just what the:

docker run --rm -e SETUP="true" \
    --mount type=bind,source="<identity-dir>",destination=/app/identity \
    --mount type=bind,source="<storage-dir>",destination=/app/config \
    --name storagenode storjlabs/storagenode:latest

step does? I mean, it works, sure. But I’m the type of person who likes to know how something works and/or why it is there. Would be great if the explanation could be added to the documentation but I’d be satisfied if someone could simply let me know here.

1 Like
2

The reason this is here is to prevent someone from DQ there by starting a node in the wrong location where another node is. Its to prevent and make sure the identity’s match to the location of the node so it prevents it from starting up.

2 Likes
3

? that’s the first I hear about that but it actually seems to be true (see further below)
The SETUP=“true” step will create all directories and files needed to set up a new node.
Without SETUP=“true” in your command, the node will not start if the directories are missing. This is to prevent the disqualification of a node if you use a wrong path and don’t realize it quickly enough.
It also seems to protect you if you point the path at the location of a different node.

I was searching in the changelogs to provide more clarification but couldn’t find it yet…

Edit: lol found it, was expecting it to be in earlier versions:

1 Like
4

Yeah, kevink’s response is along what I suspect is going on. As this is during initial setup of a node there isn’t anything lost (except the time creating the identity) if you get immediate DQ’d.

Cool, thanks for the info @kevink!

1 Like
5

The directories of the storagenode and the filesystem test file which is used to recognize a storagenode location. If that file is missing, the storagenode won’t start.

1 Like
6

It also creates a file for storage verification though, In my testing I was unable to start the node with a different identity file. So this is why I said it pervents you to start a node with a different nodes data.

1 Like
7

Haven’t read it anywhere yet but the verification files are different in each of my nodes so could be.
The main advertized purpose though is to prevent wrong path configurations from DQing you.

But I checked the changelog on github and the commits and they code says, that the verification file is created with the identity in it, so you are right, it prevents against accidentally using a different storagenode’s location too:


(Corrected my previous post)

Edit: Small code that shows how the verification file is created:

	identity, err := setupCfg.Identity.Load()
	[...]
	if err := db.Pieces().CreateVerificationFile(identity.ID); err != nil {
		return err
	}
1 Like
8

Thanks for posting the github though I actually havent read it yet.

1 Like
9

So, the main thing the SETUP command is doing is creating the initial structure and files necessary to start a node; these need to be there first as they don’t just get created on the fly. But this also “signs” these files to the identity specified at setup, which will prevent accidentally trying to start this node in the future with the incorrect identity linked to it.

That sound about right?

5 Likes
10

That sounds right :slight_smile:
It only “signs” the verification file “storage-dir-verification” though.

1 Like
11

Coolness, thanks!

And this completes my learning for Saturday. Time to drink!

2 Likes
12

I can drink to that.

2 Likes
13

Great timing! I had the same question. I am moving my Storj HDDs to a new machine (new case/backplane - 16 bays!) with a new OS (Ubuntu 20.04).

I am setting up the machine right now, installed Docker, no-ip, etc and putting a copy of the 3 identity files for all three Storagenodes I have been running; update fstab and mount points to match old paths.

So I figure I must run the setup flag after all is prepared, as above, and then use the run command (without ‘setup’) two more times - one for each additional node.

1 Like
14

If you’re moving existing nodes, you shouldn’t need to “setup” them I think.

I believe you should have 6 identity files per node, not 3.
Unless you meant 3x6 files :slight_smile:

1 Like
15

I believe you should have 6 identity files per node, not 3

No, I have 3 HDDs, each one is a node and each one has it own identity files

1 Like
16

No! You only run the “setup” flag for NEW nodes, not existing ones. They already have all files and directories and the correct verification file.

4 Likes
17

Thanks - I had not run it yet, as I have been fighting with the new backplane and HBA…

1 Like
18

I believe each node requires three identity related files:

  • ca.cert
  • identity.cert
  • identity.key

There is also a ca.key you do not need and may be stored safely offline

1 Like
19

I don’t know about that, we’ve always been told that a signed identity is made of 6 files, so I’ve always kept these 6 identity files per node.

Here is the list from one of my nodes for instance:

-rw-r--r-- 1 pi pi  518 Aug 25 07:35 ca.1598339541.cert
-rw-r--r-- 1 pi pi 1048 Aug 25 07:35 ca.cert
-rw-r--r-- 1 pi pi  241 Aug 25 07:35 ca.key
-rw-r--r-- 1 pi pi 1056 Aug 25 07:35 identity.1598339541.cert
-rw-r--r-- 1 pi pi 1586 Aug 25 07:35 identity.cert
-rw-r--r-- 1 pi pi  241 Aug 25 07:35 identity.key
2 Likes
20

The ones with the numbers can be thrown away/// such as identity.1598339541.cert

1 Like