Non a partir de 1.9 on a décidé de ne faire que des images docker car beaucoup plus simple à déployer et à maintenir.
hm c’est que faisait cgeek à la base, mais là en observant l’arbre git ça ne me semble pas aussi évident:
Le dernier commit e6505694b88207523745f3dec764faa7296d307a de la branche release/1.9 est présent sur la branche dev.
Ca je sais bien, car on a tenu à jour la branche dev par rapport à 1.9.x, mais ça ne semble pas le cas de la branche 1.8.7
C’est simple, essai de merger release/1.8 sur dev, tu vas voir les conflits.
Benoît a créé des commits adaptés à la branche dev pour l’optimisation BMA. C’est pas exactement les mêmes que sur la v1.8.
Ok super, du coup peux-tu déployer une image docker 1.9.1? Auquel cas on pourrait permettre à Cesium de se servir des noeuds 1.9.1.
Si tu es certain de toi @Moul à ce sujet, on peut supprimer ma branche release/1.9.1 qui est une tentative de fusion de tout ce travail pour tout regrouper.
Mais je me demande si la dernière image docker 1.9 ne contient pas déjà les optimisation BMA.
Il faut vraiment continuer le versionnement de 1.9.x à chaque image docker déployé, pour s’y retrouver.
@Pini sais-tu pourquoi on ne trouve pas de docker-compose à la racine du dépôt duniter sur dev ?
J’ai déployé une v1.7.15 avec ces changements:
- Retrait des popup insupportables demandant notre avis si oui ou non on veut switcher sur un noeud duniter ou Cs+ fonctionnel. La réponse est oui, à coup sûr.
- Autorisation des noeuds 1.9.0
Le but étant simplement de tester voir ce qui coince.
Un premier constat est que hébergé en https, j’ai le même problème que vous au scan réseau.
Alors qu’en http simple, je n’ai pas le problème.
https: https://cesium-dev.axiom-team.fr
http: http://cesium-dev-http.axiom-team.fr
En localhost en mode dev, ça fonctionne aussi.
Est-ce que vous confirmez ce premier constat ?
Si oui, il se passe peut être le même problème en extension navigateur que derrière https.
On peut mettre de côté:
- Les problèmes de CORS: J’ai les mêmes errors en http et localhost, hors le scan réseau se passe bien tout de même
- Les erreurs timeout qui sont également là en http, ça devrait être des warning et non des erreurs.
- Le forcing https dans les filtres de la couche réseau, en le faisant sauter j’ai le même problème.
Vous pouvez comparer vos console JS entre http et https pour essayer de voir la différence de ce qu’il peut bien se passer, il s’agit de la même instance derrière donc seul le facteur ssl diffère.
4 Likes
Il est dans le sous-répertoire release/docker/.
1 Like
Salut la team !
Désolé je débarque… Je suis au courant du soucis depuis hier seulement. Avant j’étais entre la maternité et les couches des 2 plus grands 
Bref.
Du coup oui Césium v1.7 visait à régler les pb de performances que j’ai corrigé dans Duniter 1.8 (index BDD manquants, etc). Ce travail n’a pas été fait sur la 1.9 qui a mon sens n’a jamais passé tous les tests unitaires et n’était pas une version officielle. Elle pourrait l’être mais il faut un effort de développement pour cela et personne n’a voulu s’y coller. Il faudrait y reporter les ajouts d’index que j’ai fait en v1.8. Il faut aussi ajouter dans node/summary de l’API BMA la publication des features (notamment est-ce que le noeud index les TX ou non). Peut-être être que @tuxmain l’avais déjà reporté dans Duniter 1.9 je ne sais plus.
Si tout cela était fait, alors Césium pourrait utiliser sans doute des noeuds 1.9.
Rétrograder Césium en v1.6 va apporter d’autres problèmes, puisque la sélection automatique ne devait pas encore être en place (sauf erreur). Les utilisateurs risquent donc d’utiliser des noeuds désynchronisés… (Comme avant)
On peut a la rigueur réduire le nombre de nœuds minimal pour considérer qu’on a un consensus.
Une autre solution est de remettre en service des noeuds 1.8 … Mais vous y aviez déjà pensé.
1 Like
même cas que Francis.
Si quelqu’un a une solution, je me tiens prêt à lancer un noeud avec la version necessaire.
2 Likes
La branche release/1.9.1 contient un merge du travail apporté à 1.8.x vers 1.9.
Il ne reste qu’à faire tourner les tests, et corriger les quelques coquilles potentiels, mais je j’ai pas le temps de faire ça là. Il faut un environnement de dev adéquat pour faire tourner les tests.
1.9 est utilisé par pas mal de monde via G1nkgo donc ont peut le considéré comme aussi fiable que 1.8.x selon moi. Mais il faut effectivement faire tourner les tests et les adapter si besoin.
Regarde tes MP 
1 Like
en testant juste de rouvrir mon instance https je constate que le scan fonctionne là. Bizarre bizarre.
est-ce que d’autre peuvent confirmer que ça fonctionne ou non sur mon instance https ?
Si non, est-ce que ça fonctionne pour vous en http ?
Merci
1 Like
J’ai la 1.7.14 de césium sur mon Android, cela a l’air de fonctionner correctement aujourd’hui. Avant-hier ça ne marchait pas.
J’ai observé le “ça ne marche pas” à un moment où Kazou affichait ~6 noeuds (je n’ai pas fait attention aux versions). Là il est à ~10 noeuds, certains ont été remis en place. Sans doute qu’au moins 1 noeud a une configuration qui permet à Cesium de l’utiliser.
Voici les noeuds qu’affiche Kazou :
| noeud | bloc | API | version | membre |
|---|---|---|---|---|
| g1.duniter.org:443 | 777707 | BMAS | 7752 | 1.8.7 |
| g1.nuaje.fr:443 | 777707 | BMAS | 8443 | 1.8.7 |
| duniter-v1-g1.axiom-team.fr:443 | 777707 | BMAS | 8480 | 1.8.7 |
| g1.copylaradio.com:443 | 777707 | BMAS | 8466 | 1.9.0 |
| g1.asycn.io:443 | 777707 | BMAS | 8584 | 1.9.0 |
| duniter-v1.comunes.net:443 | 777707 | BMAS | 8631 | 1.9.0 |
| duniter971.dns1.us:443 | 777707 | BMAS | 8998 | 1.8.7 |
| dharma.ynh.fr:443/bma | 777706 | BMAS | 8501 | 1.8.7 |
| duniter.econolib.re:443 | 777706 | BMAS | 13757 | 1.8.7 |
| duniter-18-dev.pini.fr:443 | 777706 | BMAS | 16309 | 1.8.7 |
| g1.cuates.net:443 | 753499 | BMAS | 8482 | 1.9.0 |
Plus qu’à trouver :
- quel noeud
- quelle config
- comment refaire une synchro (ça fait deux jours que je tente
)
3 Likes
J’ai pu aller au bout de la synchronisation avec la v1.9 sur la branche dev.
Par contre, la barre de progression n’avance pas (il me semble me rappeler avoir vu ça sur le forum) et il n’y a pas de logs. J’ai donc monitoré le dossier de config avec la commande du jusqu’à atteindre 1.6 Go et en monitorant le processus. Je met ce projet de côté, car ça semble être résolut pour le moment.
J’ai remis en place mon nœud sur YunoHost en place. J’ai copié les données de mon nœud synchronisé. Par contre, le paquet YunoHost est encore devenu quasiment inopérant suite à des changements de l’équipe packaging YunoHost 
Je vous donnerais plus de détails sur ce post Paquet YunoHost de Duniter v1 - #3 by Moul lorsque j’aurai stabilisé les changements.
5 Likes
je suis d’accord. Je m’y connais un peu en réseau, en administration serveur, mais là ça devient plus compliqué que mes compétences actuelles. Il y a quelques années avec le paquet yunohost la synchro était un peu lente, mais ça aboutissait, là c’est plus problématique. Si ça pouvait au moins reprendre là où ça s’est arrêté, ça serait un moindre mal, mais là ça retélécharge tout depuis le début à chaque fois. (ça avait été déjà évoqué ici, bon on ne peut rien y faire dans la version actuelle et substrat devrait corriger ça).
J’ai relancé la synchro de mon côté avec la dernière version du paquet duniter de yunohost, j’ai mis ça sur un serveur un peu plus puissant, et si ça bloque je referai la démarche expliquée ici, en augmentant la swap : Problème synchro "broken pipe" - #3 by farvardin
Bonjour,
Un message d’erreur apparaît quand je souhaite afficher mes portefeuilles. Je viens de désinstaller la version 1.7.9 et de réinstaller la version 1.7.13. Le problème existait avec la version 1.7.9. J’ai été éjecté par le Death Reaper car j’ai « oublié » de renouveler mon adhésion. Depuis je l’ai renouvelée. Cette erreur m’empêche d’accéder à de nombreuses fonctionnalités dont la certification. Comment puis-je remédier à cela ? Bien à vous
Bonjour Philippe,
Le sujet a été discuté dans ce fil, dans lequel j’ai déplacé ton message.
Si ça ne fonctionne pas avec Cesium v1.7.x, tu peux utiliser la v1.6.x.
Autrement, pour que ça soit résolut pour tous le monde, il faut corriger Cesium v1.7.x et/ou que plus d’API BMA soient disponibles sur le réseau. À bon entendeur !
2 Likes
J’ai pas tout compris Moul, loin s’en faut, mais merci.
Je viens de tomber sur ce post à l’instant.
J’ai mon serveur (ARM64) g1.brussels.ovh en 1.8.7
J’utilise actuellement l’image de @Pini disponible pour ARM64 : pinidh/duniter:1.8.7
Si quelqu’un arrive à faire une image 1.9.1 (ou 1.9.0 “stable”) pour ARM64, je pourrai regarder pour tenter une mise à jour si ça peut aider à améliorer la situation.