I just tried to setup my first node, however, I can’t get it to work.
When I run the container on my debian 11 machine, I get the following logs:
downloading storagenode-updater
--2022-10-22 02:00:28-- https://version.storj.io/processes/storagenode-updater/minimum/url?os=linux&arch=amd64
Resolving version.storj.io (version.storj.io)... 35.232.172.28
Connecting to version.storj.io (version.storj.io)|35.232.172.28|:443... connected.
ERROR: The certificate of 'version.storj.io' is not trusted.
ERROR: The certificate of 'version.storj.io' doesn't have a known issuer.
The certificate's owner does not match hostname 'version.storj.io'
http://: Invalid host name.
Please install/update ca-certificates package in your host system. The Certificate on version.storj.io is valid, just your OS do not know the root certificates or have the old ones.
thanks for your reply. An old version of ca-certificates does not seem to be the reason for my troubles. I updated (update-ca-certificates) and reinstalled ca-certificates, both did not change the behaviour. However, curl https://version.storj.io:443 works without issues on the host.
Yeah, I can’t reproduce it on my laptop either.
Neither deleting and downloading the image again nor removing the arguments from the docker run command makes any difference.
I just tried running the image with podman and the option --network=host, and it fixes the problem. However, that is not a setup I feel comfortable running with. And it doesn’t help me to understand what is going on on that machine.
Oh, sorry, I forgot to update this threat with my new finding.
Yes, it is correct that it fails with the bridge option. With the option --network=slirp4netns the download starts as expected.
I know to little about container networking to explain this - I always assumed that bridge was the most robust option.
discovered that it is related to some IP`s subnet blocked at server side (anti DDoS ? ). storj need provide alternate backup https servers to distribute updates.
Multiple nodes was affected, so ip need to pack them on single IP to keep it running and do not lose user data.
it is blocked on 34.173.164.90 (version.storj.io) - storj hosts its stuff on google. so google banned entrie subnet (tested). maybe some of other ISP`s customers have malware or bots which triggers google protection, i dont know. but this behaviour is weak point - auto update need to use multiple mirrors.
It’s reverse. Your ISP is blocked this IP, not Google. Or Google could block your subnet - but it’s a rare case, like connecting from sanctioned countries.
I would suggest to contact your ISP first to unblock this IP and all our IPs, you may check them by nslookup.
So, it is blocked in your location. And there are not many options, either your firewall, or smart security on your router or your ISP (or somewhere in between your ISP and this IP).
If i had port 443 blocked i wouldn’t be able to write you this message. I stated that i can reach the server in question. You must have some geoip or whatever rules set on the firewall which blocks “wrong” source ip. Please just notify someone competent in you company. Some network admin and sysops/devops who handles this and he will know what to do/check.
It could have filter only against sanctioned countries. What’s your IP?
In other cases it’s a client side only.
I’m not talking about blocking 443 port, but this IP and port or just this IP (or even subnet).