Merci elois, et merci d’avoir corrigé si vite — j’ai vu le commit sur main
(fix(deploy): make the sink token readable by Duniter). Recopier le jeton dans un volume d’exécution et l’attribuer à l’utilisateur de l’image est plus propre que mon chown : ça laisse le secret source intact. J’ai vu aussi que tu avais documenté DUNIPOD_CONTAINER_PROXY_CIDR pour un proxy sur une autre machine, merci.
Le pod tourne : https://dunipod.gtest.bulma.sleoconnect.fr/v1/graphql (ĞTest, profil regular, projectionStatus: complete, 17 436 identités, 11 pairs). Il est passé en v0.12.0 : la montée s’est faite sans accroc et sans resynchronisation, données et identité conservées.
En finissant l’installation, j’ai rencontré deux autres défauts, de la même famille que le jeton :
tous deux n’apparaissent que si l’on s’écarte des valeurs par défaut là où la doc invite pourtant à le faire, et aucun des deux ne nomme sa cause dans le message d’erreur. Les deux sont encore présents dans v0.12.0 et dans main (vérifié dans le code, pas seulement à l’exécution).
1. Le dossier des règles off-chain, quand les données sont bind-montées
docker logs dunipod-stage-offchain-rules-1
→ mkdir: cannot create directory '/bundles/releases': Permission denied
Le job stage-offchain-rules hérite de x-rules-job : user: "0:0" mais cap_drop: ALL. Sans CAP_DAC_OVERRIDE, root ne contourne plus les permissions : il se comporte comme un utilisateur ordinaire. Avec le volume Docker par défaut, celui-ci est créé root:root et tout va bien. Mais en suivant le README (« Data belongs on a separate mounted disk → set the relevant
DUNIPOD_*_DATA_SOURCE to absolute paths »), on crée ce dossier soi-même, typiquement au nom de l’utilisateur d’administration — et le job ne peut plus rien y écrire.
Contournement : sudo chown 0:0 <DUNIPOD_RULES_DATA_SOURCE>.
v0.12.0 ajoute justement des jobs de préparation qui font le chown pour les dossiers offchain et p2p — mais pas pour rules. Un job équivalent, ou une ligne dans le README sur les propriétaires attendus par service, réglerait le cas.
2. check_graphql interroge 127.0.0.1, quel que soit DUNIPOD_PUBLIC_BIND
deploy/dunipodctl (fonction check_graphql) fait :
url="http://127.0.0.1:$DUNIPOD_GRAPHQL_PORT/v1/graphql"
alors que compose.yml publie le service sur ${DUNIPOD_PUBLIC_BIND}. Or le guide demande de définir cette adresse quand le reverse-proxy est sur une autre machine — c’est mon cas (NPM sur une autre machine du LAN). Avec DUNIPOD_PUBLIC_BIND=192.168.1.111, GraphQL n’écoute que sur cette adresse : l’installateur ne peut plus joindre son propre service.
Conséquence : install a tourné pendant tout DUNIPOD_CONVERGENCE_TIMEOUT_SECONDS (2 h par défaut), puis a échoué sur GraphQL did not accept a business query — alors que la requête réussissait parfaitement au même instant sur http://192.168.1.111:8081/v1/graphql. Rien dans le message ne dit
quelle adresse a été testée, et la convergence, elle, était atteinte : j’ai rejoué ta requête SQL
offchain_final_convergence_state, qui donnait live|boundary|caught_up = t|t|t, pending_jobs = 0, lagEvents = 0 (seule la publication restait en p2p_bootstrapping, normal puisque P2P démarre en phase 4).
Contournement : DUNIPOD_PUBLIC_BIND=0.0.0.0, qui couvre la boucle locale et le LAN. À noter que upgrade et status utilisent la même vérification : le contournement doit rester en place.
Piste de correction : viser le bind configuré lorsqu’il est défini (en gardant 127.0.0.1 quand il vaut 127.0.0.1 ou 0.0.0.0), ou au minimum citer l’URL testée dans le message d’échec — ça aurait transformé deux heures d’attente en trente secondes de diagnostic.
Proposition
Je veux bien ouvrir une MR pour l’un ou l’autre, ou les deux — dis-moi ce qui t’arrange, et sous quelle forme (correction du compose et du contrôleur, ou documentation). Sinon je laisse simplement le signalement ici, c’est très bien aussi.
