diff --git a/compte_rendus/2026_02_21.md b/compte_rendus/2026_02_21.md new file mode 100644 index 0000000..dd0fd1f --- /dev/null +++ b/compte_rendus/2026_02_21.md @@ -0,0 +1,578 @@ +# Réunion IN + +Date : Samedi 21 février 2026 +Lieu : MB87 et Galène +Début : 17h15 +Fin : 20h24 + +## Présent⋅es + +* Pyjacpp +* RDBris +* Pigeon Moelleux +* Hachino +* Lzebulon + +## Ordre du jour + +[Lzebulon] mini-seminaire ceph +[Hachino] (26/01) +[Pyjacpp] Point RGPD +[Pyjacpp] Que faire des comptes inactifs ? +[Pyjacpp] un who sur zamok renvoit la liste des personnes connectées (avec IP...) +[Pyjacpp] +[Pyjacpp] +[Pyjacpp] Point mails +Un envoi de mail non authentifié depuis zamok est considéré comme safe +(e.g. gmail le considère legit) +Pas de SPF sur lists.crans.org ? +un email random ou avec un de tes alias (non authentifié, donc complètement +random mais j'ai testé avec un de mes alias)? +[Pyjacpp] ! 2 disques cameron débranchés... (et rebranchés) +Finalement pour répondre au scsi vs ATA ? du dernier point, +oui il y a des différences... (à moyen-long terme ça abîme askip, +à court terme izok) +[Lzebulon] ceph enfin bientot la ? +[Pyjacpp] Lancement des scrub sur les hyperviseurs le même jour, +c'est pas malin ? +[Pyjacpp] On fait quoi des nouveaux serveurs / d'odlyd +[Lzebulon] jack +[Pyjacpp] sam et daniel +[bleizi] (11/02) Modération des mails de spam prétendant venir de .crans.org ? +[Lzebulon] hosts.nix pour la conf nixos +[Lzebulon] meilleure resilliance aux pannes : +redemarrage auto de certainnes VM (ldap) +[Pyjacpp] Nextcloud : mettre la partie data sur une vraie partition de données ? +[Pyjacpp] Point convention ? +[Pyjacpp] On annonce du BGP à Aurore ? C'est les routeurs qui s'en chargent ? +[lzebulon] oui et oui, sinon personne pourrait accéder à nos services, +on utilise pour cela bird + +[Hachi-flood] + +* MàJ des options de borgmatic sur ~toutes les VM. Il manque le mysql sur + Zamok qui est complètement daubé. + zamok:/etc/borgmatic/config.mysql.yaml avait son source_directories vide. + Fichier inutile, déplacé dans mon home nounou au cas où, mais probablement + à delete un jour. Service stop/disable (pas mask) et target commentée sur fyre + pour couper les mails inutiles. +* Quelques lignes de monitoring commentées dans le LDAP et sur fyre : + peertube node/nginx, zamok mysql, sondages node +* systemd-networkd-wait-online.service a disparu de cameron ? Ou alors, + le service n'est pas nécessaire ? +* ilo-gulp : ptet qu'il faut un mdp ("community") pour que Prometheus arrive à le + contacter ? EDIT : réglé par Pyjac et Lzebulon +* python2.7 sur pas mal de VM et physiques (hors kiwi) : suppression sans danger + a priori, mais je préfère demander ? +* owl et gitzly encore sous bookworm : gitzly attendait son upgrade pgsql et + on a pas eu le temps je crois, mais owl, c'est un oubli ? +* owl : la conf de dovecot change + projet de nixification de la VM +* Imprimante : depuis son reboot, elle refuse d'essayer d'envoyer les scans + (donc ne fait plus sauter les plombs, bon point). + En tentant avec Kinak (3 février), on a vu un message "scan disabled by admin". + Pas compris. +* Note to self : la carte du réseau, vraiment une bonne idée. + (IP, sous-réseaux/VLAN, ce genre de chose) + dans gitlab:Nounous/Documentation Nounous/nixos +* Présences aux séminaires récents : décomptes +* TODO : swap les disques scsi de cameron pour les SATA récemment rachetés + et lancer un zpool replace EDIT : fait une fois par Pyjac et Lzebulon +* schumpy : erreurs IMAP sur ses dossiers, apparemment il manque un +x sur ses + dossiers ? (journalctl -f sur owl) --> Traité + cron:/var/local/services/robots/robots.py sur Zamok un peu trop fréquent et + probablement très daté, donc commenté pour l'instant, on verra plus tard. +* Disques à potentiellement changer sur cameron +* scsi : pas forcément prioritaire, mais pourquoi pas [Done] +* zpool iostat -vl 60 pour avoir une petite stat générale des disque + (notamment le total_wait) [Stats qui semblent ok, cf plus bas.] +* sdg : ata-ST3000NM0033-9ZM178_S1Y03Y1N (stat de synq à surveiller notamment) + 72000h d'uptime, soit plus de 8 ans, il est ptet fatigué [Tous, en fait.] +* Obtenir la correspondance emplacement physique <-> sdX : + pool offline pool ata-... et la LED s'éteint + [En fait non, elle reste allumée fixe, mais osef.] +* Vague de mise à jour des VM sous NixOS ? J'en vois sous 24.11 +* Disque neuf ATA installé dans Cameron à la place du SCSI, resilver terminé. +* La plupart des autres disques ont entre 63k et 73k heures de fonctionnement. +* Rattrapage de quelques CR en retard sur Gitlab:Nounous/Documentation +* Contact de M$ pour tenter d'augmenter la réputation de Mailman + +## Mini-séminaire Ceph + +Question spécifique sur les mails : l'Inbox est stocké dans le home-adh, +alors que les autres dossiers sont ailleurs. +Choix pour alléger le chargement des mails ? +Refonte de la gestion des mails à prévoir au passage à Ceph ? +Dovecot peut récupérer les mails lui-même (d'après Pyjac) ? + +Ceph connaît la notion de host et va par défaut chercher à répliquer sur des +hosts différents. Au pire il existe des options pour le paramétrer explicitement. + +## Point général mails + +* Un envoi de mail non authentifié depuis zamok est considéré comme safe + (e.g. gmail le considère legit) +* [bleizi] (11/02) Modération des mails de spam prétendant venir de .crans.org ? +* lists.crans.org +* Pas de SPF sur lists.crans.org ? +* un email random ou avec un de tes alias (non authentifié, + donc complètement random mais j'ai testé avec un de mes alias)? +* [Hachino] + +Hachino donne l'exemple de l'Ensae : sur le Wifi du personnel, +le serveur mail est en open relay, pas sur Eduroam ni sur le Wifi élèves. +Inspiration pour le Crans ? +Pour l'enregistrement SPF de Mailman, très minimaliste, il faudrait se +renseigner sur la conf recommandée par les dévs de Mailman. +PEB est un maintainer de Mailman, si jamais. + +## Point global sur le RGPD + +* [Pyjacpp] Que faire des comptes inactifs ? +* [Pyjacpp] un who sur zamok renvoit la liste des personnes connectées (avec IP...) +* [Pyjacpp] +* [Pyjacpp] + +La CNIL recommande, au bout de 2-3 ans d'inactivité, d'envoyer un mail à la +personne. Si pas de réponse, fermeture de compte. +Problème : comment détecter l'inactivité ? +D'autre part, plein de vieux comptes n'ont pas de mail associé. +Et on a eu plusieurs cas de très vieux comptes (entre 2006 et 2010) +qui ont demandé à retrouver leurs accès. +Check le .forward des gens pour "authentifier" les demandes de réactivation ? +Attention, le champ "dernière connexion" sur Re2o n'est que la dernière +connexion à l'intranet, pas aux autres services (dont les mails ou le Nextcloud). + +Gestion des comptes dans Ceph par SAML obligatoirement. +Pigeon soupire. Dex permet de le faire automatiquement. +Qui plus est, on aurait besoin de Dex pour l'OIDC et le 2FA. + +Pyjac : garder le dernier accès sur Re2o et d'autre part, le dernier bind LDAP. +Re2o pourrait éventuellement regarder dans un champ du LDAP qu'il faudrait créer. +Plusieurs envois de mails pour prévenir de la désactivation prochaine du compte. +Pas mal de développement à prévoir mine de rien. + +Question plus CA, mais d'après le RGPD on est censés avoir un référentiel de +traitement des données. +Bon, le CA sera pas capable de produire un tel document de toute façon. + +Référencer les services qu'on a et remplir ça en tâche de fond ? +Début de rédaction par Lzebulon ci-dessous. + +```text + +RGPD + +Le RGPD est un réglement européen qui restreint le traitement des données +afin de protéger les utilisateurs. + +Les rôles au Crans + +* Président.e +* Secrétaire +* Trésorier +* Bureau +* CA +* RTC +* Nounous +* Apprenti.e. + +Les données traitées + +Truc + +* Finalité +* Base légale +* Durée de rétention +* Données concernées +* Localisation des données +* Mesure de sécurité +* (Point d'attention) + +Registre des membres + +* Finalité : liste des membres de l'association +* Base légale : intérêt légitime +* Durée de rétention +* Données concernées : pseudo, identité (étatique), email de contact +* Localisation des données +* Mesure de sécurite +* (Point d'attention) +``` + +Aller voir le DPO de l'ENS ? + +En termes d'abus, par exemple pour Matrix, que faire ? +On avait eu une réunion avec le BDE pour parler modération, mais ça s'est pas fait. +On a un abuse@ ? Oui, alias de root@ (cf Gitlab:Nounous/mail-aliases). + +## Disques débranchés sur Cameron + +[Pyjacpp] ! 2 disques cameron débranchés... (et rebranchés) +Finalement pour répondre au scsi vs ATA ? du dernier point, +oui il y a des différences... +(à moyen-long terme ça abîme askip, à court terme izok) +Disque neuf ATA installé dans Cameron à la place du SCSI, resilver terminé. +La plupart des autres disques ont entre 63k et 73k heures de fonctionnement. + +## Ceph + +[Lzebulon] ceph enfin bientot la ? + +On espère. + +## Jack, scrub/trim + +[Pyjacpp] Lancement des scrub sur les hyperviseurs le même jour, pas malin ? + +Jack a reboot tout seul une nuit, Pyjac l'a rallumé vers 7h du matin. +Il est peut-être plus vieux que Sam et Daniel. +EDIT : les trois sont des Gen8, pas de différence notable. +Mise à jour du noyau Linux qui aurait déclenché ce reboot intempestif +plusieurs semaines après. +Désactivation d'une option dans le kernel par Lzebulon. + +Scrub : 2nd dimanche du mois (la nuit) vérifie les erreurs de la pool +D'après Korenst1, si tu n'accèdes pas à tes données pendant longtemps, +ZFS cesse de le lire et peut poser des problèmes de type +"erreurs passées inaperçues". +Un scrub est censé relire une fois toutes les données pour faire apparaître +d'éventuelles erreurs de réplication. +Problème : tous les hyperviseurs le font ~en même temps. +Jack est le moins critique des trois, +sur Sam ou Daniel on aurait vraiment moins apprécié. +Trim : 1er dimanche du mois (la nuit). On sait pas trop ce que ça fait. + +En principe, Sam, Daniel, Jack sont pas censés reboot après un unattended-upgrades. + +## Odlyd, Cora-1, Cora-2 + +Odlyd : à réparer un jour, il a été dépouillé de ses ventilos +et il a un problème de carte réseau. On demande au CA de racheter du matos ? +Pigeon dit que pour lui, la carte réseau ne fonctionne pas. +Odlyd boote, déjà essayé de changer la carte (par celle d'un autre serveur) +mais pas réussi, ça ne fonctionnait pas. Carte de rab en bas ? +Piquer des composants dans Cora-{1,2} pour les tester dans Odlyd, +au moins pour débug, ensuite on rachète les compos ? + +Sur le cluster adh : + +* 3% CPU utilisé (sur les 48 coeurs), +* 40% RAM utilisée, +* 5% stockage (sur 24 To). + +C'est peu utile de buff ce cluster. + +Cluster adm : + +* 50% RAM (parce que jack se touche), 141/280 Go, +* 10% CPU, +* 7% stockage (sur 33 To). + +Faire gaffe à Ceph pour interpréter les chiffres du stockage. + +Warning : on est samedi après-midi, peut-être qu'on a un peu plus +de trafic la semaine. En vrai il faut pas s'attendre à énormément plus. +Ce qui consomme de la pusisance, +c'est par exemple un build/une compilation un peu lourde. + +La puissance inutilisée pourrait servir à Peertube, pour de l'encodage vidéo. +On a de quoi déployer plus gros, mais déployer quoi ? + +Blague : CransAI. Rezel le fait, certes, mais on a pas de GPU et c'est pas trop +notre came. + +Pyjac remet sur la table l'idée d'une réunon avec les autres assos pour +leur demander leurs besoins. Lzebulon veut en reparler dans le point convention. + +## Fichier hosts.nix + +Lzebulon a pour envie de remanier la conf NixOS, pour avoir un hosts.nix +avec les données importantes des VM dedans. +Ça remplace un peu grossièrement le LDAP (c'est une source de vérité). +Permet notamment de gérer de la doc, de la conf des switchs, +permet de savoir où regarder les infos des VM,... +Aurore a un hosts.nix bien fourni qui peut servir de modèle +(il n'a pas tout à fait la même syntaxe que l'idée de Lzebulon). + +Cf : + +## Redémarrage auto de certaines VM (dont le LDAP) + +Lzebulon propose d'activer le HA sur le LDAP. Meilleure résilience aux pannes, +permet de se connecter. DNS même chose (romanesco et silice). +Pyjac a eu une mésaventure une fois, il a fallu un dig pour retrouver les IP et +faire du jump SSH avec les IP en dur. + +## Nextcloud : mettre la partie data sur une vraie partition de données + +Pour le Nextcloud qui se remplit, les fichiers sont pointés comme sources de +données extérieurs (le home_nounou est extérieur). +Tout le data de Nextcloud est dans la VM, or certaines données +sont plutôt typées "adhérent" et sont dans la VM. +Cette partition est un peu "style data", plus les données de cache, +nettoyage périodique à faire peut-être. +Peut-être que ça attendra Ceph. +Mettre ce système de fichier dans une vraie pool ? +Ou augmenter le quota de données ? + +Lzebulon : amélioration des performances dans les nouvelles versions, +visiblement améliorations côté cache. +Prochaine MàJ de Nextcloud dans la prochaine MàJ nixpkgs. +La MàJ sera probablement backportée (Pigeon). + +## Point convention + +Hier, Lzebulon et Lyes étaient en réunion avec Christophe Huet (le DSI), +quelqu'un de la DSVE, quelqu'un de la DPAT pour reparler de la convention Crans-ENS. + +Christophe Huet semblait étonné que l'on ait ce local en SQ39, sachant que +c'est le local d'arrivée de la fibre ENS (!) et que le local n'a pas de dispositif +anti-incendie. Il se posait des questions sur notre présence ici (nous aussi). +Il va se renseigner. Le plus important : il (Huet) veut faire une réunion en +présentiel avec un tour dans les locaux pour faire un point. +La DSVE serait intéressée pour voir à quoi ressemble la salle serveurs. + +Mdr l'habilitation élec. + +IL FAUT TOUT RANGER ! Il y a eu pas mal d'amélioration côté MB87, +mais ça reste pas foufou. SQ39 izok à peu près, faudrait faire la poussière. +Déplacer Cora-2 du haut de l'armoire (par exemple en MB87 temporairement), +la DPAT/DSI pourrait tiquer sur le côté dangereux. +Ping Gabo pour avoir ses dispos, il y a des chances qu'il soit libre. +Lyes sera en stage à Strasbourg à partir du 16 mars, pas dispo. + +Lyes et Lzebulon ont appris que le Crans est cité, dans les conventions avec les +autres assos, comme "fournisseur unique et officiel de services numériques". + +Lyes : "Ah ? On était pas au courant." + +C'est dans l'annexe 3 des conventions avec les autres assos. +C'est bien, on la découvre (cf les mails reçus sur nounou@). +On découvre la nouvelle trame en cours de négociation avec les autres assos. + +1. Est-ce que cette clause figure toujours dans les conventions avecles autres + assos ? (Pas notre problème.) +1. La DSVE veut assez vite un état des lieux des autres assos qui utilisent nos + services. Base légale ? RGPD ? +1. Les services qu'on fournit à "tout le monde" : ça c'est facile, ça n'a pas + trop bougé depuis la dernière convention. + +Pas mal d'assos ont des choses qui traînent chez nous (des mailing-lists notamment), +mais plusieurs semblent tombées en désuétude. + +La DSVE dit "assos", mais ils doivent avoir en tête "club BDE/BDA + assos déclarées" +en vrai. Cas des services en libre accès, comme Frama* ? + +Lyes pourrait envoyer un mail demandant aux assos qui utilise nos services, +répondra qui voudra et on transmet. Comme ça on se met pas à dos la DSVE +et on ne va pas contre le RGPD. + +Vérifier cette histoire de charte interne/RI qui nous obligerait à donner à +l'ENS la liste des adhérents ? (RGPD mdr ?) + +Ne pas trop insister sur les anciens adhérents, ils risquent de pas trop aimer. + +Lyes a mis les deux pieds dans le plat pour faire des maintenances plus longues +une fois par an. Huet semble favorable. La DPAT semble pas contre non plus, +il faut qu'ils vérifient quelques détails. Les vieux en SQ39 ? +Pas l'air très totalement opposés, mais plus gros doutes sur la faisabilité légale. +Les traiter comme des prestas extérieurs ? Huet appuie ce point. +Huet s'est plaint à quelques reprises de la gestion par l'ENS de ses prestas. + +Lyes a demandé une reconduction tacite, ils avaient pas l'air chauds, +Huet aimerait au contraire une reconduction tacite +(par exemple sur l'élec pour la DSI). +La vie là-haut a l'air pas trop fun. Donc il semble soutenir notre idée. + +Côté "reste de l'admin" : "Oui mais on restructure, gnagna" +Lyes : "Oui mais nous ça fait depuis 2021 qu'on essaye de la renouveler. +En plus avec 6 mois de préavis pour la rompre." + +On a laissé tomber l'idée de pouvoir fournir un Wifi adhérent dans l'ENS, +notamment pour les admissibles. D'un point de vue CT personne veut faire ça, +d'un point de vue DSI, personne là-bas veut toucher aux bornes Wifi, +ils ont l'air d'en faire des cauchemars. + +Fournir l'accès filaire dans les locaux associatifs semble envisageable, +les VLAN n'ont jamais été propagés d'après Lzebulon. +Pigeon a vu Aeltheos avoir accès au réseau du Crans dans la Med. +La DSI avait pété une conf de switch et nous avait bloqué l'accès à notre imprimante +pendant un temps. Bon au pire personne se connecte en filaire. +Borne Wifi Crans dans la Med ou la Kfet ? +Superposition des plages de fréquences avec celles de la DSI ? +Remettre en place un Radius ? + +Globalement la réunion était intéressante, tout le monde avait l'air partant. +Rester un peu méfiants vis-à-vis de leur attitude face aux vieux. +Quelqu'un a proposé de déplacer notre baie à côté de la leur : +MDR non, la zone est classée secret. + +La charte de vie étudiante autorise la participation ponctuelle +d'extérieurs sans prendre de "responsabilités". +Le Crans fait valoir une exception, qui semble passer à peu près +(cas des anciennes nounous qui ont une forme de "reponsabilité"). + +Sécurité incendie ? Huet va demander pourquoi on est là en SQ39. +Possiblement pour avoir les arrivées fibre Aurore/Viarezo + +la flemme côté ENS de tirer d'autres fibres ailleurs, c'était pratique. + +NB : l'admin a reconnu que venir d'Italie en présentiel faisait un peu loin. +Bon point. + +## BGP vers Aurore + +[Pyjacpp] On annonce du BGP à Aurore ? C'est les routeurs qui s'en chargent ? +[lzebulon] oui et oui, sinon personne pourrait accéder à nos services, +on utilise pour cela bird + +Si on a pas bird (pas de BGP), le monde ne peut pas nous contacter, +donc on le voit _très_ vite. Il est sur routeur-{sam,daniel,jack}. + +## Hachi-flood (blblblbl) + +### MàJ des options de borgmatic sur ~toutes les VM + +Il manque le mysql sur Zamok qui est complètement daubé + +zamok:/etc/borgmatic/config.mysql.yaml avait son source_directories vide. +Fichier inutile, déplacé dans mon home nounou au cas où, mais probablement +à delete un jour. Service stop/disable (pas mask) +et target commentée sur fyre pour couper les mails inutiles. +EDIT : on ne commente pas en JSON, ça n'existe pas. Il faut supprimer la target. +Quelques lignes de monitoring commentées dans le LDAP et sur fyre : +peertube node/nginx, zamok mysql, sondages node +Les commentairs en JSON n'existent pas. Supprimer le fichier. + +Le DSI a vu qu'on maintenait un Gitlab et il était surpris/content, +compte tenu de la difficulté à maintenir ce logiciel en bon état de fonctionnement. + +### systemd-networkd-wait-online.service a disparu de cameron + +Ou alors, le service n'est pas nécessaire ? + +Ne pas le supprimer. Le restart ne marche pas. +Fait chier, mais pas bien grave en vrai. + +### ilo-gulp : ptet qu'il faut un mdp ("community") + +Pour que Prometheus arrive à le contacter ? EDIT : réglé par Pyjac et Lzebulon + +Check. Il manque tealc et cameron. +Pyjac a changé le mdp de cameron, mais ça ne marche quand même pas. + +Pyjac en profite pour relever qu'un nettoyage du pass +(en contenu et en séparation d'accès) serait pas mal. + +### python2.7 sur pas mal de VM et physiques (hors kiwi) + +Suppression sans danger a priori, mais je préfère demander ? + +Oui. Les décomptes d'apt obsolete sont foirés sur les alertes, fait suer. + +### owl et gitzly encore sous bookworm + +Gitzly attendait son upgrade pgsql et on a pas eu le temps je crois, mais owl, +c'est un oubli ? + +owl : la conf de dovecot change + projet de nixification de la VM (à terme). +gitzly : augmenter la taille de son disque, pas assez de place pour mettre à jour. +Il faut supprimer une vieille pool qui nesert à rien, pour étendre la pool root. +C'est du LVM, sudo lvm puis lvmdisplay, on voit trois pools, +donc une de 40 Go avec # open 0 (les autres ont 1). +Il ne semble pas monté (lsblk). +C'est peut-être l'ancien /var/opt/gitlab ? On sait pas. +On est même pas sûrs que Gitlab utilise notre psql central, +plutôt un psql local à la VM. + +Le Gitlab du département info : les pauvres. +La DSI maintient déjà un Gitlab interne et pourrait sans grand coût +en maintenir un deuxième. Mihaela pourrait être ravie. + +### Imprimante + +Depuis son reboot, elle refuse d'essayer d'envoyer les scans +(donc ne fait plus sauter les plombs, bon point). + +En tentant avec Kinak (3 février), on a vu un message "scan disabled by admin". +Pas compris. +Peut-être que l'IP du serveur de scan.. en fait on sait pas. +Askip on a une autre imprimante dans ~1 mois. + +Dans la réunion avec l'admin, on leur a dit qu'on voulait changer +l'imprimante et la discussion a dérivé. +On a plusieurs imprimantes dans les locaux associatifs dont tout le monde +ou presque se fout. +Celle du BDA marchotterait, peut-être. + +Lzebulon : Si une imprimante bug, c'est son état normal. + +### Note : la carte du réseau, vraiment une bonne idée + +(IP, sous-réseaux/VLAN, ce genre de chose) dans gitlab:Nounous/Documentation Nounous/nixos +Rejoint en bonne partie le hosts.nix. + +### TODO : swap les disques scsi de cameron pour les SATA récemment rachetés + +Et lancer un zpool replace. EDIT : fait une fois par Pyjac et Lzebulon + +### schumpy : erreurs IMAP sur ses dossiers + +Apparemment il manquait un +x sur ses dossiers ? (journalctl -f sur owl). + +Traité. Il a suffi de chmod +x en copiant une conf fonctionnelle (genre la mienne). +Pyjac a trouvé plein d'autres exemples de gens qui ont le même souci, +mais comme les gens se plaignent pas, sans doute qu'ils ne s'en servent pas ? +Peut-être faire une passe un jour. + +### cron:/var/local/services/robots/robots.py sur Zamok un peu trop fréquent + +Et probablement très daté, donc commenté pour l'instant, on verra plus tard. + +Au moins une fois par heure. +Il reste quelques personnes honnêtes et de bonne foi entre deux crawlers IA. +Il faudrait le remettre en marche. +Le plus économe serait unscript qui appelle la MàJ à chaque changement +d'un robots.txt dans un /home, mais flemme, trop de dév. + +### Disques à potentiellement changer sur cameron + +* scsi : pas forcément prioritaire, mais pourquoi pas [Done] +* zpool iostat -vl 60 pour avoir une petite stat générale des disques + (notamment le total_wait) [Stats qui semblent ok, cf plus bas.] +* sdg : ata-ST3000NM0033-9ZM178_S1Y03Y1N (stat de synq à surveiller notamment) + 72000h d'uptime, soit plus de 8 ans, il est ptet fatigué [Tous, en fait.] + +Obtenir la correspondance emplacement physique <-> sdX : +zpool offline pool ata-... et la LED s'éteint +[En fait non, elle reste allumée fixe, mais osef.] + +### Vague de mise à jour des VM sous NixOS ? J'en vois sous 24.11 + +En fait je crois que j'ai rêvé. En revanche Nextcloud était 14 commits en retard, +Pyjac lance le refresh. + +### Rattrapage de quelques CR en retard sur Gitlab:Nounous/Documentation + +C'est fait. Ouf. + +### Contact de M$ pour tenter d'augmenter la réputation de Mailman + +SPF sur Mailman, once again ? Ajouter ~all dans le record SPF ? +Ou ajouter "mx include:crans.org ~all" dans le record ? +Pyjac l'a fait, c'était rapide. +D'après mxtoolbox c'est une bonne conf. On les croit, ils ont une bonne réputation. + +## Présences aux derniers séminaires + +* Présents au séminaire mail : huit personnes dans le public, + dont 3 curieux hors CT. Also : l'amphi 1Z71 est juste trop trop bien +* Présents au séminaire "codes correcteurs" : 8-9 personns dans le public, + dont cinq hors CT. +* Présents au séminaire réseau : cinq personnes dans le public, dont une hors CT. + +## On a récupéré l'accès au RIPE + +Merci esum ! Lzebulon aimerait remettre en place la sonde (anchor) +RIPE dans notre infra (la VM actuelle grub-panic, cf un ancien CR). +On gagnerait des crédits Atlas à utiliser pour voir l'état du réseau. +Pratique, ça fait du monitoring partagé.