Now that Testnet5 is winding down, and Testnet6 is scheduled for tomorrow, that leaves a window for reactivating community1 with some new backend tweaks. Basically, I have eight vaults running on the cloud server, as well as one locally. More than enough to run client apps, nice and fast: http://test-community1.bluebird.safenet
The theme of community1 is “The Bleeding Edge Community Network” and its distinction is to host the very latest builds of the SAFE network software.
For the convenience of participants, I have assembled the configs and binaries into four variations, at the link below Please download one, probably “community1-amd64-release” if your computer is a regular PC running 64-bit Linux, and run one instance of it. No modifications or additions are required!
Please also run the launcher and upload whatever you like.
“Release” is the official binary as used in Testnet5, while “latest” is one that is automatically compiled nightly straight from the github repo:
I have a vault running. tried to upload my site but after a few minutes of sitting at 0% I received - cannot connect to launcher, launcher should be kept running, or something like that. (launcher was connected)
going fishing I try again in a bit.
I’m running the demo app and launcher from Testnet5, with the config in the OP, and it worked fast. Just now created a new site: http://another-test.bluebird.safenet Each step took a few seconds (granted that they are just “hello world” pages. Sorry, fake spiders!)
OK, I was having the same problem as @Josh so I have reconfigured my vaults so as to eliminate the “–first” vault, which I suspect, from previous experience, can cause instability (or not), by (tl:dr) musical chairs.
I wonder that encouraging a bad habit of accepting recompiled binaries, might not be a good idea, regardless of who those are from.
Tweaks and recompile are too easy to encourage, relative to the risk later when currency and privacy is involved; and then obvious other risks beyond what the network should do.
A community network surely should follow directly from what was made available for each Test or in future Alpha. Those folk who then want to do something else, can know how to do that but obviously any change will potentially add confusion to performance.
Adding in a new network config that is human readable, is trivial and at least worth understanding for all those wanting to know how to switch networks.
Perhaps shortly community network will directly follow from each new instance of the network released from Maidsafe but even then there is a risk of putting new binaries around as if they are necessarily ‘SAFE’.
I’m finding that after a few hours the demo app won’t connect, despite the fact that the launcher connects in a few seconds. I’m going to try a slightly different approach that will require a restart (and brief downtime) of the vaults on the cloud server, in a few minutes from now.
EDIT: It’s back up now. I now have the startup script write the (parent) PID of each instance of safe_vault to a text file. I can then track them individually in Htop and kill and restart them one by one, instead of all at once. I had found that you can’t rename the binary: it simply won’t run with any other name except “safe_vault”, so it was hard to know for sure what I was looking at in Htop with twenty or so lines all saying “safe_vault”.
Now, when I see the demo app getting stuck, I’ll introduce some “churn” by restarting vaults one at a time at spaced intervals and see if that helps (while aiming to preserve IDs and data).
The relevant part of the startup script, for the first two vaults, looks like this (where $! is the variable for the PID of the most recently started process):
Although launcher connection takes a few seconds, upload of a website can take a couple of minutes even if it is a minimal site of a 100 bytes. So if you are experiencing time-out then try the least amount of data first.