MoreStabilityNet [19/07/23 Testnet] [Offline]

[chriso]

You probably have an older version of safeup. That feature comes with v0.4.0.

[happybeing]

My node seems not to have connected so I will try with @JPL’s recommendation.

@chriso might be worth changing the suggested node in the OP.

EDIT: confirmed, my node connected using JPL recommended peer.

[chriso]

I can’t make changes to the maidsafe posts I’m afraid. Will need to wait till John sees it.

[JPL]

Seen it, doing it … done it

[chriso]

Thanks John. I’m going to alter the template instructions to remove SAFE_PEERS from the peer list in the ‘Network Details’ section and just have the list of peers in there. Setting SAFE_PEERS is stated in both the ‘quickstart’ and ‘further information’ section in a cross platform way.

[JPL]

OK - let me know if any more changes are needed to the OP

[chriso]

If you wanted to update it now, I’ve changed the template to this.

SAFE_PEERS: /ip4/176.58.124.107/tcp/44439/p2p/12D3KooWEwMPj64C1MXEKaCYHGgtMApNzzvoynfprLJRLfgfGo7G
Alternatives:

 "/ip4/161.35.39.103/tcp/38297/p2p/12D3KooWCgxHVhPfSndYod2KzRivZF5AnF125R5WoZt5GbX7JMtB"
 "/ip4/143.110.169.215/tcp/38247/p2p/12D3KooWHSrZhRZSstxdhHGU3Vfj6Czxp12zqepsLvhFEfGS9R5Q"
 "/ip4/161.35.39.22/tcp/36197/p2p/12D3KooWT1ywindpChtzfaWHfCFWexGfxYG1AVNQxwyEwR2cZwR4"
 "/ip4/165.232.101.63/tcp/46029/p2p/12D3KooWGEBCRAmekSwfa7yidNNYbXtRDh1JPP14mntgtJ1yGChb"
 "/ip4/178.62.91.4/tcp/39243/p2p/12D3KooWGXKWUfiCvEevBaT9VnmR7qVihyQD1PaJThzG4LLewJCU"
 "/ip4/165.232.101.62/tcp/34009/p2p/12D3KooWAUuNGrFXux6Fx9kJGSzRxM6fXr1ZBvjY64ujqx3MwjSv"
 "/ip4/161.35.39.101/tcp/40003/p2p/12D3KooWEPNrJmZyhRyEqvFkSng8v4yVuQ1ZJDu2PerLRpaQkELH"

Edit: also probably just worth updating the peer references in the ‘quickstart’ and ‘further information’ sections, which are different from the primary peer now stated in ‘Network Details’.

[Josh]

@maidsafe

Quickstart

If you already have safeup, you can obtain the client and node binaries:

safeup client --version 0.79.26
safeup node --version 0.86.25

@chriso

rock64@one:~$ safeup node --version 0.86.25
**************************************
*                                    *
*          Installing safenode       *
*                                    *
**************************************
Installing safenode for aarch64-unknown-linux-musl at /home/rock64/.local/bin...
  [########################################] 6.10 MiB/6.10 MiB                                                                Error: Text file busy (os error 26)

Location:
    src/install.rs:198:39

[chriso]

Thanks for the info. What kind of machine are you running that on? A pi?

[Josh]

more or less, a Pine64.

Also the OP for install on Linux is bash instead of sudo bash is that intended?

[chriso]

Thanks for the info, I’ll look into this.

Yeah, the lack of sudo is intentional. I’m not sure if this was going to be included in a dev update, but here is a copy of my Slack post justifying this decision:

I know this isn’t the most exciting thing in the world, but just wanted to make everyone aware of a decision I plan to make with respect to safeup. Just in case anyone disagrees, please feel free to let me know.

safeup was written was to accommodate being able to run as either the current user or sudo. If you ran as sudo, the binaries would get installed to /usr/local/bin, which is what actually happens with a lot of apps (they get installed there, or in /usr/bin, or /bin, or somewhere that’s already on the PATH variable in a default setup). This is because some people like their binaries going there (me included) and because you don’t have to do any faffing around with modifying PATH to include a location somewhere under ~ . I know modifying PATH is actually a pretty simple concept, but it can, and has, confused some users who aren’t familiar with how shells and terminals work.

Anyway, after my sign off message yesterday, I’ve now changed my mind about this and would like to go in the direction that we only support running as the current user. So the binaries will be installed to ~/.local/bin. I make this decision for the following reasons:

• You only need one install script instruction rather than two (one for run as sudo, the other for run as current user). Again, as simple as it is, this has confused users in the testnet threads and led to complications.
• You only need to document one of those instructions.
• It prevents the possibility of a mistake where sometimes the user runs sudo safeup and gets a binary at /usr/local/bin, but then they just run safeup and install the same or different version of the binary to ~/.local/bin.
• Same applies to running update to get new components.
• Hopefully the ~/.local/bin location will be on PATH by default in the future. It would be genuinely useful if the OS could start coming with some default user-based location on PATH .
• Less code and scenarios to support (like preventing the mistakes above) in safeup , thus it’s simpler to maintain and test.

If there are users who still want binaries at system-wide locations, they’ll probably just need to download and extract themselves. Or the scenario could be supported either by community install scripts, or in the long term I would hope perhaps the safe-related binaries will get added to package managers by the people who maintain those systems.

Sorry for how long this is, but I couldn’t think of a way to make it shorter without getting everything across.

[Josh]

@chriso

It prevents the possibility of a mistake where sometimes the user runs sudo safeup and gets a binary at /usr/local/bin, but then they just run safeup and install the same or different version of the binary to ~/.local/bin.

Guilty as charged!

Good call I think, thanks Chris.

[chriso]

Thanks. I tried to add in code to prevent the mistake from happening, but it gets complicated when you run in two different user contexts. We would have needed to maintain the list of installed components in a location where both the current user and root could access. That would have meant having root access to create that location.

This mistake will happen so many times that it’s just not bothering with. I think ~/.local/bin isn’t a bad location. For my own personal OS setup, I’ve started adding it to my PATH. I’ve noticed some Python apps get installed there when you run pip in user mode. Hopefully at some point they might add it to the PATH by default.

[happybeing]

ICYMI there is an ongoing effort to package safe binaries for Debian, which has a topic in the forum but I’m not sure how that is going.

Personally I use ~/bin for local binaries.

[chriso]

Yeah, I was part of that discussion a while ago, but I haven’t look into it for ages.

[danda]

Question: Is there any kind of versioning built into the protocol for these testnets?

Stated differently, does anything prevent nodes running older code from connecting?

I ask because I would think that at this early stage, we would want to ensure that all nodes are running the same software version, or at least prevent old nodes from accidentally joining.

[chriso]

@danda

Question: Is there any kind of versioning built into the protocol for these testnets?

I know @dirvine has done a bit of thinking on this issue, and I think libp2p does provide some functionality here, but I couldn’t speak to it myself at the moment.

[dirvine]

@danda

Question: Is there any kind of versioning built into the protocol for these testnets?

Not quite yet, but it’s certainly an issue we see and something we need for launch. Just another ball in the air, but for sure it will be done. Sooner the better I think as folk do get mixed up and reasonable they do at this stage.

We also need though to cope with backward compatibility for at least a few version, right now though that’s less a concern as it’s boom or bust at this stage of dev.

[Secretariat415]

Yay! Another testnet to give us all hope and give the community a great way to contribute.

What a nice start to the 2nd half of 2023.

[Profess]

Another TestNet? It is called pace!

@maidsafe

Our next testnet, MoreStabilityNet, is looking to see how node stability has been affected by recent fixes.

The NodeDiscoveryNet has done well, surfacing data all the way through, even though we lost 12/20 nodes per droplet due to excessive memory.

We’ve a few fixes in and more pending that should improve things here. And we’d like to see how this goes for our MaidSafe Digital Ocean droplets and for those starting nodes in the community.

The installation of the client and node binaries is lightning fast, and the installation of the node is lightning fast too.