Release new image with ĞDev5 chainspecs

I’m not saying we should replace, but add.

Nodes hosted by individuals may fluctuate randomly and we’ll have to update the bootnodes list quite often. If during a few years we forgot to update it, all the bootnodes will be down with a non-negligible probability (maybe they just changed their port or domain).

So I propose a fallback server with a canonical address which is guaranteed to never change and does not depend on individuals only. Like gdev.duniter.org or gdev.axiom-team.fr.

It should also have RPC disabled to avoid becoming the de facto default node for clients.

Edit: This node may be the same used by the indexer, if the indexer is hosted by Axiom.

When all the bootnodes are down, someone starting a node can add another with --botnodes argument. What you suggest will be relevant for Ğ1 network, but for ĞDev and ĞTest, I don’t see the problem to stick to individual nodes only.

This won’t work imho, gdev-smith.pini.fr do not have its WS/RPC APIs exposed, or if you do you must avoid --rpc-methods=Unsafe usage (for security reasons), in which case you can’t administrate your validator node.

It does if RPC/WS APIs are exposed with --rpc-methods=Unsafe option. Otherwise, indeed, there is no particular security issue with P2P port.

What makes you think I manually added it? I was just giving you my bootnode URL.

This is the P2P endpoint which is bound to the port 30333 of my smith instance. Nothing related to the RPC API.

1 Like

What is the wss meant for then?

Also, I’m curious to know how you handle this mapping.

The CI released a new docker image duniter/duniter-v2s:sha-a160bedd (it’s ok to keep commit hash for now in order to find easily on which branch we are dealing with).

Only bootnode issue:

💔 The bootnode you want to connect to at `/dns/gdev.polux.re/tcp/30333/p2p/12D3KooWQ9dAZWSNQLLb3WG1gtNYhqhu7BUpaCXpUACvCFeoq8Ff` provided a different peer ID `12D3KooWJmjLNArKNerjUgVyEQmHuZgNTBe2mQb6vjmuGR635Vuh` than the one you expect `12D3KooWQ9dAZWSNQLLb3WG1gtNYhqhu7BUpaCXpUACvCFeoq8Ff`

PS : I updated my archive node and because I am not good at docker and renamed my service, I also lost my volume and changed my peerId :sweat_smile:

Now you know :stuck_out_tongue_closed_eyes:
(will be changed later)

Because the pattern p2p/<nodeId> appears twice in the address I quoted. I think the second one was set by Duniter2 and the first one was set manually. But maybe there is a bug that appends this twice with different peerId? :thinking: [edit: it’s a “copy-paste” bug :joy_cat:]

2 Likes

My mistake, I wrongly copy/pasted on the forum I think.

1 Like

See duniter command line help (duniter --help) and libp2p addressing documentation:

      --public-addr <PUBLIC_ADDR>...
          The public address that other nodes will use to connect to it. This can be used if there's a proxy in front of this node

      --listen-addr <LISTEN_ADDR>...
          Listen on this multiaddress.
          
          By default: If `--validator` is passed: `/ip4/0.0.0.0/tcp/<port>` and `/ip6/[::]/tcp/<port>`. Otherwise: `/ip4/0.0.0.0/tcp/<port>/ws` and `/ip6/[::]/tcp/<port>/ws`.

As I understand it you can force libp2p to listen on a web socket instead of TCP. This way you can setup your node behind a web reverse proxy, which is how I did.

I’m using a personal fork of nginx-proxy (*) which allows to map multiple ports of the same docker container. Here is the related configuration:

      - VIRTUAL_HOST=gdev.pini.fr
      - VIRTUAL_PORT=30333,9933:/http,9944:/ws

and

      - VIRTUAL_HOST=gdev-smith.pini.fr
      - VIRTUAL_PORT=30333,9944:/ws

For my smith node I expose the WS/RPC interface as well, but its access is protected with a certificate. This avoids the setting of an SSH tunnel when I want to deal with it.

(*) There is ongoing work on upstream nginx-proxy to implement a similar feature, so hopefully my fork won’t be needed anymore at some point in the future.

2 Likes

I’d be in favor of releasing duniter/duniter-v2s:latest as well so that:

  • current image would be easily identifiable
  • the image documentation would be pushed to dockerhub by the CI

Thois would greatly help wannabe smiths.

I’ve just updated my mirror node with your image and I see one more bootnode issue :sweat_smile::

2023-03-10 09:35:26 💔 The bootnode you want to connect to at `/dns/gdev.coinduf.eu/tcp/30333/p2p/12D3KooWMCrfuSXdGvokGCjbuN9KZvq9N7WWBoPat91gG1PU4w2b` provided a different peer ID `12D3KooWAVY7T3eqGxyjCPbKfMKrkT55XR6BuBxpW5sEEJYAJu3n` than the one you expect `12D3KooWMCrfuSXdGvokGCjbuN9KZvq9N7WWBoPat91gG1PU4w2b`.
2023-03-10 09:35:26 💔 The bootnode you want to connect to at `/dns/gdev.polux.re/tcp/30333/p2p/12D3KooWQ9dAZWSNQLLb3WG1gtNYhqhu7BUpaCXpUACvCFeoq8Ff` provided a different peer ID `12D3KooWJmjLNArKNerjUgVyEQmHuZgNTBe2mQb6vjmuGR635Vuh` than the one you expect `12D3KooWQ9dAZWSNQLLb3WG1gtNYhqhu7BUpaCXpUACvCFeoq8Ff`.

EDIT: These error messages keep showing in the logs. This goes in favor of having few but resilient bootnodes.

Ok, then I should use a release tag if I want to use the CI. I’m doing it.

Yes, I did see it immediately after updating my archive node:

[edit] you can use duniter/duniter-v2s:latest

@HugoTrentesaux je sais pas pk, probablement dû à une erreur de manipulation de ma part, le peerid de mon noeud mirroir à changé:

12D3KooWPJGF2DevfeH3gDy4rKHTR4QcyNkMWuKMD7xNeSNXhRha

Où vois-tu ce peerid ? Quand je demande à mon noeud, il me répond 12D3KooWAVY7T3eqGxyjCPbKfMKrkT55XR6BuBxpW5sEEJYAJu3n

Dans les logs de mon noeud mirroir:

poka@v2s-poka:~/duniter-indexer$ docker compose logs duniter-rpc | head -n50
duniter-indexer-duniter-rpc-1  | Node key file '/var/lib/duniter/node.key' exists.
duniter-indexer-duniter-rpc-1  | Node peer ID is '12D3KooWPJGF2DevfeH3gDy4rKHTR4QcyNkMWuKMD7xNeSNXhRha'.
[...]
duniter-indexer-duniter-rpc-1  | 2023-03-10 12:35:58 🏷  Local node identity is: 12D3KooWPJGF2DevfeH3gDy4rKHTR4QcyNkMWuKMD7xNeSNXhRha    
[...]
duniter-indexer-duniter-rpc-1  | 2023-03-10 12:35:58 🔍 Discovered new external address for our node: /ip4/163.172.105.161/tcp/30333/ws/p2p/12D3KooWPJGF2DevfeH3gDy4rKHTR4QcyNkMWuKMD7xNeSNXhRha 

Haha oui désolé, j’avais mal lu, je parlais du mien. Le tien est effectivement 12D3KooWPJGF2DevfeH3gDy4rKHTR4QcyNkMWuKMD7xNeSNXhRha, il faudra modifier…

1 Like

It does not tell what are the embeded chainspecs of this image. Maybe we should instead use tags like:

  • duniter/duniter-v2s:latest-gdev
  • duniter/duniter-v2s:latest-gtest
  • duniter/duniter-v2s:latest-g1

This way it would be clear which network Duniter tries to join when started.

On GitLab container registry, we can store containers into channels/repositories:

  • gdev:latest
  • g1:latest
  • gtest:latest

See for instance Silkaj’s channels.

2 Likes

I’d prefer:

  • duniter/duniter-v2s-gdev:latest
  • duniter/duniter-v2s-gtest:latest
  • duniter/duniter-v2s-g1:latest
2 Likes

Why do you prefer this option? I personally would prefer Moul’s option with channels. But I do not want to configure GitLab container registry or modify CI myself.

At the moment I think it is good if early testers understand the concepts of runtimes / chainspecs / bootnodes well enough to be able to choose the good image depending on what they are trying to do.

As said in the other thread I think it’s easier for newcomers when the latest tag is the one to choose.

I won’t say otherwise. But it doesn’t seem to be the case right now.

I moved this topic in ĞDev category and added the todo tag because we still should update the embeded bootnodes in ĞDev chainspecs.