documentation/compte_rendus/2019_09_30.md

# Réunion du Collège Technique

* Date : 30 Septembre 2019
* Début : 19h
* Fin : 21h25
* Lieu :  Salle de conf du PDJ
* <<Pad>>

## Présents

* Mikachu
* Krokmou
* Erdnaxe
* Pollion
* Esum
* Vulcain
* Elkmaennchen

### Des gentils première année

* h@chi.no
* !TinyLinux
* Aka
* Charles
* Batablu
* Tinette
* Armand2

## Manger

Sarcozy se propose de nous ramener des pâtes de la soirée C4, donc on accepte
et on commande des pâtes.

## Ordre du Jour

On commence par faire un bilan des derniers événements

## Incidents et autres interruptions de services

### Crash de thot le 21 Juillet 2019

Pollion a tenté un changement de disque dur de Thot. À cause de l'agencement
non protestant des disques (RAID logiciel sur 4 RAID0 gérés par une carte
propriétaire HP) thot a crashé. On l'a réinstallé.
Mais pas trop le choix sur les Gen7-, on a gardé un truc de vieux sur les
Gen8+ alors que le mode HBA sur une carte Raid HP aurait pu éviter ça.
Le Raid logiciel c'est coool et je suis de l'avis que Raid bien fait
logiciel > Raid matériel « boîte noir déconnante »

Pour plus d'informations, allez
lire : <https://wiki.crans.org/CransTechnique/MaintenancesEtIncidents/20Juillet2019>

On manque de compétences sur ces sujets, mais aller tester à ServENS est une
bonne idée et c'est ce que Pollion a fait !

Faire un séminaire sur le stockage ? RAID, ZFS, NFS, iSCSI ... ? -- Mikachu,
qui se propose pour le faire un jour ==> Cool.

### Tocardise de Pollion

En bossant sur les radius, Pollion n'est apperçu qu'Odlyd n'était pas du tout
dans la conf des switches. Il a donc décidé de le rajouter. Pour ça il a voulu
utiliser le script re2o de provisionning des switches.

Après une rapide discussion sur la non documentation de ce script, il a essayé
de le modifier pour le rendre plus fonctionnel, avec un menu d'aide et
notamment un dry-run. Bon, il avait une erreur dans son script et il s'est
planté, il a lancé le provisionning en mode normal au lieu de dry-run. Résultat
des courses, il y a eu une petite confusion sur les conf des switches du
batiment M. En voulant réparer son erreur, il s'est rendu compte que plein de
switches étaient mal enregistrés dans la BDD (un arping ne donnait pas la bonne
MAC, donc soit c'était un problème de switch mal enregistrés, soit c'était une
permutation de conf). Dans le doute, il faut prendre la pire situation, donc il
s'est tappé une visite de la plupart des locaux techniques avec un cable série
pour vérifier ça à 2h du mat.... Ça lui apprendra.
En plus, les switches du RU n'ont pas réussi à reboot tout seul, mais comme
c'était les vacances le RU était fermé. C'est réglé.
Faudrait monitorer les switches (erdnaxe ?).

### Inondation du -1I --> Coupure

On ne pouvait pas faire grand chose. L'eau chaude du I, J, H était aussi down.
Je pense que les gens sont plus intéressés par l'eau chaude que internet (enfin
quoique...).

### Maintenance d'Août 2019

On a profité qu'il n'y ait plus d'électricité pendant un après-midi. On avait
prévenu les adhérents via un mailall.

Ce qui était prévu :

* Changement du Switch de la baie
* Agrandissement de {{{/var/mail}}}
* Fin de la migration vers le subnet 185.230.76.0/22 (à nous, pas à l'ENS)

vulcain à croisé la DSI et chez eux c'est la guerre :
/!\ ON PERD NOS IP LE 15 OCTOBRE. AAAAAAAH !!!! DE TOUTES FACONS DEBUT NOVEMBRE
YA PLUS DIPV4 !!!! C'EST LA FIN DU MMONDE !!!!! AAAAAAHHHHHHHHAAAAAAHHHHH !!!!

* Mise à jour de la baie
* Mise à jour du bios des virtualiseurs
* Mise à jour du backbone

Ce qui a été fait :

* Changement du Switch de la baie
* Agrandissement de {{{/var/mail}}}
* Mise à jour de la baie --> IMPOSSIBLE
* Vérification des failovers, radius, postgresql (qui n'avait pas sa partition
  montée lol)...

`>> On n'a pas réparé le soucis avec le routage des IPv4 publiques Cr@ns. <<`

> Faut trouver une solution et réparer.

Pour les détails, voir le paragraphe suivant (quelle cohérence \o/)

## Retour sur les décisions de la dernière IN

[dernière IN](./2019_06_04.md)

On va annoncer les points dans le même ordre

## Maintenance baie

Le switch a été changé.

## Quid des mails ?

On a agrandi `/var/mail/` et on a viré les % réservés à root dans cette
partition.

On attribue un coeur en plus à redisdead pour qu'il arrête de crier à chaque
fois qu'il fait une compression ?

Je doute que ça règle le soucis, il va jsute prendre 100% de 2cpu
pendant ~2fois moins longtemps
On limite les performances dispo pour le process ?
On rallonge le temps passé à 100% avant de lancer une alerte ? -> pas con (oui
je sais o:) :D)

 -> ça représente ~5min

erdnaxe vient de monter l'alerte à >10mn. On passe à 15mn si ça ne suffit pas.
On le met dans Ansible.

## Sputnik (Soyouz2) <https://lutim.crans.org/rKdWLFev/7gU52JVF.jpeg>

erdnaxe n'a pas trop envie d'être seul devant Soyouz2, en vrai le minimum
syndical a été installé. Il faut maintenant tout migrer.
En réalité le taf à faire ici correspond à une migration BCFG2 -> Ansible.

C'est un projet parfait pour un apprenti : <https://phabricator.crans.org/T443>
et des apprentis sont motivés, c'est cool --> Hachino, TinyLinux, Batablu (si
d'autres apprentis sont motivés, feel free to join !)

erdnaxe par contre est ultra volontaire pour former des codeurs Ansible et
relire des MR.

En parlant de wiki on nous signale des soucis, Hachino dit que de façon très
bizarre, il lui arrive de changer de theme, erdnaxe dit qu'il a déjà eu le
soucis, on ira regarder.

## Mettre à jour les serveurs de backup

`omnomnom` et `zephyr` ont enfin été migrés sous Stretch par Vulcain,
encadré par Pollion. Et ce, avant la release de Buster eheh.
et les webnews ? Nope.

## Titanic

Il y avait un gros soucis avec le DNS, problèmes de permissions and co. Le DNS
était à genoux sur tous les serveurs, les zones ne se généraient plus depuis
des mois. Ça cassait DNSSec mais puisque personne ne valide ça n'embêtait
personne, et vu que Silice et Soyouz sont surdimensionnés, ils n'avaient pas le
problème de perf. Pollion a corrigé tout ça, Titanic n'est plus du tout à
genoux, et DNSSec marche \o/

## Boeing

Pour remplacer titanic, c'est en pratique la même tache que Soyouz2.

## Prometheus et fy

Actuellement les problèmes de monitoring sont envoyés sur un chan irc
idoine[^ça veut dire quoi ?] : #monitoring.

LE MONITORING EST CLEAN ! et ouaip le crans n'a jamais aussi été propre (On
parle bien d'un bot d'esum fait tourner de son côté qui est utilisé pour plein
d'autre truc et non documenté ?)

Le monitoring des bornes a bien été mis en place. Ça a pas mal spammé quand le
controlleur a été coupé un moment pendant les vacances mais c'est revenu à la
normale. On continue le monitoring à fond cette année. Des volontaires ?

<http://lutim.crans.org/IGaYWBqh/fA9qZePT.png>

Problème de la persistance sur 25jours. Censé être trivial à fix
dans {{{/etc/default/prometheus}}}, mais erdnaxe est un tocard et à fail la
dernière fois qu'il a tenté de changer ça (j'ai ptetre juste oublié de restart
le service avec la fatigue)
Niveau espace disque la VM risque d'etre limite pour contenir 1an, mais l'algo
de compression a des surprises et il se pourrait que ça marche au final. Il
faudrait récupérer moins d'info inutiles en SNMP pour nettoyer la bdd
prometheus.

Grafana utilise le CAS ?
Non mais il faudrait. Il faut définir dans NGINX le fait d'aller chercher le
CAS et de passer le nom d'utilisateur en variable.

Réinstallation de fy ?
On backup quoi ? munin
On réinstalle juste prometheus ?

Ok pour la réinstallation, on backup munin je pense que ça suffit.

QUESTION IMPORTANTE POUR FAIRE AVANCER/MOTIVER ERDNAXE :
Prometheus et les serveurs sous Stretch => est-ce que l'on prend le paquet de
backport qui monitore en plus Systemd et APT (et donc qui remplace monit et
munin entièrement de ce que j'ai vu) ?

> It's a go.

Dans le dernier épisode :

Est-ce que l'on formatte fy à terme sur buster avec Prometheus ? +1 pour le
formatage une fois qu'on a une POC de Prometheus qui fait bien tout ce qu'on
veut :)
On va tester le downslampling sur la vm et quand tout marchera bien, fy fera du
monitoring.

Et on reinstalle quoi dessus ? Que prometheus.
Le souci du stockage qui grossit à l'infini a été résolu ? A priori, avec
prometheus 2 (donc sous buster), c'est mieux géré, il droppe ce qui est plus
vieux que $jours (mais il ne sait pas faire de downsampling (= sur les données
plus anciennes, ne garder que des tendances et pas toutes les données)

On peut peut-être continuer à garder Munin s'il fait du downsampling, et que
les vieux s'en servent ça peut aider à proposer un diagnostic non ?

Bah, du graphage sans historique, c'est pas très utile, parce que ça permet pas
de répondre aux questions du type
"Ce disque s'est rempli, mais est-ce que c'est symptomatique d'un
problème (=> le régler; virer le garbage généré), ou une inflation normale
résultant d'une tendance globale longue durée et on vient seulement d'atteindre
la barre (=> agrandir le disque) ?"
Historique sans downsampling, c'est mieux que pas d'historique du tout (on n'a
pas besoin de garder les précisions sur la durée), mais ça va vite poser des
problèmes d'espace disque et de perf pour tracer les graphes (si je te demande
de tracer le graphe sur 1 an et que tu dois compiler 1 data/min sur un an, tu
vas en chier).
Donc bah sans solution correcte à tout ça, jeter munin me paraît
dangereux. -> prometheus ne renvoie pas tout heuresement
D'un autre côté, au fur et à mesure que vous renouvelez certains morceaux de
l'infrastructure, si vous les ajoutez pas à munin, il finira effectivement par
ne plus remplir son purpose.

Conclusion : On fait par ordre de priorité : Downsampling avec
Prometheus > Couper les munin nodes > Formattage de fy et reinstallation.

## Knot

Résumé du dernier épisode :

Il y a eu des soucis avec Knot depuis qu'il a été mis en place, et il
semblerait que certaines feature de Bind ne soient pas supportées correctement.
Proposition : Revenir à Bind. Des gens sont motivés pour le faire, donc
pourquoi pas. On fera ça dans l'été, il n'y a pas urgence.

> On n'a pas eu le temps de le faire pendant l'été, il faudra toucher le
service et du ansible....

## RFC2136 avec knot/bind

Résumé du dernier épisode :

On pourrait utiliser certbot en wildcard avec cette RFC.
0+On pourrait réécrire le service re2o DNS pour utiliser cette RFC.
On pourrait drop le service re2o DNS et laisser le serveur DHCP remplir le DNS
quand un client se connecte avec cette RFC.
On pourrait expérimenter des choses fun quoi... avec cette RFC.

Marrant, mais pas urgent. On le rajoute dans la file d'attente mais avec une
priority low
On envoie un mail.

Mika met en garde, on peut perdre des trucs au reboot, faut voir.

On en rediscute, car on a envie de faire un certificat wildcard.

## Mailman 3

LOL !

Résumé du dernier épisode :
Faut motiver qqun dessus mais c'est critique et stressant.
Pendant l'été
TOUT PENDANT L'ETE !
On peut faire plein de choses pendant l'été.

--> On a présenté mailman aux 1A, mais la migration n'est pas une priorité, on
  ne s'est pas attardé dessus.

## Migration des serveurs sur les ip RIPE

Parler de la maintenance d'Août.

Résumé du dernier épisode :

Un certain nombre de serveurs sont encore sur le / d'ip de l'ENS. Ça serait
bien de tout passer sur les IP Crans
sur 185.230.79.0/24 (voir [l'issue
phabricator](https://phabricator.crans.org/T323)), vlan qui a été nommé DMZ
l'an dernier.

On rappelle ce qu'est une DMZ : Il s'agit plus d'un sous-réseau séparé du
réseau local. On y met les machines qui doivent être accessibles depuis
Internet, mais qui sont susceptibles d'être attaquées, et n'ont pas besoin
d'avoir un pied sur le réseau local.

Actuellement Adm est le contraire d'une DMZ : Il s'agit d'un VLAN
d'administration sur lequel on a mis tous les serveurs crans. Les ip derrière
ADM ne sont pas accessibles depuis Internet.

A-t-on vraiment envie de faire une DMZ ?

On a migré en srv.

###############################################################################

Cool on a donc bien avancé.

###############################################################################

## Lutim

Projet d'apprenti fait par Vulcain, encadré principalement par esum.
C'est un pastebin pour des images, c'est cool ; un nouveau service.

Vulcain a mis en place un nouveau service.
Ça a l'air de bien marcher. On peut faire de la pub sur la page d'accueil de
l'intranet.

## Services framadate

Projets d'apprentis, apparemment frama ferme des projets, ça peut etre
pertinent de lancer un apprenti sur un projet des services frama qui
ferment. À voir.

## Les backups

Lien avec le crash de Thot susmensionné, les backups des bdd étaient mal faits,
Pollion a mis en place un réplicat postgres en RO sur Odlyd. C'est déjà mieux.

Chiffrement des backups : Ça n'a toujours pas été fait, mais ça peut se faire
soon. Fardale toujours intéressé pour aider même si ça fait ~1an et demi qu'il
en parle ?
(Fardale a mis en place un serveur chiffré récement donc a à nouveau charger
les données en mémoire, ça ne durera pas éternellement)

## Carte Raid sur thot, ou comment changer un disque ?

Erdnaxe a expliqué rapidement son idée de HBA :
Il existe une méthode pour pouvoir passer outre la carte raid et envoyer
directement les disques au noyau
linux (<https://fr.wikipedia.org/wiki/Contr%C3%B4leur_h%C3%B4te_de_bus>)
accessible via une mise à jour du bios à partir des HP Gen8, donc accessible
pour thot.

On a encore un serveur de test, on va essayer de mettre ça en place et on
envisage une nouvelle install de thot sous ce mode si ça marche bien.

## DHCP

Lors de la migration vers re2o, le serveur DHCP primary a été passé
sur odlyd alors que le secondary a été passé sur la vm dhcp.
La personne qui a fait ça est "Votre Nom <Vous@exemple.com>" cf commit
dece79374f94b64c3a79dfd9e8c54d03e3afb936 sur BCFG2. Anyway, qu'est-ce qu'on
fait ? On change ?

On décide de revert et de changer.

Dans tous les cas, penser à changer la page wiki
<https://wiki.crans.org/CransTechnique/LesServeurs/Virtuels/ServeurDhcp>

## Ansible

Il faut continuer, on fera une IN spécial Ansible pour lister tout ce qu'on
doit faire avec.

Il existe un serveur qui est sous buster et non sous ansible.

## Les disques cassés dans le 0b

Quid du disque orange de la baie ? --> On les rachete, pour la baie pas de
soucis pour changer, pour gulp ça va être probablement le même soucis que pour
thot. On annoncera une petite interruption de services et on passera sous
Buster à la toussaint.

## Séminaires édition 2019-2020

« Wow » beaucoup de jeunes au premier séminaire (salle de conf du Pavillon des
jard rempli au 3/4).
L'ambiance est VRAIMENT cool, y a parfois à manger en plus.
faut continuer comme ça et faire son max pour faire vivre les
séminaires ! C'est pas si difficile de faire venir des gens et faire de la pub
si on s'y prend à beaucoup.
C'est une des grandes forces du Cr@ns et c'est qqch qui continuera d'exister
après le déménagement donc autant mettre l'énergie ici. Et c'est aussi un peu
le coeur de l'assos :

```LaTeX
$$ \frac{\mathrm d \text{séminaires}}{\mathrm d t} > 0 \implies \frac{\mathrm
d \text{gens compétants}}{\mathrm d t} > 0 \implies \frac{\mathrm d \text{vie
de l'assos}}{\mathrm d t} > 0 $$
````

## SATIE + Crans

PAC et erdnaxe ont vu deux personnes du SATIE. Après long étallement de cahier
des charges d'un projet qu'ils veulent organiser, il semblerait qu'un
Matrix (non fédéré) + !EtherPad leur convient parfaitement.
On est en train d'installer une instance de test pour leur faire tester.
Deadlines ?
Ça peut être un chouette début de projet, ils ont clairement pas le même
background en info que nous et du coup ils n'imaginent pas forcément qu'une
solution à un de leur besoin existe.
On peut leur apporter des solutions qui (on l'espère) vont ptetre beaucoup les
aider.
Il faudrait faire idem dans LURPA / LMT...

On peut avoir le cahier des charges ? Ils devront adhérents au Crans ? Qui
finance ? (Les adhérents n'ont pas à financer un projet pour des non
adhérents + si le crans perd la gestion de la connection il lui faudra d'autre
source de revenu)

On laisse au CA

## KWEI

On a ouvert le portail captif au KWEI, allez voir le monitoring si vous voulez
voir l'utilisation.
Ok, ça marchait, on remettra ça pour l'install Party. C'est la nouvelle version
de fête du slip. En plus c'est monitoré.
Erdnaxe va documenter tout ça :) !

## NGINX qui reverse Apache cassait des choses

!PhpMyAdmin pleurait et Wordpress redirigeait à l'infini car Apache se croyait
en HTTP à cause du reverse proxy NGINX.
Solution ! On dit à NGINX d'ajouter un header pour dire à son poto Apache qu'il
est en HTTPS.
Et ça marche ! Son&Lumens ont enfin leur Wordpress fonctionnel, erdnaxe pense
également en parler au BDS (ils souhaitaient déménager leur wordpress à une
époque).

## Module NGINX de certbot

Bah en fait avec ça un certif wildcard ce n'est plus si pertinent...
Genre vraiment `certbot renew --nginx` c'est la folie.
Est-ce que l'on passe dessus à la place du module standalone/webroot ?

Le mieux c'est de faire du wildcard, donc on reste comme ça.

## Fin de l'IN

Bon, Sarcozy n'est pas venu avec les pâtes donc on a faim...