17 KiB
Réunion du Collège Technique
- Date : 30 Septembre 2019
- Début : 19h
- Fin : 21h25
- Lieu : Salle de conf du PDJ
- <>
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
ComptesRendusCrans/Mardi04Juin2019
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 ?
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 [[https://phabricator.crans.org/T323|l'issue phabricator]]), 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 CransTechnique/LesServeurs/ServeurOdlyd alors que le secondary a été passé sur la vm CransTechnique/LesServeurs/Virtuels/ServeurDhcp. 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 :
\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...