I’m in (3e9d93) - not too hard, although Hetzner is a bit light on instructions. I’ll try the Docker thing over the weekend.
4 Likes
we have split again 
4 Likes
I think I’m having the same issue, could you explain how you symlinked xdg-open to gnome-open? I’m running Linux Mint if that makes a difference. I searched my file system and found multiple locations that have xdg-open and I’m not sure which one needs to be symlinked
I just symlinked /usr/bin/xdg-open to /usr/bin/gnome-open (after backing up the real xdg-open, just in case).
1 Like
My VPN handles 70MBPS
To reduce the monthly cost, I intend to keep only 2 vaults. The problem is that my current 9 running vaults define the hard contact list in crust config files (for both the clients and the vaults). If I remove 7 of them, I am not sure that users will always be able to connect to the network.
If there are vault owners willing to participate in this list, then I encourage them to give their IP address so that I constitute the new crust config files and update the github repository with them.
In addition to a reduce cost for me, another advantage is that the network will be more community based if I am not the sole provider of contact vaults.
But there are conditions for the success of the operation: provide your address only if you have a fixed IP address, a powerful vault (2 cpu, 4 GB ram, 40 GB disk) and a 500 Mbit/s connectivity. These figures are the specifications of the servers I currently use (CX21 servers at Hetzner), and it is preferable to not take any risk by lowering them.
With these conditions, volunteers are welcomed to provide their IP address by responding to this post or by a PM to me.
7 Likes
I assume that’s Mbit/s?
Unfortunately my ISP doesn’t offer a fixed IP, so I can’t help with this.
10 Gbit/s is the connectivity of servers at Hetzner. I think this is common for cloud providers. In France my ISP provides 1 GBit/s at home with fiber. But I don’t know if it is enough for a contact node.
4 Likes
Wow, that’s quite a requirement! Why do contact nodes require such massive bandwidth vs normal nodes on such a small network?
I’d have thought Hetzner were sharing that 10GBit/s over far more than 10 users, making 1 GBit/s for a dedicated home connection more than what’s necessary.
4 Likes
You are right. Testing with iperf I get an effective bandwidth around 500MBit/s between 2 Hetzner servers (one at Helsinki and the other one at Nuremberg).
root@TFA--06:~# iperf -c 95.216.170.146 -r
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 95.216.170.146, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 5] local 159.69.82.188 port 56432 connected with 95.216.170.146 port 5001
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-10.0 sec 625 MBytes 524 Mbits/sec
[ 4] local 159.69.82.188 port 5001 connected with 95.216.170.146 port 38846
[ 4] 0.0-10.0 sec 561 MBytes 469 Mbits/sec
I have updated my post accordingly.
I have also added that people can PM me their IP address (when they don’t want it to be publicly associated with a forum user).
1 Like
There is someone in the community that wants to provide a very powerful node (16 CPUs, 32 GB ram) joining my docker swarm, but it never worked. This situation subsists since Jan 17.
I don’t know who he/she is. I just know that the node hostname is maidsafe-Z390-GAMING-X. I already mentioned this node twice in this topic to signal problems that prevent it to connect successfully to the safe network:
- On Jan 20: its port 5483/tcp is already allocated
- 24 days ago: log file must be created with: touch /var/log/safe_vault.log
Maybe the owner of the node doesn’t even know that it is not working. Z390-GAMING-X is the name of mother board from Gigabyte, so, please, if someone has such a mother board, can you check the mentioned problems?
You can check the status of your node with: docker ps -a --no-trunc
1 Like
I’m in!
Sorry for being slow to reply!
4 Likes
I have received 2 IP addresses, so I have defined a new contact list with 4 addresses (2 belonging to me and 2 from the community). I have updated my repository with a new safe_vault.crust.config file and a new SAFE Browser.crust.config.
For vaults you do not need to restart them, just replace the safe_vault.crust.config file. It will be taken into account the next time the vault is restarted.
If you forget to update the crust config file, client and vault should still work because there are 2 vaults in common between the old contact list and the new one. But it is safer to have 4 vaults available for connection rather than only 2.
Users that have joined my docker swarm have nothing to do. I am about to launch a general automatic upgrade of all these “tracked” vaults. The docker service machinery will restart these vaults, so to not disrupt the network a vault will be updated every 20mn, as there are 10 of them, the process will last more than 3 hours.
I will stop my 7 remaining vaults (those that are not part of the contact list anymore) in about one day. I will do it also progressively.
5 Likes
All done now!
This is a small network now with a total of 13 nodes and a contact list with 4 nodes, but more community centered with only 2 nodes from myself.
8 Likes
I have made a little change to the web site: the hostnames of vaults that have joined my Docker swarm are now displayed by default and they are all displayed when no specific sponsor is selected.
Here is current result:
8 Likes
Has the resource proof changed?
I’ve not managed to join at all since it changed (with the updated files in place), and never had a problem before.
Edit: ok, for the first time it connected, just after I posted this… just to spite me I’m sure. I guess my connection / router was just having a slow time!
1 Like
No, resource proof hasn’t changed. The only thing that has changed is the safe_vault.crust.config file which contains only 4 addresses now instead of 9 previously. Maybe this reduced number of contact nodes is a problem.
Also check that yours contains this section:
"hard_coded_contacts": [
"95.216.189.149:5483",
"116.203.25.212:5483",
"95.216.206.201:5483",
"116.203.56.138:5483"
],
Because if it still contains the old list then this means you have only 2 contact nodes available.
2 Likes
Maybe it was already mentioned, but if you’re behind a NAT running a vault on this test network on a system and then trying to connect with the SAFE Browser to the Alpha2 network on another system, that fails. At least for me (maybe depending on the configuration of the NAT on your home router).
The error messages seems similar like when your IP is not correct in invite.maidsafe.net. And in the file authenticator.log you see the error message:
Failed to Bootstrap: (InvalidNameHash) Network name mismatch.
When I stopped the vault of this test network, the SAFE Browser can connect to the Alpha 2 network (an no orange warning anymore about IP address on top).
Am I correct that this problem wouldn’t occur if this test network and Alpha2 do not use the same port nr 5483?
Probably the network name is not the correct one in your “SAFE Browser.crust.config” file. For the community network, its content should be:
{
"hard_coded_contacts": [
"95.216.189.149:5483",
"116.203.25.212:5483",
"95.216.206.201:5483",
"116.203.56.138:5483"
],
"whitelisted_node_ips": null,
"whitelisted_client_ips": null,
"tcp_acceptor_port": null,
"service_discovery_port": null,
"bootstrap_cache_name": null,
"force_acceptor_port_in_ext_ep": false,
"network_name": "tfa",
"dev": null
}
It is a different from content from Alspa 2. You have to switch the file any time you change the network you are browsing.
No, switching files is not the issue here, because it wouldnt solve what I was trying to accomplish.
On my raspberry Pi: a vault was running correctly, with your safe_vault.crust.config (network_name: “tfa”).
Then I tried to log in to Alpha 2 with SAFE Browser 11.2. It tried this on 2 systems. A Linux (not the Pi) and a Windows, with the unaltered safe-browser.crust.config with network_name: “alpha_2”. And this didn’t work until I stopped the “tfa”-vault on the Pi.
If I would want to connect to the “tfa”-network with the Browser, by changing the safe-browser.crust.config, that will probably work (that has worked in the past). But I want to connect to alpha_2…
1 Like