CR du jour
Hachino
parent
d88ae8aeb3
commit
48abec6d13
|
|
@ -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) <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é.
|
||||
Loading…
Reference in New Issue