Does anyone know the current best way to set up a local test network? Being limited to 500 PUTS seems like it will get in the way of prototyping pretty quickly. I know that the core MaidSafe team has plenty of experience deploying these test networks, so I’m wondering if there is a write up of how to deploy one (or a script to automate the process).
Thanks!
Well if you have a bunch of machines on LAN, you wouldn’t even need a config file i suppose - they should all discover each other and form a local network. Then you could run a client and that would basically bootstrap to the vault that first responds to it and you will have your local test net up and running with clients. (I cannot assert i am totally not stale on this though - e.g. one vault per LAN restrictions etc. , but do ping if you have problems).
It’s great to know that it is possible on a LAN. I’m afraid I don’t feel like I totally understand what we would need to run to start the self discovery process. What is the config file that I don’t need (even though I don’t need it I bet understanding it would help me)? Would just running a bunch of instances of the safe_launcher do the trick? Do we need to do things with vaults?
Thanks!
Yes vaults are the network (where storage etc. happens). If you compile safe_core with mock routing then use that to compile the launcher you have a self_contained network (mock). The launcher readme should show the steps, it would be great to know if any are missing for you. GitHub - maidsafe-archive/safe_launcher: Node.js App for SAFE Launcher
Thanks for being involved 
config files are crust config files - they contain among other things, a list of endpoints that crust can potentially bootstrap to. Running bunch of luanchers will only give you a bunch of clients. You will need vaults (entities that store data, manage redundancy etc) to do anything useful. So will need to run a few (say 10) instances of vaults and then perhaps a client (Launcher). If you just want to wire up something to test and don’t care about what goes on in the background (it’s transparent to apps anyway), then you could just use a Launcher that integrates with safe_core built against mock-routing. That makes safe_core totally mock basic functionality of vaults and routing (without any actual networking involved in the background) to give an illusion that it is talking to a valid network. To build safe_core with mock following the instructions here. Similarly head to safe_launcher repo and follow the instructions there to finally get launcher up and running.
This looks great! Thanks!
I run a local network for testing, and there are a few limits that I remove from vaults (I haven’t used mock routing, which may be adequate for your needs).
Hardcoded Default Account Size should be changed in maid_manager.rs
Replace the LowBalance conditional with false.
Routing will need the conditional for has_peers_on_lan replaced with false.
Cargo.toml for the vault will need to use the locally modified copy of routing.
After these changes, the new vault binary will need to be built from source.
That’s it for vaults, but then the demo app has upload limits that need to be changed if you’re using it to test.
This is quite a lot of work to get up and running, so I made a script called SafeInABox which does all this work. I confess these days I usually use it simply as a reference for where and what to change, and it probably won’t suit your needs as-is, but it’s worth a look.
Hope this helps, I’ve done a lot of work in this area (see Profiling Vault Performance) so am happy to answer any questions.
Thats fantastic. Exactly what I was looking for.
Thanks @mav, I think I will have to try this out soon so hopefully it is still up to date. I am writing my own Rust client for the SAFE Network to learn the API better so I think I will soon need a test network for that as I am already almost at my PUTs limit. (Not to mention I would like to write Elm, Javascript and Ruby versions too at some point as well.)
So just FYI team I may be back with question about using a test network soon. 
Yay for Elm! I hope to see an Elm package for the API eventually.
There are some additional things that recently required changing as outlined by @tfa in
For future records, a full list of modifications required to run a local network on Test 12C (ie vaults 0.13.1)
The diffs below are git diffs - any line starting with a minus sign is to be removed, any line starting with a plus sign is to be added.
$ rustc --version
rustc 1.16.0 (30cf806ef 2017-03-10)
$ cargo --version
cargo-0.17.0-nightly (f9e5481 2017-03-03)
$ node --version
v6.0.0
$ npm --version
3.8.6
git checkout 0.13.1
src/bin/safe_vault.rs
remove linting for unused and warnings
L27
- unknown_crate_types, warnings)]
+ unknown_crate_types)]
L33
- unknown_lints, unsafe_code, unused, unused_allocation, unused_attributes,
+ unknown_lints, unsafe_code, unused_allocation, unused_attributes,
src/lib.rs
remove linting for unused and warnings
L201
- unknown_crate_types, warnings)]
+ unknown_crate_types)]
L205
- unknown_lints, unsafe_code, unused, unused_allocation, unused_attributes,
+ unknown_lints, unsafe_code, unused_allocation, unused_attributes,
Cargo.toml
use local copy of routing
L24
-routing = "~0.28.2"
+routing = { path = "/home/user/maidsafe/routing" }
src/personas/maid_manager.rs
remove account limits
L34
-const DEFAULT_ACCOUNT_SIZE: u64 = 500;
+const DEFAULT_ACCOUNT_SIZE: u64 = 500000000;
git checkout 0.28.2
Cargo.toml
use local copy of crust
L13
-crust = "~0.22.0"
+crust = { path = "/home/user/maidsafe/crust" }
src/states/node.rs
Remove proof of work check for peers on local network
L1326
let (difficulty, target_size) = if self.crust_service.is_peer_hard_coded(&peer_id) ||
+ self.crust_service.has_peers_on_lan() ||
self.peer_mgr.get_joining_node(&peer_id).is_some() {
(0, 1)
} else {
Do not disconnect based on whitelist (@tfa this hasn’t been mentioned anywhere else yet, and was the missing piece of the puzzle for me to reliably bootstrap my pine64 network)
L398-406
- if !self.crust_service.is_peer_whitelisted(&peer_id) {
+ if !self.crust_service.is_peer_whitelisted(&peer_id) && false {
debug!("{:?} Received ConnectSuccess, but {:?} is not whitelisted.",
L1261
- if !client_restriction && !self.crust_service.is_peer_whitelisted(&peer_id) {
+ if !client_restriction && !self.crust_service.is_peer_whitelisted(&peer_id) && false {
warn!("{:?} Client is not whitelisted, so dropping connection.",
src/states/bootstrapping.rs
Fix FailedExternalReachability
L67
- let _ = self.crust_service.start_bootstrap(HashSet::new(), CrustUser::Node);
+ let _ = self.crust_service.start_bootstrap(HashSet::new(), CrustUser::Client);
L133
- let crust_user = if self.client_restriction {
- CrustUser::Client
- } else {
- CrustUser::Node
- };
let _ = self.crust_service
- .start_bootstrap(self.bootstrap_blacklist.clone(), crust_user);
+ .start_bootstrap(self.bootstrap_blacklist.clone(), CrustUser::Client);
src/node.rs
Allow peers on lan
L116
- self.deny_other_local_nodes && crust_service.has_peers_on_lan() {
+ self.deny_other_local_nodes && crust_service.has_peers_on_lan() && false {
In theory this shouldn’t need to be local since there are no modifications, but I found it wouldn’t work without using the local copy.
git checkout 0.22.0
src/lib.rs
remove linting for warnings and deprecated
L29-L30
- unknown_crate_types, warnings)]
-#![deny(deprecated, improper_ctypes, missing_docs,
+ unknown_crate_types)]
+#![deny(improper_ctypes, missing_docs,
Required for safe_launcher
git checkout 0.22.3
Cargo.toml
use local copy of routing
L21
-routing = "~0.28.2"
+routing = { path = "/home/user/maidsafe/routing" }
src/lib.rs
remove linting for warnings and unused
L29
- unknown_crate_types, warnings)]
+ unknown_crate_types)]
L33
- unknown_lints, unsafe_code, unused, unused_allocation, unused_attributes,
+ unknown_lints, unsafe_code, unused_allocation, unused_attributes,
git checkout 0.10.2
No code modifications required.
Copy the custom binary libsafe_core generated from safe_client_libs to app/ffi/
demo app is v0.6.2 which is in git tag 0.10.1 of safe_examples repo
git checkout 0.10.1
demo_app/config/env_[production|test|development]
Remove upload limits on filesize
L3-L4
- "isFileUploadSizeRestricted": true,
- "maxFileUploadSize": 25000000
+ "isFileUploadSizeRestricted": false,
+ "maxFileUploadSize": 25000000000000
Again, I have problems to run a local network.
It was Ok until commit ba64cf9 (included) of routing. I implemented principles defined above in my fork here.
But I tried to reimplement them on latest commit (ec585d1) but that doesn’t work anymore.
First, I came across this error:
INFO 23:21:20.552017000 [routing::states::bootstrapping bootstrapping.rs:295] Bootstrapping(506a15..) Connection failed: Proxy node needs a larger routing table to accept clients.
The workaround I found was to add the line testing the local-network feature in src/states/node.rs:
if (peer_kind == CrustUser::Client || !self.is_first_node) &&
!cfg!(feature = "local-network") &&
self.routing_table().len() < self.min_section_size() - 1 {
debug!("{:?} Client {:?} rejected: Routing table has {} entries. {} required.",
self,
But then the nodes fail to get relocated name:
INFO 22:58:05.075736900 [safe_vault::vault vault.rs:96] Use local-network feature
INFO 22:58:10.875088900 [routing::states::joining_node joining_node.rs:294] JoiningNode(f030ab..()) Requesting a relocated name from the network. This can take a while.
INFO 23:04:10.893171200 [routing::states::joining_node joining_node.rs:317] JoiningNode(f030ab..()) Failed to get relocated name from the network, so restarting.
WARN 23:04:10.893675800 [safe_vault::vault vault.rs:143] Restarting Vault
…
I suppose this is because the node connects as a client. But this was the way to make local network works until now. Without it I get the following error:
ERROR 23:39:38.478785200 [crust::main::bootstrap mod.rs:188] Failed to Bootstrap<UID>: (FailedExternalReachability) Bootstrappee node could not establish connection to us.
So now I am blocked. Please, could Maidsafe give some indications on making the local network works.
Note: I am pretty sure there was another thread about local networks where we were discussing the possibility to add a feature gated local network. I remember that this idea was postponed but the problem is that I don’t find this thread anymore.
Edit: I have found the thread. It is not a public topic but a PM in the other forum (initiated by @viv to @mav and me).
I still fail in running a local network. I tried some modifications but none succeeded.
Could @maidsafe_team indicates how to modify the code to make it work?
I found a way for local networks. There are modifications in 3 crates. They are available in my forks on GitHub:
To anyone: To create a local network, just clone the last one (safe_vault) and build safe_vault binary with cargo build --features "local-network" command.
@maidsafe: I didn’t make PR’s because there are probably things you wouldn’t code like I did, but please, take local networks into account in your base code. It is a pain to find how to do it each time there is a major change.
Thanks @tfa, this is awesome! Could you please share your vault / crust config files? I’m able to build your version of the vault but then it just shuts down after a while. Did you run all instances locally on one machine?
I don’t have any config files and I run all vaults locally on one machine.
I launch seed node with RUST_LOG=info ./target/debug/safe_vault -f in a first command window and then each following nodes with ./target/debug/safe_vault& in another command window.
My previous forks were not compatible with test17 client binaries. I tried to modify them but I didn’t succeed in making them work.
So, instead, I have recreated them from current master branches in hope that local networks created with new safe_vault will be compatible with next client binaries.
I am looking forward these binaries to test this possibility.
I had to add a small modification in routing to inhibit control of number of clients, but now local network work with new client binaries delivered by Maidsafe (with rate limiter). I just did a little test: created an account, added a service with a one file site and browsed to it successfully.
The procedure to create a local network is the following:
RUST_LOG=info ./target/debug/safe_vault -f./target/debug/safe_vault&. Do it at least 7 times and wait 10 s between each invocationTo use your local network with client binaries you have to:
$ cargo build --features "local-network" --verbose
Updating registry `https://github.com/rust-lang/crates.io-index`
Updating git repository `https://github.com/Thierry61/routing.git`
Updating git repository `https://github.com/Thierry61/crust.git`
error: failed to load source for a dependency on `crust`
Caused by:
Unable to update https://github.com/Thierry61/crust.git
Caused by:
failed to clone /home/folatt/.cargo/git/db/crust-8c8d4c67f38703cc into /home/folatt/.cargo/git/checkouts/crust-8c8d4c67f38703cc/2237fa3
Caused by:
[5/-1] error inflating zlib stream
[update]
It builds with sudo.