579 lines
24 KiB
Markdown
579 lines
24 KiB
Markdown
# 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) <https://alphacorp.fr/2025/08/24/comment-corriger-les-problemes-de-dkim-spf-et-usurpation-didentite-sur-un-hebergement-mutualise-2/>
|
|
[Pyjacpp] Point RGPD
|
|
[Pyjacpp] Que faire des comptes inactifs ?
|
|
[Pyjacpp] un who sur zamok renvoit la liste des personnes connectées (avec IP...)
|
|
[Pyjacpp] <https://www.cnil.fr/sites/cnil/files/atoms/files/guide_durees_de_conservation.pdf>
|
|
[Pyjacpp] <https://www.cnil.fr/fr/passer-laction/les-durees-de-conservation-des-donnees>
|
|
[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] <https://alphacorp.fr/2025/08/24/comment-corriger-les-problemes-de-dkim-spf-et-usurpation-didentite-sur-un-hebergement-mutualise-2/>
|
|
|
|
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] <https://www.cnil.fr/sites/cnil/files/atoms/files/guide_durees_de_conservation.pdf>
|
|
* [Pyjacpp] <https://www.cnil.fr/fr/passer-laction/les-durees-de-conservation-des-donnees>
|
|
|
|
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 : <https://gitea.auro.re/aurore/nixos/src/branch/main/hosts>
|
|
|
|
## 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é.
|