Mais c’est pas disponible dans l’extension Firefox ça, si ? Je ne trouve pas. Ça doit être dans l’appli Altair Graphql que je n’ai pas installée. C’est ça ?
EDIT: Ah ça y est en retournant une nième fois dans les paramètres du plugin Firefox je trouve enfin l’option pour ajouter des plugins dans le plugin. Ça m’avait échappé jusque là. ¯_(ツ)_/¯
Oui l’UX de ce plugin est désastreuse, mais il est pratique et on va être amené à manipuler du graphql de plus en plus 
En soit j’aurais aussi pu te dire de simplement utiliser curl pour faire exactement la même chose:
curl -s 'https://wotwizard.pini.fr/graphql' \
-H 'Content-Type: application/json' \
--data-binary '{"query":"query IntrospectionQuery {__schema {queryType {fields {name description}}}}"}' \
| jq -r '.data.__schema.queryType.fields[] | "Query: \(.name)\n\(.description)\n"'
@Pini j’ai une problème de CORS avec ton endpoint:
Access to fetch at 'https://wotwizard.pini.fr/' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
Il faut que tu rajoutes ça dans ta conf nginx, comme indiqué plus haut:
Je viens de mettre cette conf en place. Dis moi si ça a bien l’effet escompté.
pas tout à fait. Maintenant ça mouline, mais finit en timeout avec la même erreur:
Access to fetch at 'https://wotwizard.pini.fr/' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
Compare avec ma conf nginx plus haut, ça vient forcément d’une différence à ce niveau là.
L’effet escompté, c’est que cette erreur n’intervienne plus sur ton endpoint en prod: https://wotwizard.axiom-team.fr
Je n’ai pas assez d’info. Comment précisément je reproduis cette erreur ?
sur wotwizard-ui, le lien que je viens de te donner, tu sélectionnes ton noeud en regardant la console JS.
Seul le noeud axiom-team fonctionne correctement actuellement.
J’ai un doute. Dans ta conf nginx tu définis upstream sur le port 10050. Alors que j’ai 8080 pour ma conf. C’est parce que tu as bindé le port 8080 du service vers 10050 de l’hôte, ou bien j’ai loupé autre chose ?
Non c’est bien ma config particulière, il s’agit du port 8080 par default.
En rechargeant la page plusieurs fois, il y a un coup où ton noeud à réussi à charger et sortir le bon tableau, mais après un long moment, probablement juste avant le timeout.
Mais les fois suivantes retour en timeout.
Etrange.
Bon après te prends pas trop la tête non plus c’est pas urgent, si ça se trouve c’est du cache de je ne sais où, car je n’arrive pas à expliquer le pbm autrement … on verra plus tard ^^
sinon essai ça:
add_header 'Access-Control-Allow-Origin' '*' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization' always;
Je ne pense pas que ce soit un problème de permissions, mais effectivement un problème de timeout. Mes serveurs sont pauvres en ressources, et la requête met peut-être juste trop de temps à être traitée. Car en essayant plusieurs fois, comme toi j’ai fini par avoir une réponse correcte.
Sais-tu comment ce timeout pourrait être configuré ?
La seule différence de header que je vois entre nos conf est le keepalive:
$ curl -i -X POST -H "Origin: http://exemple.com" -H "Content-Type: application/json" -d '{"test":"data"}' https://gql.wotwizard.axiom-team.fr
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 01 Apr 2024 10:28:43 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 34
Connection: keep-alive
Strict-Transport-Security: max-age=15768000
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Content-Type
{
"errors":
"No query string"
}%
$ curl -i -X POST -H "Origin: http://exemple.com" -H "Content-Type: application/json" -d '{"test":"data"}' https://wotwizard.pini.fr
HTTP/2 200
server: nginx/1.25.4
date: Mon, 01 Apr 2024 10:28:45 GMT
content-type: text/plain; charset=utf-8
content-length: 34
strict-transport-security: max-age=31536000
access-control-allow-origin: *
access-control-allow-headers: Content-Type
{
"errors":
"No query string"
}%
Donc essai de rajouter ça à ton conf nginx:
keepalive_timeout 65;
J’ai ajouté :
proxy_read_timeout 180s;
et ça semble suffire pour que la requête passe à tous les coups.
On dirait bien
C’est là qu’on se rends compte que wotwizard est assez gourmand.
Bonjour,
Depuis quelques jours mon instance wotwizard n’arrête pas de planter. Et comme ça fait systématiquement redémarrer le conteneur, avec une charge induite non négligable sur mon petit serveur, je l’ai désactivé.
Y a-t-il un problème connu ?
Voici un exemple de logs :
2024/07/04 11:38:01 blockchain.go:3244: Starting
2024/07/04 11:38:01 blockchain.go:3245:
2024/07/04 11:38:01 blockchain.go:3090: Making a copy of "DBase.data"
2024/07/04 11:38:12 blockchain.go:3101: Copy made
2024/07/04 11:38:12 misc.go:233: *** ERROR ***
2024/07/04 11:38:12 misc.go:245: 116
2024/07/04 11:38:20 blockchain.go:3117: Adding Centralities to updateList
2024/07/04 11:38:20 run.go:53: WotWizard Server version 5.11.3 Tools version 1.0.8
2024/07/04 11:38:20 blockchain.go:3117: Adding Blockchain to updateList
2024/07/04 11:38:20 blockchain.go:3244: Starting
2024/07/04 11:38:20 blockchain.go:3245:
2024/07/04 11:38:21 blockchain.go:3090: Making a copy of "DBase.data"
panic: 116
goroutine 6 [running]:
git.duniter.org/gerard94/util/misc.haltCommon({0xc00005dc28, 0x1, 0xc00005dc38?})
/go/pkg/mod/git.duniter.org/gerard94/util@v1.0.8/misc/misc.go:250 +0x465
git.duniter.org/gerard94/util/misc.Assert(...)
/go/pkg/mod/git.duniter.org/gerard94/util@v1.0.8/misc/misc.go:260
git.duniter.org/gerard94/util/bTree.(*info).Read(0xc000134270, 0xc000306960)
/go/pkg/mod/git.duniter.org/gerard94/util@v1.0.8/bTree/bTree.go:1971 +0x5c
git.duniter.org/gerard94/util/bTree.(*Database).readPageA(0xc0000c85a0, 0x87, {0x9a6ac0, 0xcaf1e0})
/go/pkg/mod/git.duniter.org/gerard94/util@v1.0.8/bTree/bTree.go:1813 +0x10f
git.duniter.org/gerard94/util/bTree.(*Database).pageManager(0xc0000c85a0, 0xc000108120, 0xc000108180, 0xc0001081e0, 0xc000108240, 0xc0001082a0, 0xc000108300, 0xc000108360, 0xc0001083c0, 0xc000108420, ...)
/go/pkg/mod/git.duniter.org/gerard94/util@v1.0.8/bTree/bTree.go:1018 +0x50d
created by git.duniter.org/gerard94/util/bTree.(*Factory).OpenBase in goroutine 1
/go/pkg/mod/git.duniter.org/gerard94/util@v1.0.8/bTree/bTree.go:1340 +0xe6d
2024/07/04 11:38:20 blockchain.go:3117: Adding Centralities to updateList
2024/07/04 11:38:20 run.go:53: WotWizard Server version 5.11.3 Tools version 1.0.8
2024/07/04 11:38:20 blockchain.go:3117: Adding Blockchain to updateList
2024/07/04 11:38:20 blockchain.go:3244: Starting
2024/07/04 11:38:20 blockchain.go:3245:
2024/07/04 11:38:21 blockchain.go:3090: Making a copy of "DBase.data"
2024/07/04 11:38:38 blockchain.go:3101: Copy made
2024/07/04 11:38:38 misc.go:233: *** ERROR ***
2024/07/04 11:38:38 misc.go:245: 116
2024/07/04 11:38:45 blockchain.go:3117: Adding Centralities to updateList
2024/07/04 11:38:45 run.go:53: WotWizard Server version 5.11.3 Tools version 1.0.8
2024/07/04 11:38:45 blockchain.go:3117: Adding Blockchain to updateList
2024/07/04 11:38:45 blockchain.go:3244: Starting
Apparemment il n’y a plus aucun nœud Wotwizard-ui qui tourne 
l’option --no-interactive n’existe plus sur duniter ? Pourquoi ?
axiom@duniter-v1-data:~$ NODE_OPTIONS=--max-old-space-size=10192 duniter sync --no-interactive g1v1.p2p.legal:443 && duniter start
error: unknown option `--no-interactive'
Pas facile à scripter du coup.
“J’ai” recréé un script bash pour autoresync si le noeud duniter est désynchro, il tourne:
#!/bin/bash
# Définir les chemins pour les fichiers de verrouillage
LOCKFILE="/tmp/checkDuniter.lock"
# Définir l'URL du noeud distant
REMOTE_NODE="http://g1.duniter.org"
# Fonction pour créer un verrou
create_lock() {
if [ -e "$LOCKFILE" ]; then
echo "Script is already running."
exit 1
else
touch "$LOCKFILE"
fi
}
# Fonction pour supprimer le verrou
remove_lock() {
rm -f "$LOCKFILE"
}
# Assurer que le verrou est supprimé en cas de sortie du script
trap remove_lock EXIT
# Créer un verrou
create_lock
# Vérifier si le processus duniter est actif
isAlive=$(ps -aux | grep duniter | grep -v grep | grep -v checkDuniter | grep -v wotwizard)
# Si duniter n'est pas actif, le démarrer
if [[ $isAlive == '' ]]; then
duniter start
sleep 3
fi
# Obtenir le numéro de bloc local
local_block=$(curl -s http://localhost:10020/blockchain/current | jq .number)
# Obtenir le numéro de bloc distant
remote_block=$(curl -s ${REMOTE_NODE}/blockchain/current | jq .number)
# Calculer la différence de blocs
block_diff=$((remote_block - local_block))
# Vérifier si la différence de blocs est supérieure à 20
if [ $block_diff -gt 20 ]; then
echo "Local node is more than 20 blocks behind. Stopping and resyncing..."
# Arrêter le noeud
/usr/bin/duniter stop
# Attendre 2 secondes pour s'assurer que tous les processus duniter se terminent
sleep 2
# Tuer tous les processus duniter restants
pkill -f duniter
# Vérifier si tous les processus duniter ont été terminés
if pgrep -f duniter > /dev/null; then
echo "Failed to stop all duniter processes. Exiting..."
exit 1
fi
# Supprimer les données du noeud local
rm -rf ~/.config/duniter/duniter_default/data/*
# Synchroniser le noeud
NODE_OPTIONS=--max-old-space-size=10192 duniter sync g1.duniter.org:443
# Redémarrer le noeud
duniter start
sleep 3
fi
# Supprimer le verrou
remove_lock
Ce sont des choses qui arrivent, faut demander aux futures mainteneurs de la g1v1 de s’occuper de ça.
l’ essentiel des “anciens services” passent par tor et ne sont donc pas voués à d’ autres perspectives que le maintient en cas d’ imprevus tel que stipulé dès le début malgrè les incompréhensions ( Maintient G1v1 )
Grâce au fait que mon service n’est pas derrière tor (malgrè les incompréhensions), wotwizard axiom est de nouveau en ligne.
Mon script de resync duniter v1 auto fonctionne (ajusté) :
#!/bin/bash
log() {
local message="$1"
echo "$(date +"%Y-%m-%d %H:%M:%S") - $message"
}
# Définir les chemins pour les fichiers de verrouillage
LOCKFILE="/tmp/checkDuniter.lock"
# Définir l'URL du noeud distant
REMOTE_NODE="http://g1.duniter.org"
# Fonction pour créer un verrou
create_lock() {
if [ -e "$LOCKFILE" ]; then
echo "Script is already running."
exit 1
else
log "lock" > "$LOCKFILE"
fi
}
# Fonction pour supprimer le verrou
remove_lock() {
rm -f "$LOCKFILE"
}
# Créer un verrou
create_lock
# Assurer que le verrou est supprimé en cas de sortie du script
trap remove_lock EXIT
# Vérifier si le processus duniter est actif
isAlive=$(ps -aux | grep duniter | grep -v grep | grep -v checkDuniter | grep -v wotwizard)
# Si duniter n'est pas actif, le démarrer
if [[ $isAlive == '' ]]; then
duniter start
sleep 5
fi
# Obtenir le numéro de bloc local
local_block=$(curl -s http://localhost:10020/blockchain/current | jq .number)
# Obtenir le numéro de bloc distant
remote_block=$(curl -s ${REMOTE_NODE}/blockchain/current | jq .number)
# Calculer la différence de blocs
block_diff=$((remote_block - local_block))
# Vérifier si la différence de blocs est supérieure à 20
if [ $block_diff -gt 20 ]; then
log "Local node is more than 20 blocks behind. Stopping and resyncing..."
# Arrêter le noeud
/usr/bin/duniter stop
# Attendre 2 secondes pour s'assurer que tous les processus duniter se terminent
sleep 2
# Tuer tous les processus duniter restants
pkill -f duniter
# Vérifier si tous les processus duniter ont été terminés
if pgrep -f duniter > /dev/null; then
log "Failed to stop all duniter processes. Exiting..."
exit 1
fi
# Supprimer les données du noeud local
rm -rf ~/.config/duniter/duniter_default/data/*
# Synchroniser le noeud
NODE_OPTIONS=--max-old-space-size=10192 duniter sync g1.duniter.org:443
# Redémarrer le noeud
duniter start
sleep 3
fi
# Supprimer le verrou
remove_lock
très bien donc inutile de faire appel à nous pour le maintient des services utilisateurs et de s’ esclaffer lorsque ce service n’ est pas rendu car ce n’ est pas un fork mais un maintient de developpement avec relais d’ ondes radio en cas d’ imprévu
edit ğchange