documentation/compte_rendus/2020_05_09.md

Réunion du Collège Technique

• Date : 09 Mai 2020
• Début : 14:07
• Fin : 19h16 (ouais c'était un peu long)
• Lieu : En visio
• <>
• Jitsi : https://jitsi.crans.org/confINement

Présents:

• erdnaxe
• Esum
• shirenn
• Hachino
• Pollion
• Vulcain
• TinyLinux
• Mikachu
• Krokmou
• Vite fait au début
• Ÿnérant (là chez PA)
• PAC
• Thybal

Un jitsi scalable

https://github.com/jitsi/jitsi-meet/blob/master/doc/scalable-installation.md

On a augmenté la ram de Jitsi à 4G, ça a l'air de mieux tenir. On vient de se rendre compte que jitsi a publié un topo pour faire passer tout ça à l'echelle.

« The Jitsi-Meet server will generally not have that much load (unless you have many) conferences going at the same time. A 4 CPU, 8 GB machine will probably be fine. The videobridges will have more load. 4 or 8 CPU with 8 GB RAM seems to be a good configuration. »

Est-ce qu'on upgrade encore ? Est-ce qu'on tente d'avoir plusieurs videobridges?

'''''Erdnaxe''''' : Java11 va probablement réparer des choses.

'''''Hachino''''': - Pourquoi on a envie d'augmenter la puissance ?

• On a envie de garder ce service car il est cool, et en l'état il se met(tait) à crasher au bout d'une vingtaine de minutes.

'''''TLinux''''' : Pourquoi certaines personnes n'entendent pas les autres ?

• Ça fait partie des bugs qu'on a observés, et c'est potentiellement lié au manque de ressources (en particulier à la RAM). On espère que ça va être fixé.

'''''Mikachu''''' : Si le serveur peut pas être mis à jour vers java11 il va falloir trouver une solution pour pouvoir quand même mettre à jour vers Buster, ou alors dropper le service.

On ansible-ise jitsi ? oui On tente un passage sous buster malgré la jvm ? oui, sur une nouvelle vm à créer pour l'occasion.

'''Conclusion :'''

• On va garder la vm jitsi actuelle
• En parallèle on déploie un videobridge satellite sous buster pour tester.
• À terme on aurait un jitsi-meet et des petits videobridges satellites.

Vulcain est intéressé. Il regardera avec Pollion.

Désactiver UPNP sur les switches

Erdnaxe : Si on ouvre vlc sur le campus (en filaire), on s'apperçoit qu'on peut voir les fichiers multimedia de certains adhérents aussi branchés en filaire. C'est un truc par défaut fait par Windows lorsque l'utilisateur a coché réseau privé. C'est pénible.

Exemple : https://auro.re/_matrix/media/r0/download/auro.re/jgDmrbRwrscMqpdrnMiHayft

Problème aussi des imprimantes réseaux.

Attaques utilisant UPNP https://community.arubanetworks.com/t5/Wired-Intelligent-Edge-Campus/Switch-Configuration-To-Prevent-SSDP-Attacks-On-The-Servers-NAS/ta-p/522657

On peut visiblement aussi désactiver mDNS sur les switches et ça a l'air de régler le soucis UPNP.

erdnaxe s'occupe de regarder ça pour le switch de sa chambre et on en rediscutera.

Quelques points sur l'avancée du crans

Du monitoring

--> Grafana + #monitoring alertes de prometheus.

On monitore maintenant le dhcp avec l'exporteur mtail On s'est rendu compte que certaines machines qui appartenaient à des adhérents en manque de connexion/adhésion, mais qui ne s'étaient pas débranchées, continuaient à faire des requêtes dhcp mais n'obtenaient évidemment aucune ip et ne faisaient que flooder. Il a suffi de forcer la déconnexion de la prise pour ça. ---> Il faut regarder si on ne peut pas demander aux switches de forcer un challenge radius tous les X temps ... Il manque la conf radius dans mtail, ça serait bien On continue à déployer des nouveaux exporteurs etc ... Venez sur #monitoring.

Pour prometheus : https://wiki.crans.org/CransTechnique/ServicesMineurs/Prometheus#Mais_dis_donc_Jamy_comment_.2BAOc-a_marche_.3F

Krokmou est intéressé par regarder pour éventuellement rajouter des nouveaux exporteurs. Pollion propose de monitorer l'état des dépots git.

cranspasswords 3.0

Pour l'instant c'est encore une version beta. Il reste des bugs, mais on se rapproche d'un truc qui marche bien. On continue de tester.

Des motds

Sur les machines qu'on gère avec Ansible, on indique les services dans le motd. On propose de rationaliser un peu tout ça, de mettre les services en bas, '''APRÈS''' le dessin et de tout rendre modulaire.

Des dist-upgrade

Quelle belle transition !

On a pas mal avancé dans les mises à jour vers Buster. On ne lâche rien. Pour suivre les DU, on a la page wiki idoine https://wiki.crans.org/CransTechnique/AdminSyst%C3%A8me/DistUpgrade

Du ansible

• Quand on DU un serveur, on le passe en même temps de BCFG2 à Ansible. On en profite pour faire des raffraîchissement de la conf et virer les vieux trucs legacy.
• On déploie un header sur les fichiers gérés par ansible. Pour remplacer les appels de BCFG2 à la base de donnée re2o, Pollion a développé un lookup plugin dans le dépot ansible qui permet d'interroger l'API, et qui met les résultats en cache afin d'accélérer tout ça. C'est en cours de relecture, et ça sera mergé après.
• https://pad.crans.org/p/ansible_todo
• On va remplacer les lineinfile par un déploiement complet avec des templates. Ça permet de savoir exactement les options qu'on veut. Si les fichiers proposent des include, on garde évidemment la version des dépots officiels.
• Fusion des playbooks, utilisation des tags et import_playbook. Avec les tags on peut limiter à un petit playbook.

Du wildcard

On a déployé *.adm.crans.org (pour gitlab.adm.crans.org) et *.crans.org On pourrait mettre certbot sur toutes les VM et ne pas faire de wildcard mais bien un challenge DNS-01

On a 4 options :

1. On copie le wildcard du proxy partout
2. On crée un wildcard sur chaque serveur avec un challenge DNS --> Nécessite la clé privée TSIG sur tous les serveurs mais pas de conf à écrire
3. On crée un certificat nominatif par serveur avec challenge DNS --> Nécessite une clef privée TSIG pour _acme-challenge.nom_serveur(.adm).crans.org pour chaque serveur
4. On fait du challenge HTTP --> pas possible sur adm. (enfin si mais c'est chiant et on a pas envie)

On est tous d'accord que pour les MX on veut passer à un challenge DNS. On a un petit débat :

• Pollion veut mettre le wildcard sur les autres services : On copie le wildcard du proxy. --> Option 1)
• Benjamin n'aime pas l'idée de rsync, 4) là où c'est posssible et 2) sinon ( 2) pour les serveurs sur adm)
• erdnaxe: vu la facilité du challenge HTTP-01 avec nginx, autant utiliser ça où on peut, là où il y a déjà NGINX, sinon standalone avec le serveur dans certbot
• Mikachu: Pas trop de préférences entre 1 et 2 mis à part que 2 il n'y a pas de conf à écrire.
• Krokmou : (3, trop chiant -) 1 - 2 - 4
• Hachino commence à comprendre, un peu. On va dire que le couplage 4-2 de Coq a l'air pas mal. Mais au pire mon vote n'est pas éclairé. .-.
• TinyLinux : cf. Hachino
• Vulcain: plutôt 2 pour la facilité de déploiement et de maintien

Finalement, on part sur l'option 2.

Bind vs knot

Bind marche mieux et permet de faire des wildcard et des vues DNS mais c'est à faire. https://phabricator.crans.org/T444 .

• Il reste knot uniquement sur titanic et soyouz le temps de les virer
• boeing et sputnik tourneront sous bind
• Il faut aussi remettre en place DNSSEC

Framadate

• Shirenn et Erdnaxe ont installé un nouveau serveur : voyager sur lequel ils ont mis en place un Framadate. Pollion et Mikachu ont trouvé des problèmes avec Postgres et PHP7.3. On propose d'arrêter d'utiliser la vieille version 1.2alpha et de passer à la 1.1.10 mais cela nécessite d'utiliser mysql (en local).
• Le README/wiki est flou sur la question de la version de PHP compatible

'''Que fait-on ?''' Shirenn teste mysql et si ça ne marche pas on brûle le service peut-être un framaform à venir si framadate marche bien

Divers

On a DU les proxy sous buster qui ajoute le support de TLSv1.3, ça semble très bien marcher.

Idées

Remplacer les services re2o par un nouveau dépot ansible-services, qui utiliserait le lookup, et des template jinja pour générer les configurations : alias mail dns dhcp firewall Même les switches potentiellement ? Il faudrait un connection_plugin pour envoyer la conf en http mais pourquoi pas Pas la peine, Ansible For Network Automation fournit un plugin d'Aruba nommé aruba_config qui applique une conf via SSH. Shirenn est en train de tester, on a un soucis avec les commentaires mais sinon ça marche

Ça résoudrait le soucis des erreurs 500 sur l'API, puisqu'il n'y aurait plus d'invalidation de token Déploiement par otis (la vm qui scribe tout) régulièrement via un cron.

Encore mieux, si on mettait en place du MQTT ou des webhooks :p

--> Benjamin : On crée une app dans re2o avec des signaux qui envoie à un serveur MQTT (sur Otis ?) les changements quand il y en a eu.

• On rajoute en plus une commande manage.py qui permet de faire un full-regen de la conf. --> Mikachu soulève le problème suivant :
• D'une manière ou d'une autre, un service peut ne pas recevoir le message et il faut qu'il puisse recevoir la conf complète à intervalles réguliers, fasse un diff avec ce qu'il a, et prenne la vraie conf le cas échéans. Si jamais il y a eu un diff, c'est qu'il y a eu un soucis et il envoie un mail pour que les nounous regardent.

C'est la commande manage.py qui est appelée à intervalles réguliers (toutes les heures par exemple).

Conclusion: On va tenter un concept où nos services sont regroupés dans un unique dépot avec tous les scripts de regen. On utilise potentiellement des template jinja pour proprifier. Ils écoutent la file MQTT et appliquent leur conf.

Liste des trucs à faire

On prend chaque serveur un par un dans https://wiki.crans.org/CransTechnique/AdminSyst%C3%A8me/DistUpgrade et on dresse une liste, y compris avec des gens motivés.

Collegialement moins erdnaxe qui s'est barré faire du servens (oui je rage <3 <<FootNote(C'était pour une bonne cause, c'était pour installer Plop Linux pendant un temps dt -- WikiYnerant)>>) :

• On utilise les host_vars, c'est très propre, et on track les trucs locaux.
• En plus on ne se sert pas des alias interfaces.

Point déménagement

Update, déménagement le 25 Mai des locaux crous par le BdE. On est d'accord que ça ne nous concerne pas ? On n'est effectivement pas concernés

Pollion doit recontacter le Crous de Créteil, le confinement a tout de même retardé la chose.

Le confinement a violemment bougé le calendrier, il faut voir avec la DSI pour tout un tas de trucs : La demi baie Le matos de récup Le démontage de nos bornes Révision du calendrier de déménagement --> Point du bâtiment G devient critique actuellement. EPF ? Autre ? Ulmites ?