Differences
This shows you the differences between two versions of the page.
meetings:2018-06-11 [2018/06/12 08:54] pitchum [Discussions avant démarrage] |
meetings:2018-06-11 [2018/12/08 22:28] |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Meeting Brique Internet juin 2018 ====== | ||
- | |||
- | (meeting mumble) | ||
- | |||
- | CR du précédent meeting : [[meetings:2018-05-07|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) | ||
- | |||
- | ===== Discussions avant démarrage ===== | ||
- | |||
- | * 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 | ||
- | |||
- | ===== Sujets non Techniques ===== | ||
- | |||
- | ==== Conception d’un tryptique d’accompagnement pour la brique (Mode d’emploi/ objectif) ==== | ||
- | |||
- | Proposition de pitchum : concevoir une plaquette synthétique à distribuer avec les briques. | ||
- | |||
- | On pourrait s’inspirer du triptyque des chatons : https:%%//%%framagit.org/framasoft/CHATONS/blob/master/docs/communication/flyers/triptyque/tryptyque_v1.5-recto-RENDUpouhiou.pdf | ||
- | |||
- | Objectifs: | ||
- | * 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 | ||
- | * Présenter la brique et ses deux aspects principaux (neutralisateur de connexion internet et auto-hébergement facile) | ||
- | * rappeler que la brique n’est pas forcément assez puissante pour héberger de nombreuses applications | ||
- | * … autres (à compléter) | ||
- | * un espace blanc réservé aux FAI pour personnalisation | ||
- | |||
- | On recherche quelqu’un qui souhaiterait réaliser ce tryptique | ||
- | |||
- | ==== RMLL 2018 ? ==== | ||
- | |||
- | 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 ? | ||
- | |||
- | ==== Que fait-on des issues de la brique ? ==== | ||
- | |||
- | -> 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 : | ||
- | |||
- | - Catégoriser les issues en fonction du repo vers lesquelles elles doivent aller (TODO pitchum et Tharyrok) | ||
- | - Aleks doit montrer à Tharyrok comment le script d’import/export fonctionne | ||
- | - Exporter de redmine vers en local (avec la bonne classification) | ||
- | - Importer de local vers github | ||
- | |||
- | ==== Y a-t-il un channel labriqueinter.net-dev ? ==== | ||
- | |||
- | => oui, utilisé pour les notifications de builds et commits | ||
- | |||
- | Presque personne ne connaissait ce channel, maintenant y a du monde dessus :) | ||
- | |||
- | ===== Sujets Techniques ===== | ||
- | |||
- | ==== Passage à Stretch ==== | ||
- | |||
- | * 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) | ||
- | |||
- | ==== La PR de Bram sur les panneaux de configuration ==== | ||
- | |||
- | 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. | ||
- | |||
- | ==== applications ==== | ||
- | |||
- | * 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 | ||
- | |||
- | ==== Autoconfig thunderbird ==== | ||
- | |||
- | 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 | ||
- | |||
- | ==== Commits dans la liste d’app de la brique ? ==== | ||
- | |||
- | 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 | ||
- | |||
- | ==== Build d'images officielles ==== | ||
- | |||
- | 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 [[https://github.com/labriqueinternet/labriqueinter.net/pull/51|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 | ||
- | |||
- | |||
- | ==== Nouveau workflow d’install des briques (aka briques pré-installées) ==== | ||
- | |||
- | 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 | ||
- | |||
- | ==== Le bon port pour le VPN ==== | ||
- | |||
- | 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 : | ||
- | <code> | ||
- | <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 | ||
- | </code> | ||
- | |||
- | ---- | ||
- | |||
- | Prochaine date de réunion mumble : **lundi 2 juillet** | ||
- | (pour éviter une collision avec les RMLL le lundi suivant) | ||
- | |||