Bêta-test Duniter 1.6 WS2P

elois · 20 September 2017 16:08

ok c’est justement ce que je voulais tester, je confirme que mes deux nœuds ne sont pas connectés ensemble.

Et merci pour le détails ça me semble bien plus clair désormais

cgeek · 20 September 2017 16:26

Nouvelle version 1.6.3

Ajout de l’UID de membre dans la vue réseau

Afin d’y voir un peu plus clair sur qui est connecté à nous : membre ou miroir ?

Configuration WS2P par la WebUI

Il est désormais possible de configurer WS2P en majeure partie via la WebUI.

À noter qu’il est possible de totalement désactiver l’accès WS2P, aussi bien public que privé.

Autres correctifs

autoriser la connexion interne de nœuds jumeaux
les fiches de pair sans BMA sont désormais acceptées
les fiches de pair peuvent ne plus déclarer aucun endpoint (permet la suppression totale des interfaces¹)
élagage plus précis des connexions non prioritaires
contrôle que la clé réceptionnée dans la négociation de connexion est bien celle attendue
correction de l’option --ws2p-remote-host qui tronquait la valeur donnée

ajout d’options pour configurer WS2P en ligne de commande :

--ws2p-max-private <count>      Maximum private connections count.
--ws2p-max-public <count>       Maximum public connections count.
--ws2p-private                  Enable WS2P Private access.
--ws2p-public                   Enable WS2P Public access.
--ws2p-noprivate                Disable WS2P Private access.
--ws2p-nopublic                 Disable WS2P Public access.
--ws2p-prefered-add <pubkey>    Add a prefered node to connect to through private access.
--ws2p-prefered-rm  <pubkey>    Remove prefered node.
--ws2p-privileged-add <pubkey>  Add a privileged node to for our public access.
--ws2p-privileged-rm <pubkey>   Remove a privileged.

ajout des commandes :

duniter ws2p show-conf
duniter ws2p list-nodes
duniter ws2p list-prefered
duniter ws2p list-privileged

en cas d’extinction forcée (Ctrl+C), le nœud tente de terminer sa tâche d’écriture disque avant de fermer
découplage entre l’activité de preuve de travail et pull BMA
attente de la fermeture effective du serveur de WebSocket en cas de demande de fermeture

¹ : est suivie d’un ticket de sécurité : https://github.com/duniter/duniter/issues/1114

Avec la version ARM

Cette fois-ci, j’ai pu livrer la version ARM. À tester toutefois.

Dans le cas d’ARM, je conseille de définitivement couper l’interface BMA dans « Settings > Network > Enable BMA ». Cette API est devenue bien trop gourmande et inefficace pour les nœuds ARM.

elois · 20 September 2017 17:03

mise a jours sur 1.6.3 effectuée

@cgeek je t’ai ajouter dans ma privileged list pour tester

@cgeek autre question, la commande direct_webstart n’existe plus sous duniter 1.6.x ?

cgeek · 20 September 2017 17:19

Ah si la commande doit toujours exister ! D’ailleurs je l’utilise sur ARM et g1-test.cgeek.fr.

cgeek · 20 September 2017 17:20

En fait, il me semble qu’en jouant avec ces listes ainsi que les nombres max de connexions privées/publiques, ont peut créer le réseau maillé qu’on désire.

elois · 20 September 2017 17:35

~~En installation manuelle depuis les sources ça ne fonctionne pas~~ oubli, j’avais oublier que je n’est pas installer la web-ui…

EDIT : bon j’ai essayer d’ajouter la web-ui en manuel et la commande direct_webstart ne veut toujours pas se lancée :

yarn add duniter-ui
rm -r node_modules
yarn

je ne vois pas se que j’ai loupé

cgeek · 20 September 2017 18:20

Comme ça je dirais que tu n’as rien loupé, mettons que tu sois dans ~/dev/duniter, la commande est :

bin/duniter direct_webstart

cgeek · 21 September 2017 11:40

Nouvelle version 1.6.4

Fonctionnalités

Réseau
- possibilité de ne plus déclarer aucun endpoint sur sa fiche de pair, par exemple pour ne plus être contacté

Correctifs

Liés à WS2P :
- les endpoints BMAS n’étaient plus inscrits dans la fiche de pair
Indépendants :
- correction d’un bug majeur qui rendait le nœud quasi-inopérant, affichant en boucle le message The proof-of-work generation was canceled: [object Object].
- correction d’une faille potentielle où un attaquant pouvoir envoyer une infinité de fiches de pair de nœuds miroirs.

elois · 21 September 2017 14:16

Mon nœud local sur 1.6.4 reste bloqué au bloc 56070 alors qu’il est en liaison WS2P avec 3 noeuds qui eux sont au bloc 56553, ça fait plus de 30 min et il ne rattrape pas sont retard je vais devoir le resync manuellement, les log : https://hastebin.com/hogocupuje

Moul · 21 September 2017 14:50

J’ai rencontré un bug similaire alors que mon nœud diurne rattrapait le retard qu’il a pris la nuit, il n’avait pas atteint le HEAD du réseau. J’ai redémarré le nœud et il a rejoint le HEAD du réseau.

cgeek · 21 September 2017 15:14

Je pense que mes multiples redémarrages des nœuds g1-test.cgeek.fr et g1-test.duniter.org associés au bug de PoW annulée y sont pour quelque chose quand on a aussi peu de nœuds WS2P.

Mais continuez d’observer ! Je fais de même. Je vais essayer d’ajouter un ou deux nœuds ce week-end.

elois · 21 September 2017 15:24

Alors c’est très bizarre, la web-ui m’indique désormais qu’il bien au bloc 56582 mais si je clique sur NETWORK puis que je reviens sur OVERVIEW il m’affiche de nouveau 56070 puis au bout de 15s il passe a 56582.
Sachant qu’il ne calcule aucun bloc alors qu’il en calculait hier, je pense qu’il est en train de reswither en ping-pong éternel d’une branche a l’autre ou alors il y a un bug dans l’affichage, mais je suis sûr qu’il ne calcule pas je monitore l’activité cpu.

EDIT : d’après les log je crois que c’est bien un problème de résolution de fork :

017-09-21T16:14:21+02:00 - e[32minfoe[39m: Block resolution: 0 potential blocks after current#56070...
2017-09-21T16:14:21+02:00 - e[32minfoe[39m: Fork resolution: 72 potential block(s) found...
2017-09-21T16:14:21+02:00 - e[33mwarne[39m:  httpCode=400, ucode=1015, message=Document already under treatment
2017-09-21T16:14:21+02:00 - e[33mwarne[39m: Block already known
2017-09-21T16:14:21+02:00 - e[33mwarne[39m: Block already known
2017-09-21T16:14:21+02:00 - e[33mwarne[39m: Block already known
2017-09-21T16:14:22+02:00 - e[33mwarne[39m: Block already known
2017-09-21T16:14:23+02:00 - e[32minfoe[39m: ⬇ PEER 4XXUjyto
2017-09-21T16:14:23+02:00 - e[32minfoe[39m: ✘ PEER 4XXUjyto
2017-09-21T16:14:23+02:00 - e[33mwarne[39m: Unknown reference block of peer

Inso · 21 September 2017 17:57

J’essaie de faire fonctionner un noeud purement WS2P sans nginx devant. J’ai donc désactivé BMA et configuré ws2p avec les commandes :

./bin/duniter config --ws2p-noupnp --ws2p-port 7778 --ws2p-host 37.187.192.109 --ws2p-remote-port 7778  --ws2p-remote-host 37.187.192.109        
./bin/duniter config --nobma

Le parefeu est ouvert, mais il m’est impossible de joindre mon noeud. Même en local :

nc 37.187.192.109 7778
(UNKNOWN) [37.187.192.109] 7778 (?) : Connection refused

C’est comme si duniter n’avait pas réussi à ouvrir le port ws2p. Pourtant dans les logs je ne vois pas d’erreur particulière :

2017-09-21T19:52:18+02:00 - info: >> Server starting...
2017-09-21T19:52:18+02:00 - info: Node version: 1.6.4
2017-09-21T19:52:18+02:00 - info: Node pubkey: 5GXtSTTXpvnhLq4TiQM1uaFuiSZaXyEZGYETX95j6WMU
2017-09-21T19:52:18+02:00 - warn: Local node is not a member. Waiting to be a member before computing a block.
2017-09-21T19:52:18+02:00 - info: Sibling endpoints:
2017-09-21T19:52:18+02:00 - info: ⬇ PEER 5GXtSTTX
2017-09-21T19:52:18+02:00 - info: ✘ PEER 5GXtSTTX
2017-09-21T19:52:18+02:00 - error:  httpCode=400, ucode=2023, message=Peer document already known
2017-09-21T19:52:18+02:00 - info: Next peering signal in 31 min
2017-09-21T19:52:28+02:00 - info: WS2P: Could not connect to peer -------- using `WS2P 37.187.192.109 7778: WS2P connection timeout`
2017-09-21T19:52:28+02:00 - warn: WS2P >> Streamer >> WS2P connection timeout
2017-09-21T19:52:28+02:00 - info: Block resolution: 0 potential blocks for root block...
2017-09-21T19:52:28+02:00 - info: >> Server ready!

Le show conf ne me dit rien :

$ ./bin/duniter ws2p show conf
$

Bef je suis un peu largué là…

cgeek · 21 September 2017 21:18

Tu devrais voir un message “WS2P […] listen” quelque part si ton nœud est correctement configuré. Il te manque l’option --ws2p-public je pense.

Pour voir la config, la commande est duniter ws2p show-conf.

Inso · 22 September 2017 06:08

Cool ! Ca a l’air mieux mais :

2017-09-22T08:07:24+02:00 - info: Sibling endpoints:
2017-09-22T08:07:24+02:00 - info: WS2P 5GXtSTTXpvnhLq4TiQM1uaFuiSZaXyEZGYETX95j6WMU: new incoming connection from 37.187.192.109:37544!
2017-09-22T08:07:24+02:00 - info: ⬇ PEER 5GXtSTTX
2017-09-22T08:07:24+02:00 - info: ✘ PEER 5GXtSTTX
2017-09-22T08:07:24+02:00 - error:  httpCode=400, ucode=2023, message=Peer document already known
2017-09-22T08:07:24+02:00 - info: Next peering signal in 31 min
2017-09-22T08:07:24+02:00 - error: WS2P >>> >>> WS ERROR: REJECTED_PUBKEY_OR_INCORRECT_ASK_SIGNATURE_FROM_REMOTE
2017-09-22T08:07:34+02:00 - info: WS

C’est normal cette erreur ?

cgeek · 22 September 2017 08:25

Soit la clé publique qui répond n’est pas celle attendue à l’adresse indiquée, soit le nœud qui répond n’est pas sur la même monnaie que le nœud qui tente la connexion. Ou les deux à la fois, ce qui est tout à fait possible si la connexion pointe vers un nœud d’une autre monnaie.

cgeek · 22 September 2017 09:15

@SimonLefort

Je crois que ton nœud est connecté au mien, mais le tiens semble désynchronisé.

Si tu as accès à l’interface graphique, pourrais-tu aller dans “Settings > Backup > Create a data backup” et m’envoyer le fichier via https://framadrop.org ? Tu peux m’envoyer le lien par MP sur le forum.

Par avance merci !

edit : il semble que ce ne soit plus vrai depuis quelques minutes, je ne sais pas si tu as fait quelque chose ou non.

cgeek · 22 September 2017 09:24

Dans ce cas ce serait bien de faire un backup de duniter.db et wotb.bin, et de les partager pour qu’on puisse tous regarder.

Et concernant les nombreux messages :

WS2P >> Streamer >> WS2P connection timeout

Je reproduis. Il semble que la connexion websocket soit perdue à un moment donné mais incorrectement traitée dans Duniter, ce qui fait que la connexion n’est jamais réétablie.

J’ai créé le ticket #1116 à cet effet.

Alan_Schmitt · 22 September 2017 12:42

Je viens de tester, et j’ai quelques questions.

J’ai l’impression que je reste bloqué sur le premier bloc après le “sync”. J’essaye d’arrêter et de relancer pour voir. (Effectivement, après redémarrage cela a l’air d’aller mieux.)
Même après duniter stop, j’ai 4 processus node qui tournent en prenant plein de cpu. Je peux les tuer ? Quand je relance duniter, j’ai 8 nodes qui tournent, et j’ai toujours 8 nodes après l’avoir quitté.
Mon nœud continue à calculer une PoW pour un bloc qui a déjà été trouvé (je vois bien les messages comme quoi on annule le calcul sur le cluster, mais je continue à voir des messages « matched 3 zeros … » pour le vieux bloc).
Est-ce que cette erreur est grave: « error: Peer with zero endpoints that is not already known » ?
Est-ce que mon nœud sera visible sur la page https://g1.duniter.fr/#/app/network ? Ce sera sous quel nom ?

Moul · 22 September 2017 13:31

Ça semble être un bug. On a déjà rencontré ce bug. Quelle est l’architecture processeur de ton Odroid. Si c’est sur ARM64, tu dois être le premier à tester sur cette architecture.

Je pense pas que ça soit grave. C’est à titre informatif.

Normalement oui dans le cas de BMA.
Pour WS2P, c’est sur /network/ws2p/{info,heads}