That looks correct. Try running it again and see what comes up.
I think ive found the issue. Its my ip forwarding. Ill look more into it tomorrow when im more awake 
thanks for your help though. Ill confirm when I get it working.
Done. You should be able to edit it now.
1 Like
I can’t edit it either so something must have gone wrong.
thanks SOOO much for all your help yesterday @fmoledina got my first linux binary node working this morning. The problems I had weren’t anything to do with your instructions. I had an error which was caused by a missing file the node tried to write to when it starts, but because I had an error earlier in the setup process it didn’t create this file. I had to delete the config.yaml file and re run the setup to generate this file after I had put the certs/keys in the correct folder. Completely my mistake and wouldn’t have happened if I followed the instructions correctly.
The other issue I had was with port forwarding. My new ISP uses something called CGN (Carrier Grade Nat) and I needed them to configure me with a static IP so my port forwarding would work.
I do have one error in the logs though, its relating to the new QUIC implementation. Is there anything I need to do to fix this? Any idea if it’s using QUIC?
Feb 19 09:45:54 storj-node2 storagenode[652]: 2021-02-19T09:45:54.568Z INFO failed to sufficiently increase receive buffer size (was: 176 kiB, wanted: 2048 kiB, got: 352 kiB). See https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size for details.
For anyone who has an Odroid HC2/4 ive updated my documentation at http://config.storagenode.uk
2 Likes
Glad to hear it all worked out!
Congratulations on getting yourself a static IP. Hopefully it didn’t cost you an arm and a leg.
I’m seeing that as well on my native node and my Docker nodes. Looks like a new quirk with v1.22.2 and nothing to do with your specific configuration, I don’t think.
Good luck and nice website!
1 Like
Oh, I thought you need a wiki for linked article.
Made your post a wiki now too
1 Like
I should have been more clear than just saying this 
. All good, I’ll make my quick edit. Thanks!
1 Like
I am getting the same log message. Have you decided to try to increase the UDP buffer according to the link from this INFO message?
Experiments have shown that QUIC transfers on high-bandhwidth connections can be limited by the size of the UDP receive buffer. This buffer holds packets that have been received by the kernel, but not yet read by the application (quic-go in this case). Once this buffer fills up, the kernel will drop any new incoming packet.
From the link description it might be useful to change.
I know the Storj team are aware of the error msg, and everyone gets it (even the Docker installs)
Quic was only recently implemented and they are testing things so no need to make any changes at this point. I’m sure we will see an announcement in the forum if they want us to make changes.
4 Likes
Would this work, if one sets up multiple nodes on the same machine as different services with different users? Have 4 ports with 4 separate IPs from 4 separate /24 subnets on a machine. May try this because the docker is playing in very nasty ways with iptables and can’t start all nodes at once.
I could see this working since the config allows setting up contact.external-address.
Would it need multiple of those for each node then?
That is exactly what I am doing. Here is my systemd service for the updater:
less /etc/systemd/system/storagenode-updatertest.service
# This is a SystemD unit file for the Storage Node
# To configure:
# - Update the user and group that the service will run as (User & Group below)
# - Ensure that the Storage Node binary is in /usr/local/bin and is named storagenode (or edit the ExecStart line
# below to reflect the name and location of your binary
# - Ensure that you've run setup and have edited the configuration appropriately prior to starting the
# service with this script
# To use:
# - Place this file in /etc/systemd/system/ or wherever your SystemD unit files are stored
# - Run systemctl daemon-reload
# - To start run systemctl start storagenode
[Unit]
Description = Storage Node service
After = network-online.target
Wants = network-online.target
[Service]
User = storagenode
Group = storagenode
ExecStart = /home/storagenode/binaries/storagenode-updatertest run --config-dir /mnt/testnode/storagenode/storagenode --binary-location /home/storagenode/binaries/storagenodetest --service-name storagenodetest --debug.addr 127.0.0.1:12018
Restart = always
Type = simple
NotifyAccess = main
Nice = 10
[Install]
WantedBy = multi-user.target
Note: You need --binary-location and --service-name
Maybe I will use this to create several services for each node on the same machine. Docker = epic fail. Thanks!
4 posts were split to a new topic: How do I use the SN updater on FreeBSD?
@fmoledina
As yours seems to be the only instructions on setup of the native Linux client (thank you!) I’d like to suggest you change the github references to be “latest” instead of a specific version. It should help to keep these instructions more current. E.g.:
wget https://github.com/storj/storj/releases/latest/download/storagenode_linux_amd64.zip
wget https://github.com/storj/storj/releases/latest/download/storagenode-updater_linux_amd64.zip
And a link to the latest release page:
https://github.com/storj/storj/releases/latest
2 Likes
Is there any improvement on using it using SystemD vs using it using Docker? (aside from not requiring Docker installed).
Any performance difference?
Unlikely. I expect the same numbers for the same amount of running time.
Because generally the docker container is a process uses the same kernel, but run in the isolation from other process and has a network isolation as well.
Perhaps this NAT (the docker bridge) could have some impact on performance, but it’s not expected to be big enough, and can be avoided using the --network host option (but it has the same requirements - every port must be unique, include internal (private) if you run more than a one node).
I was thinking more about the IOPS translated to the disks, as in some situations it can saturate a spinning disk, and maybe not having the Docker’s mount can help on something (I don’t think it make much impact but…)
Makes it harder to run multiple nodes on the same machine, so probably easier to stick to Docker….
1 Like