C’est aussi la position de vit mais je suis mitigé là dessus, pour l’instant ma politique est: Je récupère tout ce que je peux depuis Duniter directement, de manière à avoir les données les plus à jours et les plus fiables possible. Elles sont actualisé en temps réel.
Je pense notamment aux soldes, ainsi qu’aux nombre de certifications émis/reçus. Mais aussi la valeur du DU, les idtyIndex, les données liés aux identités (identity.identities), cert.storageIdtyCertMeta.
Je vois universalDividend.pastReevals() dans mon code qui serait peut être plus judicieux de récupérer sur squid quand il le permettra, sinon je ne sais pas pour le moment je préfère rester comme ça mais on peut en parler sur un autre sujet.
Parceque c’est vrai que Squid est plus à jour que feu l’indexer hasura car il index les blocs non finalisé, et plus fiable car il résout les fork, donc à voir.
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
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
# 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.
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 ><
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 !
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 ><
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