En particulier, je ne comprends pas où je renseigne les informations qui disent que je suis membre. C’est le wizard key (avec salt = identifiant) ?
Et si j’ai bien suivi je n’ai pas besoin d’ouvrir de port avec la nouvelle version. Est-ce que je laisse les valeurs par défaut, ou il faut configurer ws2p d’une certaine manière ?
Tu peux te contenter du comportement par défaut : connexion privée uniquement, c’est ton nœud qui initie les connexions WS2P et autorise le P2P par ce biais.
Tu peux aussi autoriser le WS2P public en plus, afin de pouvoir être contacté directement pour la connexion P2P.
Ensuite concernant la clé de membre, tout dépend si tu utilises la WebUI ou pas.
Alors depuis un Duniter récupéré à travers git, j’utilise :
duniter wizard key # Configuration de la clé du noeud
duniter wizard network # Configuration réseau BMA
duniter config --ws2p-noupnp --ws2p-port 7778 --ws2p-host 37.187.192.109 --ws2p-remote-port 7778 --ws2p-remote-host 37.187.192.109 # Configuration ws2p
duniter config --nobma # Désactivation de BMA (optionnel)
duniter config --ws2p-public #Passage en mode public
Les infos “remote” correspondent par exemple à une box qui ferait un NAT vers ton raspberry pi, ou à un nginx/apache qui ferait un reverse proxy vers ton instance Duniter.
Du coup j’étais inspiré j’ai repris les notes de @cgeek et @Inso sur le forum pour en faire un tutoriel de configuration d’un noeud Duniter : https://duniter.org/fr/wiki/duniter/configurer
je n’ai rédiger que la partie ligne de commande, il manque la partie web-ui notamment parce que ça demande de faire plein de screens et les screens ça me soul mais peut être que d’autres seront motivés, c’est un wiki collaboratif
Pour la fin, est-ce que duniter logs ne serait pas plus adapté ?
Ce serait bien aussi d’avoir un tableau résumant les différents modes réseau. Plus précisément il faudrait expliquer comment les concepts suivants interagissent : bma, ws2p privé, ws2p public, upnp, ouverture de port. Si j’ai bien suivi, ws2p privé fonctionne même derrière un NAT, alors qu’il faut être joignable de l’extérieur pour ws2p public. Je ne sais pas ce qui fait bma, j’ai juste lu que ce n’est pas recommandé pour les rpi et semblables (c’est pour cela que je le désactive chez moi).
Oui ça marche aussi, a vrai dire j’avais oublier l’existence de cette commande car j’utilise tail a chaque fois, au moins je comprend ce que fait ma commande , je préfère.
Oui c’est perfectible c’est un 1er jet
Je crois que la différence fondamental n’est pas vraiment là. Si wp2p public est désactivé alors le nœud n’accepte pas de connexion initiée par un autre nœud, sauf s’il est dans sa liste d’invités (privilegious).
Donc s’il n’y a que des nœuds en ws2p privé on a un réseau entièrement privé -il faut être invité dans les privilegious d’autres nœuds pour pouvoir s’y connecter).
Alors qu’en mode ws2p public ton nœuds accepte toutes les connexions ws2p initiés par d’autres, dans la limite du nombre max de connexions configuré (d’ailleurs j’ai oublié ce point).
je ne maîtrise pas encore parfaitement toutes les subtilités de ws2p alors peut -etre que je me trompe.
WS2P est une api inter-nœuds uniquement.
BMA est l’api publique qui permet aux clients ou tout autre type de programme de requeter des nœuds duniter. Il faut donc que certains nœuds aient bma d’activé sinon les clients ne fonctionneront plus.
Et voilà je viens de créer un tableau avec http://www.tablesgenerator.com/markdown_tables, par contre les en-têtes du tableau ne sont pas rendus centrés sur duniter.org alors qu’ils sont centrés sur le rendu github page.
Un expert de pelican aurait une explication ?
J’ai toujours quelques soucis pour faire fonctionner mon nœud duniter correctement. (sur un Raspberry Pi 3). Je recommence. Voici ce que j’ai fait :
installer la dernière version pour ARM (1.6.4) : $ sudo dpkg -i downloads/duniter-server-v1.6.4-linux-armv7l.deb
configurer mes clés : $ duniter wizard key
(avec “salt” qui est l’identifiant secret et “password” qui est… le password. )
configurer le réseau :
$ duniter wizard network
2017-09-24T12:15:49+00:00 - debug: Plugging file system...
2017-09-24T12:15:49+00:00 - debug: Loading conf...
2017-09-24T12:15:49+00:00 - debug: Configuration saved.
? IPv4 interface wlan0 192.168.1.27
? IPv6 interface wlan0 fe80::ff36:xxxx:yyyy:zzzz%wlan0
? Port 10901
? Remote IPv4 83.xxx.yyy.zzz
? Remote port 10902
? UPnP is available: use automatic port mapping? (easier) Yes
? Does this server has a DNS name? No
2017-09-24T12:22:43+00:00 - debug: Configuration saved.
(c’est à mon avis là que j’avais fait des bêtises la dernière fois!)
synchroniser le nœud : $ duniter sync g1.duniter.org 443
J’attends la fin de la synchro pour lancer le nœud :
lancer le nœud : $ duniter webstart
(pour voir ce qu’il se passe facilement je lancerai probablement avec un simple “start” une fois que je serai rôdé.)
J’ai du partir avant la fin de la synchronisation. Je viens d’en relancer une pour être bien à jour et démarrer duniter. Dès que c’est fait et que j’ai une minute pour tester, je reviens faire un retour, positif ou pas.
[edit: Ça a l’air de tourner. Il reste à jour au niveau du dernier bloc. Mais il reste des soucis :
Je ne vois toujours pas mon nœud sur Cesium, non plus.
Et j’arrive à voir la page web depuis 127.0.0.1:9220 mais pas depuis une autre machine sur mon réseau local (avec les ports 10901 ou 10902 que j’ai renseigné dans la config réseau)…
Dernier détail, mon Raspberry Pi 3 tourne à pleine régime… Les quatre proc’ sont à 100%. Je suis un peu surpris…
2017-09-24T19:11:30+00:00 - warn: The proof-of-work generation was canceled: Document already under treatment
2017-09-24T19:11:30+00:00 - warn: The proof-of-work generation was canceled: Document already under treatment
Ça doit être normal le noeud g1.duniter.org qui met trop de temps a répondre parce qu’il est sur-sollicité il te faudrait voir avec d’autres nœuds, mais il y a encore trop peu de nœuds WZ2P sur la Ğ1, moi même je n’en ai pas encore déployer j’attend la 1.6.x officielle.
Cesium n’affiche que les nœuds qui ont activé BMA et que ceux qu’il arrive a trouver a partir de son noeud de référence, ce qui demande le temps que les fiches de peer se mettent a jours, et pour ça souvent il faut qu’un bloc passe, tu a peut être regardé trop tôt, ou tu n’a pas activé bma ?
Ça c’est un comportement parfaitement normal la web-ui n’écoute que sur localhost pour des raisons évidentes de sécurité
C’est un bug connu de la 1.5.x qui semble persister pour le moment dans les versions 0.6.x, comme nous l’a également signalé @stephane . @cgeek fait ce qu’il peut mais seul forcement ça prend du temps de traiter les bug, nous avons besoin de nouveaux contributeurs sur le cœur, j’espère qu’il y en aura après les rml10
Je n’avais pas activé BMA (qui est noté comme dépréciée sur l’interface web) mais je l’ai activée maintenant. Si je comprends bien, BMA reste utilisé partout…
Mais ça coince encore. Les logs sont bloqués sur “UPnP: configuring” (et j’ai bien vu sur mon modem que c’était configuré).
J’hésite à laisser le RPi tourner la nuit… À mon avis ça va continuer de coincer et le faire chauffer pour rien.
Et je n’ai pas encore eu un seul bloc qui est passé, peut-être normal que Cesium ne me voit pas.
[edit: Et je comprends bien que ça prenne du temps de régler ces bugs. J’adorerais donner un coup de main mais je n’ai pas les compétences pour, actuellement.
[edit2: Toujours bloqué sur “UPnP configuring” et plus d’accès à l’interface web…
2017-09-24T19:39:03+00:00 - info: Pulling blocks from the network...
2017-09-24T19:39:03+00:00 - info: Duniter server listening on http://192.168.1.27:null
2017-09-24T19:39:03+00:00 - info: UPnP: configuring...
Par contre, j’ai rebooté et je n’ai plus les quatre CPU à 100%.
Alors si tu a l’UPnP d’activé sur ta box et que tu utilise la web-ui, moi a ta place je laisserai la web-ui configurée automatiquement le réseau.
Tu peut lancer duniter avec un profil vierge ainsi : duniter webstart --mdb NOM_NOUVEAU_PROFIL
Ensuite va sur localhost:9220 et laisse toi guider graphiquement
EDIT : Astuce pour accéder a la web-ui de ton rpi depuis ton pc de bureau :
Depuis ton pc de bureau, connecte toi en ssh a ton rpi via un tunnel : ssh -L 9220:localhost:9220 user@ip
Et magie magie tu n’a plus qu’a te rendre sur localhost:9220 dans ton navigateur préféré
Je viens de reproduire, j’ai activé temporairement l’UPnP sur ma box (d’habitude je fais sans c’est plus safe) et idem le log bloque sur info: UPnP: configuring... à l’infini. Du coup j’ai désactivé l’UPnP puis réactivé la redirection de port manuelle et ça fonctionne nickel, je te recommande la redirection de port manuelle surtout pour un rpi qui servira de serveur permanent
)
je lancerai probablement avec un simple “start” une fois que je serai rôdé.)