Ğ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