documentation/compte_rendus/2025_06_22.md

= Réunion IN =

• Date : Dimanche 22 juin 2025
• Lieu : Galène
• Début : 14h11
• Fin : 17h20

=== présent⋅es === Lyes Lzebulon korenst1 Chiaroush Pigeon Moelleux Hachino Rigobert

== Ordre du jour == === En bref : === [Hachino] Les switchs arceus et carapuce sont devenus injoignables depuis l'extérieur. Thot aussi, du coup restic se plaint. --> Done. Descente en salle serveurs samedi 14 ? Oui. Les liens Arceus-7 (ENS) et Carapuce-17 (VR) sont éteints. Tiens, Borgmatic se met à se plaindre sur Gitzly lui aussi (mercredi 11 matin). -> Oui, il y a eu un début de passage de gitzly vers bookworm mais la procédure a été interrompu par une version pas à jour de gitlab, update de gitlab impossible à cause d'une vielle version de postgreSQL [Hachino/Lzebulon] Amélioration des mails de modération de Mailman (done) \o/ [korenstin] incident vm en7 [korenstin] sam et des problèmes

=== IMPORTANT === [Pigeon] Mettre à jour PostgreSQL sur tealc Pas encore critique mais bientôt On est en version 13, la dernière version sortie est la 17 (et 18 en beta) euh on est sur de l'info ? parce que sur sam, daniel et jack le serveur est la version 15.13 mais tealc en version 13.21 j'ai rien dit, la db est toujours en 13 besoin pour gitlab 18 (et 17 techniquement...) voir replication ?

=== Le reste ===

[korenstin] redémarrage des serveurs août test de si le système de routeur fonctionne Comprendre pourquoi l'ensemble des machines se sont éteintes (suite à un certain incident) qui à déconnecter le sam (et donc rsam) de tout réseau (adm, srv-nat, srv, 2756, aurore, ...) update / upgrade des serveurs sous bullseye vers bookworm (voire trixie si déjà sortie) vérifier / configurer les éléments manquant ou en trop sur proxmox (typiquement le port série) vérifier / débugger les problèmes les problèmes sur sam (cf point à l'ODJ) upgrade la version de postgresql (cf point à l'ODJ) Créer un pad avec la liste des trucs à faire et penser à le copier en local...

=== INTERNET === [korenstin] Depuis le ~3 juin, le wiki et le gitlab ont de forts piques de ping au point de rendre les services inaccessible (status.crans.org) toutes les ~5h, scraping ? DDoS ? le wiki ca date de bien avant <- d'après status.crans.org, le ~3 juin Anubis a été installé pour certains services : wiki, mediawiki, mirrors et install-party mais pourrait empêcher status.crans.org de bien tout surveiller la conf anti robot semble assez efficace (réduction drastique de la bande passante sur reverseproxy) passons nous eclat (http, pas la version https) par reverseproxy ou on laisse l'ip publique ? [Hachino] Dans la même veine, Mailman sature sa RAM plein de fois par jour. Pas très grave a priori, mais pourquoi ? EDIT : une fois par heure visiblement, à xx:04:18 Après vérif sur htop, le process coupable est python3 /usr/share/mailman3-web/manage.py runjobs hourly 100% sur un CPU et 50% RAM pour lui tout seul. Issue pertinente : https://github.com/maxking/docker-mailman/issues/327 Et https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/E6OLOJAGNPGYFTXZO7AVRWOC762RFGLH/ Conclusion : l'indexeur par défaut de Mailman3 est gourmand du cul, mais on peut décréter qu'on s'en tape pour l'instant. [korenstin] limitation bande passante installation de fail2ban ? (log owl, un peu trop de ssh invalide a mon gout x) ) y a pas que owl, il y a aussi gulp, et pourquoi on n'installe pas fail2ban de partout ? seulement necessaire sur les vm a ip publics justement, il n'y aurait pas certaine machine à IP publique sans fail2ban ? on a pas de fail2ban au crans a ma connaissance ça peut s'arranger... ~160/s pendant ~15min : https://grafana.crans.org/d/i9e_8GkWz/accueil?orgId=1&from=2025-06-18T18:40:47.445Z&to=2025-06-18T19:01:59.773Z&timezone=browser&refresh=30s

=== MONITORIIIINNNNG === [Lzebulon] nouvelle politique de mise en place de service : pas de création de services sans monitoring fonctionnel et check (avec dashboard grafana accessible) monitoring en particulier de la bande passante de chaque service D'ailleurs, est-ce qu'on ne referait pas certains graphes de grafana histoire que ce soit plus simple de monitorer (et jsp si grafana le permet mais ajout d'alerte en cas de sur utilisation du réseau) les alertes c'est prometheus, mais oui il faut faire ca

[Lzebulon] regroupement des logs dans graphane : <- graphane ou grafana ? oui grafana, il etait un peu trop tard pb de RGPD ? si fait : evidement seulement accessible si connecte et role de nounous (apprentie ?) [Hachino] Comment on débranche des alertes Prometheus (pour calmer un peu #roots/logs) ? Faut les droits nounou ? c'est espilonesquement pénible... en fait prometheus possède un délai de conservations des erreurs de ~3mois je crois et c'est supprimé qu'une fois passé ce délai. J'imagine que c'est possible de le faire à la main. certains diront que la meilleures facon de debrancher les alertent est de fix les pb certains pb ne peuvent pas être fix puisqu'il s'agit de machine qui n'existe plus et que prometheus n'arrive plus à contacter... C'est à celles-là que je pensais en priorité (c'est simple, on casse rien si on fait de la merde (famous last words), idéal pour apprendre). Sinon, "délai de conservation des erreurs" ? Si on réécrit la config pour tuer une alerte, Prometheus la fire encore 3 mois plus tard ? Jsp je ne connais pas les effets de bords de prometheus... (en toutes logiques, je pense que oui mais je suis tout sauf un professionnel contrairement à ce qu'une certaine maman du crans prétend régulièrement...). Je pense quand-même que prometheus doit avoir une option pour remove une alerte dans ce genre de cas mais je ne me suis pas trop pencher sur la question. Je tombe sur cette doc en cherchant un peu, à creuser tout à l'heure peut-être : https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/ La conf est plus ou moins dynamique... Une partie du monitoring est géré (au moins en partie) par la conf du LDAP, et si devais parier, je dirais qu'il s'agit d'un script python qui réactualise la conf via un cron (j'ai gagné ! /var/local/services/prometheus-target/, https://gitlab.crans.org/nounous/prometheus-target)

[Lzebulon] (si jamais on manque de points) generation auto de la doc qui_est_qui, avec une concatenation de fichier hosts/{physique,vm}/*/README.md pour chaque host dans le repo nix + un README.md par defaut pour les vm sous debian ou/et physique à ce niveau là, pourquoi ne pas fusionner nixos et documentation ? (au moins pour la partie technique) [ps : on ne manque jamais de points... plus sérieusement, ça veut dire que le crans vit] parce que c'est pratique de tout avoir sur une page, un CTRL+F suffit (on pourrait aller plus loin et generer de la doc avec la config nixos, IP, services, etc...) En soit, c'est pas une mauvaise idée, je crois que nix-topology peux aider dans ce cas. Je ne vois pas particulièrement de problème à mettre de la doc dans modules/services, que se soit à coup de README ou de commentaire ça reste plus ou moins centraliser et c'est potentiellement à l'endroit le plus important lors des modifs

=== C'est aussi important ===

[Lyes] Impossible de créer un nouveau compte sur le wiki crans (erreur 502). ça ne semble ni venir de anubis ni du passage de hodaur à reverseproxy (c'est déjà ça) [Pigeon] Passation de la VM bde-note à des plus jeunes du BdE [korenstin] préparation rentrée (séminaires, semaine d'inté, présentation du crans (amphi de rentré et forum des assos), projet apprenti·es, install-party, ...)

=== Si on a le temps 2 === [Lzebulon] suppression de vm : Trinity Éclaircie ? [korenstin] partition de 44G sur gitzly qui ne semble pas utiliser [Pigeon] Stirling PDF crash sur la conversion HTML -> PDF [Lzebulon] mail sur nextcloud [Hachino] L'éternel problème des dossiers Nextcloud/Owncloud pas symlinkés dans certains /home [korenstin] création vlan [Pigeon] Installation de helix sur zamok (faut toucher aux sources APT) [Pigeon] Dovecot -> tous les dossiers ne sont paprogrammess regardés par les clients, il faut manuellement aller sur chaque dossier pour voir s'il y a eu de nouveaux mails Jsp si ça se règle côté serveur, mais j'ai aucun problème sur mes autres mails seulement celui du Crans [Hachino] Oh tant que j'y pense : contacter les grands opérateurs mails pour vérifier notre réputation auprès d'eux ? Marre que nos mails n'arrivent pas à nos adhérents (ça ou la ML événements)

=== En bref ===

Les switchs arceus et carapuce sont devenus injoignables depuis l'extérieur. Thot aussi, du coup restic se plaint. Suite à un mauvaise configuration. Descente en salle serveur il y a 4 mois pour résoudre mis à ajour de la table des switch Tiens, Borgmatic se met à se plaindre sur Gitzly lui aussi. Il y a eu un début de passage de gitzly vers bookworm mais la procédure a été interrompu par une version pas à jour de gitlab, update de gitlab impossible à cause d'une vielle version de postgreSQL. C'est probablement la cause des erreurs

Modification des templates sur mailman pour les mails en attente de modération pour qu'ils soient plus clair.

incident vm en7 mise à jour de debian vers bookworm. Il manquait de la place sur le disque. Après augmentation de la taille des partitions, kernel panic, réinstall Lyes/korenst1 en allant cherche la doc manquante dans les backups Impossible de faire des modifs, des backups, d'éteindre, de supprimer le disque pour une réinstal, obligé de supprimer la VM de Sam pour le recréer après

sam et des problèmes Deuxième problème pour redémarrer la VM apprentix, elle a été déplacée sur un autre hyperviseur (jack) et depuis elle remarche très bien. On soupçonne que Sam a des problèmes plus profonds (ça et les ventilos changés souvent, ça fait beaucoup), il faut être vigilants.

=== Mettre à jour PostgreSQL sur tealc ===

Pas encore critique mais bientôt On est en version 13, la dernière version sortie est la 17 (et 18 en beta) euh on est sur de l'info ? parce que sur sam, daniel et jack le serveur est la version 15.13 mais tealc en version 13.21 j'ai rien dit, la db est toujours en 13 besoin pour gitlab 18 (et 17 techniquement...) voir replication ?

PostgreSQL est très important car beaucoup de services dépendent de lui (dont gitlab qui ne peut pas être mis à jour) Les mises à jour doivent être effectuées une à une, et pigeonmoelleux et lzebulon ne savent pas s'il est possible de le faire pendant que les services sont en fonctionnement

=== redémarrage des serveurs août ===

test de si le système de routeur fonctionne Comprendre pourquoi l'ensemble des machines se sont éteintes (suite à un certain incident) qui à déconnecter le sam (et donc rsam) de tout réseau (adm, srv-nat, srv, 2756, aurore, ...) update / upgrade des serveurs sous bullseye vers bookworm (voire trixie si déjà sortie) vérifier / configurer les éléments manquant ou en trop sur proxmox (typiquement le port série, qemu-guest à désactiver pour certains services) High-avaibility pour les services importantes (paas les routeurs mais d'autres machines importantes : owl, redisdead par exemple) vérifier / débugger les problèmes les problèmes sur sam (cf point à l'ODJ) upgrade la version de postgresql (cf point à l'ODJ) Créer un pad avec la liste des trucs à faire et penser à le copier en local...

=== le wiki et le gitlab ont de forts piques de ping au point de rendre les services inaccessible (status.crans.org) toutes les ~5h, scraping ? DDoS ? ===

bot IA qui scrappe nos sites (au point de DDoS le wiki) Anubis a été installé pour certains services : wiki, mediawiki, mirrors et install-party mais pourrait empêcher status.crans.org de bien tout surveiller. eclat.crans.org (http) miroir a été désactivé pour éviter scrap des bots. Pas possible de (facilement) retirer eclat.crans.org.

Il y a une deuxième vm de reverseproxy, nom de code : reverseproxy, qui hébegerge.

la conf anti robot semble assez efficace (réduction drastique de la bande passante sur reverseproxy) passons nous eclat (http, pas la version https) par reverseproxy ou on laisse l'ip publique ?

=== Dans la même veine, Mailman sature sa RAM plein de fois par jour. Pas très grave a priori, mais pourquoi ? === EDIT : une fois par heure visiblement, à xx:04:18 Après vérif sur htop, le process coupable est python3 /usr/share/mailman3-web/manage.py runjobs hourly 100% sur un CPU et 50% RAM pour lui tout seul. Issue pertinente : https://github.com/maxking/docker-mailman/issues/327 Et https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/E6OLOJAGNPGYFTXZO7AVRWOC762RFGLH/ Conclusion : l'indexeur par défaut de Mailman3 est gourmand du cul, mais on peut décréter qu'on s'en tape pour l'instant.

=== limitation bande passante ===

Configuration d'une limitation de la bande passante pour éviter à aurore d'avoir des dépassements (et de nous le faire payé) Limitation sur les switchs ? Sinon limitation au niveau des routeurs à configurer (limitation 100Mb/s entrant et 100Mb/s).

Installation et configuration de fail2ban pour les machines à ip publique au crans Règle : pour ssh : whitelist les ip du crans maxretry: 4 bantime: 1h bantime-increment maxtime: infinity cf conf de Pigeon pour s'inspirer : https://gitlab.crans.org/pigeonmoelleux/nixos/-/blob/main/modules/services/fail2ban.nix?ref_type=heads Il y a un concept de "jail" pour les récidivistes : https://stackoverflow.com/questions/66392687/fail2ban-how-to-ban-ip-permanently-after-it-was-baned-3-times-temporarily

monitorin sur fail2ban : Lzebulon s'est gentillement proposé pour le faire ! merci beaucoup !!!

~160/s pendant ~15min : https://grafana.crans.org/d/i9e_8GkWz/accueil?orgId=1&from=2025-06-18T18:40:47.445Z&to=2025-06-18T19:01:59.773Z&timezone=browser&refresh=30s

=== nouvelle politique de mise en place de service : pas de création de services sans monitoring fonctionnel et check (avec dashboard grafana accessible) ===

L'absence de monitoring gêne pour le débug. Pour simplifier le débug et être alerter lors de pb, l'ajout d'un services est désormais subordonné à l'ajout du monitoring associer (loi passée par décret maternel). Grafana a des dashboards pré-impléms, certains services viennent avec du monitoring par défaut, bref c'est pas censé être trop difficile Exemple : https://grafana.crans.org/dashboards/f/depm89vkifshsb/?orgId=1 Le monitoring de la bande passante de chaque service avec des alertes. D'ailleurs, est-ce qu'on ne referait pas certains graphes de grafana histoire que ce soit plus simple de monitorer (et grafana permet l'ajout d'alerte en cas de sur utilisation du réseau c'est aussi possible sur prometheus.

=== regroupement des logs dans graphane : <- graphane ou grafana ? oui grafana, il etait un peu trop tard ===

loki peremt de regrouper le log de grafana pour aider le monitoring. Loki permet d'avoir accès au log sur une plage de temps qu'on peut sélectionner..

Les logs possèdent des ip qui correspondent à des données personnelles. Ne pas donner accès au log aux apprenti⋅es. L'utilisation des logs pour le debug est une utilisation légitime (au sens du RGPD) pour la protection du crans.

=== Comment on débranche des alertes Prometheus (pour calmer un peu #roots/logs) ? Faut les droits nounou ===

Un script random du crans regarde dans le LDAP pour synchroniser et configurer. cf le script : https://gitlab.crans.org/nounous/prometheus-target nettoyage de excalibur, ecilis, collabora pas touche aux ilo-*, printer-lp, neo, en7 (bind), belenios ecilis si éteinte casse le dns du crans, donc important de garder !!! Lzebulon dit qu'il y a un foirage quelque part sur la config prometheus de neo thot : en attente (on a thot.crans.org et thot.adm.crans.org) odlyd : problème de carte réseau et de ventilos, joie Suppression de éclaircie (Nextcloud-old), Trinity (matrix-old et bridgematrix-old), lynx (pour son historique sulfureux), aeris (probable VM de test de ds-ac) sword = VM pour Excalidraw, projet mis en attente de manière indéfinie redite n'est pas (encore) dans Nounous/Documentation one : esum & shirenn, test NixOS, brûlable two : VM de référence/test pour NixOS de Pigeon, à garder hydra-one : test d'Aeltheos de hydra, brûlable test-debian-postfix (x2) : osef ?

=== generation auto de la doc qui_est_qui, avec une concatenation de fichier hosts/{physique,vm}/*/README.md pour chaque host dans le repo nix + un README.md par defaut pour les vm sous debian ou/et physique ===

Générer le qui_est_qui automatiquement avec nixos. Dans chaque dossier de nixos, un README soit ajouté un qu'un script concatène ces fichiers pour en faire un README Lzebulon subodore qu'une CI/CD pourrait faire l'affaire

La doc restera dans documentation sauf les README.

=== Impossible de créer un nouveau compte sur le wiki crans (erreur 502). ===

Ça ne semble ni venir de anubis ni du passage de hodaur à reverseproxy

=== Passation de la VM bde-note à des plus jeunes du BdE ===

Toutes les vms de clubs n'ont pas donné de personnes dans le club pour substituer

=== préparation rentrée (séminaires, semaine d'inté, présentation du crans (amphi de rentré et forum des assos), projet apprenti·es, install-party, ...) ===

Forum des associations : possiblement ramener un serveur ou un switch projet apprentisrécupérer le pad projet apprentis : https://pad.crans.org/p/projets-apprentis install-party : pour fin de support de windows 10 -> date : voir CA (Samedi 11 octobre) proposer plusieurs créneaux pour faire des install'. Événement avec install' linux et/ou d'installation : thunderbird, firefox, nextcloud crans (et conf nextcloud-desktop), sync todo list, contact, gestionnaire de mot de passe.

avoir les dates du BDE pour choisir l'orga

=== partition de 44G sur gitzly qui ne semble pas utiliser ===

Pas utiliser depuis 2021. Peut-être supprimer et l'espace dispponible réalloué.

=== Stirling PDF crash sur la conversion HTML -> PDF (et PDF -> {Word,ODT}) ===

Tester de redéployer stirling et peut-être que ça a été fix et en réactivant les dépendances. problème de droit aussi.

=== mail sur nextcloud ===

Nextcloud ne peut potentiellement pas envoyer des mails. pigeonmoelleux a réglé le pb en direct live.

Est-ce qu'on propose d'utilise nextcloud comme client mail ? nextcloud est assez lourd et possiblement pas très utiliser. Le plugin semble être un plugin officiel. connexion rouncube-nextcloud : https://apps.nextcloud.com/apps/mail_roundcube semble maintenu (màj ~récentes) Projet apprenti⋅es

Sondage : que pensez-vous des services du crans (et du Crans lui-même) ?

=== L'éternel problème des dossiers Nextcloud/Owncloud pas symlinkés dans certains /home === Un script sur cameron s'occupe normalement de créer les /home, d'autres pour Owncloud/Nextcloud. Pour NC, il suppose l'existence du dossier OC, crée le dossier NC et le symlinke Pendant un temps, OC ne checkait pas le bon sous-dossier, mais ce point a été corrigé pour les nouveaux adhérents. Il en reste une tranche temporelle passée à la trappe (Lila, Romain par exemple). "Personne n'a envie de toucher à des scripts Python" -- Pigeon

korenst1 se propose pour modifier les scripts Python pour corriger le problème. Possible de tenter de faire un petit script pour corriger les anciens comptes. Lzebulon dit qu'en principe le problème est résolu pour les nouveaux adhérents, il suffirait de résoudre à la main le souci sur les "oubliés"

=== création vlan ===

vlan 15 = vlan de test (quand le vlan sera créé)

=== Installation de helix sur zamok (faut toucher aux sources APT) ===

pigeon s'en charge, en plus de rajouter le repo au mirror

=== Dovecot -> tous les dossiers ne sont pas regardés par les clients, il faut manuellement aller sur chaque dossier pour voir s'il y a eu de nouveaux mails ===

Jsp si ça se règle côté serveur, mais j'ai aucun problème sur mes autres mails seulement celui du Crans. Personne ne sait... Pigeonmoelleux va débugger

=== Oh tant que j'y pense : contacter les grands opérateurs mails pour vérifier notre réputation auprès d'eux ? Marre que nos mails n'arrivent pas à nos adhérents (ça ou la ML événements) ===

Des opérateurs nous ban, des gens reçoivent pas leurs mails (La Poste, Microsoft, etc). C'est chiant, alors qu'on respecte toute les règles et bonnes pratiques (SPF, DKIM, SRS). Hachino souhaite checker la réputation des serveurs mails du Crans auprès des grands opérateurs. Lzebulon suggère de regarder du côté de DMARC (on serait peut-être trop laxistes en entrée et ça nous donnerait une mauvaise réputation en sortie).

Tiens, Talos intelligence (opéré par Cisco) nous met une réputation Neutral : https://www.talosintelligence.com/reputation_center/lookup?search=crans.org

Extrait de mailq de Mailman :

A03B122BAD 11079 Sun Jun 22 00:11:37 ens-saphire11-bounces+[censuré]=laposte.net@lists.crans.org (host smtpz4.laposte.net[160.92.124.66] said: 450 4.7.0 Service refuse. Veuillez essayer plus tard. service refused, please try later. LPN007_510 (in reply to end of DATA command)) [censuré]@laposte.net (host smtpz4.laposte.net[160.92.124.66] said: 450 4.7.0 Service refuse. Veuillez essayer plus tard. service refused, please try later. LPN007_510 (in reply to end of DATA command)) [censuré]@laposte.net

=== Drop du Stop/Spam sur Mailman au profit d'Anubis ===

korenst1 trouve que c'est une bonne idée. Le reste des gens présents n'objecte pas. Il s'en occupera quand il pourra et voudra. NB : penser à mettre à jour le message générique des mails de modération de Mailman (voir doc à ce sujet)