(meeting mumble)
CR du précédent meeting : Meeting Brique Internet mai 2018
Présents :
Proposition de pitchum : concevoir une plaquette synthétique à distribuer lors d'événements libristes et également au moment où on livre un brique à un nouvel utilisateur.
Sur la forme, on pourrait s’inspirer du triptyque des chatons.
Problème concret rencontré par franciliens.net sur des stands : lorsqu'on parle des FAI associatifs, de neutralité du Net et de la brique on finit toujours par parler de yunohost. On est obligé d'épeler le nom à chaque fois car l'orthographe n'est pas forcément intuitive et ce nom n'est même pas mentionné sur notre brochure. Les personnes que ça intéresse sont obligées de noter ce nom par elles-même. Ce serait cool d'avoir une mini-brochure synthétique dédiée à la brique qu'on pourrait distribuer en plus de nos brochures de FAI associatif.
Autre problème concret : après avoir reçu leur brique et être rentrés chez eux, la plupart des utilisateurs ont du mal à se souvenir où aller pour obtenir de l'aide (forum yunohost, ML du FAI, ML labrique, IRC, …). Il faut dire que lors des install-parties on a tendance à les noyer sous une masse d'informations difficile à digérer.
Objectifs du vade-mecum :
On recherche quelqu’un qui pourrait réaliser ce tryptique
Du 7 au 12 juillet à Strasbourg Stand de 12h à 18h
Quelqu’un pense-t-il pouvoir y aller ? Pour l’instant pas beaucoup de personnes ont prévu d’y aller, peut-être ljf.
ljf propose de présenter le sujet suivant : comment faire de la brique dans votre asso ?
→ https://dev.yunohost.org/projects/la-brique-internet/issues
Le projet yunohost a déjà migré de redmine vers github (avec en tête l’idée de migrer vers framagit dès que possible). Ce serait bien que les projets labrique suivent la même voie.
À l’unanimité des personnes présentes les projets brique vont effectivement être migrés sur github.
Aleks a écrit un script pour la migration des projets yunohost. Tharyrok se propose de reprendre ce script et l'adapter pour les besoins des projets de la brique (75 tickets à migrer). Pour la brique chaque projet aura ses propres tickets (contrairement à ce qui a été fait pour yunohost : tous les tickets dans un méta-projet)
Pré-requis à cette migration :
⇒ oui, utilisé pour les notifications de builds et commits
Presque personne ne connaissait ce channel, maintenant y a du monde dessus :)
* Le passage en stable de la migration + yunohost 3.0 est prévu pour le ~15 juin * Port pour l'envoi de mail qui a changé (le port 465 est déprécié et n'est plus supporté, il faut désormais utiliser le port 587)
* retour utilisateur : j'ai du redémarer php-fpm après vpnclient * Workflow recommandé pour les utilisateurs finaux (quand ce sera release)
TODO : faire une page sur le wiki sur comment faire des backups +1 (et la mettre en lien depuis le disclaimer de la migration)
https://github.com/YunoHost/yunohost/pull/488
C'est un proof of concept montrant comment faire des panneaux de configuration pour les Apps. Un fichier JSON + un script bash, pas besoin de coder du PHP et ça donnerait une bonne intégration dans l’UI yunohost. Ces panneaux de configuration seraient alors disponible dans l’interface d’admin et non pas l’interface utilisateur comme c’est le cas aujourd’hui (pour les apps de labrique en tout cas).
TODO : à terme il faudrait que les applis vpnclient et hotspot utilisent ce nouveau mécanisme.
* passage de l'app de vpnclient en notworking ( https://dev.yunohost.org/issues/1129 ) ⇒ c'est pas la bonne version qui est testé (buildé) !
Workflow recommandé pour les développeurs d’apps : bosser dans une branche testing et réserver la branche master pour la plublication officielle. Et plutôt que de renseigner et tenir à jour le hash d’un commit dans le fichier applist.json (ce que les mainteneurs d'apps ne font pas en pratique) il vaut mieux marquer HEAD comme révision.
Pour info, les tests automatisés (intégration continue du dashboard) testent systématiquement HEAD. https://dash.yunohost.org/appci/branch/stretch Demander à Maniack un accès SSH (par clef) sur le CI de dev : https://forum.yunohost.org/t/proposition-for-a-new-non-official-ci/3595/6?u=aleks
pitchum se propose de contribuer dans yunohost sur le mécanisme d’autoconfig pour thunderbird cf. https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration
Y a des PR urgentes à prendre en compte. Notamment : https://github.com/labriqueinternet/vpnclient_ynh/pull/38/files
pitchum se charge cette semaine de faire le nécessaire pour que ces PR urgentes soient disponibles pour les utilisateurs de brique.
https://github.com/labriqueinternet/labriqueinter.net/blob/master/apps/labriqueinternet.list
Pour le moment il n'y a toujours pas de nouvelles images disponibles. Les images actuellement en ligne ne sont pas fonctionnelles pour une installation fraiche, à moins d'utiliser le contournement de la PR 51.
keoma bosse sur ce sujet et a désormais accès au container dédié à jenkins. Il aurait un soucis concernant LDAP. Affaire à suivre…
Le 31/05/18 à 10:12, keoma a écrit :
Yop,
Je bosse sur un fork du repo de build pour construire les images avec la
postinstall deja installée : https://github.com/keomabrun/build.labriqueinter.net
Pour l'instant ça bloque avec une erreur LDAP. Si tu as le temps de
tester ça et de comprendre ce qui foire c'est chouette.
Il faut peut être start slapd avant de faire la postinstall ? ⇒ transmettre la suggestion à keoma
keoma bosse déjà dessus.
Le principe c’est d’installer un yunohost avec un domaine bidon et un user bidon pré-configurés, puis un script de post-install spécifique. Pour cela, il s'agirait de produire une image avec postinstall yunohost et les apps de labrique déjà installées. La customisation se ferait alors depuis l'interface yunohost (UI admin ou UI utilisateur ?) à partir d'un hypercube qui serait alors utilisé pour modifier le domaine bidon, l'utilisateur bidon.
Description faite par keoma dans un mail :
La procédure idéale à mes yeux:
- Alice a commandé une brique et vient à l'install-party
- On arrive avec une Brique pré-installée
- Alice crée un fichier hypercube via l'interface existante
install.labriqueinter.net
- On branche la Brique au réseau LAN et on donne l'IP à Alice
- Alice se connecte à l'interface web de sa Brique et y fourni son
fichier hypercube
- La Brique applique les modifications (domaine, vpn, ssid, mots de
passes…) → maximum 10 minutes
- On passe 1h à parler du pourquoi et du comment et on boit des bières
Ce qu'il faut faire pour en arriver là:
- modifier le script de build et construire des images avec:
- nom de domaine bidon
- mots de passes bidons (aléatoires)
- démarrer une interface pour permettre de charger l'hypercube et de
lancer la post-installation de Brique
Utiliser le port 1194-UDP peut parfois poser des problèmes sur certains réseaux bridés (comme à la Villette). Utiliser une connexion TCP-443 est plus fiable mais moins performant. Utiliser une connexion UDP-443 pourrait suffire à traverser certains réseaux bridés.
Openvpn permet de spécifier plusieurs plusieurs triplets IP/Port dans le fichier de config client. Il faudrait voir s'il est possible de produire des fichiers .cube permettant d'utiliser cette fonctionnalité.
Exemple de config openvpn :
<connection> remote vpn.server.example 443 tcp </connection> <connection> remote vpn.server.example 993 tcp </connection> <connection> remote vpn.server.example 22 tcp </connection> <connection> remote vpn.server.example 80 tcp </connection> remote-random
Prochaine date de réunion mumble : lundi 2 juillet (pour éviter une collision avec les RMLL le lundi suivant)