Suite à Les datapods partent en prod et aux annonces faites dans Terminer Duniter v2 -- priorisation des tâches, j’ai entrepris de stabiliser les datapods pour les mettre en prod facilement et sans risque de devoir faire des actions manuelles compliquées pour mettre à jour. Je me suis un peu arraché les cheveux sur mon code vraiment très expérimental, et suis en train d’arriver à quelque chose qui plante moins. J’ai particulièrement galéré pour que la synchro avec les pairs ne vienne pas surpasser les capacités de traitement et entraîne des comportements erratiques des connexions avec ipfs. J’y suis allé comme un bourrin pour que ça stabilise quitte à brider les performances, je vais tester ça prochainement en live, mais les aventureux peuvent déjà essayer la dernière version des images docker, ce qui rendra la synchro plus intéressante.
Voici une série de deux longues vidéo qui sont un pré-tutoriel à l’installation de datapods encore très expérimentaux.
sommaire
00:00 bonjour, intro de rentrée
00:15 lien de la vidéo Ğ1ntada Ğ1ntada 2024 - Conférence Hugo et Kapis - P2Tube
00:18 programme : installation des datapods v2 expérimentaux
01:10 prérequis serveur debian avec docker
01:50 création du dossier docker/datapod
02:32 dépôt avec docker-compose.yml d’exemple nodes / Duniter Datapod · GitLab
03:17 explication du docker-compose.yml
08:11 récupération du fichier .env d’exemple
11:48 docker compose pull
12:23 docker compose up -d && docker compose logs -f datapod
13:17 examen des logs du datapod
14:18 problème de résolution IPNS
15:16 démo de l’admin du noeud IPFS
17:10 configuration DNS CNAME
20:12 démonstration d’une publication pubsub
21:46 récupération du peer id webtransport
23:36 datapods settings dans duniter panel
26:44 démonstration des trois connections p2p dans chromium
27:16 démonstration des connections webtransports dans firefox
27:49 petit bug de duniter connect qui ne charge pas les comptes
28:10 édition du profil datapod via duniter panel
28:40 découverte du bug d’initialisation d’un datapod vide et dépôt de ticket gitlab associé
31:39 changement du endpoint graphql datapod dans duniter panel
32:14 programme de la suite de cette vidéo et de la vidéo suivante
33:10 présentation des clés IPNS
34:50 présentation de l’arbre d’indexation des datapods
36:12 démonstration des requêtes graphql dans le datapod
36:33 résilience des systèmes distribués
37:55 présentation des logs pubsub
38:29 conclusion de la première partie
sommaire
00:00 regardez la partie 1 d’abord
00:50 examen des logs quand un datapod se synchronise
04:04 [passage d’une voiture bruyante dans la rue]
04:44 connection directe à la console hasura (via pont ssh)
05:40 souscription graphql sur le dernier arbre indexé
06:10 souscription graphql pour voir le nombre de profils indexé
07:14 souscription aux derniers profile indexés sur les datapods
09:36 mise à jour du pair dans duniter panel
11:11 publication d’un nouveau profil sur les datapods
18:56 config nginx pour l’api graphql des datapods
21:06 génération du certificat avec certbot
22:26 ça marche du premier coup
23:18 modification du endpoint graphql datapod dans duniter panel
27:17 vérification que l’indexation a bien eu lieu en base de donnée
27:42 examen des configuration hardcodés dans les datapods
28:45 ajout de gyroi.de dans la config hardcodée
32:32 un peu de contexte sur les mécanismes de peering datapods dans ipfs
34:14 exemple sur l’avatar récupéré sur plusieurs passerelles ipfs
36:00 configuration du https sur la passerelle http ipfs
36:20 découverte d’un nouveau bug d’indexation :‘(
40:04 test de la récupération de l’avatar sur la nouvelle passerelle
41:32 différence entre passerelle ipfs et passerelle à sous-domaine
43:43 découverte d’un nouveau bug d’indexation :’(
44:44 conclusion sur le duo de vidéo
Il y a un problème de transcodage sur la deuxième, @poka si tu as le temps de regarder les logs peertube je suis preneur.
Petit retour suite à la première vidéo, sans obligation de réponse, je vais attendre que la seconde video soit dispo si jamais mon souci vient d’un mauvais réglage de mon reverse proxy … Pourtant, DATAPOD me répond bien depuis l’extérieur, mais avec un “404 page not found”, je pense que c’est ma liaison avec Pusub qui déconne… Je continu mes investigations…creuser de ses mains pour apprendre…
Vu que j’ai mes Id IPFS, vais tenter plus tard, d’ajouter ce Datapod via le Panel… Je ferai un EDIT de ce post de l’avancée de ce test de mise en place Datapod.
Edit : Aucune connexion sur le noeud IPFS avec l’extension IPFS compagnion
Dans tous les cas merci @HugoTrentesaux pour ce petit Tuto en DirectDev’
Logs et Divers
- Lors des essais de connections via tunnel SSH
http://127.0.0.1:5002/ipfs/bafyreic3z6fetku5dpudahsne3dwbmwkddfnqxapshknel6a2i5xhiwige/#/
ssh -NL 5002:datapod.g1.rendall.fr:5001 root@g1.rendall.fr
root@g1.rendall.fr's password:
channel 2: open failed: connect failed: Connection refused
channel 2: open failed: connect failed: Connection refused
...etc .... a chaque essai de connection via le navigateur
- Logs de Démarrage
✨ starting
🌴 self root key is k51qzi5uqu5dh3cd2y6bkg95s6ifne8wgie5gc991x7pjm3svlmpmac832q60s
🔨 starting from scratch: bafyreic3z6fetku5dpudahsne3dwbmwkddfnqxapshknel6a2i5xhiwige
🌱 adding empty node to ipfs
initialize history to dd_tamt_hist
🛢 latest indexed cid bafyreic3z6fetku5dpudahsne3dwbmwkddfnqxapshknel6a2i5xhiwige
🔌 connected to http://kubo:5001
👂 listening on topic ddd
👌 already at bafyreic3z6fetku5dpudahsne3dwbmwkddfnqxapshknel6a2i5xhiwige
🔄 syncing from peer /ipns/k51qzi5uqu5dip97g90ww9dxql8jc7t7sd0qi1fxx8g0rfr56vbt41tk17xnoe
🔄 syncing from peer /ipns/k51qzi5uqu5djid2dlwsjecuri0yluo1yy1lzqkdvlthjljiaff28b38gf2399
🔄 syncing from peer /ipns/k51qzi5uqu5dic5o2c15iw5k06witnddyrroln4qhblq8lkqp7yq7zj6uql03u
+++ pubsub error +++
1726674971718
🔌 connected to http://kubo:5001
👂 listening on topic ddd
+++ pubsub error +++
1726675271767
🔌 connected to http://kubo:5001
👂 listening on topic ddd
🔄 syncing from peer /ipns/k51qzi5uqu5dip97g90ww9dxql8jc7t7sd0qi1fxx8g0rfr56vbt41tk17xnoe
🔄 syncing from peer /ipns/k51qzi5uqu5djid2dlwsjecuri0yluo1yy1lzqkdvlthjljiaff28b38gf2399
🔄 syncing from peer /ipns/k51qzi5uqu5dic5o2c15iw5k06witnddyrroln4qhblq8lkqp7yq7zj6uql03u
+++ pubsub error +++
1726675572029
🔌 connected to http://kubo:5001
👂 listening on topic ddd
🔄 syncing from peer /ipns/k51qzi5uqu5dip97g90ww9dxql8jc7t7sd0qi1fxx8g0rfr56vbt41tk17xnoe
🔄 syncing from peer /ipns/k51qzi5uqu5djid2dlwsjecuri0yluo1yy1lzqkdvlthjljiaff28b38gf2399
🔄 syncing from peer /ipns/k51qzi5uqu5dic5o2c15iw5k06witnddyrroln4qhblq8lkqp7yq7zj6uql03u
+++ pubsub error +++
1726675872403
🔌 connected to http://kubo:5001
👂 listening on topic ddd
-
Reglages DNS
-
KUBO logs
Initializing daemon...
Kubo version: 0.30.0-846c5cc
Repo version: 16
System version: amd64/linux
Golang version: go1.22.7
PeerID: 12D3KooWG7Ns48xGNaKPEBqcCdznAKWPvnKyzrzcYw6Y9HkCyhmE
2024/09/18 18:14:36 failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 7168 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details.
Swarm listening on 127.0.0.1:4001 (TCP+UDP)
Swarm listening on 172.19.0.8:4001 (TCP+UDP)
Run 'ipfs id' to inspect announced and discovered multiaddrs of this node.
RPC API server listening on /ip4/0.0.0.0/tcp/5001
WebUI: http://0.0.0.0:5001/webui
Gateway server listening on /ip4/0.0.0.0/tcp/8080
Routing V1 API exposed at http://0.0.0.0:8080/routing/v1
Daemon is ready
- Gateway Logs
Listening on http://127.0.0.1:3000
- Hasura Logs
INF detail={"http_info":{"content_encoding":null,"http_version":"HTTP/1.1","ip":"127.0.0.1","method":"GET","status":200,"url":"/healthz"},"operation":{"query":{"type":null},"request_id":"b1426711-8498-4b43-8ebb-477dc716cbd9","request_mode":"non-graphql","response_size":2,"uncompressed_response_size":2},"request_id":"b1426711-8498-4b43-8ebb-477dc716cbd9"} timestamp=2024-09-18T18:23:44.353+0000 type=http-log
INF detail={"http_info":{"content_encoding":null,"http_version":"HTTP/1.1","ip":"127.0.0.1","method":"GET","status":200,"url":"/healthz"},"operation":{"query":{"type":null},"request_id":"24d01126-3351-445a-8b30-6f8d624f8537","request_mode":"non-graphql","response_size":2,"uncompressed_response_size":2},"request_id":"24d01126-3351-445a-8b30-6f8d624f8537"} timestamp=2024-09-18T18:24:14.391+0000 type=http-log
- PostGres Logs
2024-09-18 18:14:35.273 UTC [1] LOG: starting PostgreSQL 16.4 (Debian 16.4-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2024-09-18 18:14:35.275 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2024-09-18 18:14:35.275 UTC [1] LOG: listening on IPv6 address "::", port 5432
2024-09-18 18:14:35.279 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-09-18 18:14:35.291 UTC [29] LOG: database system was shut down at 2024-09-18 18:14:22 UTC
2024-09-18 18:14:35.309 UTC [1] LOG: database system is ready to accept connections
2024-09-18 18:19:35.379 UTC [27] LOG: checkpoint starting: time
2024-09-18 18:19:35.913 UTC [27] LOG: checkpoint complete: wrote 8 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.517 s, sync=0.006 s, total=0.535 s; sync files=7, longest=0.003 s, average=0.001 s; distance=8 kB, estimate=8 kB; lsn=0/15C1388, redo lsn=0/15C1350
- PubSub Logs
No log line matching the '' filter
Waouh! Je ne m’attendais pas à ce que quelqu’un suive si vite ce “pré-tuto” avant même que je ne partage les configs nginx par écrit ><
Je veux bien voir ta config nginx (et je vais mettre la mienne en ligne).
Ce qui est étrange, c’est que ça ressemble au 404 d’un nœud IPFS, pas de hasura. Donc je veux bien voir quels noms tu as mis dans les variables d’environnement. Regarde, j’ai le même 404 sur mon ipfs : https://gateway.datapod.gyroi.de/, ce qui ne m’empêche pas de résoudre une image : https://gateway.datapod.gyroi.de/ipfs/QmTUDdEw2KzpDw4Ahnpa8QLfpSbk88TiHJkDzK1CQdc7MM.
Non, ça ça devrait fonctionner sans problème (sauf le timeout toute les 5 minutes), et ce n’est que du p2p, donc indépendant des proxy http.
L’extension IPFS companion est faite pour deux choses :
- lire les sites compatibles IPFS sur une passerelle IPFS-HTTP de préférence locale (port 8080 par défaut)
- exécuter des opérations d’admin sur un nœud IPFS local (port 5001) par défaut
Tout d’abord, je recommande :
- De ne pas utiliser root pour se connecter à un serveur distant. (perso j’ai désactivé la connection root)
- D’utiliser une clé ssh plutôt qu’un mot de passe. (idem, j’ai désactivé la connexion par mot de passe)
- D’utiliser une config ssh dans
.ssh/config
pour se connecter via un simple nom d’hôte.
J’avais fait un mini article à ce sujet sur un blog secondaire : https://h30x.fr.tild3.org/gestion-ssh/, ça pourrait t’aider.
Ensuite, si tu lies le port 5002 local, c’est cette adresse qu’il faut utiliser dans le navigateur (http://127.0.0.1:5002/) et dans ipfs companion. J’utilise le 5002 plutôt que le 5001 car j’ai déjà un nœud IPFS local qui écoute sur le 5001, mais tu peux utiliser le 5001 directement si tu veux bénéficier des réglages par défaut.
Une de mes hypothèses pour expliquer que la synchro ne trouve rien au début, c’est qu’il faut un peu de temps à IPFS pour établir sa DHT, notamment pour les enregistrements IPNS utilisés pour la synchro. Pour l’instant je vais laisser comme ça donc la première synchro ne se fera pas immédiatement, mais j’ai une idée de comment contourner cette faiblesse d’IPNS.
Je te vois bien dans mes pairs à l’adresse /ip4/193.168.145.31/tcp/57780/p2p/12D3KooWG7Ns48xGNaKPEBqcCdznAKWPvnKyzrzcYw6Y9HkCyhmE
. Par contre, ce ne sera pas possible de m’y connecter parce que ça ressemble à une adresse locale (!).
Effectivement, tu as mis une adresse locale dans tes réglages DNS ce qui n’est pas très intéressant pour nous. Le mieux en général est d’avoir une entrée A/AAAA
qui pointe vers l’IP publique de la machine et ensuite des entrées CNAME
qui pointent vers cette première entrée. Exemple de config en autohébergement :
[edit j’avais pas vu que c’était une IP publique , je laisse quand même pour que d’autres puissent lire]
# la command dig permet de voir les entrées DNS
$ dig +noall +answer datapod.coinduf.eu
# première entrée, un CNAME vers ma freebox
datapod.coinduf.eu. 9219 IN CNAME freebox.trentesaux.fr.
# deuxième entrée, un A vers l'IP de ma freebox
freebox.trentesaux.fr. 9217 IN A 78.199.27.8
Comme ça, si l’adresse de ma box change pour une raison ou une autre, je n’ai qu’une entrée A
à changer, tous les CNAME
vont suivre. Ensuite, j’ai demandé à ma box de rediriger tout le traffic entrant sur l’IP locale 192.168.0.25
.
Note : le conteneur pubsub unhealthy, c’est juste un bug du healthcheck qui n’est pas fait pour ce cas d’usage.
Par contre, je n’arrive pas à m’y connecter. Est-ce que le port 57780 est bien ouvert ? Je n’ai pas laissé le port d’écoute p2p paramétrable, donc normalement c’est 4001
, mais je veux bien tes retours là dessus.
$ ipfs swarm connect /ip4/193.168.145.31/tcp/57780/p2p/12D3KooWG7Ns48xGNaKPEBqcCdznAKWPvnKyzrzcYw6Y9HkCyhmE
Error: connect 12D3KooWG7Ns48xGNaKPEBqcCdznAKWPvnKyzrzcYw6Y9HkCyhmE failure: failed to dial: failed to dial 12D3KooWG7Ns48xGNaKPEBqcCdznAKWPvnKyzrzcYw6Y9HkCyhmE: all dials failed
* [/ip4/193.168.145.31/tcp/57780] dial tcp4 0.0.0.0:4001->193.168.145.31:57780: i/o timeout
PS : oh, surprise !! J’arrive bien à me connecter avec le 4001 :
$ ipfs swarm connect /ip4/193.168.145.31/tcp/4001/p2p/12D3KooWG7Ns48xGNaKPEBqcCdznAKWPvnKyzrzcYw6Y9HkCyhmE
connect 12D3KooWG7Ns48xGNaKPEBqcCdznAKWPvnKyzrzcYw6Y9HkCyhmE success
Donc je ne comprends pas ce qui pose problème dans l’annonce de la fiche de pair
Je t’ai ajouté comme pair permanent de le panneau d’admin. Donc ne retire pas le volume IPFS, sinon, tu changerais de clé publique.
Merci @HugoTrentesaux de tes analyses toujours pertinentes
Je vais faire quelques corrections suite à ton message et je fais retour de l’avancement dès que possible…