Nous n’avons plus aucun ticket d’ouvert pour ce Runtime ! J’attends le résultat de cette discussion Faire le tri dans la pallet duniter-account puis je propose de reboot la ĞDev
La ĞDev est relancée
- Version du client : 0.8.0
- Release: runtime-800
- Docker : duniter-v2s-gdev (x86 et ARM)
- Télémétrie : Polkadot Telemetry
- Détails de génération du Genesis : logs du job
Les bootnodes par défaut sont ceux de gdev.cgeek.fr et gdev.coinduf.eu.
Les données Ğ1 sont celles du bloc #700,935, soit le 04/02/2024 à 13:41:09. Le n° de bloc utilisé est présent dans le fichier g1-data.json :
"current_block": {
"number": 700935,
"medianTime": 1707054069
}
Des difficultés
Le redémarrage ne s’est pas très bien passé, le lancement date de ce week-end mais suis tombé sur deux nouvelles embûches : #189 et #190.
J’ai contourné ces bugs mais comme je n’étais pas trop sûr du résultat, j’ai préféré attendr avant de faire l’annonce.
mon miroir Gdev est relancé en runtime-800, mais il apparaît dans la page télémétrie de la runtime-701. quelle valeur mettre ici pour que le client soit bien orienté ?
environment: - DUNITER_CHAIN_NAME=gdev
Auto-reponse : Ne pas oublié d’effacer ancien conteneur et ancien volume, ensuite tout se reconstruit correctement et où il faut !!
8 posts were merged into an existing topic: Ğcli s’adapte au runtime 800 : nouveau parcours forgeron
L’image Docker pour ARM est également disponible.
À propos des différents réseaux :
- Polkadot Telemetry à Nuremberg en 0.3.0, qui est encore sur ce réseau ?
- Polkadot Telemetry @tatinetteb, @guenoel, (Nuremberg), @1000i100, @Art15te il est temps de redémarrer vos noeuds pour rejoindre le nouveau réseau !
- Polkadot Telemetry @pini @Robin @bgallois @poka @daigongen @jef @vit il est temps de redémarrer vos noeuds pour rejoindre le nouveau réseau !
Pour redémarrer son noeud :
# retirer le volume pour ne pas démarrer sur l'ancien réseau
docker compose down -v
# télécharger la nouvelle image
docker compose pull
# démarrer sur le nouveau réseau
docker compose up -d
Vous verrez des erreurs dans les logs pour des raisons de bootnodes mal configurés, c’est normal, c’est notre faute, on publiera une autre image quand on aura plus de bootnodes. Pour savoir si vous avez réussi à vous connecter au nouveau réseau, plus simple que regarder les logs, tout simplement regarder Polkadot Telemetry.
Objectif : plus un seul noeud sur les vieux réseaux et tout le monde sur le nouveau ! Promis on va faire moins de reboots pour que ce soit plus facile à suivre.
Et quand vous aurez réussi avec votre noeud miroir, vous pourrez suivre si vous le souhaitez le nouveau parcours forgeron ! (Ğcli s'adapte au runtime 800 : nouveau parcours forgeron).
C’est sync de mon côté.
Les erreurs dont tu parles c’est bien ces erreurs là ?
Report 12D3KooWDuzVbBcnnEEKh32R6MUKvQvLENyzLHHUfg4kTyUQq7hp: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.
Je parlais d’erreurs de bootnodes, mais celle là c’est parce que des noeuds de l’ancien réseau tentent de se connecter à ton noeud qui est sur le nouveau, donc ton noeud les met gentiment dehors avec un coup de pied aux fesses ><
Done
Fait pour le compte de @jef , c’est moi qui ai la main sur le docker de son VPS pour l’instant…
Fait.
Si vous êtes sur l’ancien réseau dans Telemetry, et que vous n’avez pas vu le lien de @cgeek plus haut,
vous pouvez cliquer en haut à droite de Telemetry, sur les trois petits points.
Un outil de recherche s’ouvre et vous tapez “dev” (“gdev” ne fonctionne pas car des petits malins ont mis un Ǧ libre à ĞDev )
Puis cliquez sur le tag ĞDev14 et vous afficherez le bon réseau !
Hope it helps…
Comment faites-vous au niveau des ports avec deux instances sur la même machine ?
J’utilise l’option --port 30333
pour gdev-validator
et --port 30334
pour gdev-rpc
(mon nœud archive public).
Merci, je remettrais le nez dedans plus tard étant donné que tu dis que c’est possible.
J’ai mis en place un nœud smith, puis exécuté ce qui suit :
Pas sûr d’avoir compris cette phrase :
Puis, après un go-online
, je passe dans les online (clé du milieu) après une ère :
Online:
“ 5E6q47RRGZU15LjUiBTm2DZjpqFKAjRNafYS8YV8AzTQZtLG ”
“ 5HDikVWZ2xHfqvVVFwex5zmRsH4LuR3KqMgKZYEbCSjStSKw ”
“ 5Dq8xjvkmbz7q4g2LbZgyExD26VSCutfEc6n4W4AfQeVHZqz ”
Une époque est passée et toujours rien. Dois-je attendre une seconde epoch ?
Ou bien dois-je faire un set-session-keys
? Si oui, comment faire ? Pas trouvé dans la doc :
Pour une meilleure sécurité le nœud forgeron devrait être seul sur sa machine, pour éviter qu’il soit affecté par une attaque sur un autre logiciel qui sature les ressources de la machine. Mais même en prod on ne sera pas à ce niveau d’exigence ><
Dans mon template qui écrit les docker-compose, j’ai mis ce truc un peu crado.
ports:
# prometheus endpoint
- 127.0.0.1:{{9615+port_increment}}:9615
# rpc via http
- 127.0.0.1:{{9933+port_increment}}:9933
# rpc via websocket
- 127.0.0.1:{{9944+port_increment}}:9944
# public p2p endpoint
- {{30333+port_increment}}:30333
Mais j’ai discuté avec @aya pendant l’AG Axiom qui m’a parlé d’une solution d’orchestration docker plus satisfaisante dont j’ai évidemment oublié les détails ><
Et il y a aussi la solution de @Pini qui utilise nginx-proxy-manager (https://nginxproxymanager.com/).
Désolé, je n’ai pas mis à jour cette doc. J’ai tendance à essayer de centraliser sur le site officiel et ça donne donc :
Mais grâce à ton commentaire je me rends compte que je n’ai pas documenté la solution que j’utilise personnellement : gcli smith update-keys
.
Ah, en fait j’avais fait un gcli smith update-keys
hier.
Du coup, j’ai enfin écrit mes premiers blocs ĞDev
Il fallait attendre deux époques. Ça a du commencer quand je suis allé me coucher
À 22h08 j’ai eu une alerte d’une nouvelle autorité entrante (Incoming). Effectivement tu n’a pu forger de blocs qu’une ou deux session plus tard soit entre 23h08 et 00h08.
c’est là que je sèche actuellement !
En utilisant NGinxProxyManager, tous mes autres conteneurs (odoo, etc…) sont bien accessibles, depuis leur sous domaine ou avec leur port dédié. mais pas les nœuds V2S. J’ai bien bien intégré le réseau d’écoute de NGinxProxyManager, dans chacun de mes compose V2S. le MIRROR utilise les ports du template et j’ai fait +1 pour les ports du SMITH.
le noeud n’étant pas accessible, même en essayant un tunnel SSH comme décris ici dans la doc :
- Create an SSH bridge from your computer to your server:
ssh -L 9945:localhost:9945 SSH_USER@YOUR_SERVER
- Install PolkadotJS browser extension. It will manage your private keys and known pubkeys safely.
- Go to a PolkadotJS web UI. (it’s not the same thing as the browser extension)
Donc avant de continuer mon parcours SMITH va falloir régler ce problème accessibilité extérieure et donc mieux comprendre comment configurer NGinxProxyManager… STEP BY STEP
Ici tu fais un lien du port local 9945 vers le port interne 9945, or le port interne par défaut est 9944, donc il faudrait écrire à la place : 127.0.0.1:9945:9944
(ou changer le port interne avec l’argument duniter). Mais on sort de mon domaine de compétence, ce n’est plus de la programmation mais de l’adminsys/devops et donc il nous faudrait de l’aide de gens comme @Pini (actuellement indisponible j’ai cru comprendre), @immae (qui est plutôt sur l’infra Duniter, il a déjà pas mal de boulot), @aya (aussi pas mal pris mais a des trucs intéressants à partager )…
J’ai encore un problème de micro avec le nouveau micro que j’ai acheté en Ğ1, mais je crois que je vais juste en acheter un en € et dès que je l’ai je vais pouvoir faire des vidéos explicatives moins crado.
j’ai corrigé les port du compose comme indiqué et j’ai pu me connecter sur le RPC de mon SMITH via PolkadotJS web UI.