Aide installation noeud Duniter2

Nodes Duniter-v2s
1

Bonjour !

J’essaie de lancer un noeud (miroir pour le moment), mais le noeud ne trouve aucun peer et se met en idle. Pouvez-vous m’aider ? Voici la ligne d’erreur :

💤 Idle (0 peers), best: #0 (0xc184…b6c3), finalized #0 (0xc184…b6c3), ⬇ 0 ⬆ 0

La machine est un VPS premier prix chez OVH, une debian bookworm.
Les ports 30333, 9615 et 9944 sont ouverts à la fois sur la machine (ufw) et sur OVHCloud. (NB - vu que ça ne marche pas je les ai refermés par sécurité)

Voici le parefeu 
Status: active

To                         Action      From
--                         ------      ----
XXXX/tcp                  ALLOW       Anywhere       # ssh custom            
80                         ALLOW       Anywhere                  
443                        ALLOW       Anywhere                  
9944                       ALLOW       Anywhere                  
9615                       ALLOW       Anywhere                  
30333                      ALLOW       Anywhere                  
XXXXX /tcp (v6)             ALLOW       Anywhere (v6)     # ssh custom          
80 (v6)                    ALLOW       Anywhere (v6)             
443 (v6)                   ALLOW       Anywhere (v6)             
9944 (v6)                  ALLOW       Anywhere (v6)             
9615 (v6)                  ALLOW       Anywhere (v6)             
30333 (v6)                 ALLOW       Anywhere (v6)

NB - Nginx tourne pour servir un site statique, mais n’écoute que sur les ports 80 et 443. Donc il ne sert pas de reverse proxy pour Duniter, sauf si j’ai mal compris le principe d’un reverse proxy.

Voici le dockerfile 
# cat docker-compose.yml 
version: "3.5"

services:
  duniter-mirror:
    image: duniter/duniter-v2s-gdev:latest
    restart: unless-stopped
    ports:
      # Prometheus endpoint
      - 9615:9615
      # rpc
      - 9944:9944
      # p2p
      - 30333:30333
    volumes:
      - data-mirror:/var/lib/duniter/
    environment:
      - DUNITER_CHAIN_NAME=gdev
      - DUNITER_NODE_NAME=matograine
      - DUNITER_DISABLE_TELEMETRY=true
      - DUNITER_VALIDATOR=false
volumes:
  data-mirror:

Doker a été installé depuis les dépôts Debian.

Voici les logs 
# docker-compose up
Creating network "node_default" with the default driver
Pulling duniter-mirror (duniter/duniter-v2s-gdev:latest)...
latest: Pulling from duniter/duniter-v2s-gdev
728328ac3bde: Pull complete
5a2a4343e789: Pull complete
d31cb97a7447: Pull complete
dc6b8b163b0f: Pull complete
0c4611f091b9: Pull complete
fed34ea2d480: Pull complete
ea8304b1b05b: Pull complete
4baf93696b48: Pull complete
Digest: sha256:52a2ad80d637bb02581586e94719abc92ef31d6b7096bccb6199b2a3e34bb82a
Status: Downloaded newer image for duniter/duniter-v2s-gdev:latest
Creating node_duniter-mirror_1 ... done
Attaching to node_duniter-mirror_1
duniter-mirror_1  | Node key file '/var/lib/duniter/node.key' exists.
duniter-mirror_1  | Error: Input("failed to decode secret as hex")
duniter-mirror_1  | Node peer ID is ''.
duniter-mirror_1  | Starting duniter with parameters: --name matograine --node-key-file /var/lib/duniter/node.key --rpc-cors all --no-telemetry --chain gdev -d /var/lib/duniter --unsafe-rpc-external
duniter-mirror_1  | 2024-06-30 09:29:39 Duniter    
duniter-mirror_1  | 2024-06-30 09:29:39 ✌️  version 0.0.0-unknown    
duniter-mirror_1  | 2024-06-30 09:29:39 ❤️  by librelois <c@elo.tf>:tuxmain <tuxmain@zettascript.org>:c-geek <https://forum.duniter.org/u/cgeek>:HugoTrentesaux <https://trentesaux.fr>:bgallois <benjamin@gallois.cc>:Duniter Developers <https://duniter.org>:Axiom-Team Developers <https://axiom-team.fr>, 2021-2024    
duniter-mirror_1  | 2024-06-30 09:29:39 📋 Chain specification: ĞDev    
duniter-mirror_1  | 2024-06-30 09:29:39 🏷  Node name: matograine    
duniter-mirror_1  | 2024-06-30 09:29:39 👤 Role: FULL    
duniter-mirror_1  | 2024-06-30 09:29:39 💾 Database: ParityDb at /var/lib/duniter/chains/gdev/paritydb/full    
duniter-mirror_1  | 2024-06-30 09:29:44 👶 Creating empty BABE epoch changes on what appears to be first startup.    
duniter-mirror_1  | 2024-06-30 09:29:44 Local node identity is: 12D3KooWLrqPZXz4uFuAvnGcXuZDzsWhEvs8XQcavAmVyg8QyUiJ    
duniter-mirror_1  | 2024-06-30 09:29:44 Running litep2p network backend    
duniter-mirror_1  | 2024-06-30 09:29:44 💻 Operating system: linux    
duniter-mirror_1  | 2024-06-30 09:29:44 💻 CPU architecture: x86_64    
duniter-mirror_1  | 2024-06-30 09:29:44 💻 Target environment: gnu    
duniter-mirror_1  | 2024-06-30 09:29:44 💻 CPU: Intel Core Processor (Haswell, no TSX)    
duniter-mirror_1  | 2024-06-30 09:29:44 💻 CPU cores: 1    
duniter-mirror_1  | 2024-06-30 09:29:44 💻 Memory: 1935MB    
duniter-mirror_1  | 2024-06-30 09:29:44 💻 Kernel: 6.1.0-21-cloud-amd64    
duniter-mirror_1  | 2024-06-30 09:29:44 💻 Linux distribution: Debian GNU/Linux 11 (bullseye)    
duniter-mirror_1  | 2024-06-30 09:29:44 💻 Virtual machine: yes    
duniter-mirror_1  | 2024-06-30 09:29:44 📦 Highest known block at #0    
duniter-mirror_1  | 2024-06-30 09:29:44 〽️ Prometheus exporter started at 127.0.0.1:9615    
duniter-mirror_1  | 2024-06-30 09:29:44 Running JSON-RPC server: addr=0.0.0.0:9944, allowed origins=["*"]    
duniter-mirror_1  | 2024-06-30 09:29:44 ***** Duniter has fully started *****    
duniter-mirror_1  | 2024-06-30 09:29:49 💤 Idle (0 peers), best: #0 (0xc184…b6c3), finalized #0 (0xc184…b6c3), ⬇ 0 ⬆ 0

Parmi les choses qui me semblent étranges, ou que je ne comprends pas :

version 0.0.0-unknown

duniter-mirror_1 | Node peer ID is ‘’.

Running JSON-RPC server: addr=0.0.0.0:9944, allowed origins=[“*”]
(pourquoi 0.0.0.0 et pas l’IP publique du noeud ?)

Merci d’avance !

2 Likes
2

Je ne suis pas un spécialiste, les Devs devront compléter/corriger mes propos, mais à l’analyse de tes logs :

= Ton noeud ne communique pas avec d’autres noeuds.

= le fichier Key existe et son contenu n’est pas dans le format attendu pour pouvoir identifier ton noeud sur le réseau pour ensuite communiquer avec la autres noeuds

J’imagine que ce n’est pas la première fois que tu as lancé le compose qui a généré ces logs… Je te conseille de fermer le conteneur lancé, effacer les volumes associés pour repartir de zero lorsque tu re-lancera à nouveau ton compose.

La commission Forgeron v2, dans sa future documentation, va conseiller l’ajout de Portainer à Docker afin d’avoir une interface GUI, ce qui facilite une vision d’ensemble des éléments Docker en lien avec les conteneurs et d’agir dessus … à toi de voir si Portainer peut t’aider ou si tu maîtrise la ligne de commande Docker.

Ajoute le port RPC via HTTP dans ton compose

      # rpc via http
      - 9933:9933

Fais nous un retour :no_mouth:

1 Like
3

J’ai supprimé le volume,

DRIVER    VOLUME NAME
local     node_data-mirror
# docker volume rm node_data-mirror

Puis relancé docker-compose up et effectivement, les logs sont plus explicites :

# docker-compose logs -f
Attaching to node_duniter-mirror_1
duniter-mirror_1  | Generating node key file '/var/lib/duniter/node.key'...
duniter-mirror_1  | thread 'main' panicked at node/src/command.rs:182:21:
duniter-mirror_1  | unknown runtime
duniter-mirror_1  | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
duniter-mirror_1  | Error: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })
duniter-mirror_1  | Node peer ID is ''.
duniter-mirror_1  | Starting duniter with parameters: --name matograine --node-key-file /var/lib/duniter/node.key --rpc-cors all --no-telemetry --chain gdev -d /var/lib/duniter --unsafe-rpc-external
duniter-mirror_1  | 2024-07-01 05:15:28 Duniter

On a un problème d’I/O à l’intérieur du docker ? Il faut peut-être reinstaller docker depuis le site web et non depuis apt ? Ca me semble bizarre.

1 Like
4

On arrive au bout de mes compétences… :smiling_face_with_tear:

Les seules differences que je remarque sur ton compose par rapport au mien :

  • j’ai créé un réseau spécifique pour les conteneurs Duniter et ouvert sur l’extérieur via NGinx Proxy Manager
  • mon compose utilise uniquement 2 variables :
    – DUNITER_CHAIN_NAME=gdev
    – DUNITER_NODE_NAME=Rendall-Gdev-Mirror
  • et j’ai le port 9933 pour la com RPC via HTTP

Mon conteneur a été créée en février 2024, avec la même source que toi (duniter/duniter-v2s-gdev:latest) mais depuis, à cette adresse, l’image a été mise à jour, nous n’avons donc pas, toi et moi, la même image avec le tag LATEST. J’imagine pourtant que cela n’a pas d’importance, elle a été utilisée par d’autres noeuds qui fonctionnent.

La seconde info, @cgeek est en train de mettre à jour les images à utiliser pour continuer les tests sur la Gdev, il y a de nouveaux Repos sur HubDocker/Duniter qui datent de moins d’une semaine, je ne sais pas quand ils seront définitifs et devront être utilisés pour mettre à jour nos noeuds et continuer les tests Gdev. Ca ne devrait pas trop tarder c’était prévu pour fin Juin d’apres ce que m’avais dit @HugoTrentesaux … mais on ne va pas mettre de pression… :smiling_face_with_three_hearts:

Peut-être devrait tu attendre un peu et refaire tes tests avec la version definitive de ces nouvelles images Docker ? Sinon, il va falloir que d’autres t’accompagne…

1 Like
5

Effectivement j’ai demandé la revue de code à @HugoTrentesaux vendredi 28/06, selon les allers-retours ça peut être bientôt ou pas :slight_smile:

D’ailleurs en faisant des tests sur Docker, ça sera plutôt “ou pas” pour l’instant, il y a des soucis avec le build podman.

2 Likes
6

Pour l’instant il n’y a que deux nœuds dans le bootstrap, celui de cgeek et le mien mais avec un mauvais peerid. J’ajouterai plus de nœuds bootstrap dans le prochain release pour avoir un découverte réseau plus fonctionnelle.

Le but d’utiliser nginx comme reverse proxy est de servir l’API RPC du miroir en https sur 443. Donc pas besoin d’écouter sur 9944 à l’extérieur, il suffit d’écouter à l’intérieur et de mettre le reverse proxy. Je ne suis pas très compétent sur le sujet, mais j’essayerai de détailler ce point.

Il faut que je regarde sur quoi pointe duniter-v2s-gdev:latest suite au travail de cgeek. Chez moi j’ai encore version 0.8.0-unknown. On va justement travailler sur ces numéros de version pour s’y retrouver plus facilement.

Ça c’est parce qu’il n’a pas réussi à décoder la clé, c’est donc normal qu’il ne puisse pas donner le node id. Je ne sais pas ce qui se passe dans ce cas là.

Ça aussi je ne suis pas spécialiste, mais voici ce que j’ai compris :

  • Si un service écoute sur 127.0.0.1, il n’écoute qu’en local. Si on veut le faire écouter sur l’extérieur, il faut soit
    • Avec Docker binder le port d’écoute local sur un port qui écoute à l’extérieur.
    • Avec Nginx faire un reverse proxy pour ajouter https.
  • Si un service écoute sur 0.0.0.0, il écoute sur l’extérieur.
    • S’il est dans un Docker, il faut de toute façon binder le port.
    • S’il n’est pas dans un réseau local virtuel, il écoute vraiment sur l’extérieur et il faut ouvrir le pare-feu.

Quelques exemples de binding de port avec docker pour un service qui écouterait sur 8080 dans le docker :

ports:
  # écoute uniquement en local sur 80
  - 127.0.0.1:80:8080
  # écoute sur l'extérieur sur 80
  - 0.0.0.0:80:8080
  # note : on peut omettre le 0.0.0.0, c'est le comportement par défaut

Donc ce que je fais si j’ai trois nœuds miroir, c’est 127:0.0.1:9944:9944, 127:0.0.1:9945:9944, 127:0.0.1:9946:9944. Et ensuite trois reverse proxy https depuis 443 vers 9944, 9945, 9946 avec les noms de domaine noeud1.gdev.net, noeud2.gdev.net, noeud3.gdev.net. Comme ça le endpoint est simplement de la forme wss://noeud1.gdev.net/, où 443 est implicite. Par contre, le p2p, je le bind sur l’extérieur avec 30333:30333, 30334:30333, 30335:30333, et j’écoute directement en tcp/udp sans passer par un proxy. Le dns sert alors uniquement à trouver l’ip, pas à identifier une ressource sur la machine. J’espère que ça clarifie les choses.

Ça c’était sur les anciennes versions de Duniter, depuis une mise à jour substrate (je ne sais plus laquelle), il n’y a plus que le 9944, http et ws étant sur le même endpoint, ce qui est plus logique et plus pratique. Les docs sont à jour normalement, mais je n’ai pas communiqué dessus dans des release notes parce que ça ferait beaucoup de travail en plus alors qu’on est encore assez tôt dans l’aventure.

Ça c’est étrange, si tu as bien dans ton compose

il devrait connaître la chaîne gdev. Et je suppose que le “no such file or directory” vient de là.

Non, c’est à nous de faire en sorte que ça fonctionne avec les version de docker que les gens auront, même si c’est improbable que ce soit lié à ça. Là je pencherais plutôt pour une histoire de dossier non créé, mais c’est surprenant, je regarderai en relisant la MR de cgeek.

Je pense au contraire que ça vient de là, je vais faire des tests.

Oui, j’ai été un peu optimiste ><
En général je travaille plutôt en semaine, donc le weekend du 29 et 30 j’ai un peu déconnecté (même si j’ai bien avancé sur Panneau pour visualiser les forgerons, mais c’est une autre histoire :joy:). Comme je ne suis pas chez moi, je ne garantis rien avant dix jours

Au contraire, ça m’aide à m’y mettre ! Quand je me sens seul, j’ai tendance à avancer sur ce qui me plait le plus même si ce n’est pas le plus urgent, mais quand je vois que des gens attendent mes retours, ça me motive pour y répondre ! C’est ce que j’attendais dans la constitution de l’équipe forgeron et vos questions sont le plus beau cadeau que vous pouvez me faire (cf Objectif : 20 forgerons v2 pour mon anniversaire!).

PS : @matograine as tu vu Debian package for Duniter v2 ? On a aussi besoin de retour là dessus, et c’est plus facile, ça demande moins de configuration que docker. En gros l’idée pour l’instant c’est :

  • docker est packagé pour le maximum de contrôle
  • debian est packagé pour la simplicité

La doc est déjà à jour (Duniter | Run a mirror node) mais je compte faire une vidéo en français pour expliquer davantage les choix et donner des exemples.

2 Likes
7

Ok, j’ai trouvé ce qui n’allait pas, il s’agissait d’une mauvaise configuration du parefeu OVH.

En l’occurence, j’avais fermé tous les “ports sources”, dans une volonté mal maîtrisée de sécuriser le serveur… Donc rien ne pouvait en sortir, et le noeud ne pouvait contacter aucun peer. J’avais confondu les ports sources/destination du pare-feu avec le mécanisme de redirection des ports d’un NAT.

Au niveau des logs, j’observe que j’ai toujours un Node peer ID vide et une version 0.0.0-unknown:

duniter-mirror_1  | Node key file '/var/lib/duniter/node.key' exists.
duniter-mirror_1  | Error: Input("failed to decode secret as hex")
duniter-mirror_1  | Node peer ID is ''.
duniter-mirror_1  | Starting duniter with parameters: --name matograine --node-key-file /var/lib/duniter/node.key --rpc-cors all --no-telemetry --chain gdev -d /var/lib/duniter --unsafe-rpc-external
duniter-mirror_1  | 2024-07-02 11:29:39 Duniter    
duniter-mirror_1  | 2024-07-02 11:29:39 ✌️  version 0.0.0-unknown

Mais j’ai plus loin :

Local node identity is: 12D3KooWNwxC1hgF7mCGuWYB1SXd4DeEqnpNsNhEHm12vhem72Px

edit - du coup, le noeud sync :slight_smile:

3 Likes
8

j’ai regardé, cela vient de la config de l’image sur le Repo Docker…à mon avis c’est pas grave …

Quel nom as-tu mis à ton noeud ? matograine ?
le vois-tu ici ? je n’en vois pas de nouveau qui se synchronise…

9

Effectivement, je ne le vois pas sur ce tableau de bord. Je verrai a plus tard.

1 Like
10

C’est normal de ne pas voir le nœud dans le panneau de télémétrie si la télémétrie est désactivée :wink:

1 Like
11

Moi qui pensais que mon VPS était à Gravelines… Un peu d’exotisme ne fait de mal à personne :smiley:

image
image798×19 3.28 KB

1 Like
12

Voir le dernier tag :
https://hub.docker.com/r/duniter/duniter-v2s-gdev/tags

Le tag a changé de format, peut-être un problème de parsing, il prend peut-être la fin ?

  • 800-0.0.0
  • runtime-800
1 Like
13

Rebonjour !

  • le noeud synchronise

  • je n’ai pas testé son endpoint rpc local (ne sais pas comment faire)

  • j’ai mis en place un certificat TLS pour gdev.matograine.fr

  • j’ai mis en place nginx en reverse-proxy en copiant l’exemple de la doc

  • je veux tester la connexion en allant sur https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fgdev.matograine.fr#/explorer (j’ai pris l’exemple d’un lien avec le wss de gdev.coinduf.eu) mais l’initialisation de la connexion tourne sans arrêt.

  • j’ai pu tester le endpoint rpc avec gcli, cool :

gcli -u wss://gdev.matograine.fr blockchain current-block
    on wss://gdev.matograine.fr
    finalized block	2121750
    current block	2121752

Ma question est : Comment me connecter à l’endpoint RPC de mon noeud via la webapp PolkadotJS ?

Merci d’avance :wink:

14

On dirait que ton lien n’est pas accessible de l’extérieur de ton lan. Le port (443?) est il bien ouvert sur ton parefeu ou ton nat ?

15

Oui. Le parefeu OVH est désactivé, et le parefeu interne interdit tout sauf 80, 443 et un port custom.

Par ailleurs, la machine est hébergée chez OVH et je n’ai pas mis en place de VPN entre elle et mon LAN, donc elle n’est pas sur mon LAN.

J’avais rencontré un problème similaire à la mise en place du HTTPS sur mon site, qui marchait depuis chez moi (ce que je n’explique pas) mais pas depuis mon bureau. Le problème était la fermeture des ports source par le parefeu, qui bloquait le traffic sortant du serveur (si j’ai bien compris ce que m’a dit notre adminsys)

16

Peut être que si tu analyses les logs réseau dans ton navigateur (f12 sur firefox), ou la console javascript, tu auras un indice sur le problème que rencontre Polkadot.js… Je sors des évidence mais autant on scrute les logs des applications sans IHM comme ngynx, autant on oublie celles du navigateur. My two cents…

Peut etre aussi comparer les logs ngynx lors d’un connection réussie avec gcli et lors d’une tentative de polkadot. (Cross origin ? )

17

C’est tombé en marche, sans que je sache ce qui a changé.

Cette première installation via docker est réussie, je passe au paquet Debian pour moins de complication.