Pour en rajouter une couche : plus la méthode n°2 est utilisée, moins la n°1 devient efficace. Aujourd’hui cette dernière méthode semble devenue inutilisable.
On est dans une sorte de “hard fork de synchro”.
Il est grand temps que Duniter v2 prenne le relais, plus que 2 mois à tenir. Ça devrait le faire 
Du coup, est-ce qu’il ne serait pas judicieux de faire également un backup journalier des données de quelques autres noeuds ?
Dans le cas ou le mien (en v1.8.7) se ferait désynchroniser; je ne sais pas comment je pourrais le rétablir.
Il y a toujours les miens, j’en ai utilisé un il y a quelques jours.
Exemple : https://dl.cgeek.fr/public/auto-backup-g1-duniter-1.8.7_2025-12-26_23-00.tgz
Il faut juste changer la date. Je ne conserve que les 5 derniers jours.
pour faire court, pour résoudre le pb d’affichage de wsp “privé” dans cesium, j’utilise l’image “pinidh/duniter:1.8.7” au lieu de l’image “pinidh/duniter:1.8.7-pini2”. Dans cette dernière version le port ws2p (20901) n’est pas bindé dans le container, un contournement possible est de faire la config réseau via l’interface d’admin.
@pini FYI
Du coup ça pourrait expliquer les soucis que j’avais à tester la partie ws2p avec mon serveur 1.8.7 
@daigongen Je confirme que j’ai pu corriger la config dans le GUI
J’ai décoché Enable Public WS2P access through UPnP, et configuré en détail:
Et maintenant, je peux enfin tester mes mappings ws2p correctement
nix run nixpkgs#websocat -- ws://g1.brussels.ovh:20901
{"auth":"CONNECT","pub":"EnFfLNWnonXwxmzipLbbqa1fybSs7xdPoYhmbkMYzR3G","challenge":"7772cd31-6617-4f70-bbe8-fd50992e159ed733c48f-e5aa-4c78-bb98-28e80584d425","sig":"j5bhDOxppRO53+bDqK04Do7bmwBdXfKWHamJ6EcuyZGgSe6+G/aUiE9hrF39c0txVC2iCiKXDRatFCF9JWiZBQ==","currency":"g1"}
nix run nixpkgs#websocat -- wss://g1.brussels.ovh/ws2p
{"auth":"CONNECT","pub":"EnFfLNWnonXwxmzipLbbqa1fybSs7xdPoYhmbkMYzR3G","challenge":"1f7bfbef-0d64-423d-a351-fb96431e7ccefee82106-3c36-43c7-a9a5-095fb9a36df7","sig":"qK4iZZmm7m8VLDVif5ANYW66D/NuC6YjHHyAuavH4UzyeBrWit2C7zPWTtkg5EB7TY69wFROKc4qDwa4nQHlAg==","currency":"g1"}
Bon, j’ai fait un truc un peu sale, mais ça a l’air d’être passé : j’ai désactivé l’exception ruleToBeKickedArePresent dans les sources 1.9.0 et la synchro est allée au bout. Mon noeud duniter.pini.fr est revenu. Je vais tenter de mettre en place des snapshots réguliers.
J’avais aussi tenté la ligne de commande avec les options ws2p, cela ne binde pas le port.
@Nicolas80 dans mon cas le setting fait via l’admin n’est pas persistant en cas de relance.
Ha zut, pas pratique ça :-/
Je verrai d’ici 2 jours si ça fais la même chose chez moi.
Il faudrait que tous les autres hébergeurs de nœuds 1.9.0 se basent sur tes snapshots pour assurer une certaines stabilités de ces nœuds, dans ce cas.
Allez plus que 2 mois à tenir, ça devrait le faire
Je suis preneur d’une image docker
J’ai reconfiguré mon 2ème noeud (non forgeron) avec l’image de @Pini et également récupéré son backup.
Avec cela, cela semble fonctionner correctement:
Le serveur: https://g1-1.9.0.de.brussels.ovh/
curl -i https://g1-1.9.0.de.brussels.ovh/
>
... "version": "1.9.0"
# Je ne sais pas trop pourquoi; mais le "block" mentionné dans le retour de network/peering semble toujours un peu en retard
curl -i https://g1-1.9.0.de.brussels.ovh/network/peering
>
...
"endpoints": [
"GVA S g1-1.9.0.de.brussels.ovh 443 gva",
"BMAS g1-1.9.0.de.brussels.ovh 443",
"WS2P dabd02a6 g1-1.9.0.de.brussels.ovh 443 ws2p"
],
...
"block": "895858-000000024B516CE641AB6BAEEF6E87F1E867BBF1133F3F77CD60648EE2266831",
curl -i https://g1-1.9.0.de.brussels.ovh/blockchain/current
>
...
"number": 895959,
nix run nixpkgs#websocat -- wss://g1-1.9.0.de.brussels.ovh/ws2p/
{"auth":"CONNECT","pub":"885mk73feWoX59VpBDDV5Msys7NVnAmkfyyCd5Y3u9CC","challenge":"dd9e53e7-b334-4ad3-8039-c366e26d31787b3650e3-7372-4a1d-81e0-1cd2bc409e39","sig":"MINcZCbrtmM9Uw23VVwdL3EvqVCM9XYSZ4bJFLV7a/YknYdLks2/IR8tXEpGEkuLQt012/FKmVHZla5WrkphAQ==","currency":"g1"}
gva:Query:
{currentBlock{number}}
Result:
{
"data": {
"currentBlock": {
"number": 895959
}
}
}
Si quelqu’un d’autre peut vérifier si cela semble correct; on peut voir pour utiliser la même image pour les autres noeuds v1.9.0 qui le souhaitent.
Je vais regarder pour faire un backup journalier de mon 2ème noeud en 1.9.0 également.
C’est pinidh/duniter-190:test. J’avoue que j’hésite à diffuser cette image très largement. À n’utiliser que si vous êtes en rade avec votre noeud 1.9.0.
J’ai aussi des snapshots quotidiens là : Private Seafile .
Je viens de créer un post qui liste les backups disponibles:
N’hésitez pas à adapter (c’est en mode wiki)
J’ai mis en anglais au cas ou d’autres personnes ont du mal en français.
Je viens de resynchroniser mon noeud, merci @Pini
Par contre je crois que j’ai provoqué un fork
Je voie mon noeud ainsi que les autres 1.9 espagnols au bloc 896002 alors que les 1.8 et le 1.9 de pini sont bloqués au 895998…
EDIT: fausse alerte c’est le temps de rafraichissement de g1specte qui m’a induit en erreur.
Je confirme, la configuration manuelle ws2pa été réinitilisée pour mon noeud 1.8.7 après son redémarrage (une fois tous les 2 jours).
Du coup le ws2p n’est pas vraiment disponible en public; mais on s’en contentera encore pendant 2 mois 
Le WS2P se configure dans le docker-compose :
DUNITER_WS2P_HOST: "0.0.0.0"
DUNITER_WS2P_PORT: '20901'
DUNITER_WS2P_PUBLIC: 'true'
DUNITER_WS2P_REMOTE_HOST: "duniter-18-dev.pini.fr"
DUNITER_WS2P_REMOTE_PORT: "443"
DUNITER_WS2P_REMOTE_PATH: "ws2p"
Oui, j’ai bien ces valeurs configurées; mais comme dis plus haut, c’est un soucis avec l’image 1.8.7-pini2 que j’utilise actuellement.
J’utilise la même image.
Que veux-tu dire par là ? Le port 20901 fait bien partie des ports exposés par l’image :
$ docker inspect pinidh/duniter:1.8.7-pini2 | jq -r '.[].Config.ExposedPorts'
{
"10901/tcp": {},
"20901/tcp": {},
"9220/tcp": {}
}