La réunion se passe sur le serveur mumble de LDN : https://wiki.ldn-fai.net/wiki/Mumble
Compte-rendus des précédentes réunions : https://wiki.labriqueinter.net/doku.php?id=meetings:index
Participants :
La réflexion est un peu revenue sur le tapis à l'occasion du brique camp.
De quelle manière les 2 projets doivent-ils se confondre et de quelle manière doivent-ils rester distincts ?
Réponse simple (à étayer en réunion) : du point de vue utilisateur (le grand public) il faudrait conserver une séparation nette et l'aspect “marketing” de labrique mais côté équipes de maintenance/dév/support/communication cette séparation n'a pas vraiment de sens.
Aleks: Ces derniers jours je me disais que ca aurait du sens de gérer la brique comme un groupe de travail (c.f. core, apps, support&doc, …) de yunohost ⇒ idée à soumettre au CA pour la forme
Plot twist : après moult échanges il semblerait inutile de changer quoique ce soit à l'organisation actuelle des 2 projets qui sont déjà fusionnés et distincts juste comme il faut :)
Pour une meilleure visibilité nous inaugurons ce soir-même un projet (au sens github, façon kanban) :
https://github.com/orgs/labriqueinternet/projects/1
Jalon 1 : Réparer la brique
Jalon 2 (1 à 2 mois) :
Jalon 3
pitchum s'est suffisamment investi sur cette app pour accepter d'en devenir le mainteneur officiel.
Si personne n'est contre pitchum se permettra de pousser des modifs directement dans le dépôt upstream sans passer par des PR ni reviews (ou alors seulement lorsqu'il l'estimera utile). +1 (Aleks) +1 (Keo) +0 (agentcobra)
Liste des personnes actives sur labrique/vpnclient
TODO pitchum: abandonner le fork perso et utiliser une branche “testing” develop sur le dépôt officiel sur laquelle auront lieu les PR etc. TODO identifier différents cas d'usage de vpnclient (certificats, login/password, autre…) et faire valider toute nouvelle version avant merge de testing vers master. Solliciter les FAI pour avoir un compte vpn de test
IMPORTANT: il est urgent de mettre le bon commit sur les listes
Proposition de mettre un exit 0 au début dans le script d'upgrade, afin de permettre de publier rapidement une version plus à jour de vpnclient pour les personnes qui installent une brique fraîche.
Note pour pitchum: pas besoin d'un fork dédié pour tester les install/upgrades d'une app, on peut préciser une branche de github avec le syntaxe suivante (par exemple) :
yunohost app install https://github.com/labriqueinternet/vpnclient_ynh/tree/testing
A intégrer dans la branche master :
Et peut être: https://github.com/labriqueinternet/vpnclient_ynh/commit/1fc458110660ce775f7613091cde3c5fdcfbe4e6
Dans yunohost 3.X (et peut-être également dans la 2.7.X je ne sais pas) l'appli vpnclient empêche php7.0-fpm de se lancer automatiquement au boot :
$ grep ERROR /var/log/php7.0-fpm.log | tail -n 10 [10-Sep-2018 12:18:23] ERROR: [pool vpnadmin] cannot get uid for user 'admin' [10-Sep-2018 12:18:23] ERROR: FPM initialization failed
Bizarrement, quand on relance php7.0-fpm manuellement, ça marche. Il doit y avoir un problème d'ordonnancement au boot…
Pb signalé : https://github.com/YunoHost/issues/issues/1179
En tout cas j'ai patché la conf chez un abonné FCN comme ceci pour le débloquer :
sed -i 's/^user = admin/user = www-data/' /etc/php/7.0/fpm/pool.d/{wifiadmin,vpnadmin}.conf
sed -i 's/^group = admins/group = www-data/' /etc/php/7.0/fpm/pool.d/{wifiadmin,vpnadmin}.conf
- Pensez-vous qu'il puisse y avoir des effets de bord liés au fait de modifier admin par www-data ?
⇒ oui gros problème : notamment, le script ynh-vpnclient-loadcube.sh ne fonctionne plus à cause de ça très probablement
Bug tout frais, et peut-être spécifique au VPN franciliens.net.
Dernières découvertes de pitchum (avec tcpdump) :
dig xxxxx @ns1.franciliens.net
la requête DNS part bien de la brique, le serveur DNS FCN reçoit bien la requeête et la réponse part bien (vu avec tcpdump côté serveur) mais la réponse n'arrive jamais côté brique, et ce, même après avoir retiré toutes les règles iptables de vpnclient
NB: Images avec yunohost 2.7.14 (Debian jessie)
Une nouvelle image de LIME2 non chiffrée est maintenant disponible. Qui peut faire des tests sur une LIME ? Keoma se propose de faire les tests de LIME2 chiffrée (premier test est un echec, il doit regarder avec l'interface serie)
Question des briques chiffrée. Est-ce qu'on continue à en faire dans l'etat du projet ? ⇒ à l'unanimité : on ne gaspille pas d'énergie sur les briques chiffrées (pour le moment) ⇒ TODO: enlever les images et ajouter une mention pour expliquer pourquoi elle n'est plus supportée
\o/
Le but est d'avoir des images à jour sur le repo (https://repo.labriqueinter.net/ )
Le but est de fournir des images sur lesquelles des applications sont déjà installées et que les utilisateurs n'aient qu'à renseigner leurs identifiants et domaines.
⇒ Aleks suggère de partir du mécanisme de build d'armbian Keo: tester de construire des images en passant par de l'emulation (QEMU…) (ou virtualisation)