Je viens de découvrir l’option --only-peers de la commande duniter sync. Elle est parfaite car elle permet d’initialiser une conf sans lancer la synchro.
Malheureusement ça plante :
$ duniter --home /var/lib/duniter sync g1-test.duniter.org:443 --no-interactive --only-peers
2021-05-10T16:10:39+00:00 - warn: No configuration loaded
2021-05-10T16:10:40+00:00 - info: mode=Sync
2021-05-10T16:10:40+00:00 - info: open duniter databases...
2021-05-10T16:10:40+00:00 - info: Databases successfully opened.
2021-05-10T16:10:40+00:00 - info: Current block: no blockchain
2021-05-10T16:10:40+00:00 - info: start dbs threadpool...
2021-05-10T16:10:40+00:00 - info: Duniter sever started.
2021-05-10T16:10:40+00:00 - info: start duniter modules...
2021-05-10T16:10:40+00:00 - info: generated self endpoints: []
2021-05-10T16:10:41+00:00 - info: Block resolution: 0 potential blocks for root block...
2021-05-10T16:10:41+00:00 - error: TypeError: Cannot read property 'getPeers' of undefined
at RemoteSynchronizer.syncPeers (/duniter/app/modules/crawler/lib/sync/RemoteSynchronizer.js:269:39)
at Object.onDatabaseExecute (/duniter/app/modules/crawler/index.js:156:41)
at Stack.processCommand (/duniter/index.js:378:47)
at process._tickCallback (internal/process/next_tick.js:68:7)
J’utilise l’image docker duniter/duniter:dev présente sur DockerHub à l’instant où j’écris ces lignes.
EDIT : j’ai hésité à saisir une issue sur le projet gitlab, mais il semblerait que ce ne soit pas l’usage (rien depuis 3 ans).
Non, c’est une bonne pratique. Hésite pas à répertorier les problèmes sur le bug tracker, sinon ça se perd sur le forum. Le BTS a un peu été délaissé depuis la transition.
Pour ça tu as déjà une commande fait pour: la commande config. tu l’aurais vu en faisant un --help
Je sais depuis longtemps qu’elle plante. Ça ne sera pas corrigé avant migration, d’autant que la commande synrc va être migrée ce mois-ci, c’est la 1ère étape de ma roadmap !
Non il n’a pas été délaissé. Simplement il n’y a eu qu’une seule version stable de sortie depuis la « transition », et cette dernière n’a quasiment pas introduit de nouveaux bugs, donc très peu de nouveaux tickets.
Quant aux tickets existants, la plupart concernent des bugs anciens liés à la codebase nodejs et que je ne corrigerai pas, il n’aurons juste plus lieu au fur et à mesure de la migration.
Si de nouveaux bugs (pas déjà connu) sont découverts, il faut évidemment ouvrir un ticket. Dans le doute, vous pouvez ouvrir un ticket, mais si le bug est déjà connu et tracé je clôturerai le ticket.
Mais beaucoup de bug existant ont eu d’intérêts à être tracés, car ils concernent des pans de code qui vont disparaître d’ici la prochaine version.
Je pense que c’est faisable via un script en reprenant un fichier de conf généré par Duniter. Il faut juste que tu génères aléatoirement le champ ws2p.uuid (qui doit être 4 octets aléatoires encodés en hexadécimal) et ça devrait marcher
@HugoTrentesaux et @poka ont réussi à le faire pendant le hackathon, l’astuce: faire une synchro locale sur un seul chunk json qui ne contient que un bloc genesis.
Aucun de nous n’aura le temps de s’y pencher dans les semaines voir mois qui viennent.
Et pourtant, ça nous permettrait de pouvoir tester beaucoup plus efficacement Duniter et GVA, surtout pour la migration de DuniterTS → DuniterRust.
Donc si c’est un projet qui t’intéresse, pose moi toutes les questions que tu veux
La partie qui me faisait surtout penser à ça, c’est:
En bonus: Un script permettant de boostraper automatiquement une nouvelle monnaie Duniter de test, à partir de différents snapshots.
Mais je ne sais pas si programmer un bot killer de gtest t’intéresse lol
la commande duniter config permet de résoudre cela. Tu n’as pas besoin de définir les paramètres de la monnaie dans le fichier de conf, ils sont remplis automatiquement lors d’une synchro (qu’elle soit locale ou pas).
On fait ça uniquement pour contourner le fait que la sync par le réseau à des gros problèmes. Quand cette commande sera migrée la sync par le réseau fonctionnera bien, donc on aura plus besoin de ce contournement.
En attendant, la seule possibilité c’est de copier un ficher peers.db existant.
La synchro coûte cher. Je veux l’éviter. C’est tout le but de la manip.
Ben non, justement. Il suffit juste d’un peers.db vide et d’un petit script de quelques lignes. Si je n’ai pas de peers.db vide, je peux maintenant le créer avec la commande duniter sync --only-peers (*) qui évite la synchro complète.
(*) qui ne marche toujours pas comme je voudrais, mais ne plante plus grâce à ce patch, et qui crée au moins le peers.db vide que je n’ai plus qu’à remplir avec un GET sur /network/peering du noeud distant.
diff --git a/app/modules/crawler/lib/sync/RemoteSynchronizer.ts b/app/modules/crawler/lib/sync/RemoteSynchronizer.ts
index f173627c..11303635 100644
--- a/app/modules/crawler/lib/sync/RemoteSynchronizer.ts
+++ b/app/modules/crawler/lib/sync/RemoteSynchronizer.ts
@@ -382,6 +382,9 @@ export class RemoteSynchronizer extends AbstractSynchronizer {
}
async syncPeers(fullSync: boolean, to?: number): Promise<void> {
+ if (!this.node) {
+ this.init();
+ }
const peers = await this.node.getPeers();
for (let i = 0; i < peers.length; i++) {
const peer = PeerDTO.fromJSONObject(peers[i]);
