283 lines
11 KiB
Markdown
283 lines
11 KiB
Markdown
# 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
|
|
* <<Pad>>
|
|
* 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
|
|
1. 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
|
|
1. 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
|
|
1. 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 | Tâche Phabricator ]].
|
|
|
|
* 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 ?
|