Il y a eu pas mal de chamboulements du côté du paquet YunoHost de Duniter.
Les mainteneurs des apps YunoHost ont fusionné un refactoring que je n’ai pas vu passé, car ma configuration M$ GH faisait que je ne recevais pas de mail.
Il y a eu quatre choses qui n’ont pas été gérés dans cette migration :
- arrêt du support ARM
- déplacement du dossier des données Duniter pas géré lors de la migration
- la webadmin n’est plus protégée à l’utilisateur admin choisit, mais est accessible à tout Internet
- l’accès BMA a été cassé
- gestion correcte du fait de faire tourner Duniter avec l’utilisateur Unix
duniter
Cependant, ils ont apporté de nouvelles choses intéressantes :
- utilisation des derniers standards de packaging YunoHost (helpers)
- Gestion de la sauvegarde et de la restauration (pas testé)
- Gestion du déplacement de l’app sur un autre chemin (
$domain.tld/$path) (pas testé) - Duniter ne tourne plus avec l’utilisateur
root(grosse faille de sécurité)
- Passe les tests de la CI
- Niveau 7 / statut maintenu
- De nouveau listé dans les paquets YunoHost
Vous comprendrez que je n’ai pas crié ces informations sur tous les toits le temps que j’arrive à mettre de l’ordre dans toutes ces choses.
Cette première section était pour vous tenir au courant. La section qui suit est pour vous demander de l’aide et votre avis sur certains points très précis.
Il y a une série de tests qui tourne dans la CI de YunoHost-Apps. Elle vérifie, entre autres, à différentes étapes, si le chemin principal / est accessible. Pour le contexte, actuellement BMA est accessible sur /, la webadmin sur /webui et W2SP sur /ws2p tout sur le port 443 du même nom de domaine exclusif à Duniter.
Le problème est que BMA retourne une erreur HTTP 502 sur un nœud non synchronisé, du coup elle ne passe pas les tests. Pensez-vous qu’il y ait une possibilité pour que BMA retourne quelque chose sans avoir à faire une synchronisation (post-étape laissée à l’admin) ?
La solution qui m’est venue à l’esprit pour contourner cette vérification est de déplacer BMA sur /bma et l’admin sur /. Cette solution pose entre-autres d’autres problèmes :
Je n’ai pas réussi à lancer une synchronisation sur un nœud avec BMA sur un chemin /bma. Est-ce géré par Duniter ? Si non, ça vous parait acceptable que les instances YunoHost ne permettent pas de se synchroniser dessus ? Pas sûr si ce sera géré par Duniter v1 qui est en maintenance d’ici la migration définitive à Duniter v2.
Je n’ai pas réussi à spécifier l’endpoint BMAS avec un chemin. BMA est déjà exposé sur le port 443, ceci fait que Duniter génère un endpoint BMAS. Du coup je n’arrive pas à spécifier un endpoint BMAS contenant un chemin avec la commande : `duniter config --addep « BMAS $domain 443 /$bma ». Une idée sur ce point ? Est-ce que ça vous semble acceptable si ça n’est pas correctement défini ? Je dirais qu’un endpoint WS2P correctement défini est plus important pour le réseau inter-nœuds. Si un endpoint BMA n’est pas correctement défini ça empêche uniquement sa découverte. Êtes-vous de mon avis ?
Autrement, les clients Césium et Silkaj gèrent la connexion BMA avec les nœuds ayant un chemin. Par exemple, pour tester : https://monit.g1.nordstrom.duniter.org/bma/