Community-run Testnet Info!

[tfa]

@whiteoutmashups

It shouldn’t be hard

No, it is. Please be patient. Some people are trying very hard to connect vaults and define corresponding config file with needed seeds (@frabrunelle, @smacz and @polpolrene).

[whiteoutmashups]

Well we can’t give up!

I already pay for DigitalOcean so just let me know exactly how to help get this network up and running @polpolrene @frabrunelle etc

[Josh]

“started a new network as a seed node” but my meaningless fumbling in the dark gets no further. Have you made better progress?

[MrAnderson]

{
  "hard_coded_contacts": [
    {
      "tcp_acceptors": [
        "46.101.82.42:5483"
      ],
      "tcp_mapper_servers": []
    },
    {
      "tcp_acceptors": [
        "139.59.174.99:5483"
      ],
      "tcp_mapper_servers": []
    },
    {
      "tcp_acceptors": [
        "139.59.173.133:5483"
      ],
      "tcp_mapper_servers": []
    },
    {
      "tcp_acceptors": [
        "139.59.173.198:5483"
      ],
      "tcp_mapper_servers": []
    },
    {
      "tcp_acceptors": [
        "139.59.171.74:5483"
      ],
      "tcp_mapper_servers": []
    },
    {
      "tcp_acceptors": [
        "139.59.163.140:5483"
      ],
      "tcp_mapper_servers": []
    }
  ],
  "tcp_acceptor_port": 5483,
  "service_discovery_port": null,
  "bootstrap_cache_name": null,
  "tcp_mapper_servers": [
    "162.243.228.81:39590",
    "128.199.185.249:44473",
    "178.62.82.189:46782"
  ]
}

So really the main part for the test net is the tcp_mapper_servers? If some one spends the time (sorry, no time for me for a little while) to figure out the changes to make to the config file then let us know and I should have time to make a quick config file change.

[polpolrene]

@tfa

No, it is. Please be patient. Some people are trying very hard to connect vaults and define corresponding config file with needed seeds (@frabrunelle, @smacz and @polpolrene).

Don´t expect that much from me on this level. I´m really not handy with a terminal, compilers etc.

[polpolrene]

No, I just started a node and after some time it said it was listening. I gave my IP to @frabrunelle and @smacz but we couldn’t connect that way.

[smacz]

Well, I reinstalled by VM Host’s OS 'cause I screwed up the networking big time on the old install. But good news is now I have the perfect testbed for this. I’ll let you guys know what I’m trying in there. I just need to get two connected…

[whiteoutmashups]

I’ll get my setup running in the morning

[polpolrene]

I’m online, let me know if you have some alternative config and I’ll try to connect

[lightyear]

@polpolrene

I’m online, let me know if you have some alternative config and I’ll try to connect

Could you try this one:

gnunicorn/safevault-docker/blob/master/safe_vault.crust.config

This is my docker running the latest 0.8.0 version. I can’t get my locally run vaults to connect it though. The parameters don’t seem to be thoroughly explained anywhere…

---

@tfa

To build the vault issue following commands in safe_vault crate:

export NETWORK_VERSION=COMMUNITY-NETWORK-1.0
Cargo build

I don’t think there is any need to create our own network version (also, if anything it should COMMUNITY-NETWORK-0.8). If the core team wants to make a test with updated libs, they’d have to bump the version and then the new ones woulnd’t connect to the old network – that’s all good. It would just be different networks on different version. And as long as we are under v1.0 there is no point in having “backwards compatibility”. BUT no one can prevent anyone from starting any network run on any version they like – that’s kind of the point, isn’t it?

So. I’m trying to my vault up and in a position to provide a config that others can connect and we can bootstrap a network from there. Once a new network is up, I’ll upgrade the docker image and therefore all connections with previously clients will be rejected – however, any network that they bootstrapped by then might still be running. Which should be fine, as they won’t interact.

[polpolrene]

I’ve tried it. but it didn’t work

This is what I get.

[lightyear]

Yeah, It’s what I see on my tests, too …

Without some enlightenment from the maidsafe team, I am afraid this is just poking around in the dark at the moment…

[dirvine]

YEa, been watching, we are making some changes again, just so few resources to help to much. Lets see what another couple of days brings though Tiny bit more patience and we should be good.

[bluebird]

During Test 2 I commented as follows:

SAFE Network - TEST 2 - Update (7th May 12:15 BST) Now complete

I see that the log.toml file in the distributable is necessary to the test, and not just the config file. I did a new compile and the resulting binary would not run until I added both of those files.

EDIT: It isn’t used during compiling, since my own binary (built from a clone from github.com) would work if it was in the same folder as the binary. You don’t need to know what it does (secret sauce) but just that it provides some values that are required by the binary:

[appender.async_console]
kind = "async_console"
pattern = "%l %d{%H:%M:%S.%f} [%M #FS#%f#FE#:%L] %m"

[[appender.async_console.filter]]
kind = "threshold"
level = "info"

[appender.async_file]
kind = "async_file"
path = "Node.log"
pattern = "%l %d{%H:%M:%S.%f} [%M #FS#%f#FE#:%L] %m"
append = false

[root]
level = "error"
appenders = ["async_console", "async_file"]

[[logger]]
name = "crust"
level = "debug"
appenders = ["async_file"]
additive = false

[[logger]]
name = "routing"
level = "debug"

[[logger]]
name = "safe_vault"
level = "debug"

[bluebird]

@lightyear

Without some enlightenment from the maidsafe team, I am afraid this is just poking around in the dark at the moment…

Nonsense!! I would have it running now but I’m refurbishing my dedicated server and it won’t be ready until tomorrow.

HOW TO START A COMMUNITY NETWORK:

1. Have two machines with fixed, or at least known, IP addresses (home/office and a dedicated server/droplet in the cloud). (Note 1)

2. Unzip the distributable. Copy the files to two folders.

3. Edit the config file in folder A to include the IP address of host B, and vice versa, and no other IP addresses (very important at this point, to avoid stepping on the Maidsafe net). Use the first example in note 2 below, substituting the IP of host A or host B (or both).

4. Upload folder A to your dedicated server and run the binary.

5. Run the binary in folder B.

6. (optional) Pray to your deity.

7. If that test works then great! Next test would involve a customized build as described by @tfa after setting environment variable NETWORK_VERSION

8. If that (second) test works then great! Now send that folder to someone else to run, and you should now see three nodes.

9. If the first test fails then debug, probably starting with the config file (check syntax: commas and brackets).

Note 1: You can do this even if you have one fixed IP (presumably the one in the cloud) and one dynamic IP (perhaps a home broadband service). The nodes will find each other even if only one knows the address of the other. You might determine your home IP address (acquired the last time you restarted your router, probably) by going to a site such as whatismyip.com.

Note 2: Minimal safe_vault.crust.config

{
  "hard_coded_contacts": [
    {
      "tcp_acceptors": [
        "aaaa.aaa.aaa.aaa:5483"
      ],
      "tcp_mapper_servers": []
    },
    {
      "tcp_acceptors": [
        "bbb.bbb.bbb.bbb:5483"
      ],
      "tcp_mapper_servers": []
    }
  ],
  "tcp_acceptor_port": 5483,
  "service_discovery_port": null,
  "bootstrap_cache_name": null,
  "tcp_mapper_servers": null
}

Now try this, and see what happens (breaks, doesn’t break, connects faster)!

{
  "hard_coded_contacts": [
    {
      "tcp_acceptors": [
        "aaaa.aaa.aaa.aaa:5483"
      ],
      "tcp_mapper_servers": []
    },
    {
      "tcp_acceptors": [
        "bbb.bbb.bbb.bbb:5483"
      ],
      "tcp_mapper_servers": []
    }
  ],
  "tcp_acceptor_port": 5483,
  "service_discovery_port": null,
  "bootstrap_cache_name": null,
  "tcp_mapper_servers": [
    "aaa.aaa.aaa.aaa:45678",
    "bbb.bbb.bbb.bbb:56789"
  ]
}

EDIT: On that second example in note 2: I’m not sure if that is enough to cause A or B to listen as a tcp_mapper-server. Conceivably, other nodes might be sending “mapper” requests to that port but the receiver isn’t paying attention. Still, I’m proceeding on the premise that all the nodes are indeed the same, i.e., that they have identical config files, and the config file in the distributable has no other types of values than are in my second example (no values that might make a node listen as a mapper, other than the tcp_mapper_servers list at the bottom).

[davidpbrown]

@lightyear the port suggested in your post looks like 15483 not the 5483 suggested elsewhere.
@Josh how did you start a seed node rather than a normal one?

I still don’t see the need to recompile that bluebird and tfa are suggesting. The next network that doesn’t want old nodes needs to action a defence against those itself.

If there’s another IP address suggested I’ll give it a go but expect at this stage this is something for next round.

[Traktion]

Is it not better to let maidsafe get a fully operational network live first, before adding the complexity of maintaining this? Just saying.

[epic]

In the dash community we keep a test network . I think the community can develop its tests and results. For me it is important to go as fast as possible in this idea. Less in the background.

[Josh]

@davidpbrown happens automatically if you open 2 or more vaults on the same machine but I could not get a second machine to join. - its all Hebrew to me I’m just messing about.

@Traktion you are probably correct!

[anon81773980]

How can we test our own build application on safenet without maidsafe going live?