documentation/compte_rendus/2025_11_29.md

# Réunion IN

* Date : Samedi 29 novembre 2025
* Lieu : MB87 et Galène
* Début : 15h58
* Fin : 17h45

Ordre du jour :
[Hachino] [cross-post CA] Tuxae aurait besoin d'un rebond pour router du trafic
depuis/vers un Keycloak interne. On leur file une petite VM (et un compte) ?
GÂTEAU !
[Hachino] Planification de la migration de Tealc
(Ses BDD ont pas l'air en super forme ces derniers temps.)
Trouver une date où les nounous sont présentes physiquement (au moins en partie)
et où la coupure de services va pas trop gêner les gens.
Prévenir les adhérents assez lontemps à l'avance (> 2 semaines), avec des
relances sur différents canaux.
Couper les services, dist-upgrade Tealc, upgrade PGSQL et migrer les bases.
Prier pour que tout redémarre normalement. (C'est faux. Prévoir quelques heures
de rab.)
On en profite pour mass reboot les VM qui le réclament ? EDIT : mdr la coupure.
[Hachino] INFO : Fix pipeline django-printer. Au revoir Python 3.9.
D'ailleurs, faudrait faire quelque chose pour appliquer les changements ?
Redéployer helloworld ?
Done (dans la douleur), avec l'aide de Lzebulon
[Hachino] Le retour des mails
[LaPoste/PEB] Et si on demandait à Mailman3 d'écraser les signatures
avant la sienne ?
Dans notre record SPF (dig TXT crans.org) on fait référence à l'IP `*.79.38`,
or Redisdead est sur `*.79.39`.
Le DMARC report de Microsoft/Outlook du 21/10 à 05h32 mentionne des fails DKIM
sur certains mails envoyés par .79.39, mais pas tous. J'ai raté quoi ?
Dans le même genre, cf le rapport de fastmail.com le 23/10 à 05h20,
source ip en `*.79.40` (= Mailman)
Visiblement des gens randoms aiment bien tenter de nous spoof
(jcom.zaq.ne.jp 06/11 17h41).
En parlant de mails et de spams, askip le non-delivery report systématique
c'est pas bien : <https://www.backscatterer.org/?target=bounces>
[Hachino] INFO : ajout d'une unit systemd pour Restart onfailure isc-dhcp-server
sur routeur-sam. Une alerte de moins à gérer.
[Hachino] INFO : Gitlab qui se remplit de logs, incluant production_json.log
(1,4G avant, 2,4G maintenant, mais va te faire).
On y peut pas grand-chose : <https://docs.gitlab.com/omnibus/settings/logs/> :
"You cannot edit the log_level for [..] production_json.log"
Journald a été calmé à 500M comme sur Jitsi. Ça ne règle pas totalement
le problème.
Dans /etc/gitlab/gitlab.rb, ligne logging['logrotate_size'] = '100M'
ajoutée (décommentée) le 30/10.
Suppression a la mano de production_json.log (2,5G le bébé) le 31/10,
gitlab-ctl restart {puma,sidekiq}, gitlab-ctl reconfigure
et ça a l'air de tourner ?
On a toujours des fails sur les backups les lundis et jeudis
(mail matinal sur roots@), à examiner.
En parallèle, /var/opt/gitlab/gitlab-rails/shared/artifacts avait 1G d'orphelins
(maintenant nettoyés), toujours ça de pris.
[Lzebulon/Pyjac] Modif du DNS pour bde-note.
[Lzebulon/Pyjac] DMARC c'est cool mais ça spamme un peu.
Une adresse réelllement dédiée (+ changer le rua du SPF) ?
[Pyjacpp/Lzebulon] Parseur de DMARC relié avec grafana
<https://domainaware.github.io/parsedmarc/> ?
[Lzebulon/Hachino] INFO : sudo systemctl stop/disable/mask de openimi,
qui n'a aucun sens sur une VM (kenobi, ethercalc, fyre, gitzly, hodaur, routeur-daniel)
[Hachino] Est-ce que Bind a un sens sur en7 ?
Si oui, pourquoi il est pas installé ?
Sinon, pourquoi l'avoir ajouté à fyre dans /etc/prometheus/targets/bind.json ?
[Hachino] Backup les logs, est-ce indispensable ?
Cf les crashs sur certaines VM (Etherpad/calc, Gitlab, Fyre).
Proposition : élargir les patterns d'exclusion dans /etc/borgmatic/config.yaml
(ajouter /var/log/* ou au moins /var/log/gitlab/*).
En fait, j'ai trouvé : certains dossiers dans /etc n'avait pas les bonnes perms
(d'écriture). Fix possible :
sudo mkdir -p {/var/borgmatic/cache, /var/lib/borg/security},
chmod 700 les deux dossiers
Dans /etc/borgmatic/config.yaml, changer borg_cache_directory en
/var/borgmatic/cache et borg_security_directory en /var/lib/borg/security.
sudo cp -a /etc/borgmatic/config/security/* /var/lib/borg/security/
sudo systemctl restart borgmatic.service
Testé sur ethercalc et kenobi a la mano, fonctionne. Sur gitzly : typo, réglée.
Sur fyre : réglé aussi. Moralité : systemd n'est pas root.
[Hachino] INFO : Redisdead flag comme spammeur par Abusix : <https://app.abusix.com/lookup/results?q=185.230.79.39>
Pas réussi à faire un compte avec des adresses génériques,
j'ai fait un compte perso et delist redisdead, puis postqueue -f.
Semble avoir marché.
[Lzebulon] petit probleme technique
[Hachino/Gabo] Il fallait voir que les interfaces physiques enp* n'avaient pas
le tag SLAVE, les empêchant d'être correctement liées dans l'interface virtuelle
bond0. Pour corriger ça, down toutes les interfaces concernées,
lier la physique à la virtuelle par ip set link <enp*> master bond0, re-down,
relier si deux interfaces physiques à lier et vérifier sur chaque serveur si
c'est bon (au moins Cameron, probablement Tealc ?).
Ah et /run/screen perd son chmod 777, pénible un peu.
[All/Lyes] Discuter avec la DPAT pour être prévenus les prochaines fois.
Voire, rêvons un peu, avoir enfin ce deuxième circuit électrique.
[Pyjacpp] Le pass...
[Lzebulon] PAS TOUCHE AUX SWITCHS Surtout pas au MLAG. MLAG = GMAL.
Les fibres débranchées, les switchs et le load average...
solution pour eviter que ca se repoduise :
na pas toucher aux switch
avoir du MLAG fonctionnel (et c'est pas une blague)
ceph pour eviter d'avoir un serveur de stockage inaccessible
avoir une doc a jour (pour etre sur qu'elle est fiable)
[Lzebulon] mail, faire les calculs de zamok dans une vm
(monte les homes, puis c'est comme zamok):
negatif: on perd la puissance de zamok sous exploite
[Hachino] Si la VM est dopée aux hormones, ça compense ?
[Lzebulon] je voulais dire, zamok est sous exploite
[Hachino] Ça j'avais compris, mais est-ce qu'on peut "rattraper ça"
en donnant masse ressources à zamok-vm ?
positif: on est plus dependant de zamok et quand il y aura ceph
(soon) plus grande resilliance
[Hachino] En parlant de résilience : jack montre un premier signe de fatigue
sur un disque (roots@, 10 novembre, 11h05)
[Hachino] Thot est sous NixOS et n'a pas Prometheus, pertinent de l'ajouter
peut-être ?
oui, normalement il faut juste update son /etc/nixos
[Hachino] Dpeuis le 15/11 matin, les routeur-* n'arrivent visiblement plus à
taper dans le LDAP, alors que les LDAP écoutent toujours sur le 636.
Semblerait qu'il y ait un souci avec les certs ?
[Lzebulon] framasoft est passe sur pollaris pour framadate, on fait pareil ?
[Hachino] En passant, SFR semble pas aimer nos automails de Framadate. :(
[Hachino] Anu-bis, ou Anu-ter, on sait plus trop. VG demande avec insistance
qu'on lève le bot pour ses pages persos, promis on le fait avant Noël.
ne jamais promettre une date au Crans
[pyjacpp] Framaforms au Crans ?
[Pyjacpp] Point sur les nounous présentes dans un futur proche.
[Lzebulon] Vaultwarden avec une adresse ENS.
[Lzebulon] style pad et autres services du Crans
[Pyjacpp] Routes avec viarezo
[Pyjacpp] Liste de diffusion pour les problèmes

## Point sur les nounous présentes

C'est pas jojo. On a plus d'apprentis. Gabin (1A Saphire) semble intéressé.
Sébastien Véry (3A info) l'est après ses exams.
Il faut qu'on attrape Quark par la manche.

RDB est nounou !!!

Gabo dispo jusqu'en juin. Lyes jusqu'en Mars.
L'année prochaine, RDB est dans le coin, Gabo aussi

## [Hachino] Planification de la migration de Tealc

(Ses BDD ont pas l'air en super forme ces derniers temps.)

La semaine du 5-10 janvier semble optimale, Lzebulon sera sur place.
Vendredi soir, comme ça on a samedi pour réparer si besoin ?
Faire bien gaffe avec les exams, rendus de projet
(Hachino a ping Vincent Lafeychine pour ses 1A par exemple).
En profiter pour remplacer les disques qui couinent, genre sam ou cameron.
Les switchs, Zamok et Cameron pour la redondance ? Et les nouveaux serveurs.

Mettre à jour les BDDs:
    éteindre les services
    dist-upgrade tealc (Debian)
    possible alternance de MàJ pgsql/Debian, à voir
    Lire la doc de Pigeon : <https://gitlab.crans.org/nounous/documentation/-/blob/master/howto/redemarrer_crans.md?ref_type=heads>
    chercher comment resilver des disques en zfs (pour cameron/sam)

Proposition d'achat : un adaptateur pour disque (câble SATA-USB ?).
Peut permettre de tester un disque éteint, notamment ceux du stock
dont on ne sait rien. Possible achat sur la caisse noire de la maman.

Point annexe : Lzebulon va tenter un dist-upgrade de Framdate pour tester trixie.

## Framasoft est passe sur pollaris pour framadate, on fait pareil ?

Pollaris: nouveau moteur de Framadate. Pas compatible avec l'ancien :(

Annoncer une date de coupure (pour faire la mise à niveau) durant les vacances
de Noël. Un joli bandeau en tête de page pour informer.
Framadate est stable.

## INFO : Fix pipeline django-printer. Au revoir Python 3.9

Plus de print error.
Plan de mettre à jour un des quatre (avec des apprentis ?)

## Le retour des mails

[LaPoste/PEB] Et si on demandait à Mailman3 d'écraser les signatures
avant la sienne ?
Dans notre record SPF (dig TXT crans.org) on fait référence à l'IP `*.79.38`,
or Redisdead est sur `*.79.39`.
Le DMARC report de Microsoft/Outlook du 21/10 à 05h32 mentionne des fails DKIM
sur certains mails envoyés par .79.39, mais pas tous. J'ai raté quoi ?
Dans le même genre, cf le rapport de fastmail.com le 23/10 à 05h20,
source ip en `*.79.40` (= Mailman)
Visiblement des gens randoms aiment bien tenter de nous spoof
(jcom.zaq.ne.jp 06/11 17h41).
En parlant de mails et de spams, askip le non-delivery report
systématique c'est pas bien : <https://www.backscatterer.org/?target=bounces>

Plus trop de refus.
La blocklist qui pose prolbème avec orange.
SFR: spam (mais pour framadate).
À vérifier (DKIM ou truc du style)

## INFO : ajout d'une unit systemd pour Restart onfailure isc-dhcp sur routeur-sam

Une alerte de moins à gérer.

Deux lignes de confs environ. Ça redémarre.
Pas d'idée de la cause.
isc est déprécié.
Il faut migrer vers KEA.

isc-dhcp: serveur dhcp sert à donner les adresses IP,
spécifiquement pour les VM/serveurs adhérents.

## INFO : Gitlab qui se remplit de logs, incluant production_json.log

(1,4G avant, 2,4G maintenant, mais va te faire).
On y peut pas grand-chose : <https://docs.gitlab.com/omnibus/settings/logs/> :
"You cannot edit the log_level for [..] production_json.log"
Journald a été calmé à 500M comme sur Jitsi.
Ça ne règle pas totalement le problème.
Dans /etc/gitlab/gitlab.rb, ligne logging['logrotate_size'] = '100M' ajoutée
(décommentée) le 30/10.
Suppression a la mano de production_json.log (2,5G le bébé) le 31/10,
gitlab-ctl restart {puma,sidekiq}, gitlab-ctl reconfigure
et ça a l'air de tourner ?
On a toujours des fails sur les backups les lundis et jeudis
(mail matinal sur roots@), à examiner.
En parallèle, /var/opt/gitlab/gitlab-rails/shared/artifacts
avait 1G d'orphelins (maintenant nettoyés), toujours ça de pris.

On peut faire du cache sur les CI : <https://docs.gitlab.com/ci/caching/>
Proposition en l'air : migrer vers Forgejo.
Apparemment Forgejo permet de garder les issues au clone, mais les CI changent.
On pourrait tester avec git2 pour commencer (qui a Gitea).

## Logs

Le temps de sauvegarde des logs pour les fournisseur de services n'est pas clair.

## Modif du DNS pour bde-note

Il faut aller dans le ldap, et ça marche bien.
Attention aux CNAMEs

## [Lzebulon/Pyjac] DMARC c'est cool mais ça spamme un peu

Une adresse réelllement dédiée (+ changer le rua du SPF) ?

Oui.

## [Pyjacpp/Lzebulon] Parseur de DMARC relié avec grafana

<https://domainaware.github.io/parsedmarc/> ?

Pour avoir des résultats synthétiques.
Prometheus sonde les serveurs, Grafana mange les résultats de Prometheus
et affiche des tableaux.

## [Lzebulon/Hachino] INFO : sudo systemctl stop/disable/mask de openimi

Ce service n'a aucun sens sur une VM
(kenobi, ethercalc, fyre, gitzly, hodaur, routeur-daniel)

openimi service utilitaire de systemd qui permet d'accéder
à des sondes sur le hardware. Pleins de fausses alertes. ⇒ supprimer

## Est-ce que Bind a un sens sur en7 ? Si oui, pourquoi il est pas installé ?

Sinon, pourquoi l'avoir ajouté à fyre dans /etc/prometheus/targets/bind.json ?

Accès de secours de l'ENS. VM par lequel on accède depuis le bureau.
Bind n'avait a priori pas de sens et son monitoring a été viré du LDAP.

## Backup les logs, est-ce indispensable ?

Cf les crashs sur certaines VM (Etherpad/calc, Gitlab, Fyre).
Proposition : élargir les patterns d'exclusion dans /etc/borgmatic/config.yaml
(ajouter /var/log/* ou au moins /var/log/gitlab/*).
En fait, j'ai trouvé : certains dossiers dans /etc
n'avait pas les bonnes perms (d'écriture). Fix possible :
sudo mkdir -p {/var/borgmatic/cache, /var/lib/borg/security},
chmod 700 les deux dossiers
Dans /etc/borgmatic/config.yaml, changer borg_cache_directory en
/var/borgmatic/cache et borg_security_directory en /var/lib/borg/security.
sudo cp -a /etc/borgmatic/config/security/* /var/lib/borg/security/
sudo systemctl restart borgmatic.service
Testé sur ethercalc et kenobi a la mano, fonctionne.
Sur gitzly : typo, réglée. Sur fyre : réglé aussi.
Moralité : systemd n'est pas root.

Permet de débugger en cas de problèmes.
Légal, si c'est obligatoire de les garder, les backup est bien.

## INFO : Redisdead flag comme spammeur par Abusix : <https://app.abusix.com/lookup/results?q=185.230.79.39>

Pas réussi à faire un compte avec des adresses génériques, j'ai fait un compte
perso et delist redisdead, puis postqueue -f. Semble avoir marché.

Automatique si on demande de manière raisonnable.

## Petit probleme technique

[Hachino/Gabo] Il fallait voir que les interfaces physiques enp* n'avaient pas
le tag SLAVE, les empêchant d'être correctement liées dans l'interface virtuelle
bond0. Pour corriger ça, down toutes les interfaces concernées,
lier la physique à la virtuelle par ip set link <enp*> master bond0, re-down,
relier si deux interfaces physiques à lier et vérifier sur chaque serveur
si c'est bon (au moins Cameron, probablement Tealc ?).
Ah et /run/screen perd son chmod 777, pénible un peu.
[All/Lyes] Discuter avec la DPAT pour être prévenus les prochaines fois.
Voire, rêvons un peu, avoir enfin ce deuxième circuit électrique.

Problème(s) électrique(s) indépendant(s) de notre volonté.

Cameron n'est probablement pas bon une seule fibre.
Si on branche une fibre pétée et qu'on agrège, le serveur tente d'utiliser le lien,
n'y arrive pas (ou perd plein de paquets), renvoie ses paquets en boucle
et c'est comme ça qu'on arrive à Zamok qui a une load average ~ 500

## [Pyjacpp] Le pass

Il faut faire un repo... Clés GPG ? Signatures avec ?
On trust ou on trust pas les clés sur ce repo ? Signing-party du CT ?

## [Lzebulon] PAS TOUCHE AUX SWITCHS Surtout pas au MLAG. MLAG = GMAL

Les fibres débranchées, les switchs et le load average...
solution pour eviter que ca se repoduise :
na pas toucher aux switch
avoir du MLAG fonctionnel (et c'est pas une blague) des deux côtés
ceph pour eviter d'avoir un serveur de stockage inaccessible
avoir une doc a jour (pour etre sur qu'elle est fiable)

## [Lzebulon] mail, faire les calculs de zamok dans une vm

(monte les homes, puis c'est comme zamok)

negatif: on perd la puissance de zamok sous exploite
[Hachino] Si la VM est dopée aux hormones, ça compense ?
[Lzebulon] je voulais dire, zamok est sous exploite
[Hachino] Ça j'avais compris, mais est-ce qu'on peut "rattraper ça"
en donnant masse ressources à zamok-vm ?
positif: on est plus dependant de zamok et quand il y aura ceph (soon)
plus grande resillience

Pas urgent.

## En parlant de résilience : jack montre un premier signe de fatigue sur un disque

(roots@, 10 novembre, 11h05)

Semble résolu. Ce qui n'est pas cameron. Voir la maintenance de janvier.

## Thot est sous NixOS et n'a pas Prometheus, pertinent de l'ajouter peut-être ?

Oui, normalement il faut juste update son /etc/nixos.
Bon ça aura été un peu plus compliqué que ça en vrai. (Très compliqué.)

## routeur-* et LDAP

Depuis le 15/11 matin, les routeur-* n'arrivent
visiblement plus à taper dans le LDAP,
alors que les LDAP écoutent toujours sur le 636.

Semblerait qu'il y ait un souci avec les certs ?

On ne sais plus à quoi cela fait référence. Il se passe trop de choses au Crans.

## Anu-bis, ou Anu-ter, on sait plus trop

VG demande avec insistance qu'on lève le bot pour ses pages persos,
promis on le fait avant Noël.
ne jamais promettre une date au Crans

Mettre un dossier api (ou bot-allow, ou allow-anubis, ou allow-all, all, ou /public
(possiblement déjà pris mais sémantique claire), bref) où anubis n'opére pas.
Ou un fichier à la racine de www/ qui toggle la présence d'Anubis.
Demande un script Python maison, Anubis n'a pas prévu le cas.

## Point redémarrage en janvier

Vincent Lafeychine
Vendredi au soir, c'est tout bon. Les rendus sont les vendredis à 13h

## Framaforms au Crans ?

Frama teste une nouvelle version. Même souci que pour Polaris, incompatible avec
l'ancienne version, on peut attendre que leur nouvelle version soit en place.
Ils ont une auth, on peut tenter de faire de l'Oauth2/OIDC/whatever pour relier
à la note et/ou au LDAP Crans.

Plutôt CransForm. Projet apprenti.e. Need more apprentis cependant.

On ajouterais date.crans.org ?
On peut faire la transition de framadate vers date en plus.
À faire avant le 15 décembre.

## Vaultwarden avec une adresse ENS

Bonne idée. Juste à modifier la conf ?

## Style pad et autres services du Crans

Cf CA.

## [Pyjacpp] Routes avec viarezo

Demander SFP, longueur d'onde et distance. Problème de couche 1.
Pyjac ira leur parler en permanence. C'est possiblement pas le seul problème,
mais c'en est un.

## Liste de diffusion pour les problèmes

On a status.crans.org. La source doit être extérieure à l'infra principale,
sinon c'est un peu con. ML Renater ? Plutôt bandeaux/messages sur status.crans.org
dans l'idéal. Lzebulon a déjà essayé de mettre des messages, ça n'a jamais marché.
Trouver une alternative ? <https://github.com/louislam/uptime-kuma/>

Clôture à 17h45.