Installation d'un nœud Duniter (avec le paquet YunoHost)

farvardin · 7 November 2021 23:48

bonjour,

j’ai 2 serveurs yunohost qui tournent chez moi, et également des raspberry pi. J’étais tenté d’installer duniter via yunohost, mais j’ai vu que c’était cassé / plus maintenu. D’autre part, je voulais plutôt séparer ça et utiliser un raspberry pi.

J’ai téléchargé le paquet 1.8.0.

Sur le paquet 1.8.1 plus récent c’est indiqué « Hotfix pour la variante Desktop uniquement. Les utilisateurs de la variante Server doivent installer la version 1.8.0. » de plus il n’y a pas de paquet dédié rpi donc je suis resté sur la 1.8.0.

J’ai configuré en suivant la doc, puis synchronisé à partir d’un noeud (ça a téléchargé environ 1.6 Go de données).

Ensuite j’ai lancé la commande « duniter start ». Si je vais à l’adresse monserveur:20900 ça me dit « Upgrade Required ». Est-ce que je suis censé installer quand même la version 1.8.1 malgré l’avertissement ? (et donc compiler la version spécialement pour le rpi ?)

vit · 8 November 2021 08:54

Merci pour ta contribution !

“Upgrade Required” est un problème connu de configuration du serveur web.

Le service WS2P est en websocket…

Moul · 8 November 2021 10:21

Je te conseille malgré tout l’installation du paquet YunoHost, que je maintiens.
Il n’est pas reconnu par le projet YunoHost comme maintenu, mais je pense qu’il apporte de la pre-configuration, et ça vaut le coup.

farvardin · 8 November 2021 16:29

désolé, mais je ne vois pas trop ce que je dois faire. On ne m’avait pas vendu Duniter comme devant rajouter un serveur nginx en plus, je pensais que tout était compris dans le binaire !

j’ai rajouté ton exemple dans nginx.conf et/ou dans proxy_params mais ça fait pareil (j’ai mis / à la place de /path), pourtant ça semble bien être ça dans le paquet yunohost duniter_ynh/nginx.conf at master · YunoHost-Apps/duniter_ynh · GitHub

je pense que je vais repartir sur le paquet yunohost, ça sera plus simple. Faut juste que je regarde comment gérer ça, j’ai mon serveur qui est virtualisé, et je n’ai pas envie de rajouter la blockchain dans le système de sauvegarde, donc je vais faire ça dans un montage à partir de la machine hôte…

et merci à @Moul d’avoir confirmé que le paquet yunohost était toujours d’actualité !

vit · 8 November 2021 17:22

ahah oui, ce serait trop facile !

Blagues à part, tu n’es pas obligé d’ajouter un nginx normalement. Si tu as l’api BMA sur 20900, il ne devrait pas y avoir de problème pour te connecter dessus avec ton navigateur. L’erreur vient peut-être d’un autre problème (http 1.0 vs 1.1 ?)

On ajoute souvent un reverse proxy devant le serveur duniter, surtout pour ajouter le serveur https.

Ce n’est pas un pré-requis, mais quand on le fait, on doit “upgrader” le port de WS2P qui est en websocket. C’est pour ça que je t’ai dirigé sur cette solution. Mais ce n’est peut-être pas ça le problème…

farvardin · 17 November 2021 10:22

je continue mes essais…

finalement j’ai installé via Yunohost, sur mon serveur, comme l’a préconisé @Moul

J’ai un peu tâtonné je dois dire, d’abord, comme c’est dans un environnement virtualisé, je me suis dit que je pouvais monter le dossier data (qui prend le plus de place) de duniter de la machine hôte vers la machine virtualisé

Ça a apparemment correctement commencé la synchro depuis l’interface web, et quand j’ai arrêté le processus duniter pour modifier le point de montage, ça a commencé à dérailler : ça m’a mis quantité d’erreurs, et j’ai l’impression qu’il n’aimait pas être sur ce type de fs (vboxfs).

J’ai pris donc le parti de tout mettre dans l’environnement virtualisé, et là ça synchronise (j’en suis à 1,3 Go sur les 1,6 go que compte la base)

Néanmoins, j’ai quelques erreurs bizarre :

2021-11-17T11:05:39+01:00 info WS2P: init: bundle of peers 1/1
2021-11-17T11:05:43+01:00 warn Security trigger: proof-of-work process seems stuck
2021-11-17T11:05:43+01:00 warn Local node is not a member. Waiting to be a member before computing a block.
2021-11-17T11:05:45+01:00 error WS2P >>> >>> WS ERROR: REJECTED_PUBKEY_OR_INCORRECT_ASK_SIGNATURE_FROM_REMOTE

notamment le « local node is not a member », alors que je fais pourtant partie de la toile de confiance (j’ai entré correctement ma clé). Est-ce qu’il faut être membre référent pour que ça passe ? (je n’ai que 5 certifications pour le moment)

D’autre part, le réseau devrait fonctionner en ipv6 (j’ai ouvert les ports 10900, 20900, 10901 et 20901 dans le parefeu du routeur), mais l’upnp ne semble pas se configurer (le routeur le détecte bien pour d’autres services), peut-être que c’est virtualbox qui pose problème ?
J’ai également ces erreurs parfois :

error Error: timeout
    at Timeout._onTimeout (/opt/duniter/node_modules/nat-upnp/lib/nat-upnp/client.js:187:14)
    at ontimeout (timers.js:436:11)
    at tryOnTimeout (timers.js:300:5)
    at listOnTimeout (timers.js:263:5)
    at Timer.processTimers (timers.js:223:10)

mais à la place de l’upnp je peux peut être configurer manuellement les redirections de port. Il n’y a que les ports 10900, 20900, 10901 et 20901 à rediriger, ou bien cela utilise le port 443 également ? (qui est pris par une autre machine)

@vit si je bloque encore avec yunohost, je regarderai cette histoire de reverse proxy…

Moul · 17 November 2021 11:35

Vérifie que ton nœud est bien synchronisé, qu’il est bien sur le dernier bloc. Et si tu fais une sync en CLI, vérifie que tu n’es pas dans cette situation.

Non.

C’est une erreur de connexion inter-nœuds, je ne pense pas que ça soit grave, tant que ton nœud arrive à se connecter à d’autres nœuds pour rester synchronisé. Ce log pourrait être descendu de niveau.

L’UPnP est volontairement désactivé --noupnp, car son implémentation ne fonctionne pas bien, en tout cas pour moi :

github.com

YunoHost-Apps/duniter_ynh/blob/5ee8d5322d6cf1f2ef2e9fc81b2b5e890d09d374/scripts/functions.sh#L29


      
          	dpkg -i $deb_path > /dev/null
          	rm -f $deb_path
          }
          
          INSTALL_SYSTEMD () {
          	cp ../conf/duniter.service /etc/systemd/system/duniter.service
          	systemctl enable duniter.service
          }
          
          CONFIGURE_DUNITER () {
          	duniter config --bma --ipv4 127.0.0.1 --port $port --remoteh $domain --remotep 443 --noupnp
          	duniter config --ws2p-host 127.0.0.1 --ws2p-port 20901 --ws2p-remote-host $domain --ws2p-remote-port 443 --ws2p-remote-path "/ws2p" --ws2p-noupnp
          }
          
          CONFIG_PERMISSIONS () {
          	# Remove deprecated permission system settings to remove their effects
          	if ynh_legacy_permissions_exists; then
          		ynh_legacy_permissions_delete_all
          	fi
          
          	# Protect senstive sub-routes to Duniter web admin interface, give access to choosen admin

Dans ton cas, l’UPnP n’est pas trouvé sur ta box, du coup il y a cette erreur de timeout.

Donc, sur ta box, il devrait y avoir les ports suivants d’ouverts : 443, 80 pour HTTP/HTTPS pour les apps YnH et BMA l’API cliente + les ports WS2P : ceux commençant avec 2 il me semble.

farvardin · 17 November 2021 20:19

parfait, ça semble correctement fonctionner, mon serveur apparaît bien dans Cesium maintenant, en accès privé cependant. Je vais continuer à étudier tout ça, merci pour votre aide !

farvardin · 18 November 2021 11:32

bon, je continue mon exploration. Globalement, ça fonctionne, j’ai pu calculer quelques blocs, mais je me demande si je ne suis pas un peu juste en mémoire, je n’ai que 2 Go de dispo sur ce serveur

J’ai ce type d’erreurs :

2021-11-18T11:55:23+01:00 info WS2P: connected to peer 2rVYALGp using `WS2P g1.duniter.openmyprojects.com 443`!

2021-11-18T11:55:23+01:00 info WS2P: connected to peer 5UhU5aNc using `WS2P g1.fdlibre.eu 443`!

2021-11-18T11:55:38+01:00 info WS2P: Could not connect to peer A79nvGns using `WS2P 5.135.220.105 20900: WS2P connection timeout`

2021-11-18T11:55:38+01:00 info WS2P: Could not connect to peer GTUMYd3X using `WS2P 91.175.29.153 20900: WS2P connection timeout`

2021-11-18T11:55:38+01:00 info WS2P: Could not connect to peer 5dzkzedB using `WS2P duniter.vincentux.fr 443: WS2P connection timeout`

2021-11-18T11:55:53+01:00 info WS2P: connection [5UhU5aNc `WS2P g1.fdlibre.eu 443`] has been closed

D’autre part, sur https://g1.ortie.org/ j’ai une erreur 502 bad gateway, et si je vais sur le port configuré pour WS2P (20901) ça me met une erreur de certificat (j’ai configuré le certificat avec let’s encrypt sur g1.ortie.org et il est correctement activé) : “SSL a reçu un enregistrement qui dépasse la longueur maximale autorisée.”

(depuis j’ai essayé également le port 443 en ipv6 uniquement mais ça ne change rien)

C’est ws2p qui gère l’affichage du noeud ?

Après, je constate qu’il y a pas mal de noeuds qui n’arrivent pas non plus à afficher les informations…

je ne sais pas comment j’ai fait, à un moment j’ai réussi à avoir l’api de duniter avec la version qui s’affichait, lorsque j’allais sur g1.ortie.org…

Le BMA je n’ai toujours pas compris comment ça fonctionnait ni ce que ça apportait de plus, apparemment c’est activé quand même.

Moul · 18 November 2021 11:52

Il s’agit d’informations, donc pas de problème de ce côté ci.

Attention à bien séparer la compréhension des deux API BMA et WS2P.
BMA sert pour la communication entre un nœud et des clients tel Césium.
WS2P sert pour les connexions inter-nœuds.

L’interface d’administration de Duniter propose de corriger la configuration qu’il détecte incorrecte, mais qui est en réalité correcte, car adaptée à la solution YunoHost. Donc, pour expliquer comment ça fonctionne, il y a un reverse proxy Nginx qui redirige localhost:10901 sur $nom_de_domaine:443. Si tu as cliqué sur le bouton qui corrige la configuration réseau, je te propose de mettre à jour le paquet avec lui-même ou d’exécuter cette commande pour avoir de nouveau BMA accessible.

Il y a donc besoin d’un certificat que pour BMA. WS2P fonctionne sur une connexion non chiffrée.

farvardin · 18 November 2021 12:07

impeccable, ça répond à toutes mes questions, merci beaucoup, c’est de nouveau fonctionnel, et je ne pense pas pouvoir avoir mieux.

Effectivement, quand je galérais pour la première configuration, j’ai vu que l’interface webui m’a proposé de corriger la config réseau, et comme j’ai supposé qu’elle savait mieux que moi ce qui pourrait fonctionner, j’ai accepté ces modifs. Je ne savais pas que ce n’était pas adapté avec Yunohost ! (j’ai lancé la commande que tu as pointée plus haut, et l’accès à l’api est revenu, je peux maintenant utiliser mon noeud depuis Cesium)

Pour les infos, effectivement j’ai pris cela comme un warning, mais je me demandais si l’info (non bloquante) « WS2P connection timeout » n’indiquait pas un problème par ailleurs, ou un manque d’optimisation.

Moul · 18 November 2021 12:27

Super que ça soit ça le problème ! J’ai pensé une fois à mettre un warning dans le README. Ça n’est toujours pas fait. Si tu as un moment pour rajouter ce warning, ça serait bien pour la prochaine personne qui rencontre ce problème.

Même pour un nœud bien configuré au niveau WS2P, il y a ces logs d’« erreur », ça doit être plutôt lié au réseau Internet.

Si tu vas dans l’onglet Réseau https://g1.ortie.org/webui#/main/home/connections (je n’ai pas accès hein ), tu devrais voir des connexions WS2P. (Sinon, ce qui resterait à faire serait d’ouvrir le port WS2P 20901 sur ta box Internet.)

farvardin · 18 November 2021 13:10

c’est fait, j’ai envoyé le PR. Tu pourras corriger les approximations. J’ai hésité à parler de l’ouverture des ports dans le parefeu de Yunohost. Je n’ai pas l’impression que ça soit nécessaire, j’imagine que si ça l’avait été, tu l’aurais rajouté dans le paquet.

Le port WSP2 est déjà ouvert sur ma box. Je vois beaucoup de connexions WS2P dans l’onglet que tu indiques, j’imagine que tout est bon. Peut-être que ce message est lorsqu’il passe d’un noeud à l’autre (vu qu’il y a un nombre limité de connexions simultanées peut-être ?)

Moul · 18 November 2021 13:22

Il n’y a pas de PR d’ouverte. Autrement, je peux m’occuper de récupérer le commit, c’est pas un problème.

En fait, il est nécessaire d’ouvrir aucun port bien que le paquet ouvre le port 10901/BMA dans le firewall de YnH (à enlever) (sauf 80 et 443 bien sûr), car tout passe via le reverse proxy Nginx, même WS2P.

Ça devrait pas être nécessaire au final.

Oui, il y a un mécanisme de limitation de connexions simultanées.

farvardin · 18 November 2021 13:26

oups, j’avais pas vu que cela l’avait juste mis dans mes PR à moi, il fallait que je le valide pour te l’envoyer, c’est maintenant fait.

Je vais me renseigner comment fonctionne exactement un reverse proxy, merci encore pour toutes tes précisions et conseils

farvardin · 30 September 2022 11:11

@Moul peut-être peux-tu m’aider, j’ai dû réinstaller Duniter dans yunohost suite à la maj vers la dernière version, et j’ai maintenant un soucis avec le BMA, mais peut-être pas que ça : auparavant, pour accéder au webui j’allais sur URL/webui. Si on tapait juste URL, on tombait sur la version de duniter en cours.
Maintenant, si on tape URL, ça demande l’auth yunohost. Dans l’installation de duniter, pour l’url demandée j’ai tapé URL, et non pas URL/webui, il aurait fallu faire autrement ?

le ws2p doit fonctionner puisque le noeud figure bien dans la liste :

mais j’aimerais bien utiliser mon serveur avec cesium…

Moul · 1 October 2022 11:29

Les choses ont changé vis-à-vis des accès à BMA et à l’interface d’admin. Tu peux lire les deuxième et troisième puces de cette section. Tiens-moi au courant si ça résout ou non ton problème.

farvardin · 2 October 2022 21:28

oui, merci, j’ai réussi à avoir le BMA en lançant la commande de reconfiguration manuelle :

sudo su - duniter -c “duniter --home $HOME config --bma --ipv4 127.0.0.1 --port 10901 --remoteh MY_DOMAIN --remotep 443 --noupnp”

je ne comprends pas trop l’intérêt d’avoir modifié l’adresse du BMA, parce que maintenant l’adresse à mettre dans cesium est MY_DOMAIN/bma/

et dans la page sur cesium avec les noeuds, si je clique sur “voir la fiche de pair”, ça n’abouti à rien, je ne vois pas non plus mon noeuds dans la liste des noeuds disponibles (mais peut-être qu’il faut attendre que ça se propage)

C’est comme si on demandait au gens d’aller sur g1.duniter.org/bma/ au lieu de g1.duniter.org ça me semble moins convivial, d’autant plus que s’ils vont sur MY_DOMAIN ils se tapent une page d’authentification yunohost.

Moul · 3 October 2022 06:46

Je comprends tout à fait que ce choix de changement ne soit pas idéal pour l’utilisateur.
Je me suis retrouvé dans une situation où les mainteneurs des paquets YunoHost ont appliqué des changements pour mettre à jour à niveau les helpers YnH. En réalité, ça a cassé pas mal de choses.
J’y ai pas mal réfléchi, et il me fallait réparer la CI, les tests qui passent et qui essayent d’accéder à domain.tld/ qui vérifie que l’app est bien installée.
J’ai fait ce choix afin d’avoir l’app niveau 7 et qu’elle soit toujours disponible dans le catalogue des apps.
C’est le compromis que j’ai choisi.

Peut-être que Césium ne gère pas bien les endpoint BMA avec un chemin.

Oui, de plus en faisant ce choix j’avais peur que ça rende l’admin plus facilement découvrable. À l’époque la gestion des accès était pas correctement gérée et l’admin était accessible sur tout internet sans authentification.

Une solution pour revenir en arrière serait d’adapter les tests sur les paquets YunoHost pour gérer le cas particulier de ce paquet. Je préfèrerais que la v2 prenne le dessus.

Moul · 3 October 2022 07:03

En fait j’en avais parlé de manière détaillée sur ce post :

Mais, je n’ai pas taggé le groupe yunohost.