Fiche de pair inaccessible, demande d'upgrade

[fdrubigny]

Bonsoir tout le monde.

Suite à quelques soucis, j’ai dû re-configurer mon noeud et sync…

Ce fût laborieux mais finalement ça m’a l’air d’être de nouveau opérationnel mais avec quelques interrogations tout de même…

Je précise que mon noeud est sur Raspberry Pi 3 / YunoHost tout est à jours y compris Duniter 1.8.0

J’ai eu du mal à retrouver la bonne configuration pour que mon noeud soit il me semble découvert publiquement.
Pensant être arrivé à la bonne configuration, une fois le noeud sur le bon bloc dans l’interface web, je vais voir dans Césium/réseau pour voir si j’ai la même info.
Effectivement je vois mon noeud apparaître, en mode privé par contre alors que j’ai autorisé le mode public, configuré à la main, pas d’Upnp à cause de la box…
Bref de là je clique sur mon noeud, impossible d’avoir le détail.

Je regarde d’autres noeuds, nous sommes énormément dans ce cas.
Du coup je regarde sur le noeud de Bertrand Presles, là j’ai accès au détail, je regarde la fiche de pair, ok.
Du coup à la main j’ouvre mon URL de fiche de Pair => https://duniter.adn.life/network/peering et là un message me dit « Upgrade Required »

Je consulte d’autres fiches de pair de noeuds sur lesquels lorsque je clique dessus je n’ai pas le détail, pareil, « Upgrade Required »…

Du coup, qu’est-ce qu’il faut upgrader ?
Mon Duniter est à jour, YunoHost également…

Mais bon nous sommes nombreux dans ce cas.

Par avance merci pour votre retour d’infos, faites savoir si votre noeud est dans le même cas ?

Bonne fin de soirée, amicalement, Francis.

[vit]

Cesium, par expérience, est parfois capricieux pour afficher l’accès publique et qualifie le nœud en accès privé. Avec un peu de patience, le nœud finit par apparaître en accès publique.

Par contre, pour les fiches de pairs, je pense que tu as mis le doigt sur quelque chose de très intéressant, qui pourrait expliquer pourquoi le nœud MLO ne voyait plus de pairs…

Il faut enquêter sur ce problème rapidement, car il concerne Duniter et pas Cesium, comme tu le montre bien dans tes tests.

Merci pour tes retours !

ping @elois, @moul, @matograine

[matograine]

@fdrubigny

Effectivement je vois mon noeud apparaître, en mode privé par contre alors que j’ai autorisé le mode public, configuré à la main, pas d’Upnp à cause de la box…

Il faut à la fois ouvrir les ports en local avec le parefeu, et faire une redirection depuis la box. Je suppose que tu l’as déjà fait, mais je le dis à tout hasard.

---

Cesium indique le port 10901 pour duniter.adn.life. C’est ce que tu as configuré ? Dans ce cas, l’adresse de ta fiche de pair devrait être http://duniter.adn.life:10901/network/peering (qui est inaccessible, mais pas en “Upgrade Required”)

---

J’ai rencontré une fois ou deux ce souci de “Upgrade Required”, c’est parce que j’utilisais le mauvais port. De mémoire, je voulais me connecter au port WS2P au lieu du port BMA.

---

J’ai ta fiche de pair, en DOWN :

      "version": 10,
      "currency": "g1",
      "status": "DOWN",
      "first_down": 1604908283901,
      "last_try": 1604911892532,
      "pubkey": "32jZNQLKYfW9KtCHiaSewR27ZRb6zoncC6JvBVCBW4k1",
      "block": "371864-0000001072E3610EA7B6CFEEF1EA37C82861B2972F05B68C440DC1D5965975FF",
      "signature": "zA7FNKOB2v84RkGvJ66+H7NqRsLaoXNWQDii/FA6V9SeWCh18yJBRi8fCc7N0VNWga9zRCP4yoXo87pLI3B7AQ==",
      "endpoints": [
        "BASIC_MERKLED_API duniter.adn.life 195.74.76.194 2a01:cb1c:8096:e000:841b:d1bc:15af:f9d4 10901",
        "WS2P 25a3e152 duniter.adn.life 10901",
        "BMAS duniter.adn.life 2a01:cb1c:8096:e000:841b:d1bc:15af:f9d4 443"

J’observe que BMA et WSP sont sur le même port 10901. Je ne sais pas si ça peut générer des conflits.

Je n’arrive pas non plus à avoir de réponse de ton BMAS sur le port 443.

Juste des pistes…

[Moul]

As-tu mis à jour le paquet YunoHost manuellement en CLI ?
Ça devrait corriger l’accès à BMA.
Pas sûr que mon correctif fonctionne selon Thatoo. Ça fonctionne sur mon nœud.

---

Le paquet configure WS2P sur le port 20901 et BMA sur le port 10901 en local qui n’est pas accessible à l’extérieur, mais l’est à l’extérieur sur les ports HTTP 80 et 443.

La fiche de paire de mon nœud est correctement configurée :

curl https://duniter.moul.re/network/peering
{
  "version": 10,
  "currency": "g1",
  "endpoints": [
    "BMAS duniter.moul.re 443",
    "BASIC_MERKLED_API duniter.moul.re 80",
    "WS2P 871d6889 duniter.moul.re 443"

[fdrubigny]

Bonjour à tous,

alors, sans avoir touché à la configuration, j’ai laissé passer du temps…

Dans Césium le noeud n’est plus indiqué « Privé » et je peux cliquer dessus mais il n’arrive pas à récupérer les infos et apparaît comme noeud miroir.

Pour l’adresse https://duniter.adn.life/network/peering toujours « upgrade required »
Par contre je ne comprends pas pourquoi l’adresse devrait préciser le numéro du port 10901 ?
Par exemple pour ceux où cela fonctionne normalement, leur adresse de fiche de pair ne mentionne pas le numéro du port… en tout cas pour ceux qui sont sur le 443…

@Moul oui j’utilise justement la dernière version avec le correctif su systemd etc. par ailleurs dans ma ligne de commande su-i j’essaie de faire un upgrade il me dit que je suis déjà à la dernière version.

Par contre je peux tenter de re-configurer à la main les mêmes ports ?

@matograine oui mes ports sont ouverts dans ma box.

[fdrubigny]

@Moul je viens de reconfigurer mes ports à la main en suivant ton lien comme suit :

duniter config --ipv4 127.0.0.1 --port 80 --remoteh duniter.adn.life --remotep 80 --noupnp
duniter config --addep « BMAS duniter.adn.life 443 »
duniter config --ws2p-host 127.0.0.1 --ws2p-port 20901 --ws2p-remote-host duniter.adn.life --ws2p-remote-port 443 --ws2p-noupnp

Là je vais attendre un peu voir si cela provoque des changements, mais déjà l’erreur de fiche de pair n’est plus la même, maintenant j’ai une erreur 502 Nginx

[Moul]

yunohost app upgrade duniter -u https://github.com/YunoHost-Apps/duniter_ynh

devrait faire la job. Je te conseille de ne pas le faire manuellement, car tu as fait une erreur :

@fdrubigny

–port 80

devrait être 10901, c’est ce qui explique l’erreur 502 de Nginx.

[fdrubigny]

@Moul

yunohost app upgrade duniter -u https://github.com/YunoHost-Apps/duniter_ynh

Ok, je vais essayer mais normalement j’ai déjà cette version…
Ok pour le port je n’étais pas sûr, je vais refaire en mettant 10901.

Par contre je vois que dans Césium nous sommes nombreux où les “informations du noeud ne sont pas récupérables” et où l’adresse de fiche de pair ne fonctionne pas…

Compliqué tout ça, mais on va bien comprendre pourquoi.

[fdrubigny]

Yeah! @Moul You rock!

Alors, je ne sais pas pourquoi je n’avais pas visiblement ton dernier correctif alors que j’avais justement suivit la discussion…
Mais bon peut-être qu’avec les bugs que j’ai eu, le fait d’avoir tout remis à zéro cela m’avait fait suter ton correctif ?
Bref, toujours est-il que l’Upgrade c’est déroulée !

Ensuite j’ai refait la manip à la main quand même pour configurer les ports et tout re-fonctionne, le noeud affiche les informations dans Césium, la fiche de pair est accessible à l’adresse https://duniter.adn.life/network/peering

Merci beaucoup, par contre du coup je m’interroge pour tous les autres noeuds qui ont les mêmes soucis que j’avais, soit lorsque l’on clique sur leur Noeud, il ne se passe rien, on n’a pas accès aux informations, et lorsque l’on tape leur adresse de pair « upgrade required » …
D’autres noeuds, « récupération des informations du noeud impossible » …

---

Edit :
Attendons de voir quand même la stabilité car j’ai déjà 2 blocs de retard…

[Moul]

Perso, je n’arrive pas à me connecter à ton nœud via BMA. Tu devrais y avoir accès lorsque t’es connecté au SSO de ton instance YnH. As-tu également accès à BMA lorsque tu n’es pas connecté au SSO pour que ça soit publiquement accessible ?

[fdrubigny]

Si tu parles de l’interface web, j’y est accès lorsque je suis connecté au SSO.

Mais pas lorsque je suis déconnecté :

[Moul]

Je parle de l’accès à BMA via curl ou dans le navigateur directement :

curl https://duniter.adn.life/node/summary

• https://duniter.adn.life/node/summary

[fdrubigny]

Désolé là c’est quelque chose que je ne comprends pas en fait…
Je ne suis pas dev, je bricole, j’essaie, je test… mais là ?

Moi ça m’affiche ça le lien que tu m’as mis =>

Même résultat en mode curl

Même résultat déconnecté du SSO

Je viens de tester sur ton adresse ça m’affiche la même chose, du coup je me dis que ça doit être bon ?

[Moul]

Ok, tant mieux. En fait, j’ai un problème pour accéder à ton serveur.
Tu peux vérifier avec le Tor Browser si ton serveur est accessible via l’extérieur via tes noms de domaines.

[fdrubigny]

Oui tous mes domaines sont accessibles via Tor Browser.
Le domaine nohost.me
Le domaine adn.life et tous les sous-domaines
Ainsi qu’un autre domaine en.xyz

[elois]

Dsl je n’ai pas la foi de tout lire mais sache que « Upgrade Required » n’a rien a voir avec les mises à jour. « Upgrade Required » signifie que tu contactes en HTTP un serveur qui attend un protocole «par-dessus» HTTP, par exemple le protocole websocket, le fait de passer à un protocole «supérieur» est appelé upgrade en anglais, oui c’est confusant

Bref, tout ça pour dire que le problème c’est que tu contactes en HTTP un endpoint qui attend que tu lui parles en websocket.

[fdrubigny]

OK, merci de la précision, je n’ai pas vraiment compris mais j’imagine que certains comprendront et que ça leur sera utile.

Sinon, pour le moment j’ai l’impression d’avoir retrouvé les bons réglages et tout semble fonctionner.
A voir maintenant la stabilité ou pas du noeud.

Amicalement, Francis

[vit]

Je viens d’être confronté au même problème, erreur 426 demande d’upgrade.

J’ai donc mis à jour toute ma machine… Nan, je déconne, ne faites pas ça !

En fait un reverse proxy qui doit rediriger le protocole websocket utilisé par WS2P doit ajouter des instructions dans l’entête des requêtes adressées à l’application.

En fait, le protocole websocket est géré comme une upgrade du protocole http. Le client dit à nginx : il faut que tu upgrades http en websocket.

Mais nginx doit alors à son tour signaler dans la requête à l’application qu’il faut faire un upgrade de http vers websocket.

Pour cela, il faut ajouter ce bloc d’instruction dans la définition de la redirection :

    location /path {
        # required for websocket
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $host;

        proxy_pass http://127.0.0.1:21901;
    }

Pour les anglophones, le sujet est très bien expliqué dans cet article :

Using NGINX as a WebSocket Proxy

[fdrubigny]

@Moul

Je parle de l’accès à BMA via curl ou dans le navigateur directement :

curl https://duniter.adn.life/node/summary

• https://duniter.adn.life/node/summary

Salut !
Je reviens sur cette notion d’atteindre le noeud depuis l’extérieur…

Chez moi je vois bien les infos lorsque je clique sur le lien ou lorsque j’utilise la commande curl…

toutefois, lors d’une remarque pertinente de @Spencer hier soir, j’ai tenté de me connecter à mon noeud dans Césium, c’est vrai que par habitude mon Césium est paramétré sur le noeud de Bertrand @bpresles du coup bizarrement je n’avais jamais testé de me mettre tout simplement sur mon noeud…

Bref, du coup lorsque je choisis mon noeud dans Césium dans la liste de noeuds proposés et que je clique sur mon compte, j’ai le message “Césium interroge le noeud Duniter” mais ça reste bloqué là-dessus et Césium ne me propose pas d’autre noeud en me disant que celui-ci n’est pas joignable, ça reste bloqué et c’est tout…

Du coup, Spencer essaye de joindre via le lien ci-dessus et il n’y arrive pas.
Hors chez moi, je comprends bien que j’utilise le même réseau que celui où est hébergé le noeud, mais en utilisant le nom de domaine ou curl, j’obtiens la bonne réponse…

Par ailleurs, si j’essaie avec tor de me connecter à l’interface web du noeud, ça fonctionne aussi…
Lorsque j’essaie le lien ci-dessus avec mon Tel en 4G, donc un autre réseau que ma box internet, le lien c i-dessus fonctionne aussi…

Du coup, voilà, je m’interroge pourquoi je n’arrive pas à me connecter via Césium et pourquoi certains de l’extérieur comme Spencer n’arrive pas à joindre le noeud ?

Bon dimanche, amicalement, Francis

---

Alors j’édite ce post car je me pose la question d’utiliser un service de DynDNS…
En effet mon fournisseur d’accès a priori, je n’en suis pas si sûr finalement m’a déjà changé d’adresse ipv4, du coup j’avais lu sur les forums comme quoi cela arrive lors des mises à jours de la box, d’un redémarrage, qu’Orange fournisse un système d’adresses IP dynamiques, mais rien de certain puisque cela fait plusieurs mois qu’il ne m’a pas changé l’adresse IP finalement, cela n’a été fait qu’une seule fois ?.. bizarre.

Bref, du coup, ayant eu ce soucis une fois et que tout ce que j’ai sur le Raspberry Pi ne fonctionnait plus à cause de ce changement d’adresse Ipv4, j’avais trouvé la parade d’utiliser les services de DynDNS…

Mais voilà, je m’aperçois que la redirection de l’adresse fournie par DynDNS est configurée sur le Port 4001, ce qui est différent des ports HTTP et HTTPS, peut-il y avoir du coup une incidence ?
Ce port est bel et bien ouvert sur ma box dans les règles NAT/PAT.

Amicalement, Francis

---

Une autre édition de ce post, j’ai modifié la configuration sur le service DynDNS pour qu’elle se fasse sur le port 443 mais ça ne change absolument rien…