The nodes might be test nodes, but they are on SSD only storage on fast hardware on a dedicated IP - should not be any performance issues. Like so many else, they did have extreme ingress over the test, and as you can see, it’s already filled
Additional info:
I’ve onlined five identical nodes. The rest are also filled, but otherwise completely fine. I’m running docker on a spare 12 bay rack synology with 32GB of RAM, a modern quad core and no other load on the box
I think I have an answer. It seems like I two nodes with this very same ID. I don’t understand how this is possible, but here is the same node ID on a different machine in a different city - but also disqualified on a single sat.
Yeah, I am fairly sure I reused identities, hence the same ID. I’ve tried this before though, it should not be possible to get the second node to connect. It should stay in an errornous “duplicate ID” state.
For the satellite it is exactly the same node with a different IP but lost data, thus - disqualification is inevitable.
The satellite cannot detect a duplication - the node could switch between IPs very often, but it can issue audits, which will detect this and disqualify this identity, no matter how many clones do you run.
This is actually doesn’t matter. The authorization token is used to sign the identity. If it’s used, you cannot use it in the second time. But you may request another one. However, using the same identity and different authorization tokens will not create an unique identity - it will remain exactly the same.
Thank you. I’ll remove the younger of the two nodes. I generate a bulk list of identities and take them into use when needed. I must have messed up in where in the list i’ve reached
Ahh, that’s a good idea. I’d have to significantly increase the size of the node, but that does not really matter. I wonder if I can do it in time, since it has taken me over a month now to realize my mistake.
