root@bcn003:~# grep -c BEGIN /root/.local/share/storj/identity/storj-q160/ca.cert
2
root@bcn003:~# grep -c BEGIN /root/.local/share/storj/identity/storj-q160/identity.cert
3
root@bcn003:~#
Can you stop this node and check its port on the yougetsignal again?
Is it become closed?
1 Like
i think i got this figured out… you have accidentally over written the identity and now some of the nodes are sharing identity…
according to littleskunk that would cause the nodes to switch between being offline and online…
i keep all my identities in the storagenode dir before the blobs folder, that way they cannot be mixed up with other identities and they will not be overwritten by accident.
the folder location you use would make it possible to mix up identities i think… duno… it’s an idea… maybe
2 Likes
1 moment, let me check. However the port is open on the firewall (a seperate multi-wan ubiquiti router).
So just because its not open on the local machine doesn’t necessarily mean it won’t show online on the firewall machine.
1 minute checking.
It must be closed, if no service is listening. Otherwise your port forwarding is wrong.
1 Like
These ID’s were all generated at the same time a month or so again.
Of the hundred ID’s or so i generated, half are working normally, and some, without any changes, are behaving differently.
You are correct sir
This is after shutting down the docker image.
It’s open for me right now.
Your node even didn’t try to update it’s contact information on satellites.
Can be your traffic blocked somehow?
The storagenode must have allowed any outgoing connections on the firewall.
1 Like
Ah - the sat see’s it’s proxied address, not the direct address. I was checking the port on direct server address.
For sure there is no firewallet blocking outgoing connections, only a firewall blocking incoming connections.
It’s a reverse nginx proxy so that is probably why the port still shows open on the IP reported to the sat.
That’s the odd part, there are other nodes, on this same physical machine, which are functional exactly as normal.
The nginx doesn’t support dRPC as far as I know.
it is highly doubtful that it will work at all.
1 Like
If you use the stream feature it should.
I have many nodes, for many months, setup exactly like this. Others are setup the exact same way and still functional.
Whats strange is why identical setups work sometimes and not others. I cannot find what is the inconsistency (not saying its on StorJ end and not mine).
The satellite see an IP, not the domain. Why you need to have a reverse proxy there at all?
1 Like
I have a server with 36 hard drives and 36 nodes on a single IP. I then redirect via nginx 35 additional IPs to this server in order to maximize traffic for each of the 36 nodes/hdds on that server.
Please, do not confuse the dRPC with gRPC. They are different protocols. We removed the gRPC a while ago.
1 Like
Did something change in the past 2 or 3 versions that were released in the past few weeks? This has just become a problem, i never had an issue with this setup previously.
It certainly has been functional, bcn003 did over 80TB ingress since oct1.
The 130mbit is the currently functional nodes on bcn003. This doesn’t include nodes such as q160 which are not functional at the moment.
I cannot say for sure. I still think it’s a configuration issue, so let’s continue.
Can you setup this node to do not use the reverse proxy?
1 Like