Meeting Brique Internet juin 2018

(meeting mumble)

CR du précédent meeting : Meeting Brique Internet mai 2018

Présents :

• ljf (membre de ARN et contributeur YunoHost)
• irina (membre de ARN, utilisatrice de la brique)
• Aurélien (utilisateur de la brique)
• pitchum (membre de franciliens.net)
• Tharyrok (membre de Neutrinet)
• Aleks (membre de ARN / dev YunoHost)
• agentcobra (membre de LDN)

• Retour utilisateur : le script install-sd.sh n’est pas capable de détecter que la carte SD est en lecture seule (bouton physique activé involontairement), ça peut prendre longtemps avant de comprendre pourquoi l'install ne fonctionne pas
• Discussions sur “comment packager une app ?”
• Comment sont détectées les apps non à jour ?
  • réponse rapide : ce sont les mainteneurs qui choisissent d'indiquer l'état d'avancement de leur app
  • Aleks à codé un script qui taggue automatiquement “unmaintained” les apps n'ayant pas eu d'attention depuis un certain temps et qui créé automatiquement un ticket sur le dépôt github correspondant
• Problème de la dépendance aux api github pour de nombreux aspects de fonctionnement de yunohost
  • problème connu mais qui n'est pas une priorité pour le moment

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 :

• Présenter la brique et ses deux aspects principaux (neutralisateur de connexion internet et auto-hébergement facile)
• Répondre aux questions typiques
• Résumé du mode d’emploi (mémo au cas où l’adhérent oublie une info transmise)
• Indiquer où obtenir de l’aide
• Mettre en garde sur le fait que la brique n’est pas une machine très puissante : éviter d'y installer trop d'applications (pour ça, passer à yunohost sur un serveur plus robuste)
• Indiquer clairement que la brique est basée sur yunohost
• … autres (à compléter)
• Laisser un espace blanc réservé aux FAI pour personnalisation

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 :

1. Catégoriser les issues en fonction du repo vers lesquelles elles doivent aller (TODO pitchum et Tharyrok)
2. Aleks doit montrer à Tharyrok comment le script d’import/export fonctionne
3. Exporter de redmine vers en local (avec la bonne classification)
4. Importer de local vers github

⇒ 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)

• à signaler haut et fort dans le disclaimer lors d'un upgrade
• bonus : trouver un moyen de détecter si le port 587 est bien joignable pour cause de règle firewall customisée par l'utilisateur (nc ou nmap, telnet sur le port en question)

* retour utilisateur : j'ai du redémarer php-fpm après vpnclient * Workflow recommandé pour les utilisateurs finaux (quand ce sera release)

• Mettre à jour le serveur avec une upgrade classique
• Faire un backup (ou un dd de la carte sd)
• Aller dans Tools > Migrations dans la webadmin
• Lire le disclaimer, le comprendre et l'accepter si l'on comprend les notes / risques / …
• Lancer la migration et être patient
• Si ça crashe pour une raison X ou Y, on peut normalement relancer la migration

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)