Mon nœud validateur v2s tournait dans podman-compose et ça se passait bien.
Depuis que je l’ai passé à l’utilisation de Quadlet (podman + systemd), mon identité était sortie des authorities.
J’ai tenté à plusieurs reprises de le faire re-rentrer, mais en vains, ça échoue.
Un gcli smith go-online, j’attends que deux epoch passent, et là il détecte que mon nœud est hors ligne, du coup infraction offence et mon identité est expulsée des forgerons :
À noter que mon nœud est bien visible dans Polkadot Telemetry.
Autre sujet peut-être lié, après plusieurs manipulations, j’ai remarqué des problèmes que j’ai eus précédemment avec plus d’accès réseau à l’intérieur du conteneur. Un redémarrage de ma machine (host) a résolu le problème.
Je pourrais de nouveau tenter avec podman-compose, mais je n’ai pas réussi. Je pourrais tenter sans conteneur. Avez-vous une idée de la raison pour laquelle mon nœud pourrait être détecté hors ligne ? Est-ce via l’API p2p30333 que cette vérification a lieu ?
Ce qui est étrange, c’est que dans la télémétrie, il semble que ton nœud forgeron “moul-smith” soit bien connecté à huit pairs (p2p, via le port 30333 normalement). Donc on dirait que ce n’est pas un problème réseau. Mais peut-être qu’il y a un problème de session keys ?
session.nextKeys(5HDikVWZ2xHfqvVVFwex5zmRsH4LuR3KqMgKZYEbCSjStSKw) me donne les clés suivantes :
Je n’arrive pas à exécuter cette commande dans Chain state, je rajoute mon adresse (Moul dans mes contacts) et le bloc courant copié de Telemetry. Puis, je ne sais pas sur quoi cliquer pour exécuter la commande. Faut-il être sudo ?
J’ai bien false avec cette clé de session.
Comment mettre la bonne clé de session sur mon nœud ? gcli smith {update,set-session}-keys ?
Ok donc tu as dû supprimer ton keystore d’une manière ou d’une autre, il est dans le volume docker pourtant.
Ce n’est pas une bonne pratique de “déposer” une clé privée sur un nœud, car ça veut dire qu’elle a été à un moment quelque part ailleurs (un presse papier, une autre machine…). Donc le mieux est de demander à ton nœud de générer de nouvelles clés avec author.rotateKeys() (rpc), puis d’annoncer publiquement la nouvelle clé avec authorityMembers.setSessionKeys() (extrinsic). C’est ce que fait gcli en une seule commande avec gcli update-keys. Alternativement, tu peux décomposer en deux étapes en faisant rotateKeys autrement et setSessionKeys ensuite.
J’ai concaténé les quatre chaînes de caractères en enlevant le préfixe 0x des trois dernières.
J’ai commencé à le faire avec Polkadot.js, mais je ne trouve pas où sont les extrinsics
Après un gcli smith update-keys, cette fois j’ai un true avec author.hasSessionKeys(). Espérons que ça passe cette fois. Merci pour l’aide.
rpc calls = une API pour interagir avec le nœud directement
gcli smith update-keys masque cette complexité et fait les vérifications tout seul. On pourrait ajouter une commande “gcli smith check” pour vérifier si les session keys sont bien sur le nœud et qu’on peut faire go-online sans problème.
[edit] je vois que tu calcules à nouveau des blocs, comme le 831,070 par exemple.
Tu ne peux pas soumettre d’extrinsic sans le signer, et pour signer dans l’app polkadotjs, il faut une extension navigateur. Tu peux donc installer une extension navigateur pour gérer tes clés. Par exemple duniter-connect qui gère les clés v1, ou l’extension polkadotjs, ou enkrypt que je trouve plus grand public.
Merci, je ne savais pas qu’il fallait avoir une extension pour signer qui soit configurée pour avoir l’onglet Extrinsic dans Polkadot.js. Chose qui été là sur ma précédente installation sans j’en aie conscience.
Il me manquait la connexion entre duniter-connect et Polkadot.js.
Je l’avais sauté. En rechargeant Polkadot.js, le pop-up demandant la connexion apparaît, et maintenant j’ai bien la section Extrinsincs