Duniter 1.8.0-beta5 released

elois · Mai 22, 2020, 10:16

Télécharger Duniter 1.8.0-beta5

Cette version nécessite une resynchronisation de la blockchain (avec reset data)

Cette nouvelle version majeure de Duniter cumule beaucoup de petites modifications, dont certaines ont été réalisées il y a plus d’un an déjà (notamment le passage à nodejs v10); elle marque également le commencement d’une migration progressive de Duniter en Rust !

Changements principaux :

Migration sous nodejs v10 @cgeek et @Moul
Migration en Rust de module wotb @elois
Migration en Rust de toutes les fonctionnalités de cryptographie (sauf scrypt) @elois
Remplacement vielles dépendances qui présentaient des vulnérabilités de sécurité @elois
Auto-complétion bash @vit
Amélioration du process de build et allègement des paquets @sveyret

Cette version inclus de très nombreux autres changements, je vous invite à lire le CHANGELOG pour plus de détails :

Il s’agit d’une version beta (et non alpha), donc nul besoin d’être un érudit du code, @TestSmith tous les membres forgerons de la G1-test peuvent d’ores et déjà se mettre à jours.

Merci de nous aider à réaliser la campagne de test de Duniter 1.8.

Vous pouvez également tester cette version sur la Ğ1, cette version est toutefois réservée aux testeurs de Duniter, comme indiqué c’est une « beta ».

Ça implique quoi d’être bêta-testeur ?

Connaître les fonctionnalités de Duniter dans les grandes lignes, savoir à peu près comment un nœud est censé se comporter (donc être déjà utilisateur de Duniter depuis au moins quelques mois).
Aider à compléter le cahier des tests de la version : Campagne de Test Duniter 1.8
Surveillez régulièrement son nœud durant la campagne de test afin de détecter toute anomalie (et donc être capable de créer un ticket avec un rapport de bug le cas échéant).
Être réactif en cas de correctif publié sur ce forum : donc faire l’effort de checker quotidiennement ce fils pendant la campagne de test (ce qui prend 30 secondes par jours, il s’agit juste de « vérifier » sur ce fils si un correctif a été publié).

elois · Mai 22, 2020, 10:43

Nœud officiel g1-test.duniter.org mis a jour

Attilax · Mai 23, 2020, 12:47

Version 1.8.0beta2 installée et apparemment fonctionnelle sur pi4 : ça tourne.

elois · Mai 27, 2020, 3:24

je viens de livrer Duniter 1.8.0-beta3, cette version corrige la régression sur la commande wizard signalée par tuxmain ici : Campagne de Test Duniter 1.8

tuxmain · Mai 27, 2020, 4:07

J’ai testé la beta3, le wizard key marche mais…

$ duniter wizard network
2020-05-27T17:52:06+02:00 - debug: Plugging file system…
2020-05-27T17:52:06+02:00 - debug: Loading conf…
2020-05-27T17:52:06+02:00 - debug: Configuration saved.
2020-05-27T17:52:06+02:00 - error: TypeError: done is not a function
at upnpResolve (/opt/duniter/app/modules/bma/index.js:387:9)
at process._tickCallback (internal/process/next_tick.js:68:7)

Sur Debian et ArchLinux, à partir du .deb server.

elois · Mai 27, 2020, 7:28

Chez moi la commande wizard network ne rend jamais la main, car ma box ne répond pas aux requêtes upnp, donc je ne peux pas tester cette commande « facilement ».

Le problème que tu avais remonté au préalable concernait toutes les sous-commandes wizard sans exception, ça n’avait rien de spécifique ni à key ni a network ni autre, aucune sous tache wizard ne pouvais s’exécuter, donc tester sur une seule sous commande suffisait pour s’assurer que le problème était résolu.

C’est pour ces 2 raisons que je n’ai pas testé la commande wizard network.

Suite à ton nouveau test (qui retourne bien une erreur différente), je viens de passer 3h à chercher la cause de ce 2ème bug (cause qui n’a aucun rapport avec le 1er).

Il m’a d’abord fallu trouver comment tester la commande wizard network, ce qui fût galère car Duniter utilise nat-upnp qui est vieux de 3 ans et très mal documenté, tellement mal que j’ai dû regarder au débogueur les propriétés pour trouver une propriété timeout et la setter à 1, ce qui m’a permis de tester la commande wizard network.

Je n’ai pas trouvé l’unité de cette propriété timeout (qui vaut 1800 par défaut), mais j’ai remarqué que si je la fixe a 55 ou moins j’ai un retour immédiat (en moins d’une seconde), et à partir de 56 ou plus je n’ai jamais de retour (pas même au bout de plusieurs minutes), c’est à n’y rien comprendre.

Bref, l’important c’est que j’ai réussi à tester la commande, mais je n’étais pas au bout de mes peines, il m’a fallu mener l’enquête et faire quelques recherches sur stackoverflow, pour finalement me rendre compte que le problème venait de changements cassant lors du passage de async 2.x à async 3.x.

Tout cela parce que le 23 avril j’ai mis à jours toutes les dépendances de Duniter qui pouvait l’être (afin de réduire les vulnérabilités de sécurité).

Changements cassant non détectés par Typescript parce que c’est un passage plein de any… quel enfer le typage faible

Bon c’est corrigé mais ce bug chiant m’a rappelé pourquoi je n’aime pas le typage faible (et je déteste encore plus l’absence de typage), ça fait perdre un temps fou à chercher des bugs qui ne peuvent tout simplement pas exister en typage fort.

Voici les diff pour les curieux :

Moul · Mai 27, 2020, 8:07

Je pense qu’on devrait retourner travailler sous GitLab pour laisser des traces des changements.
Maintenant que GitLab n’est plus lent, utiliser le forum pour le développement très spécifique ne me semble plus une très bonne chose. Ça peut toujours être utilisé pour discuter des grands projets et des grandes décisions.

Tout ça pour dire que si on tombe sur ton commit, on n’a pas accès à tous les détails ci-dessus.
L’idée serait de faire un lien, comme mettre un lien vers ce message dans le message de commit.
Ce qui est encore mieux c’est créer un ticket et y mettre ce contenu. Même si le ticket et en français, c’est déjà ça. En anglais c’est mieux, mais ça n’est pas obligatoire.

elois · Mai 27, 2020, 8:08

Bof c’est de nouveau bien lent, ça swap a mort, je pense qu’on aura un gitlab utilisable que quand le forum ML aura été migré

elois · Juin 1, 2020, 2:08

Version 1.8.0-beta4 publiée.

Il est temps de tester sur la Ğ1 directement, j’ai besoin que plus de monde installe Duniter 1.8 avant de pouvoir l’estampiller « stable », mais on s’en rapproche

vit · Juin 1, 2020, 5:15

Incroyable !

Je viens de mettre à jour en beta 4 et je me rend compte que mon nœud était arrêté (g1-test). Il était dans les 568000 blocs et se met à remonter fissa jusqu’à atteindre le bloc 572973 de la branche majoritaire.

Du jamais vu chez moi, un nœud qui rattrape les autres avec bien plus de 100 blocs de retard !

Mais ce n’est pas tout.

Il calcul alors deux blocs d’affilé ! le 572974 et 572975 !

C’est possible ça de ne pas être « assez exclu » pour enchaîner deux blocs ?

elois · Juin 1, 2020, 5:25

Oui j’ai remarqué ça aussi quand j’ai testé la version desktop, je pense que l’oxydation de toutes les opérations de cryptographie a eu un impact positif sur les perf

Oui bien sûr que c’est possible, s’il y a très peu de membres dans la fenêtre courante alors un même membre a le droit de trouver plusieurs blocs d’affilé

elois · Juin 1, 2020, 8:36

La version 1.8 nécessite une resynchronisation de la blockchain (avec reset data)

Cela est du à la migration du module wotb en Rust, la manière de stocker la wot dans ce module a changée, il faut donc refaire une synchronisation pour recréer ce fichier comme il faut.

J’avais écrit un code de migration, mais il bug et j’y ai déjà passé beaucoup de temps tout en ayant toujours aucune piste, je pense que ça ne vaut pas le coup de perdre plus de temps que ça sur une fonctionnalité temporaire qui ne servira plus a rien quand tout le réseau sera en 1.8, je préfère consacrer ce temps à plus utile.

vit · Juin 2, 2020, 8:45

Si les performances de Duniter explosent avec cette version, la synchronisation est maintenant beaucoup plus lente (g1-test).

J’ai fait ceci :

duniter reset data

puis :

duniter sync g1-test.cgeek.fr

et le log dynamique reste figé sur Peers... et les pourcentages download et apply à 27%/25%.

J’ai ensuite détruit le dossier de config de duniter, en préservant la conf et le keyring.

Je relance la synchro :

Le log dynamique n’est plus figé, mais j’avance très lentement à partir de 25%.

Je n’ai jamais mis plus de 15/30mn pour une synchro, là je suis parti pour compter en heures je pense…

elois · Juin 2, 2020, 5:04

Je pense que cela n’a absolument aucun apport avec la nouvelle version de Duniter, j’ai fait de très nombreux tests de synchro (avec reset data) au moment des dev et je n’ai observé aucun ralentissement.

La cause est propre a l’état du réseau g1-test, ce réseau étant très très petit (il n’y a que 3 noeuds BMA accessibles pour la sync), il un seul des noeuds BMA est plus lent a répondre, ça ralenti énormément la partie téléchargement des chunk de blocs.

J’ai remarqué un ralentissement de la sync sur la g1-test depuis le bastionnage du serveur hébergeant le noeud g1-test.duniter.org, pour moi la cause est là

Pour y pallier il faut beaucoup plus de noeuds g1-test avec une api BMA correctement configurée, actuellement il n’y en a que 3 (le noeud officiel, celui de cgeek, et le mien).

Moul · Juin 2, 2020, 5:13

3 messages ont été scindés en un nouveau sujet : Config BMA nœud moul

elois · Juin 3, 2020, 6:15

Je viens de publier une beta5 : https://git.duniter.org/nodes/typescript/duniter/-/releases/v1.8.0-beta5

Le changement : Duniter détecte automatiquement qu’il nécessite une nouvelle sync avec reset data :

$ duniter start
This upgrade requires resetting the data and resynchronization (duniter reset data && duniter sync).

Cela évitera les oublis.

À noter que les utilisateurs de la variante desktop ne verront pas le message (sauf à aller voir dans les logs). Je mettrais bien en avant dans la communication qu’il faut supprimer le dossier de données. Mais si certains utilisateurs de la variante desktop oublis ou ne lisent pas, ils seront bloqués et viendront demander du support ici.

Au moins ça rendra impossible le lancement d’un noeud 1.8 sans resync, c’est ça le but

J’invite tous les testeurs de la 1.8 à se mettre à jours dès que possible : @Attilax @Moul @matograine @poka @Pafzedog @tuxmain

Attilax · Juin 4, 2020, 8:38

Fait. Bravo à toi, komrad, tu avances vite

Le noeud est reparti et calcule des blocs sans souci. C’est un succès