11 KiB
Réunion du Collège Technique
- Date : Mardi 16 Avril 2019
- Lieu : Amphi Tocqueville
- Début : 19:15
- Fin : 21:55
- <>
Présents
- WikiFardale (via jitsi)
- Edgar Pierre "edpibu" BURKHART
- Solal "SolalNathan" NATHAN (nous quitte à 21h07)
- Romain "Vulcain" Thibert
- "WikiErdnaxe"
- Gauthier "Elkmaennchen" CROSIO (disparu à 19h50)
- Émile Siboulet
- Arthur "Grizzly" GRISEL-DAVY
- Benjamin "Benjamin" GRAILLOT
- Maxime "WikiPollion" BOMBAR
- Michaël "WikiMikachu" Paulon
Ordre du Jour
Bilan des différents trucs mis en place et lignes directrices des futurs
projets
GitLab CI
Installé par PaC sur CransTechnique/LesServeurs/ServeurVulcain. PaC n'est pas là on passe ce point.
Prometheus et Ansible
Déployé par WikiErdnaxe et Grizzly
Déploiement du serveur principal sur une VM. L'installation s'est bien passée, mais la création de VM est déjà une aventure. Mise à jour de l'iso dans proxmox. WikiFardale suggérait d'utiliser le CransTechnique/ServicesMineurs/PXE.
Petite interlude d'explication sur le CransTechnique/ServicesMineurs/PXE, CransTechnique/LesServeurs/ServeurCharybde etc.
Linkage vers la page wiki: CransTechnique/ServicesMineurs/PXE.
Playbooks Ansible:
- Monter LDAP sur une VM fraîche (testé et ça marche ./)
- Déploiement de Prometheus (testé et ça marche ./)
- Déploiement des nodes (pas encore testé)
Objectif: On continue à déployer les nodes, on continue à tester, déploiement de grafana
{{{[digression]}}}
Création de VM: Discussion sur un CransTechnique/Services/DHCP sur adm, pour le moment on estime qu'on n'a pas besoin de ça…
Erdnaxe propose de se documenter sur terraform (https://www.terraform.io/) qui permettrait de faire tout ça automagiquement.
{{{[/digression]}}}
Actuellement Prometheus monitore uniquement Prometheus, déploiement des nodes ce WE, test du playbook ansible.
Quand tout sera stable et que ça marchera bien on migrera tout ça sur CransTechnique/LesServeurs/ServeurFy. (en réinstallant CransTechnique/LesServeurs/ServeurFy :) )
- WikiFardale: attention CransTechnique/LesServeurs/ServeurFy est déjà un peu charger il me semble.
Mailman 3
Il n'y a pas grand chose à dire en fait.
Benjamin a installé la VM sous Buster, elle marche. Il faut la configurer avec Ansible. Entre temps mailman3 n'a pas encore été installé parce que soucis sur soucis ça a donné une impossibilité de se logguer. On poursuit dans cette direction, on déploie petit à petit.
- Elkmaennchen et le CT Aurore intéressés
A priori Via est en train de déployer un mailman3 aussi mais d'après WikiErdnaxe ils en chient sur quelques points. Il serait interessant de les contacter pour ne pas tomber dans les mêmes pièges.
Cr@ns-5g
Historique rapide: Depuis N mois les adhérents avec des Mac ont des soucis de wifi (Broken pipe, instabilité wifi etc). On savait pas trop d'où ça venait, on avait essayé plein de trucs sans succès.
On a décidé à une dernière IN de séparer les SSID 2.4 GHz, 5 GHz. On n'a pas trop de retours dessus, puis une mise à jour du controlleur Unifi est arrivé, Chibrac avait dit qu'il gérait mieux la gestion 2.4/5 et a donc refusionné les SSID. Idem, on ne sait pas trop s'il y a eu une amélioration, mais il y a ~un mois pas mal d'adhérents sont venus dire que le Crans ne marchait plus. On a resplitté, et à présent les adhérents avec des devices Apple (Iphones, MacOS & co) ne parviennent plus à se connecter sur le SSID Crans (2.4 GHz) par contre le SSID Cr@ns-5g (5 GHz) marche parfaitement. Pour le moment on ne sait pas exactement d'où ça vient, et on se contente de ça pour l'instant.
On fait un dashboard grafana pour afficher le nombre d'user mac sur le 2.4G et 5G ?
En fait il y a déjà un truc du même genre sur le contrôleur Unifi
WikiMikachu: Une explication au problème qui s'est passé après la 2^ème^ séparation des SSID, une mise à jour de MacOS est arrivée récemment et dans les release notes ils disent avoir améliorer la gestion du Wifi. Mika pense qu'ils utilisent une sorte de cache pour mémoriser que des réseaux font du 5GHz, et comme Crans ne fait plus de 5 les devices Apple pourraient ne pas vouloir s'y connecter. Who knows ?
WikiErdnaxe: Aux journées Federez WikiErdnaxe a rencontré d'autres assos avec exactement les mêmes symptômes et leur a conseillé de faire comme nous. Pas de retour pour l'instant.
WikiMikachu: Apparemment les soucis Mac/Unifi sont connus, Mika rapporte d'autres cas qu'il a pu voir dans sa boîte.
Micro-code et Virtualiseurs
Fait par WikiFardale.
Le microcode est un firmware tournant sur le cpu, qui peut être mis à jour via des paquets debian. Le paquet modifie la séquence de boot pour mettre à jour le firmware au prochain reboot.
Pour intel les fimrwares ont été mis à jour pour alléger les fix de metldown et spectre.
Le microcode a été déployé sur tous les serveurs physiques, il n'attend qu'un reboot pour être activé. CransTechnique/LesServeurs/ServeurFz tourne avec le microcode mis à jour.
Testé sur CransTechnique/LesServeurs/ServeurFt la migration des VM de CransTechnique/LesServeurs/ServeurStitch (qui n'a pas le microcode installé + Ancien noyau) n'a pas fonctionnée (VM éteintes à l'arrivée) alors que cela n'avait pas posé de problème lors du test de CransTechnique/LesServeurs/ServeurFz (VM migrées de CransTechnique/LesServeurs/ServeurFt vers CransTechnique/LesServeurs/ServeurFt)…
Après la catastrophe grosses lenteurs, prompt qui n'apparaît plus etc, WikiFardale a dû se connecter en root, commenter la ligne dans grub et rebooter CransTechnique/LesServeurs/ServeurFt. Une fois le reboot terminé les lenteurs avaient disparu. Benjamin propose de désactiver les patches contre Spectre et Meltdown (proposé aussi sur le forum sur lequel Peb avait posté il y a un an).
Bon dans tous les cas on va devoir attendre une grosse maintenance pour faire ça, on pourra voir ce qu'il se passe quand on migrera vers Buster, et/ou en Juillet-Août.
WikiFardale: Sinon il est peut être interessant de passer sur un noyau plus récent qui améliore les patch meltdown et spectre.
Proposition d'achat de matériel
Il y a aussi ce petit problème de switch de la baie qu'est pas très important mais faut quand même…
- https://www.senetic.fr/product/J9774A * 2 (ou 3 histoire d'avoir du spare et de pouvoir le prêter à S&L) 380€
- https://www.senetic.fr/product/J9979A 90€
- https://www.senetic.fr/product/JL258A 500€
- ou
<troll>
https://www.senetic.fr/product/JH329A (moins cher et moins de latence !)</troll>
50€ - ou racheter des alims.
On explique à tout le monde comment fonctionne la baie, CransTechnique/Services/NfS/OpenIscsi, CransTechnique/LesServeurs/ServeurZbee & co. On rappelle que le 3 Février le Switch est tombé, et du coup ça a coupé tout le réseau. Pas cool. Actuellement c'est un Aruba 48 ports de Spare qui est branché, on va proposer au CA quelques modèles pour racheter un switch.
Le CT propose ce modèle au CA: https://www.senetic.fr/product/J9979A
On propose d'en acheter 2 (pour redonder) + 1 de spare, et puis au pire un switch 8 ports c'est toujours utile.
On propose aussi au CA de racheter des Alims pour les switches qu'on a mais qui ont perdu leurs alims. Grizzly s'en occupe.
Projet
Matrix a l'air de bien marcher, et toute la conf (ou presque) est déjà sous Ansible. On en déploie un au crans ?
Bon personne n'est vraiment chaud et puis c'est maintenir deux trucs pour pas grand chose. On peut par contre faire de la pub pour le Matrix d'Aurore.
WikiFardale: je peux déployer ça, je l'ai déjà fait sur un serveur perso si besoin.
Mises à jour
Buster arrive, Jessie-updates et Jessie-backports ont été droppés des miroirs debian (et du coup du crans). On termine la mise à jour des serveurs de backup ?
Vulcain est chaud à distance on lui filera tous les droits dessus évidemment, Benjamin veut bien superviser sur place.
knot
Transition de knot vers bind.
Il y a des trucs chiants avec knot, on veut les views de bind (split horizon CransTechnique/Services/DnS) que knot n'implémente pas. Benjamin demande donc au CT (avant de déployer).
WikiErdnaxe serait aussi intéressé, on en profiterait pour déployer la conf avec Ansible pour avancer la transition CransTechnique/Services/Bcfg2 vers Ansible.
Le CT n'y voit pas d'inconvénient mais on ne veut pas de downtime.
Lenteurs
Pourquoi que c'est lent le crans ?
- Symptomes: les ssh mettent 10000 ans à aboutir, le wiki est lent…
- Causes possibles:
- Latence/soucis d'IO: comment on debug ça ?
- Savoir si le soucis vient
de CransTechnique/LesServeurs/ServeurZbee ou de la baie ?
- WikiFardale: voir les graphes munin ou les ajouter si il n'y en a pas assez
- Problèmes de DNS (récursif ou résolution récursive sur les domaines
crans); qui expliquerait assez bien les latences (dont ssh)
- WikiFardale: mais ça n'explique pas les ralentissement sur les homes
- CransTechnique/LesServeurs/ServeurZbee swap depuis quelque jours
- WikiFardale: un serveur qui swap c'est normal, après à voir si ça a augmenté brusquement ou non.
- Les fichiers CransTechnique/Services/DnS de CransTechnique/LesServeurs/Virtuels/ServeurSilice échoue à se mettre à jour depuis quelques jours.
- La partition pour les mails de la baie est pleine à 99% . Fear
- La latence des disks de CransTechnique/LesServeurs/Virtuels/ServeurSilice a explosé depuis quelques jours. C'est le cas de plusieurs VM. C'est synchronisé avec CransTechnique/LesServeurs/ServeurStitch. Les autre virtu ont pas ce comportement. Il faut casser la gueule à CransTechnique/LesServeurs/ServeurStitch.
Routage
Bon en fait on a des soucis de routage v4… On a des boucles sur le réseau…
Va falloir investiguer…
Benjamin et WikiMikachu veulent reprendre le routage et le parefeu. WikiFardale aussi est motivé pour aider sur ça.
Gâteau
WikiErdnaxe a accepté de devenir Nounou et a apporté des biscuits (🍪).
Bravo à lui !