(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 !
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.
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.
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.
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 !
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 !
Ne pas confondre avec « Qui y aura-t-il au menu ? »↩
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).
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.
La réunion aura lieu le jeudi 17 mars à 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. J’essaierai de vous concocter un petit ordre du jour d’ici là.
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” ?
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” ?
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.
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) !
La date du lundi 25 juillet a été retenue pour la prochaine réunion à propos du développement technique de ZDS ! On se donne donc rendez-vous à partir de 19 heures sur le salon vocal du serveur Discord.
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.
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
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 :
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 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 ;
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).
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 ?
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).
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 ?
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
) 