Excellent !!
Merci @aya. J’ai pu tester ton conteneur et me rendre compte que j’avais le même problème GVA qu’avec le mien. Ce qui m’a permis de débusquer une erreur grossière dans mon vhost nginx. Je faisais le proxypass vers mon instance g1-test au lieu de mon instance mirroir de la ǧ1. La magie des copier-coller…
Bref, mon noeud duniter.pini.fr est maintenant OK côté gva/playground.
Est-ce que tu tu souviens comment paramétrer les IPs whitelists GVA ?
J’en ai absolument besoin pour refaire fonctionner g1-stats
Il faudrait ajouter cette IP en whitelist à vos conf: 163.172.67.95
Ça me rappelle cette conversation.
Voici comment c’est géré pour BMA :
// Override BMA DDOS configuration from environment variables
if (process.env.DUNITER_BMA_WHITELIST) {
ddosConf.whitelist = process.env.DUNITER_BMA_WHITELIST.split(",");
}
Ça pourrait être aussi simple pour GVA, mais je n’ai pas trouvé dans le code où était initialisée cette whitelist.
tout ce que ca me rappelle c’est 2 jours de galère à démarrer GVA à cause de cette variable d’environnement
bien vu @pini une simple liste d’adresses IP séparées par des virgules ca fonctionne…
DUNITER_GVA_WHITELIST=163.172.67.95,127.0.0.1,::1
Pour info j’ai enfin trouvé où ces variables d’environnement sont gérées. C’est dans le projet duniter-core, fichier conf/src/lib.rs, fonction load_module_conf().
Voici l’arrivé d’un nouveau noeud duniter 1.9-GVA: https://g1v1.p2p.legal/gva/playground
Il sert notamment à fournir les données pour g1-stats.
Voici son docker-compose:
version: '3.6'
services:
duniter:
environment:
- DEBUG_ENTRYPOINT=${DUNITER_DEBUG_ENTRYPOINT:-${DEBUG_ENTRYPOINT:-${DEBUG:-}}}
- DUNITER_AUTO_SYNC=${DUNITER_AUTO_SYNC:-true}
- DUNITER_BMA_ENABLED=${DUNITER_BMA_ENABLED:-true}
- DUNITER_BMA_IP4=${DUNITER_BMA_IP4:-0.0.0.0}
- DUNITER_BMA_REMOTE_HOST=${DUNITER_BMA_REMOTE_HOST:-duniter.localhost}
- DUNITER_BMA_REMOTE_PORT=${DUNITER_BMA_REMOTE:-443}
- DUNITER_GVA_ENABLED=${DUNITER_GVA_ENABLED:-true}
- DUNITER_GVA_PATH=${DUNITER_GVA_PATH:-gva}
- DUNITER_GVA_PORT=${DUNITER_GVA_PORT:-30901}
- DUNITER_GVA_REMOTE_HOST=${DUNITER_GVA_REMOTE_HOST:-duniter.localhost}
- DUNITER_GVA_REMOTE_PATH=${DUNITER_GVA_REMOTE_PATH:-gva}
- DUNITER_GVA_REMOTE_PORT=${DUNITER_GVA_REMOTE_PORT:-443}
- DUNITER_GVA_REMOTE_TLS=${DUNITER_GVA_REMOTE_TLS:-false}
- DUNITER_GVA_WHITELIST=${DUNITER_GVA_WHITELIST:-127.0.0.1,::1,192.168.9.67}
- DUNITER_MANUAL_CONFIG=${DUNITER_MANUAL_CONFIG:-false}
- DUNITER_POW_PREFIX=${DUNITER_POW_PREFIX:-}
- DUNITER_POW_CPU=${DUNITER_POW_CPU:-0.8}
- DUNITER_POW_NBCORES=${DUNITER_POW_NBCORES:-1}
- DUNITER_START_OPTS=${DUNITER_START_OPTS:-direct_webstart}
- DUNITER_SYNC_HOST=${DUNITER_SYNC_HOST:-g1.duniter.org:443}
- DUNITER_SYNC_OPTS=${DUNITER_SYNC_OPTS:-}
- DUNITER_WS2P_HOST=${DUNITER_WS2P_HOST:-0.0.0.0}
- DUNITER_WS2P_PORT=${DUNITER_W2SP_PORT:-20901}
- DUNITER_WS2P_PUBLIC=${DUNITER_W2SP_PUBLIC:-true}
- DUNITER_WS2P_REMOTE_HOST=${DUNITER_WS2P_REMOTE_HOST:-duniter.localhost}
- DUNITER_WS2P_REMOTE_PATH=${DUNITER_WS2P_REMOTE_PATH:-ws2p}
- DUNITER_WS2P_REMOTE_PORT=${DUNITER_WS2P_REMOTE_PORT:-443}
image: duniter/duniter:dev
networks:
- private
ports:
- 0.0.0.0:10901:10901
- 0.0.0.0:20901:20901
- 0.0.0.0:30901:30901
- 0.0.0.0:9220:9220
restart: unless-stopped
volumes:
- data:/var/lib/duniter
- etc:/etc/duniter
networks:
private:
name: ${DOCKER_NETWORK_PRIVATE:-duniter}
public:
name: ${DOCKER_NETWORK_PUBLIC:-host}
volumes:
data:
etc:
encore merci à @Pini et @aya pour leur travail sur la dockerisation de Duniter 1.9 !
Salut à tous,
est-ce possible d’avoir cette version dans un livrable comme auparavant ? (ex ici)
Cette version est-elle bien taguée ?
Non, justement. La question à se poser est donc : prévoit-on de faire une release officielle de la 1.9.0, et si oui, peut-on tagguer en l’état la branche dev ou a-t-on des modifs à intégrer impérativement au préalable ?
Pour ma part j’aimerais qu’on puisse merger !417 et !419 avant de taguer.