Hey guys! I think it’s really important that we have constantly-running testnets up at all hours! So even when MaidSafe’s one goes down for rebuild, we can keep testing our website, vaults, apps, DNS, accounts, etc and make discoveries around the clock, independent of theirs.
What do you guys think? I didn’t see a thread for it so I’m making this.
Let’s keep coming back here and updating it with most current info on the live testnets
Cool, If we have someone that wants to setup a Droplet or some other website that would be great. It’s only about 10$/month so that shouldn’t be a problem. I don’t know about how to change the config file.
@bluebird was talking about it as well. Let’s do it!
I do need that too, to test my apps.
What version of the vault should we run on this ? It would need something stable enough, and up to date enough so testing against it is meaningful.
Yeah I can Help pay for this, it’s definitely a worthwhile investment.
I already have a droplet going that I was considering closing anyway, but we can definitely start using it for this
Would be interesting to see how much of the network still exists, if it’s brought back from the dead. If it’s simply a case of a config fix to point in the right direction, it might be interesting to try it.
I just had a chat with @frabrunelle and @smacz and we tried to connect to a Vault. But it didn’t work so far. We changed the IP-address in the config file to one of ours but weren’t able to connect so far. Even after some port forwarding.
Hmm Could my droplet Help? What kind of info would you need? The DigitalOcean login? Or just the ssh login info? (I’ll tell you what folders not to change, etc)
I’m not that handy with Linux and SSH etc. We tried to connect to a Vault I ran at home. But we have to know exactly how to change the config for the Vaults. There are several IP’s in there. Do we need to change them all to the same one??
This is David’s reply:
As a heads up, I tried running safe_vault on my VPS (not digital ocean) that runs CentOS7 and it complained that I didn’t have a recent enough version of glibc. Changing the libc6 (same thing, just another name for it) version is very dangerous, and no other versions are available in the repos - for good reason.
For a reference, when installing my favorite distro - bunsenlabs (formerly crunchbang) it pops up with this warning:
While FOSS is primarily about freedom and choice, certain choices are known to carry an increased risk of breaking things in BunsenLabs.
Two of the riskier things are:
More information on some of the riskier things, the above included,
can be found here:
DontBreakDebian - Debian Wiki
(Right click the above link and choose “Open Link” to visit the page.)
I’ll have to spin up a Fedora Server VPS or something else that is more bleeding edge in order to run vaults on it.
I’m thinking that any computer behind a NAT would need a tcp_mapper_server in order to function properly - perhaps even if you have port forwarding enabled.
This would be the most likely use-case for your droplet.
I would be very interested in getting descriptions of the variables in the config file. Namely:
tcp_acceptorstcp_acceptor_portservice_discovery_portbootstrap_cache_nametcp_mapper_serverswill config in launcher not require a similar change?
Guessing … Launcher will look to local vault perhaps… but if ones not running perhaps config would need to know the seed ip??
I was thinking about this as well. On the other hand, I someone has a Vault active, Launcher connects over the Vault if I understood correctly.
As suggested by the test config file and @dirvine 's input here. He did say that all the droplets are the same when I asked if any had special abilities. So assume that any of them can accept tcp, map tcp or whatever.
tcp_acceptors: some vault’s IP
tcp_acceptor_port: 5483
service_discovery_port: null
bootstrap_cache_name: null
tcp_mapper_servers: some vault’s IP
Right now I don’t have time to do it. But next weekend I’d be glad to join the party.
To avoid errors inherent to management of different seeds files I would advise you to define NETWORK_VERSION environment variable and then compile from source. This is to insure connection to the community network and not the Maidsafe test network (see my previous post).
To build the vault issue following commands in safe_vault crate:
export NETWORK_VERSION=COMMUNITY-NETWORK-1.0
Cargo build
Of course this doesn’t replace the config file (and it seems that some people here are on the way to define it). The benefit of defining this environment variable is that if someone uses the wrong config file (from example the one from Maidsafe) the vault won’t connect to the community network and a crust error will be displayed.
Will new new Maidsafe network not just reject older versions?.. or else there’s a risk of older version being used by those unaware of an update, regardless of some trying to put nodes to a community network.
No, the Maidsafe binaries check version and reject older Vaults etc. I think a community net should only be up when there’s no official testnet. We should take ours down immediately and run the official one once they start again. The only reason I see for a community testnet are the following:
Well we really gotta get this figured out guys,
We need to have testnet running
It shouldn’t be hard with all the MaidSafe releases we now have
A version hash is used by crust to control validity of connecting node. This hash is based on 2 environment variables:
CARGO_PKG_VERSION which is set automatically by cargo to the version of the binary being build. This is the way that the network rejects older vaults.
NETWORK_VERSION which can be set manually at compile time. I proposed to use this variable to prevent accidental connection to Maidsafe network when we wanted to connect to community network or vice-versa. This is useful when both networks use vaults based on the same sources, and so cannot be discriminated by CARGO_PKG_VERSION.
EDIT:
In current master branch of crust the 2 environment variables controlling connecting nodes have been replaced by only one element: network_name parameter in config file
The advantage is that there is no risk of errors anymore when one wants to launch an independent network because the seed IP addresses are provided together with the network name in the same file.
The drawback is that automatic rejection of older vaults is lost. The sensible workaround is to include the vault version in the network name.
So I guess we have to agree on a certain for our community-net?
Which one will we use?
And we should organize to deploy several vaults at the same time to get it going