J’essaye de mettre en place l’oracle. J’ai ça dans les journaux :
thread 'main' panicked at /root/distance-oracle/src/api.rs:31:10:
Cannot create RPC client: Rpc(ClientError(Transport(Error when opening the TCP socket: Connection refused (os error 111))))
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Waiting 1800 seconds before next execution...
Comment communiquent le nœud forgeron et l’oracle ? Via RPC ? Via le système de fichier ? Je suppose via RPC.
Cette erreur dit-elle que l’oracle a un problème à se connecter au nœud smith via RPC ?
Il me semble avoir un problème sous Fedora pour avoir un bridge, réseau de podman et docker fonctionner correctement, car firewalld est utilisé à la place iptables. À creuser…
Peux-tu donner plus d’infos sur la manière dont tu configures ton réseau ? Voici comment j’ai fait la séparation sur la doc :
je déclare un réseau extérieur correspondant à mon nœud archive
# external network of duniter node to read data from rpc API
networks:
duniter:
name: duniter-gdev-smith_default # <---- network name of your smith node
external: true
je définis le endpoint RPC en utilisant le nom du service dans ce réseau
ORACLE_RPC_URL: "ws://duniter-smith:9944" # <--- here "duniter-smith" corresponds to your smith service
Comme en pratique ça ne fonctionne pas actuellement parce que j’ai configuré mon nœud forgeron pour garder 256 blocs alors qu’il en faudrait 600 (cf docs/user/distance.md#additional-duniter-configuration), j’ai opté pour une solution externe :
ORACLE_RPC_URL: "wss://gdev.coinduf.eu/"
Ça a l’air de fonctionner :
2024-09-23T17:21:17.856Z DEBUG [distance_oracle::api] Looking at Pool1 for session 5568
2024-09-23T17:21:17.872Z INFO [distance_oracle] Evaluating distance for session 5568
2024-09-23T17:21:36.401Z DEBUG [distance_oracle] Evaluating distance for idty 14588
2024-09-23T17:21:36.405Z INFO [distance_oracle] Distance for idty 14588: 1684/1736 = 97.00461%
2024-09-23T17:21:36.407Z DEBUG [distance_oracle] Saving distance evaluation result to file `"/var/lib/duniter/chains/gdev/distance/5569"`
Waiting 180 seconds before next execution...
Merci pour ta réponse, ça m’a aidé avec plus de ressources.
J’ai essayé de convertir les fichiers compose vers Quadlet (Podman + Systemd).
J’ai un peu galéré avec les volumes et réseaux. J’ai fini par trouver, il m’a fallu définir "ORACLE_RPC_URL=ws://systemd-duniter-v2s-validator:9944" en rapport avec le nom du fichier et définir ces deux champs dans les deux fichiers :
l’API RPC unsafe n’est pas censée être ouverte sur l’extérieur, donc il ne faut pas bind le port 9944 à 0.0.0.0 mais seulement localhost
c’est mieux de déclarer explicitement l’adresse publique p2p, notamment si le port public n’est pas 30333
Quand il faudra évaluer la distance de Daigongen (cf Compte Daigongen en v2), on devrait le voir dans les logs. En attendant, il n’y a pas beaucoup de demande.
Amusant Quadlet, je me souviens avoir lu l’article que tu avais partagé. Peut-être à proposer officiellement parmi les différentes méthodes d’installation…
Est-ce toujours nécessaire de mettre en place la section Running distance evaluation de la documentation ? L’oracle semble à présent fonctionner comme un daemon et la fréquence est configurable. Si c’est correct, je veux bien supprimer cette section via une MR.
Concernant le fait de devoir conserver plus de blocs pour que l’oracle fonctionne correctement. J’ai tenté de passer mon nœud en archive, mais c’est incompatible avec le fait d’être forgeron.
La définition de la variable d’environnement DUNITER_PRUNING_PROFILE n’est pas clair, elle ne précise pas combien c’est par défault. Est-il possible de passer une valeur comme 600 à cette envvar ?
Effectivement, c’est a priori pas une bonne idée d’avoir un nœud validateur configuré comme archive. Le DUNITER_PRUNING_PROFILE est un wrapper de --state-pruning et --blocks-pruning (cf docker/docker-entrypoint · master · nodes / rust / Duniter v2S · GitLab). Pour l’aide de duniter directement, c’est duniter --help :
--state-pruning <PRUNING_MODE>
Specify the state pruning mode.
This mode specifies when the block's state (ie, storage) should be pruned (ie, removed) from the database.
This setting can only be set on the first creation of the database. Every subsequent run will load the pruning
mode from the database and will error if the stored mode doesn't match this CLI value. It is fine to drop this
CLI flag for subsequent runs. Possible values: - archive: Keep the state of all blocks. - 'archive-canonical'
Keep only the state of finalized blocks. - number Keep the state of the last number of finalized blocks.
[default: 256]
--blocks-pruning <PRUNING_MODE>
Specify the blocks pruning mode.
This mode specifies when the block's body (including justifications) should be pruned (ie, removed) from the
database. Possible values: - 'archive' Keep all blocks. - 'archive-canonical' Keep only finalized blocks. -
number Keep the last `number` of finalized blocks.
[default: archive-canonical]
Pas la peine de passer à 600 par défaut, puisque le runtime 802 ramène à une évaluation plus fréquente de la règle de distance. Il faut juste lancer un runtime upgrade, ce sera l’occasion de faire fonctionner le comité technique.
Waiting 1800 seconds before next execution...
INFO [distance_oracle] Evaluating distance for session 5634
INFO [distance_oracle] Distance for idty 9653: 797/1710 = 46.608185%
INFO [distance_oracle] Distance for idty 13585: 1362/1710 = 79.649124%
INFO [distance_oracle] Distance for idty 9710: 1369/1710 = 80.05848%
INFO [distance_oracle] Distance for idty 5938: 1454/1710 = 85.02924%
INFO [distance_oracle] Distance for idty 10051: 1590/1710 = 92.98246%
INFO [distance_oracle] Distance for idty 6535: 1618/1710 = 94.61988%
INFO [distance_oracle] Distance for idty 13578: 1634/1710 = 95.55556%
INFO [distance_oracle] Distance for idty 9902: 1616/1710 = 94.50293%
INFO [distance_oracle] Distance for idty 10291: 1688/1710 = 98.713455%
Waiting 1800 seconds before next execution...
INFO [distance_oracle] Nothing to do: File already exists
Mon oracle est donc bien installé et fonctionnel ! Le résultat est ensuite partagé via le volume au nœud forgeron
J’aimerais rajouter la date dans les logs, mais ça semble être déjà activé par défaut sur simple logger. Je ne trouve pas dans le répertoire de l’oracle où est-ce que ça pourrait être désactivé.
En effet, je découvre, que podman logs --help a une option pour afficher le timestamp :
-t, --timestamps Output the timestamps in the log
L’option doit être activée par défaut avec docker logs.
Du coup, je suppose que les timestamps sont écrits dans le fichier de log par simple_logger et que podman et docker l’affichent ou pas avec la commande logs.
En fait, si j’active cette option sur les logs de Duniter v2s, j’ai deux fois la date.
Du coup, pour l’oracle, je n’ai pas de date. Autrement, cette option me suffit avec l’oracle dans un conteneur.
