choose a port number and set the “tcp_acceptor_port” parameter of “safe_vault.crust.config” file with this value.
select the list of vaults users will connect to. Then set the corresponding list in of ip address + port number pairs in “hard_coded_contacts” parameter of both “SAFE Browser.crust.config” file (for the browser on clients) and “safe_vault.crust.config” file (for the vaults).
choose a network name and set this name to “network_name” parameter of both “SAFE Browser.crust.config” file and “safe_vault.crust.config” file.
You can use the screen utility to avoid maintaining a window constantly opened for each vault. You can also use the tee command to display output to the screen and simultaneously store it in a log file. For example, to launch the first vault the commands could be:
And later screen -r SV each time you want to recall the screen.
For subsequent vaults (on other droplets), do the same except that you must omit the -f argument.
Note: I did that a long time ago for some tests, so I may have forgotten some elements.
Client side, an empty string must be entered instead of an invitation token. This is OK for a private network you control. But if your network is public, things are more complex because to avoid spams you must manage invitations. Source of gen_invites program is available, but I don’t know how it works.
If you only need a network for some internal tests, the simplest way is to keep your “SAFE Browser.crust.config” file secret, so that nobody outside your company can connect to your network.
I was considering doing this as well in cloud or a local network but haven’t been able to make the time. The posts from @tfa and @mav on this are great, Thank you! In addition to protecting the crust config, you will want to make sure you have some good firewall rules and protections in place to make sure no one can get out-of-band access to the web through your network. This can be done by blocking all connections in-out on each node using iptables (except node to node in your network). Sometimes the cloud providers (such as aws) will let you do this from the web management gui. After that you can allow access to only one or more entrance nodes for your office IP on a specific port.
Thanks, I could solve the issue later. I did a mistake in the config file. Another problem I am facing now is if I stop the safe vault instance and start again, the data stored earlier is lost. Can you please suggest something for this?
If anyone please has any thoughts on his question. I suggested making vaults on multiple droplets so the data gets shuffles around in case one goes down, but don’t know how to go about connecting them?
Further to my email to you @Nayeem, if you stop and restart a vault the data on that vault will be lost, no way around that one atm. As @WhiteOutMashups mentioned, running a network of vaults on multiple droplets correctly will enable data to be retained by the network in the event a node goes offline.