I have a happy vault
You can be proud of yourself and show your name in the galaxy to every one.
Sorry, I don’t intend doing this:
- The limit is hardcoded, and I want users to be able to use direct deliveries from Maidsafe and not force them to use an external fork.
- During the transition phase I am not sure that a consensus on a user balance can be reached if some nodes implement the old limit and some other nodes the new one.
- I don’t even know how the code is supposed to work: an account has 2 fields that seem redundant to me (mutations_done and mutations_available) and I don’t know which one really matters.
- One account with 1000 PUTS could potentially use 8GB in the network (duplication factor is 8, so 8 * 1000 * 1MB). That’s already huge
What could be done instead is reducing restriction to trust level 1 members and/or allowing a second invite.
The blues are back safe://safeblues.jpl
So, today I decided to give the SAFE Vault a try. Very exciting stuff!
I tried it on both a Raspberry Pi, a 64-bit Arch Linux machine and a 64-bit Windows 10 machine.
I followed the instructions to build version
0.18.0  from source on the Raspberry.
Running yields the following:
$ RUST_LOG=info ./safe_vault INFO 15:09:20.552779598 [safe_vault safe_vault.rs:74] Running safe_vault v0.18.0 ========================== INFO 15:09:22.656258092 [safe_vault::chunk_store mod.rs:122] Created chunk store at /tmp/safe_vault_chunk_store.vjSTX3MViexL with capacity of 34359738368 bytes. ERROR 15:09:26.749222621 [crust::main::bootstrap mod.rs:208] Failed to Bootstrap: (FailedExternalReachability) Bootstrappee node could not establish connection to us. INFO 15:09:26.750127413 [routing::states::bootstrapping bootstrapping.rs:287] Bootstrapping(388b05..) Failed to bootstrap. Terminating.
Seems like a few others also encountered this. Then I tried running the
0.17.2 binaries from @maidsafe but on Windows, and I got the exact same result.
Then, reading about firewalls and routers I forwarded my port to the Raspberry. This resulted in the same with the following extra
INFO log line before the
INFO 15:15:39.650965286 [routing::states::joining_node joining_node.rs:310] JoiningNode(e29897..()) Requesting a relocated name from the network. This can take a while.
Then, I also tried forwarding with Windows (
0.17.2) and it succeeded!
Edit: after experimenting some further I notice that the versions and OSes might not really matter. It seems that after port forwarding I get inconsistent results when running the vault. It either fails to ‘establish connection’, hangs on ‘Requesting a relocated name’ or it just runs. E.g. after removing the
.cache file, it fails to connect twice, the third time it runs fine.
Anyway, running a vault now!
Did you try open ports on Arch software firewall, like ufw, if Arch has that or similar? Nice to see you atleast got the windows one up and running. I don’t know if it helps but @bart made a package which worked on his Arch pi.
I have looked at
iptables briefly, but it doesn’t seem like my Pi has a firewall enabled.
Also, like I mentioned in my edit it seems the versions or OSes don’t matter. @bart’s binary, @maidsafe’s binary and my own compiled binary are interchangeable as far as I can tell. At this moment I have the node running on my Pi within a Tmux session.
I wasn’t paying attention to my exact steps, so I can’t say how the errors are reproduced reliably. If I would guess it’s network-related. Perhaps my router is the culprit, perhaps it’s by chance that I can bootstrap at certain moments; I don’t know.
Kinda funny that it’s actually easier to run a vault than to create an account assuming you meet the minimum requirements for a vault.
Might be something to learn from that with respect to mainnet ux…? As in, what’s it like to be a read-only participant unless you ‘jump a hurdle’ (have invite / safecoin)?
“Sorry you can’t reply, your safecoin balance is too low.”
Gonna be an interesting process to educate new users via the browser ux.
edit: really stoked to be able to run a vault at home again, it just feels good for some reason.
I’m hoping there is some sort of setup wizard like education walk throughs when first interacting with the network (ie account creation) that inform users of earning for network services by helping secure the network with a simple click.
Something like “your game balance is too low to buy that ???” OR “your itunes balance is too low to listen to that song” OR “your recharge balance is used up and cannot make that phone call”
Surely it will be possible to make the “need to spend another coin” a lot easier than being caught out unexpectantly. I would think there will be plenty of opportunity to warn the user of low PUT balance.
Also it was suggested by the devs early in the piece that there could be a way to have coins ready to be automatically spent when the PUT balance runs out.
Also if division like Frazer’s then this should be simpler.
@bzee has asked me via PM about the compilation process for ARM+musl, so that he could try doing it himself, then suggested that I could also post the instructions here, so here you go
What I did was cross-compile for ARM on a x86-64 laptop with Gentoo. The only part that would look different on other distros (or maybe even OSs, like Windows) should be getting the cross-compilation GCC toolchain. The rest should look pretty similar.
The process also works almost unchanged whether you compile for musl or for glibc, although it might be easier to get a cross-compiler for glibc on some distros (it is on Arch).
- You need a cross-compilation GCC toolchain for linking. On Gentoo, I could get that with
crossdev -t armv7a-hardfloat-linux-musleabi(although I had to modify the build script slightly - if you want details, ping me); I’ve also tried searching for a corresponding Arch package, but there seem to be none for musl; there is one for glibc on AUR, though: https://aur.archlinux.org/packages/arm-linux-gnueabihf-gcc/
If you want to compile directly on the Pi, you don’t need this step if compiling for glibc (regular gcc will suffice), and you need musl and musl-gcc if compiling for musl.
- Add an appropriate target to Rust via
rustup target add armv7-unknown-linux-musleabihffor musl or
rustup target add armv7-unknown-linux-gnueabihffor glibc (not needed if compiling on Pi for glibc).
- Configure the cross-GCC as the linker for the target. This is done by editing
linker = "armv7a-hardfloat-linux-musleabi-gcc"
(You would need to change
gnueabihfif compiling for glibc, and provide the proper GCC binary name, of course. For musl directly on Pi, the linker would be
musl-gcc. For glibc directly on Pi, you can omit this step entirely.)
- Clone the safe_vault repo (
git clone https://github.com/maidsafe/safe_vault.git; git checkout 0.18.0or just download the source from here), enter its directory and execute
cargo build --release --target=armv7-unknown-linux-musleabihf(or
-gnueabihfif compiling for glibc; you can omit
--targetentirely if compiling for glibc on Pi).
On my system, there was a crate among the dependencies that wouldn’t compile this way, as it was trying to call the cross-gcc under a wrong name for some reason - I solved that by creating the symlink to the gcc binary with the name it was looking for.
And that’s it. You should have a binary that will work on a Pi after that. When you use a musl target, it’s statically linked by default, a glibc binary is dynamically linked and it’s what caused problems for some people (although worked for me with Arch on the Pi).
I hope it’s useful, or at least allows someone to learn something
@bart Really useful post! It might be worth posting that as it’s own topic. It will be easier for people to find, and any questions, problems, answers and solutions can be on the topic too.
Perhaps add a link to the source code and version as well, just to be clear.
Post a lap time in the final, I will start it off with a paltry 2.02.6
Ha! Is that Outrun?!
Yep. Where is the time when this was the coolest arcade game on the fair.
I remember playing it when on holiday as a kid. Happy days!