ĞTest #2 - Reboot October 2025 runtime 1100

Networks ĞTest
42

Question concernant la mise à jour des serveurs - je ne sais pas si c’est normal; mais depuis la GTest#2; je n’arrivais plus à faire des requêtes sur mon serveur GTest#1:

gcli identity show
Duniter("can not connect to duniter ws://127.0.0.1:9954")

Alors que le serveur tournait toujours sur ce même port…

Et la commande pour récupérer les endpoints (sur le même port) fonctionnait toujours

curl -X POST http://127.0.0.1:9954 -H 'Content-Type: application/json' --data '{"jsonrpc":"2.0","id":1,"method":"duniter_peerings","params":{}}' | jq

Du coup je me demande s’il y a un mécanisme qui empêche l’usage d’une vieille version de serveurs depuis Gcli ?

(rien de grave vu que je passe à la nouvelle version; mais je trouve le comportement étrange tout de même)

43

Normalement un check du hash genesis doit être fait côté client pour chaque réseau.
Mais je crois pas que ce hash ait été mis à jour dans gcli depuis gtest2, et je ne sais même pas si ce mécanisme est déjà en place sur gcli.

44

Je sais qu’il y a un check de Hash entre le serveur Duniter et le Squid; mais cela n’a pas l’air bloquant.

J’ai juste eu un message d’erreur quand j’ai mélangé GTest#2 pour Duniter & le Squid qui était encore sous GTest#1 tout en me donnant la réponse à ma requête.

45

Hello, suite au déménagement de mon serveur, je suis de nouveau dans la forge !
J’ai ajouté un noeud archive et un mirror accessible sur wss://ws.gtest.bulma.sleoconnect.fr/

Je vais me repencher sur la question des indexeurs :wink:

3 Likes
46

Tu aurais une url d’un indexeur pas encore à jour (sur l’ancienne gtest) ?

C’est pour tester Tikka.

Dans la prochaine version compatible gtest2, chaque monnaie supportée par Tikka a son hash du bloc zero stocké en dur dans le currencies.yaml.
Je vérifie qu’on ne puisse pas se connecter sur des serveurs rpc ou squid qui ont des hashes différents.

47

@Moul il ne reste plus que ton nœud sur l’ancienne ĞTest, est-ce voulu ?

48

J’ai éteint progressivement mes services Ğtest1. Il reste mon nœud validateur. Je ne sais pas si ça fait encore sens de le garder allumé. Pourquoi poses-tu la question ?

49

Car je ne vois pas d’intérêt à le garder justement, par contre sur ĞTest2 ce pourrait être utile.

Mais peu importe.

50

Depuis quelques jours je n’arrive plus à rejoindre le réseau Ğtest2. Je penche sur deux options :

  • Un problème sur ma machine : màj dépendances, problème réseau, kernel.
  • Un problème de bootnode Ğtest2.
2025-10-27 14:48:07 💤 Idle (0 peers), best: #0 (0xd458…c57a), finalized #0 (0xd458…c57a), ⬇ 0 ⬆ 0    
2025-10-27 14:48:07 ❌ Error while dialing /dns/telemetry.polkadot.io/tcp/443/x-parity-wss/%2Fsubmit%2F: Custom { kind: Other, error: Timeout }

Pendant que mon nœud sur la Ğtest1 était resté synchronisé aux autres nœuds, mes nœuds Ğtest2 ont perdu la connexion avec le réseau.

Mon nœud Ğtest2 fini par être trouvé par la télémétrie. Du coup, c’est peut-être pas un problème réseau de mon côté ?

Je teste l’endpoint précisé dans les specs intégrés dans chaque nœud :

Mais, ça échoue :

ipfs swarm connect /dns/gtest.axiom-team.fr/tcp/30333/p2p/12D3KooWRsoY1uWFh5manQ7qjYt6bNiLTfJr9fAgcLz3mxwJY79y
Error: connect 12D3KooWRsoY1uWFh5manQ7qjYt6bNiLTfJr9fAgcLz3mxwJY79y failure: failed to dial: failed to dial 12D3KooWRsoY1uWFh5manQ7qjYt6bNiLTfJr9fAgcLz3mxwJY79y: all dials failed
  * [/ip6/2a02:c206:2161:7756::1/tcp/30333] failed to negotiate security protocol: EOF
  * [/ip4/84.247.184.53/tcp/30333] failed to negotiate security protocol: EOF

Est-ce que ce bootnode (endpoint) est bien fonctionnel ?
Est-ce que ce dernier doit toujours rester fonctionnel toute la durée de vie d’une monnaie pour que de nouveaux nœuds rejoignent le réseau ? Est-il changeable dans le runtime via un changement via le comité technique ?

Merci pour votre aide :wink:

1 Like
51

@aya est-ce que tu saurais vérifier que ton bootnode est toujours le bon depuis ta maintenance sur le noeud ?

52

Effectivement je reproduis le pb, je vais chercher l’erreur. En utilisant un autre bootnode ca fonctionne bien :

duniter2 [...] --bootnodes /dns/gtest.coinduf.eu/tcp/30333/p2p/12D3KooWK6KDYpEhrGTTYRqSanXhgt4Hb2YpFZfUugSiiuzB3XUi

Plutôt que de modifier l’adresse du bootnode embarqué dans les clients il vaudrait mieux, si c’est supporté, utiliser un enregistrement dnsaddr pour la libp2p comme _dnsaddr.bootstrap.libp2p.io :

$ dig _dnsaddr.bootstrap.libp2p.io txt

;; QUESTION SECTION:
;_dnsaddr.bootstrap.libp2p.io.  IN      TXT

;; ANSWER SECTION:
_dnsaddr.bootstrap.libp2p.io. 591 IN    TXT     "dnsaddr=/dnsaddr/sg1.bootstrap.libp2p.io/p2p/QmcZf59bWwK5XFi76CZX8cbJ4BhTzzA3gU1ZjYZcYW3dwt"
_dnsaddr.bootstrap.libp2p.io. 591 IN    TXT     "dnsaddr=/dnsaddr/sv15.bootstrap.libp2p.io/p2p/QmNnooDu7bfjPFoTZYxMNLWUQJyrVwtbZg5gBMjTezGAJN"
_dnsaddr.bootstrap.libp2p.io. 591 IN    TXT     "dnsaddr=/dnsaddr/am6.bootstrap.libp2p.io/p2p/QmbLHAnMoJPWSCR5Zhtx6BHJX9KiKNN6tpvbUcqanj75Nb"
_dnsaddr.bootstrap.libp2p.io. 591 IN    TXT     "dnsaddr=/dnsaddr/ny5.bootstrap.libp2p.io/p2p/QmQCU2EcMqAqQPR2i9bChDtGNJchTbq5TbXJJ16u19uLTa"

EDIT: le bootnode est à nouveau fonctionnel. @poka j’ai supprimé le répertoire paritydb comme tu m’avais conseillé (et que je n’avais pas fait :p) et c’est reparti. pour info j’avais simplement relancé duniter sans l’option --validator suite à ton go offline, apparement c’était pas une bonne idée.

4 Likes
53

Super ! Le problème était bien le bootnode.
Étonnant qu’on n’ait pas d’erreur d’accès au bootnode dans les logs. Ça pourrait aider.
En ayant en plus l’erreur d’accès à la télémétrie on pourrait croire que c’est un problème réseau dans le conteneur. Or il arrive que la télémétrie fonctionne plus tard du fait de saturation du service.

4 Likes
54

Hello, vous pouvez considérer un nouvel indexeur sur mon serveur https://squid.gtest.bulma.sleoconnect.fr/v1/graphql

3 Likes
55

Si tu veux que celui-ci soit visible, tu peux relancer ton nœud RPC avec la variable d’environnement DUNITER_PUBLIC_SQUID=https://squid.gtest.bulma.sleoconnect.fr/v1/graphql.

Ton nœud apparaîtra dans Cesium² ensuite.

3 Likes
56

Je viens de modifier les ports de mon nœud miroir gtest, mais impossible de resynchroniser.

Voici la config nix pour Arion, équivalente du docker compose :


  services = {

    # Duniter gtest RPC container
    duniter-rpc = {
      service = {
        image = "duniter/duniter-v2s-gtest-1100:latest";
        restart = "unless-stopped";

        ports = [
          # add +2 to all port numbers for gtest (to avoid conflict with nginx and g1 node)
          # P2P networking (external access) - only port exposed directly
          "30334:30333"
          # Internal ports exposed on different host ports to avoid collision with Nginx
          "127.0.0.1:9617:9615" # Prometheus metrics
          "127.0.0.1:9946:9944" # RPC WebSocket
        ];

        volumes = [ "data-duniter-gtest-rpc:/var/lib/duniter" ];

        environment = {
          DUNITER_CHAIN_NAME = "gtest";
          DUNITER_NODE_NAME = "vit-gtest-rpc";
          DUNITER_PUBLIC_ADDR = "/dns/vit.fdn.org/tcp/30334/ws";
          DUNITER_LISTEN_ADDR = "/ip4/0.0.0.0/tcp/30333/ws";
          DUNITER_PUBLIC_RPC = "wss://vit.fdn.org:9947";
        };

Le nœud démarre bien :

docker logs duniter-gtest-rpc-duniter-rpc-1 2>&1 |  more
Node key file '/var/lib/duniter/node.key' exists.
Node peer ID is '12D3KooWNpCpiZdAY1W9qngQoYmMfDsBoqYeNwH2NuPmiTunebhu'.
Starting duniter with parameters: --bootnodes /dns/gtest.coinduf.eu/tcp/30333/p2p/1
2D3KooWK6KDYpEhrGTTYRqSanXhgt4Hb2YpFZfUugSiiuzB3XUi --name vit-gtest-rpc --node-key
-file /var/lib/duniter/node.key --public-addr /dns/vit.fdn.org/tcp/30334/ws --publi
c-rpc wss://vit.fdn.org:9947 --listen-addr /ip4/0.0.0.0/tcp/30333/ws --rpc-cors all
 --chain gtest -d /var/lib/duniter --unsafe-rpc-external
2026-03-10 13:31:48 Duniter
2026-03-10 13:31:48 ✌️  version 0.12.0-unknown
2026-03-10 13:31:48 ❤️  by librelois <c@elo.tf>:tuxmain <tuxmain@zettascript.org>:c-
geek <https://forum.duniter.org/u/cgeek>:HugoTrentesaux <https://trentesaux.fr>:bga
llois <benjamin@gallois.cc>:Duniter Developers <https://duniter.org>:Axiom-Team Dev
elopers <https://axiom-team.fr>, 2021-2026
2026-03-10 13:31:48 📋 Chain specification: ĞTest
2026-03-10 13:31:48 🏷  Node name: vit-gtest-rpc
2026-03-10 13:31:48 👤 Role: FULL
2026-03-10 13:31:48 💾 Database: ParityDb at /var/lib/duniter/chains/gtest/paritydb
/full
2026-03-10 13:31:49 Creating transaction pool txpool_type=ForkAware ready=Limit { c
ount: 8192, total_bytes: 20971520 } future=Limit { count: 819, total_bytes: 2097152
 }
2026-03-10 13:31:49 👶 Creating empty BABE epoch changes on what appears to be firs
t startup.
2026-03-10 13:31:49 Local node identity is: 12D3KooWNpCpiZdAY1W9qngQoYmMfDsBoqYeNwH
2NuPmiTunebhu
2026-03-10 13:31:49 Running litep2p network backend
2026-03-10 13:31:49 💻 Operating system: linux
2026-03-10 13:31:49 💻 CPU architecture: x86_64
2026-03-10 13:31:49 💻 Target environment: gnu
2026-03-10 13:31:49 💻 CPU: Intel(R) Core(TM) i7-8700T CPU @ 2.40GHz
2026-03-10 13:31:49 💻 CPU cores: 6
2026-03-10 13:31:49 💻 Memory: 31935MB
2026-03-10 13:31:49 💻 Kernel: 6.12.61
2026-03-10 13:31:49 💻 Linux distribution: Debian GNU/Linux 11 (bullseye)
2026-03-10 13:31:49 💻 Virtual machine: no
2026-03-10 13:31:49 📦 Highest known block at #0
2026-03-10 13:31:49 〽️ Prometheus exporter started at 127.0.0.1:9615
2026-03-10 13:31:49 Running JSON-RPC server: addr=0.0.0.0:9944,[::]:36791
2026-03-10 13:31:49 ***** Duniter has fully started *****
2026-03-10 13:31:54 💤 Idle (0 peers), best: #0 (0xd458…c57a), finalized #0 (0xd458
…c57a), ⬇ 0 ⬆ 0
2026-03-10 13:31:59 💤 Idle (0 peers), best: #0 (0xd458…c57a), finalized #0 (0xd458
…c57a), ⬇ 0 ⬆ 0
2026-03-10 13:32:04 💤 Idle (0 peers), best: #0 (0xd458…c57a), finalized #0 (0xd458
…c57a), ⬇ 0 ⬆ 0
2026-03-10 13:32:09 💤 Idle (0 peers), best: #0 (0xd458…c57a), finalized #0 (0xd458
…c57a), ⬇ 0 ⬆ 0
2026-03-10 13:32:09 ❌ Error while dialing /dns/telemetry.polkadot.io/tcp/443/x-par
ity-wss/%2Fsubmit%2F: Custom { kind: Other, error: Timeout }
2026-03-10 13:32:14 💤 Idle (0 peers), best: #0 (0xd458…c57a), finalized #0 (0xd458
…c57a), ⬇ 0 ⬆ 0

Il est joignable en p2p :

nc -zv vit.fdn.org 30334
Connection to vit.fdn.org (80.67.176.219) 30334 port [tcp/*] succeeded!

et apparaît sur la télémétrie.
Mais il ne se synchronise pas. Une idée ?

1 Like
57

Est-ce que l’on a encore des noeuds Archive en GTest ? (personellement, j’ai coupé le mien pour faire de la place pour la G1)

Edit: J’en vois encore quelques uns dans la télémétrie…

58

On a pas besoin de nœud archive pour faire un réseau, de ce que j’ai compris. Tous les nœuds qui ont les entêtes de blocs peuvent faire tourner le réseau.

Si le réseau dépendait de la survie d’un nœud archive, je ne vois pas où serait la décentralisation, ou alors on devrait tous lancer des nœuds archive pour avoir un réseau résilient.

1 Like
59

J’ai un nœud archive sur la ĞTest. En effet, il y a un état puis les blocs courant pas encore finalisés qui devraient suffire à la synchronisation.
Les bootnodes sont peut-être plus accessibles ?

60

On sait voir quelque part quels sont les bootnodes actuels en GTest ?

Recherche rapide sur le repo duniter (v2)
https://git.duniter.org/nodes/rust/duniter-v2s/-/blob/master/node/specs/gtest_client-specs.yaml

bootNodes:
  - "/dns/gtest.axiom-team.fr/tcp/30333/p2p/12D3KooWRsoY1uWFh5manQ7qjYt6bNiLTfJr9fAgcLz3mxwJY79y"
telemetryEndpoints:
  - ["/dns/telemetry.polkadot.io/tcp/443/x-parity-wss/%2Fsubmit%2F", 0]

Edit:
Aucune idée si c’est la cause, mais si je tente de vérifier la connectivité vers cette adresse P2P, cela me donne une erreur (mauvais peer id).

 ipfs swarm connect /dns/gtest.axiom-team.fr/tcp/30333/p2p/12D3KooWRsoY1uWFh5manQ7qjYt6bNiLTfJr9fAgcLz3mxwJY79y                                                     │
│Error: connect 12D3KooWRsoY1uWFh5manQ7qjYt6bNiLTfJr9fAgcLz3mxwJY79y failure: failed to dial: failed to dial 12D3KooWRsoY1uWFh5manQ7qjYt6bNiLTfJr9fAgcLz3mxwJY79y: all dials failed                                                │
│  * [/ip6/2a02:c206:2161:7756::1/tcp/30333] dial refused because of black hole                                                                                                                                                    │
│  * [/ip4/84.247.184.53/tcp/30333] failed to negotiate security protocol: peer id mismatch: expected 12D3KooWRsoY1uWFh5manQ7qjYt6bNiLTfJr9fAgcLz3mxwJY79y, but remote key matches 12D3KooWAQdLdSScMu5uPRLAyKenAWRhwho517qf8bfN2hkb│
│zteE

Peut-être que @aya pourrait vérifier, je suppose que c’est lui qui gère les serveurs de axiom-team ?

3 Likes
61

Il faut vraiment qu’on maintienne la gtest. Pouvez-vous, s’il vous plaît, indiquer dans ce topic et dans ce dépôt vos endpoints P2P gtest :

Dès qu’on aura quelques bootnodes fiables, je livrerai un nouveau binaire Duniter pour la gtest avec ces bootnodes. En attendant, vous pouvez synchroniser en renseignant manuellement un endpoint avec l’option. –reserved-nodes /dns/DOMAINE/tcp/PORT/p2p/12D3KooWRso…

4 Likes