Réunion des dév' de Zeste de Savoir

a marqué ce sujet comme résolu.

Bonjour les agrumes,

Voici la première ébauche d’ordre du jour pour la réunion de jeudi :

  • (40 min) Discussion à propos de l’infrastructure
    • (Situphen) Discussion à propos du petit DDOS du 28 mars et des solutions pour s’en prémunir
    • (firm1) Migration de Google Analytics vers Matomo (PR 6063)
    • (Situphen) Migration du Sentry de Sandhose vers celui de Sentry.io
    • (?) Discussion à propos de la migration de Munin ?
  • (40 min) Derniers préparatifs pour la v30.1
    • (artragis) Publication des contenus directement avec le manifeste (PR 6025), ce qui permettra d’améliorer nos performances
    • (artragis) Intégration des quizzs (PR 5928)
    • (?) Revue des PRs en cours
  • (15 min) Fonctionnement de la QA lors des PRs
    • (Situphen) Retour d’usage sur la possibilité de fusionner automatiquement une PR une fois que les tests passent et que les reviews sont au vert et pérennisation si OK
    • (Situphen) Retour d’usage sur l’obligation d’avoir au moins une review au vert avant de pouvoir fusionner et pérennisation si OK
  • (15 min) Questions diverses et variées

Dites moi si vous souhaitez ajouter ou modifier quelque chose !

+4 -0

Et voici le compte rendu. Désolé pour le léger retard, la préparation de chicons au gratin m’ayant quelque peut ralenti

  • (40 min) Discussion à propos de l’infrastructure
    • (Situphen) Discussion à propos du petit DDOS du 28 mars et des solutions pour s’en prémunir
      • Petit billet qui existe déjà : 05/03 une DDOS depuis 4000 IP, gunicorn au tapis. Du coup on a mis une limitation à 5 req/s puis 15req/s en pic (conf nginx) pour faciliter la vie de gunicorn.
      • 14/04 : vague de requêtes depuis une seule IP russe => uniquement 30% servie (impeccable)
      • Idem, les bot qui fonctionnent mal sont limités.
      • Voir avec Gandi s’ils ont pas une offre anti DDOS. Pour l’instant on n’a vu que du DNS antiDDOS.
      • Proposition de philippemilink d’une liste de bot à complètement bloquer
      • Nota: pas de fail2ban mais ufw
    • (firm1) Migration de Google Analytics vers Matomo (PR 6063)
      • Respect du RGPD ok
      • On garde les mêmes fonctionnalités (sauf une métrique : nombre de session)
      • Import GA : on a un rate limit donc ça bloque à la fois la prod et l’import. Proposition de passer rapidement Matomo en prod.
      • On envoie les IP mais il faudra la retirer des logs nginx matomo
      • Question à propos du stockage: est-ce qu’il est possible de facilement ajouter du stockage sur l’instance scaleway qui héberge actuellement le matomo ? Comment l’extension de stockage est gérée dans Linux (étendre la partition ?)
      • Le serveur de test pour Matomo a presque les caractéristiques qui sont recommandées (sauf 20 Go de DD au lieu de 50)
    • (Situphen) Migration du Sentry de Sandhose vers celui de Sentry.io
      • avant de passer en prod: mise à jour du sdk django, vérifier la configuration (env var)
    • (?) Discussion à propos de la migration de Munin ?
      • sur quel serveur on place Munin ? Il faudrait le placer sur un serveur qui ne contient pas ce qu’il surveille. Un tout petit serveur pour ça, ou bien on place la surveillance de Matomo sur la prod et vice-versa (<- tenter cette solution) ou multimaster
      • Passage à netdata ? Stocke bien plus de données: "dizaine de Go par an"
      • Mise en place de notifications pour les niveaux critiques ?
  • (40 min) Derniers préparatifs pour la v30.1
    • (artragis) Publication des contenus directement avec le manifeste (PR 6025), ce qui permettra d’améliorer nos performances
      • Prêt à QA
      • Faire des PDFs de la version bêta: à coder, pipeline LaTeX compliqué, mais le rendu par manifeste règle beaucoup de problèmes, mais: stockage de tous ces PDFs non publiés, demande bcp de CPU à générer (à la demande) (ce dernier point est le plus gênant). Plus de blocage technique aujourd’hui si ce n’est un peu de développement nécessaire.
    • (artragis) Intégration des quizzs (PR 5928)
      • Pas d’évolution depuis la dernière fois. Architecture prête, il faut faire le front.
    • Passage à Django 3 ?
      • PR en cours, une dépendance non compatible avec Django 3.2
    • (?) Revue des PRs en cours - Amélioration de l’UX: la PR pourrait être fermée (ne sera jamais mergée), a été déplacé vers le dépôt lime-editor - Migration vers ES7: en cours - Réduit la quantité de requêtes réalisées sur la page d’accueil des forums #6089: à tester, mettre sur la bêta ? (utiliser la django debug toolbar)
  • (15 min) Fonctionnement de la QA lors des PRs
  • (Situphen) Retour d’usage sur la possibilité de fusionner automatiquement une PR une fois que les tests passent et que les reviews sont au vert et pérennisation si OK - Tout le monde OK
  • (Situphen) Retour d’usage sur l’obligation d’avoir au moins une review au vert avant de pouvoir fusionner et pérennisation si OK - Tout le monde OK
  • (15 min) Questions diverses et variées
    • à propos de l’interface de review : ça semble pertinent de se contenter de se lier au markdown dans un premier temps car ça permet une meilleure intégration à git tout en visant les relecteurs de la béta et les valido. Ceci dit des améliorations restent possible surtout si on ajoute des métadonnées dans zmarkdown.
+3 -0

J’ai été invoqué par @Aabu pour relancer ce sujet « sans activité depuis plus de 90 jours », donc voilà !

Vous connaissez la chanson, le principe est simple : remplir ce magnifique sondage avec vos disponibilités des prochaines semaines pour que l’on puisse convenir de la date de la réunion !

N’hésitez pas à dire si vous souhaitez aborder certains sujets en particulier, j’en tiendrai compte pour l’ordre du jour. :)

+0 -0

L’heure du scrutin est venue : la réunion aura lieu le dimanche 12 septembre (soit dans 4 jours) à partir de 19 heures dans le salon textuel #développement-de-zds et le salon vocal Développement de ZdS de notre serveur Discord non-officiel.

Je n’ai pas l’impression qu’il y ait de sujets importants à aborder mais je pense qu’il est quand même utile d’organiser une petite réunion pour parler des petits sujets bloquants s’il y en a et sinon pour qu’on se remotive mutuellement à contribuer après les grandes vacances !

+0 -0

Et voilà le compte-rendu. Libre aux autres d’amender tout ça avec les éventuels oublis. ^^

Réunion devs Zeste de Savoir

Dimanche 12 Septembre 2021 - 19h30

Présents : Aabu, Amaury, firm1, Melcore, philippemilink, Situphen.

Accès au serveur de prod

artragis, Situphen, philippemilink, sandhose

(juste pour informer les autres que philippemilink a aussi les accès)

=> voir avec le CA pour gérer les droits (bien séparer, etc)

Imposer les tests back-end pour les nouvelles PRs ?

(cf https://zestedesavoir.com/forums/sujet/15658/imposer-la-presence-de-tests-pour-accepter-les-prs))

  • ajouter/améliorer la doc au sujet des tests et destiné surtout aux débutants sur le projet
    • politique globale : tests obligatoires par principe pour les PR qui touchent au Python, les infractions doivent rester exceptionnelles
    • renforcement de la pédagogie autour des tests (éviter de faire fuir les contributeurs)
      • être dispo en cas de soucis/doutes/assistance requise pour les contributeurs (éviter de tuer les PR) ;
      • "fortement recommandé", "on est là pour vous aider au besoin" ;
      • guide sur comment utiliser les outils de tests (Factory par exemple) ;
      • guide sur comment organiser les tests
  • mettre à jour le template de PR pour rajouter un pense-bête sur l’ajout de tests backend (https://raw.githubusercontent.com/zestedesavoir/zds-site/dev/.github/pull_request_template.md))
Préparatifs pour Hacktoberfest ?
  • revue des tickets "Faciles" ? => prémâcher des tickets avant octobre
  • communication ? => contacter l’équipe comm'
    • billet sur Hacktoberfest avec lien vers les tickets Facile
    • promo sur Twitter et Mastodon
  • prévoir d’être réactif sur les PRs
  • si pas de fusion possible avant novembre => mettre le bon tag Hacktoberfest
Revue des PRs en cours

Redirige l’utilisateur vers la bonne page si déjà connecté => Ne pas pouvoir rediriger vers une image

Bonjour les agrumes,

L’heure (n’)est (pas) grave. Nous n’avons pas organisé de réunion depuis plusieurs mois ! Je propose donc que l’on en organise une ce mois-ci et pour ce faire, je vous remercie par avance de remplir le traditionnel sondage des disponibilités. 14 dates possibles avec deux créneaux horaires, 28 choix au total, tout le monde devrait pouvoir y trouver son bonheur.

Qu’y aura-t-il au menu ?1 Je pense qu’il faudra aborder la question de la prochaine version puisque la dernière date de juin, soit il y a presque un an. On pourra en profiter pour discuter plus globalement de notre organisation pour éviter une aussi grande période sans nouvelle version, de la motivation et des disponibilités de chacun sur le projet, etc. Si vous souhaitez que l’on aborde un sujet en particulier, dites le !


  1. Ne pas confondre avec « Qui y aura-t-il au menu ? »
+4 -0

Merci pour l’organisation de la réunion @Situphen.

Je vois plusieurs points à aborder (éventuellement redondants avec ceux que tu proposais, mais ce n’est pas bien grave !) :

  • nouvelle version (mineure) de ZdS. Il y a actuellement 57 PR fusionnées en attente d’arriver sur le serveur de production. C’est principalement des changements qui n’impacteront pas les visiteurs, mais il y a aussi des mises à jour qui incluent des correctifs de sécurité (notamment EasyMDE, et, si on y arrive, zmd pour l’export des PDF).
  • d’ici à la réunion, je devrais avoir réussi à apporter les changements nécessaires à nos sauvegardes, je pourrai faire un retour dessus.
  • NodeJS version 12 (version utilisée en production) n’est plus maintenu à la fin du mois d’avril. On dit déjà dans le code de ZdS qu'on utilise la version 16. Même si ça ne réglera pas vraiment le problème, j’aimerai en profiter pour passer nos serveurs à Debian 11 avant cette date.

Veuillez trouver ci-contre ma proposition pour l’ordre du jour de la réunion :

  • (20–25 min) Petit état des lieux de nos ressources humaines (Situphen)
    • (Contributeurs depuis 2021)
    • Motivation, ambitions et disponibilités de chacun au sein de l’équipe technique
    • Qui pour prendre la suite d’artragis en tant que responsable du projet technique ?
    • Plus globalement, y a-t-il encore assez de membres actifs dans l’équipe ? ne serait-il pas temps de relancer un appel aux contributeurs ? etc.
  • (10–15 min) Organisation du projet et de l’équipe (Situphen)
    • (Ce point est grandement lié au point précédent)
    • Comment éviter une aussi grande période sans nouvelle version ?
    • Reste-t-on sur le modèle « chacun fait ce qu’il veut sans direction particulière » ou est-ce que l’on définit des grands axes de développement ?
  • (20–25 min) En avant pour la v30.2 ! (Situphen)
    • Résumé des principaux changements depuis la v30.1 (à partir de la liste des commits)
    • Y a-t-il des PR qui doivent être incluses dans la v30.2 ?
    • Y a-t-il des PR qui devraient si possible être incluses dans la v30.2 ?
    • Fin du support de Django 2.2 en avril 2022 donc ne pas tarder avant de déployer la nouvelle version !
    • Quel calendrier prévoit-on pour la mise en bêta puis la mise en prod ?
  • (10–15 min) Notre infrastructure et ses sauvegardes (philippemilink)
    • (Résumé du sujet Sauvegardes de ZDS)
    • Quels changements ont été mis en place récemment ?
    • Quels changements sont envisagés dans le futur ?
  • (10–15 min) Notre infrastructure et le passage à Debian 11 (philippemilink)
  • (15–20 min) Intendance des PR (Situphen)
    • Dépoussiérage des PR relativement récentes
    • Mise au cimetière des PR en décomposition (notamment celles étiquetées Zombie)
  • (10+ min) Nouvelle organisation des contenus (Aabu)

Cordialement,

+4 -0

Peut-être un petit moment sur les grands axes futurs de développement ? Ou on reste sur le modèle “chacun fait ce qu’il veut sans direction particulière” ?

Amaury

Je vais rajouter cela au point « Organisation du projet et de l’équipe ». Cela dit, je pense qu’étant donné le peu de membres actifs qu’on a dans l’équipe actuellement et que personne pour l’instant ne souhaite reprendre le poste de responsable de projet, il est fort probable qu’on reste sur le modèle actuel pour les mois à venir. Enfin bon, on en discutera jeudi.

Édition : Je viens de m’apercevoir que j’ai oublié de mettre le point sur la nouvelle organisation des contenus. Je le rajoute aussi.

+1 -0

J’ai ajouté la proposition d’Amaury ainsi que le point demandé par Aabu que j’avais oublié. J’ai ajusté les estimations de temps, ce qui donne à l’arrivée une estimation entre une heure et demie et deux heures et quelques. Il est probable que l’on déborde étant donné que cela fait longtemps qu’on n’a pas fait de réunion. Merci si possible d’arriver à l’heure pour éviter de perdre trop de temps au démarrage ! L’ordre du jour est ordonné par importance (ressources humaines, puis organisation, puis nouvelle version, puis infrastructure et enfin intendance) à l’exception de la nouvelle organisation des contenus que j’ai choisi de mettre en dernier car le potentiel de débordement du temps imparti me semble élevé. Bien entendu, je reste ouvert à toutes propositions de modification (tant qu’elles tiennent compte que le temps de la réunion est limité à deux heures) !

+2 -0

Bonjour les dev’s de ZdS.

Une petite réunion des dévs s’organise doucement. Pensez à remplir le sondage avec vos disponibilités !

Un ordre du jour préliminaire :

  • changements dans la récupération des statistiques des contenus depuis Matomo
  • chargement des images non-hébergées sur notre serveur
  • petit point sur l’infrastructure (état des sauvegardes, mise à jour de Matomo, …)
  • prochaine version de ZdS (si elle n’est pas déjà publiée avant la réunion !)

N’hésitez pas à proposer d’autres points à aborder.

Voici le compte-rendu de la réunion, qui a duré moins de 2h.

Prochaine version de ZdS

@philippemilink

La sortie de la version 30.3 de zds-site est imminente (vraiment : dans les jours qui viennent). Elle sera mise sur la bêta puis sur le serveur de production ce week-end, si aucun bug n’est remonté. Quelques suggestions pour le nom de la version ont été faites. :)

Point sur l’infrastructure

@philippemilink

Le système des sauvegardes est maintenant pleinement fonctionnel : la base de données ainsi que les données du serveur de production sont sauvegardés sur le serveur de bêta ainsi que sur des serveurs tiers gérés par des membres de l’équipe (sauvegardes chiffrées, bien-sûr). Les données de Matomo sont maintenant également sauvegardées de la même manière : sur le serveur de bêta et sur des serveurs externes.

Matomo a été mis à jour : on est passé de la version 4.2.1 à la version 4.10.1.

Le prochain "gros" chantier sur l’infrastructure est le rapatriement de notre outil de supervision Munin sur nos propres serveurs, et pas sur un serveur tiers. La politique de sécurité retenue pour l’interface web de Munin est diffusion privée, mais accès libre (tout le monde peut y accéder si l’URL est connue).

Changements dans la récupération des statistiques des contenus depuis Matomo

@Situphen

La page de statistiques de consultation des contenus publiés sur ZdS récupère les données gérées par Matomo. L’affichage de cette page peut-être très long, voire mener à un timeout. Situphen s’est penché sur la question, et propose des changements dans la manière de récupérer les données de Matomo : au lieu de récupérer les données pour chaque journée et faire les sommes côté zds-site, on récupère uniquement les données dont on a besoin, avec seulement la granularité requise (pas forcément besoin de toujours avoir une granularité à la journée). Il semble y avoir quelques limitations du côté de Matomo, mais peut-être aussi des paramètres à changer dans notre configuration de Matomo :

J’ai parcouru un peu la documentation de Matomo (notamment https://developer.matomo.org/guides/how-piwik-works et https://developer.matomo.org/guides/archiving) par rapport au soucis rencontré (https://github.com/matomo-org/matomo/issues/19460) et je pense que le dernier commentaire explique bel et bien la raison du soucis rencontré. Il faudrait essayer de modifier la configuration pour augmenter les limites, en s’inspirant de cette page : https://fr.matomo.org/faq/how-to/faq_54/.

Il est probable que l’on puisse réduire le temps de chargement de la page de statistiques en demandant à Matomo de faire ses calculs régulièrement à l’aide d’un cronjob au lieu de à la demande à chaque requête. https://matomo.org/faq/on-premise/how-to-set-up-auto-archiving-of-your-reports/

Situphen sur Discord.

Chargement des images non-hébergées sur notre serveur

@amaury

En autorisant l’affichage d’images stockées sur d’autres serveurs que ceux de ZdS dans les contenus et messages (forums, commentaires, MPs), l’adresse IP du visiteur est connue du serveur tiers qui héberge l’image. Cela peut-être considéré comme une fuite de données personnelles (seuls l’IP publique de l’utilisateur ainsi que le User-Agent de son navigateur web sont connus du serveur tiers). Des solutions possibles ont été discutées :

  • ignorer le problème, comme la plupart des sites avec un fonctionnement similaire au nôtre ;
  • proxifier les URLs des images : le visiteur de ZdS charge les images en communiquant uniquement avec le serveur de ZdS, et celui-ci se charge de récupérer l’image auprès du serveur tiers. Un tel système est utilisé par GitHub ;
  • héberger nous-mêmes toutes les images : stocker sur notre serveur les images hébergées sur un serveur tiers, ou bien interdire les images externes et ne permettre que le téléversement d’images sur notre serveur via les galeries.

La position actuelle de l’équipe de développement est que ce n’est pas un sujet prioritaire. Si quelqu’un souhaite se pencher sur le problème, toute contribution sera la bienvenue ! :) Un sujet dans la même veine et plus prioritaire est de ne plus dépendre de service tiers pour l’hébergement des fichiers de polices.

Contributions à ZdS comme projets d’étudiants en informatique

@philippemilink

philippemilink a l’occasion de proposer des sujets pour des projets d’étudiants-ingénieurs en informatique, de niveau Master 1. Il a été discuté de la possibilité de proposer comme sujet la réalisation de certaines tâches de développement de zds-site, zmarkdown, voire le futur/possible/embryonnaire/nouvel ( ;) ) éditeur.

Il s’agit de jouer le rôle du "client" qui demande à une entreprise de services informatiques (un groupe de 6 étudiants) de réaliser les tâches qui sont demandées. Les étudiants travaillent sur le projet de novembre à mai, à raison de quelques heures (~ 2h) par semaine. Les principales idées de tâches qui ont été proposées sont les suivantes :

  • Migration de zmd vers micromark ;
  • Évolution de l’interface de rédaction vers un système unifié (sans séparation entre les parties, chapitres et sections) et temps-réel ;
  • Mettre en place les évolutions du groupe de travail « Organisation des publications » ;
  • Mise en place des parcours ;
  • Nouvel éditeur
  • Amélioration de la recherche (mise à jour de ElasticSearch, passage à un autre outil ?) ;
  • Quizz et sondages.

Un sujet dédié sera ouvert sur le forum pour en discuter plus en détails.


Merci à ceux qui étaient là !

Sur le sujet des images non hébergées par ZdS : attention aux impacts légaux et techniques (de sécurité, en particulier). Je ne sais pas à quel point il est autorisé de copier une image (à priori sous copyright) pour la ré-héberger. Si c’est OK, il faut aussi penser que le serveur d’images intermédiaire doit résister à des attaques assez triviales à priori, comme la saturation par des images géantes ou l’envoi de données dangereuses (exécutables prétendant être des images, ou même images exploitant les failles de sécurité dans les bibliothèques de gestion d’images, ce qui apparait de temps à autre).


Pour les gens qui n’ont pas suivi, c’est quoi cette « migration de zmd vers micromark » qui passe de temps en temps depuis au moins 2021 ?

Sur le sujet des images non hébergées par ZdS : attention aux impacts légaux et techniques (de sécurité, en particulier). Je ne sais pas à quel point il est autorisé de copier une image (à priori sous copyright) pour la ré-héberger. Si c’est OK, il faut aussi penser que le serveur d’images intermédiaire doit résister à des attaques assez triviales à priori, comme la saturation par des images géantes ou l’envoi de données dangereuses (exécutables prétendant être des images, ou même images exploitant les failles de sécurité dans les bibliothèques de gestion d’images, ce qui apparait de temps à autre).

@SpaceFox

Bonne remarque concernant les protections vis-à-vis des attaques par fichiers malicieux. Concernant l’autre point, c’est juste si on parle d’un ré-hébergement ; pas si on parle d’un proxy, à ma connaissance — ce qui est également envisagé.

Et, n’a-t-on pas déjà le problème depuis des années vu que les PDF des contenus intègrent de telles images ?

Pour les gens qui n’ont pas suivi, c’est quoi cette « migration de zmd vers micromark » qui passe de temps en temps depuis au moins 2021 ?

@SpaceFox

zmd se base actuellement sur remark pour transformer le markdown brut en un AST (MDAST) qui servira à la production de HTML ou de LaTeX. remark a migré vers une nouvelle solution pour le parsing du markdown, micromark, plus puissante et performante mais aussi plus complexe. Pour continuer à pouvoir se tenir à jour et évoluer avec remark, on doit migrer nos plugins spécifiques vers micromark — ce qui n’est pas une mince affaire, les contributeurs·trices sont les bienvenu·e·s.

@Stalone est en train de rédiger un guide d’aide à la migration, qui sera prêt quand il sera prêt (et quand j’aurai plus le temps de relire et tester la compréhension du contenu, entre autres).

+2 -0

Bonne remarque concernant les protections vis-à-vis des attaques par fichiers malicieux. Concernant l’autre point, c’est juste si on parle d’un ré-hébergement ; pas si on parle d’un proxy, à ma connaissance — ce qui est également envisagé.

Et, n’a-t-on pas déjà le problème depuis des années vu que les PDF des contenus intègrent de telles images ?

Amaury

Je pense que pour un proxy ça passe – l’idée c’est surtout que si l’auteur de l’image la modifie ou supprime sur son hébergement source, la modification soit répercutée chez nous aussi.

Pour la question des PDF, ça me parait acceptable de demander à ce que les ressources des contenus soient hébergées sur ZdS, ne serait-ce que pour garantir la pérennité de leur affichage. Je suis moins convaincu pour les ressources autres (contenus des MP, des forums, des biographies, avatars…)

Et merci pour l’explication sur micromark. C’est assez infernal cette histoire de Markdown – on a un effort démesuré dessus depuis le début, entre les problèmes de la versions Python et maintenant la migration de la version JS. Mais j’imagine qu’on a pas tellement le choix.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte