Et tu arrivais à t’y connecter avec Césium ou Silkaj ?
Oui, enfin il me semble avoir pu m’y connecter avec Césium.
En tout cas il calculait des blocs ça c’est sûr.
36 messages ont été scindés en un nouveau sujet : Installation et utilisation paquet Duniter pour YunoHost
12 messages ont été scindés en un nouveau sujet : Packaging Cesium/Duniter dans Debian et YunoHost
Bon ben ça s’arrange pas, toujours aucun bloc de calculé, et les logs montrent un apparent blocage de connexion, le truc semble tourner à vide… https://hastebin.com/givememado
Je vois que ton nœud est à la ramasse :
Peut-être un problème réseau. Mais, je vois que ton nœud est connecté à d’autres nœuds via WS2P.
2020-06-11T08:46:06+02:00 - e[32minfoe[39m: WS2P: connected to peer 74RBUM4V using `WS2P
[…]
2020-06-11T08:46:21+02:00 - e[32minfoe[39m: WS2P: connected to peer CTQZd3h8 using `WS2P g1.guenoel.fr 443`!
Du coup, je vois pas ce qui cloche.
Ce n’est pas un bloquage de connexion, c’est un problème de fork qui ne se résout pas :
2020-06-11T08:34:36+02:00 - e[32minfoe[39m: Fork resolution: block #307383-0000016F is known as incorrect. Skipping.
Or la branche majoritaire contient bien le bloc #307383-0000016F, j’en déduit que tes index sont corrompus car un bloc valide a été estimé a tord invalide. Il te faut reset data et sync.
J’ai progressé ! http://hastebin.com/igazecimez
A tout hasard j’ai rebooté Yunohost… (c’est pas long de toute façon)
Mise à jour de la clé (via la webui)
duniter stop
sudo duniter webstart (ou connexion root, sous Yunohost il faut se connecter en admin, puis su, duniter webstart)
Il a resynchronisé sans demander mon avis.
Maintenant on dirait bien qu’il est bien connecté et qu’il tente de calculer des blocs… J’attends maintenant impatiemment qu’il m’en mette un dans la blockchain ! 
A noter que derrière une Freebox, j’ai remis l’UPnP en mode version 1 (et pas version 2 qui était activé, mais ne serait pas totalement validé), pas sûr que ce soit important, mais je le signale au cas où.
@Moul une idée de pourquoi le paquet ynh fait ça ? Je n’ai jamais observé ce comportement sur duniter desktop.
C’est peut-être parce qu’il avait été lancé en admin initialement, et que là j’ai lancé en root… Il gère peut-être des dossiers différents dans ce cas ?
1 Like
Le dossier de données de Duniter étant stocké dans l’espace utilisateur, oui si tu change d’utilisateur tu change de dossier de données donc tu n’a plus de blockchain. Le mystère est résolu, je n’avais pas vu que tu avait changé d’utilisateur.
Par contre il ne faudrait jamais lancer Duniter en root, ce n’est pas une bonne pratique 
Apparemment tout le monde est d’accord…
Le paquet ne fait pas de synchronisation complète. Je pense que Ğaluel veux dire une synchronisation différentielle.
J’ai pas voulu faire trop de bruit, n’ayant pas créé de ticket, car c’est une faille potentielle de sécurité. Mais, ça traine, et c’est toujours pas fais. Voilà, maintenant c’est clairement connu par plus de monde que moi. Y’a plus qu’à corriger.
Bon je sais pas si ça marche ou pas, il finit régulièrement par avoir des problèmes de connexion… Pourquoi ? Firewall Yunohost qui bloque ? Connexions WS2P instables ?
Il y a souvent ces erreurs de connexion WS2P que ça soit installé sur YunoHost ou pas. L’important étant d’avoir des connexions (il y a treize fois cette ligne dans les logs ci-dessus) :
2020-06-12T08:02:15+02:00 - e[32minfoe[39m: WS2P: connected to peer HmH5beJq using `WS2P g1.le-sou.org 443`!
2020-06-12T08:05:50+02:00 - e[32minfoe[39m: WS2P: connected to peer Bf9PttKS using `WS2P g1.mithril.re 443`!
C’est vrai que ces erreurs WS2P cachent sous leurs nombres les lignes de succès WS2P. Il y a surement quelque chose à améliorer de point de vue là. Il y a beaucoup d’administrateurs qui se plaigne de ce comportement.
Autrement, tu as un bloc dans la fenêtre courante 
:
| 330028 | 2020-06-11 20:05:06 | 2020-06-11 18:08:18 | 000002FE15 | Galuel |
2 Likes
Génial, je l’avais pas vu ! Faut dire que ça n’apparaît pas dans la WEBUI, pourquoi ?
Pourquoi ne pas faire à la place une ligne simple qui dise régulièrement (disons toutes les 5 mn ?!) un truc du type : “Connexions XS2P réussies : 80%” ? Et ne lister les clés de connexion que si on tombe sous un certain % ?
Après tout dans un réseau P2P le fait d’échouer sur certaines connexions n’est pas un bug, ce qui importe c’est de réussir à se connecter à quelques noeuds…
1 Like
Le nombre de blocs trouvés au total dans la chaîne était affiché dans la tuile en bas à gauche. Mais, cette information a été enlevée pour une raison valable, dont je ne me rappelle plus.
Oui, conserver la ligne d’établissement de connexion semble une bonne chose, et remplacer les erreurs par ce que tu proposes semble une amélioration.
Ce n’est pas moi qui gère la web-ui, donc je ne suis pas sûr, mais il me semble que ça ralentissait trop le chargement de l’interface graphique.
Concernant le code de WS2P je ne souhaite pas le faire évoluer, il est trop complexe je risquerai d’y introduire des régressions et d’y perdre un temps fou. Je prévois de réécrire directement un nouveau protocole réseau en Rust (WS2Pv2) qui corrigera les écueils de WS2Pv1, dont celui que vous signalez ici.
1 Like
Bon alors bilan, 1 seul block pour @Galuel toujours : https://remuniter.cgeek.fr/#forum
Est-ce qu’il y a une commande Duniter pour connaître ses blocs calculés ?