Paquet YunoHost de Duniter v1

Nodes Duniter-v1
, , , ,
1

Il y a eu pas mal de chamboulements du côté du paquet YunoHost de Duniter.
Les mainteneurs des apps YunoHost ont fusionné un refactoring que je n’ai pas vu passé, car ma configuration M$ GH faisait que je ne recevais pas de mail.

Il y a eu quatre choses qui n’ont pas été gérés dans cette migration :

  • arrêt du support ARM
  • déplacement du dossier des données Duniter pas géré lors de la migration
  • la webadmin n’est plus protégée à l’utilisateur admin choisit, mais est accessible à tout Internet :smiley:
  • l’accès BMA a été cassé
  • gestion correcte du fait de faire tourner Duniter avec l’utilisateur Unix duniter

Cependant, ils ont apporté de nouvelles choses intéressantes :

  • utilisation des derniers standards de packaging YunoHost (helpers)
  • Gestion de la sauvegarde et de la restauration (pas testé)
  • Gestion du déplacement de l’app sur un autre chemin ($domain.tld/$path) (pas testé)
  • Duniter ne tourne plus avec l’utilisateur root (grosse faille de sécurité) :slight_smile:
  • Passe les tests de la CI
  • Niveau 7 / statut maintenu
  • De nouveau listé dans les paquets YunoHost

Vous comprendrez que je n’ai pas crié ces informations sur tous les toits le temps que j’arrive à mettre de l’ordre dans toutes ces choses.
Cette première section était pour vous tenir au courant. La section qui suit est pour vous demander de l’aide et votre avis sur certains points très précis.

Il y a une série de tests qui tourne dans la CI de YunoHost-Apps. Elle vérifie, entre autres, à différentes étapes, si le chemin principal / est accessible. Pour le contexte, actuellement BMA est accessible sur /, la webadmin sur /webui et W2SP sur /ws2p tout sur le port 443 du même nom de domaine exclusif à Duniter.

Le problème est que BMA retourne une erreur HTTP 502 sur un nœud non synchronisé, du coup elle ne passe pas les tests. Pensez-vous qu’il y ait une possibilité pour que BMA retourne quelque chose sans avoir à faire une synchronisation (post-étape laissée à l’admin) ?

La solution qui m’est venue à l’esprit pour contourner cette vérification est de déplacer BMA sur /bma et l’admin sur /. Cette solution pose entre-autres d’autres problèmes :

Je n’ai pas réussi à lancer une synchronisation sur un nœud avec BMA sur un chemin /bma. Est-ce géré par Duniter ? Si non, ça vous parait acceptable que les instances YunoHost ne permettent pas de se synchroniser dessus ? Pas sûr si ce sera géré par Duniter v1 qui est en maintenance d’ici la migration définitive à Duniter v2.

Je n’ai pas réussi à spécifier l’endpoint BMAS avec un chemin. BMA est déjà exposé sur le port 443, ceci fait que Duniter génère un endpoint BMAS. Du coup je n’arrive pas à spécifier un endpoint BMAS contenant un chemin avec la commande : `duniter config --addep “BMAS $domain 443 /$bma”. Une idée sur ce point ? Est-ce que ça vous semble acceptable si ça n’est pas correctement défini ? Je dirais qu’un endpoint WS2P correctement défini est plus important pour le réseau inter-nœuds. Si un endpoint BMA n’est pas correctement défini ça empêche uniquement sa découverte. Êtes-vous de mon avis ?

Autrement, les clients Césium et Silkaj gèrent la connexion BMA avec les nœuds ayant un chemin. Par exemple, pour tester : https://monit.g1.nordstrom.duniter.org/bma/

2 Likes
2

@Moul

Par rapport au /bma/ c’est un peu dommage mais tant pis.
Pour le webui qui tombe sur / ça me semble un peu problématique aussi.

Est-ce qu’une solution intermédiaire pourrait être de proposer /bma/ pour la connexion BMA, et /webui pour l’interface d’admin, comme avant. Et de mettre une page web générique pour / genre « Serveur duniter » avec rien dessus comme cela cela ne perturbera pas les tests qualités de ynh, de plus les gens pourront ensuite faire une redirection / alias vers /bma/ voire même pourront via un rewrite remettre /bma/ sur / ?

2 Likes
3

C’est une idée intéressante à explorer. Merci pour ta contribution !

1 Like
4

cf ce post : [Yunohost] BMAS déployé sur `/bma` - #3 by kimamila

5

Lors de la mise à niveau du paquet Duniter v1 pour YunoHost au format de paquet v2, les accès publics aux API BMA et WS2P n’ont pas été préservées. Ce changement a été intégré en février 2024.

Sachant mon instance désynchronisée, j’ai voulu la remettre en fonctionnement suite à cet évènement. J’ai découvert que les API BMA et WS2P n’étaient plus accessibles publiquement et que c’était le cas de toutes les instances de Duniter v1 hébergés sur YunoHost (avec le chemin /bma/).

Voilà, tout ça pour dire que j’ai rajouté les accès aux API. Pour les utilisateurs @YunoHost, vous pourez mettre à jour votre instance. Bien sûr je suis au courant du problème de synchronisation, auquel je ne peux remédier via le packaging.

Les changements sont dans cette PR :

Les tests sont concluants de mon côté. La CI passe. Il reste peut-être une review, je ne sais pas si j’attends. Une fois fusionné et disponible pour tous le monde dans le store, je vous pingerais une autre fois. Autrement, vous pouvez déjà tester ces changements en faisant une mise à jour vers la branche de cette PR.

4 Likes
6

Ça y est, j’ai fusionné ! cc @YunoHost.

3 Likes
7

merci @Moul j’ai mis à jour vers 1.8.7~ynh3 et ça resynchronise !

8

@Moul

j’ai relancé la synchro, ça a mis plus de 24h pour terminer, mais maintenant c’est bloqué au bloc 780 073 du 14/11 et je ne vois pas comment terminer la synchro sans tout relancer et recommencer depuis le début, à moins que ça finisse par rattraper son retard ? (edit : j’ai arrêté puis relancé Duniter, ça semble à continuer l’avancée des blocs, je suis arrivé maintenant au 780,376)

Je ne sais pas non plus si je dois laisser l’accès visiteur dans yunohost pour duniter juste pour l’api ou pour l’appli “duniter”, mais en ce cas tout le monde peut voir la console (et peut-être l’éditer) et ce n’est pas super rassurant…

J’imagine que l’api est suffisante quoi qu’il en soit, je vais continuer de bidouiller, mon serveur semble redevenu fonctionnel…

9

Oui, plusieurs redémarrages pour se resynchroniser semble également fonctionner chez moi. L’algorithme reste bloqué pour une raison après la découverte du réseau. Après redémarrage, il établit des connexions et se remet à se synchroniser jusqu’à ce qu’il se rebloque.

Je n’ai pas précisé. Il faut choisir “la valeur” par défaut :

  • choisir un administrateur (son compte YnH) pour l’accès à la webadmin.

Pour les APIs BMA et WS2P, le groupe visiteurs est configuré par défaut, pour que les clients et nœuds puissent s’y connecter.

Autrement, il ne faut pas éditer la configuration Duniter pour que la configuration via le proxy Nginx fonctionne.

Ne pas oublier que pour accéder à BMA, il ne faut pas oublier d’ajouter le / à la fin du chemin /bma/. Je n’ai pas trouvé comment faire autrement pour l’instant.

Avec l’adresse que tu as donnée, je n’arrive pas à me connecter à BMA ni à WS2P.

De quelle console parles-tu dans ton message ? Si c’est la webadmin, elle est configurée pour être accédé que par l’admin sélectionné à l’installation.

Si tu souhaites remettre la configuration par défaut, tu peux désinstaller puis réinstaller l’app. Les données de synchronisations vont rester sur le serveur et ne seront pas supprimées.

1 Like
10

merci, j’ai désinstallé puis réinstallé, je ne toucherai plus à l’interface de configuration réseau. Par “console” je parlais de cette interface web Duniter.

bien vu pour le slash après /bma/ si je le rajoute dans mon navigateur web ça affiche bien le json avec la version.

Par contre j’ai l’impression que quand on entre l’adresse complète du noeud dans cesium, ça corrige le /bma/ en /bma et ça empêche de l’utiliser et lorsqu’on sélectionne le noeud dans la liste des noeuds du réseau, ça sélectionne d’office adresse/bma sans slash.

Sinon malgré de nombreux redémarrages, ça reste toujours bloqué sur le block 780 950.
Dans les logs j’ai :

nov. 18 13:38:30 duniter[17180]: 2024-11-18T13:38:30+01:00 - warn: WS2P: cannot connect to incoming WebSocket connection: WS2P connection timeout
nov. 18 13:38:31 duniter[17180]: 2024-11-18T13:38:31+01:00 - info: WS2P 4yojwbYtAwAmNpnHNRTx5DR5q3ounkpwG144hE4N5JS1: new incoming connection from 127.0.0.1:51780!
nov. 18 13:38:31 duniter[17180]: 2024-11-18T13:38:31+01:00 - trace: WS2P >>> sendCONNECT >>> WS2P:CONNECT:g1:4yojwbYtAwAmNpnHNRTx5DR5q3ounkpwG144hE4N5JS1:e0c3b60f-112c-41c1-b34d-092e4f68bc1a397b41f3-b4f7-4d97-8c1e-140fadb3a0a4
nov. 18 13:38:31 duniter[17180]: 2024-11-18T13:38:31+01:00 - error: WS2P >>> >>> WS ERROR: REJECTED_PUBKEY_OR_INCORRECT_ASK_SIGNATURE_FROM_REMOTE
nov. 18 13:38:37 duniter[17180]: 2024-11-18T13:38:37+01:00 - warn: WS2P: cannot connect to incoming WebSocket connection: WS2P connection timeout
nov. 18 13:38:43 duniter[17180]: 2024-11-18T13:38:43+01:00 - warn: WS2P: cannot connect to incoming WebSocket connection: WS2P connection timeout
nov. 18 13:38:46 duniter[17180]: 2024-11-18T13:38:46+01:00 - warn: WS2P: cannot connect to incoming WebSocket connection: WS2P connection timeout
nov. 18 13:38:48 duniter[17180]: 2024-11-18T13:38:48+01:00 - info: WS2P 4yojwbYtAwAmNpnHNRTx5DR5q3ounkpwG144hE4N5JS1: new incoming connection from 127.0.0.1:34402!

en cherchant à REJECTED_PUBKEY_OR_INCORRECT_ASK_SIGNATURE_FROM_REMOTE j’ai vu un vieux message (de 2018 je crois) où on conseiller de réinitialiser l’installation parce qu’il restait des adresses obsolètes dans la base. J’hésite à le faire vu qu’il faudra 1 ou 2 jours encore pour resynchroniser…

je ne comprends pas les connexions depuis “127.0.0.1:51780!” vu que c’est en local est-ce que c’est parce que ça passe par un autre flux de données envoyé depuis un autre service ? Et pourquoi ces différents ports ? 51780, 34402…

1 Like
11

J’arrive bien à me connecter au BMA et WS2P de ton nœud avec Simple WebSocket Client – Get this Extension for 🦊 Firefox (en-US) sur ws://domain.tld/ws2p.
Ton admin web ne m’est pas accessible :slight_smile:

Concernant Cesium, je ne saurais pas aider. Avec Silkaj, ça fonctionne :

silkaj -ep monnaie-libre.ortie.org/bma/ wot lookup 4yojwbYtAwAmNpnHNRTx5DR5q3ounkpwG144hE4N5JS1
Public keys or user id found matching '4yojwbYtAwAmNpnHNRTx5DR5q3ounkpwG144hE4N5JS1':

→ 4yojwbYtAwAmNpnHNRTx5DR5q3ounkpwG144hE4N5JS1:BVH ↔ Eric

Concernant WS2P, il y a toujours des connexions qui ne s’établissent pas. L’important étant que ton nœud soit connecté à plusieurs nœuds. Tu peux le vérifier dans sur la première page de la webadmin.

Je ne sais pas, la connexion semble avoir été établie avec le nœud d’« Eric ». Peut-être UPnP, mais il est désactivé dans la conf de duniter_ynh.

1 Like
12

merci pour avoir vérifié. Effectivement, après désinstallation et réinstallation, les connexions fonctionnent bien.

Concernant Cesium, je ne saurais pas aider

peut-être que c’est un bug dans cesium, de ne pas permettre de rajouter le slash final, mais est-ce qu’il n’est pas possible dans le paquet duniter de faire une redirection nginx qui considérerait /bma comme /bma/ ?

L’important étant que ton nœud soit connecté à plusieurs nœuds

oui, il l’est. J’ai augmenté le nombre de connexion à 20 puis je me suis dit que s’il y avait des noeuds problématiques (pas bien synchronisés), ça pouvait empêcher de terminer la synchro, alors je suis redescendu à 1 seule connexion, et le noeud que j’avais en “incoming” était bien à la dernière synchro. J’ai redémarré, attendu un peu, mais ça n’a pas avancé la synchro, toujours bloqué au même bloc…

Je me demandais par exemple si le fait que je sois connecté à pini.fr qui est aussi au même bloc que moi ne joue pas dans ce problème :

image
image857×201 29.6 KB

13

J’ai un peu regardé cette fois avant de publier ces changements, afin de ne pas nécessiter le slash de fin de /bma/, mais la configuration précise de Nginx est encore complexe pour moi. De plus, celle du paquet duniter_ynh est un peu spéciale. Si un Pro de Nginx passe par là, je peux le guider. Je ne souhaitais pas passer plus de temps sur ça, car ça fonctionne sans pour autant être parfais. Mais, si ça peut aider à la connexion depuis Cesium, je peux me plonger une autre fois dans le sujet.

Avec Cesium, ça semble être le slash à la fin qui est enlevé. En soi, ça serait bien que Cesium gère ce cas. Je vais regarder ce qu’il est possible de faire du côté Nginx, car c’est aussi un problème de duniter_ynh.

image
image354×244 15.8 KB

Tentative intéressante ! Peut-être que le nœud de @Pini est bloqué pour la même raison, pour intégrer un changement d’état de la blockchain.

Est-ce que ton nœud est membre ? J’ai cru observer le fait que mon nœud bloquait le rattrapage de blocs lorsque l’algorithme de calcul de blocs prenais le dessus, au lieu de continuer de rattraper les blocs qui manquent. Peut-être qu’un nœud miroir rattrape mieux la synchronisation ?

1 Like
14

Avec Cesium, ça semble être le slash à la fin qui est enlevé. En soi, ça serait bien que Cesium gère ce cas.

je ne pense pas forcément que ça soit spécifiquement le code de cesium qui supprime le slash, mais c’est possible qu’il utilise un framework android quelconque qui “nettoye” les URL de cette façon. D’ailleurs la version PC (sous linux) ne présente pas cela, et je peux utiliser Cesium avec mon serveur…

image
image527×432 26.2 KB

j’imaginais que c’était cette partie dans duniter qui indiquait au client d’être sur /bma et non pas /bma/ :

je l’ai changé, ainsi que dans le manifest, mais ça fait pareil.

Est-ce que ton nœud est membre ?

oui. J’ai essayé de retirer les pairs non synchronisés comme indiqué ici :

https://duniter.fr/wiki/doc/commandes/

duniter config --remep "SUPER_ENDPOINT_ELASTIC_SEARCH  duniter-18-dev.pini.fr blablabla 21020"

ou
duniter config --remep “SUPER_ENDPOINT_ELASTIC_SEARCH duniter-18-dev.pini.fr blablabla 443”

mais ça ne semble rien changer, il apparaît toujours dans les pairs. Bon je laisse comme ça, pas la peine de s’acharner, on verra si ça sync d’ici quelques jours…

15

Tu ne peux pas agir sur les endpoints générés par les autres nœuds.

La ligne 25 de _common.sh permet de déclarer correctement l’endpoint BMAS du nœud pour la découverte du réseau :
https://monnaie-libre.ortie.org/bma/network/peering

"BMAS monnaie-libre.ortie.org 443 /bma" # au lieu de la ligne ci-dessous générée automatiquement qui est enlevée
"BMAS monnaie-libre.ortie.org 443"

Ça n’a pas de rapport. La solution qu’il faut trouver se trouve à ces lignes ou dans la globalité du fichier nginx.conf :

Après avoir tenté d’ajouter monnaie-libre.ortie.org/bma/, j’observe la console réseau :

Screenshot From 2024-11-18 19-34-29
Screenshot From 2024-11-18 19-34-291673×1036 180 KB

Les requêtes à ton nœud au-dessus du curseur se font bien sur /bma/ (c’est affiché en passant le curseur dessus) et il y a un retour HTTP 200 success. Par contre, à l’endroit du curseur la requête current n’est pas sur /bma/. Les requêtes sous et en dessous du curseur semblent être l’algo multi-nœuds de la v1.7, qui ne gère pas le chemin BMA. Donc, un bug Cesium.

Est-ce que ça fonctionne avec Cesium v1.6.x ? Cependant, je ne sais pas si la dernière version supporte le chemin BMA.

Donc, rendre BMA accessible sur /bma dans duniter_ynh, ne résoudra pas le problème ci-dessus de Cesium v1.7.

1 Like
16

ok, peut-être donc que l’affichage que j’avais dans cesium PC, qui était correct, c’était parce que c’est un cesium 1.6.

pour le noeud, j’ai réinitialisé et relancé la synchro, y’a plus qu’à attendre quelques heures / jours…