¶ Introduction
¶ Ordre du Jour
¶ Projets orphelins (cherchant un parent)
Tous les projets ne vont pas forcément trouver de "parent", ne vous sentez pas forcé à en prendre, mais c'est bien d'en avoir si on veut s'investir et qu'on n'a pas forcément d'idée précise de quoi faire
- Pont OVH/Saclay : mise en place d'un pont WireGuard (ou IPSec) entre Saclay et OVH à la place du VPN actuel
- Peut-être mettre un pont de backup à Saclay (pour pouvoir rallumer l'hyperviseur) ? Par exemple sur les mêmes hyperviseurs que routeur-aurore et routeur-aurore-backup.
- Gestion de Knot via Ansible : Ansible-iser les configurations du maître et de l'esclave Knot (les 2 ne sont pas synchronisées entre elles, ni avec re2o)
- Obsolescence de Debian Stretch : création d'une page wiki pour tracker les VM qui sont encore sous Debian 9 (Stretch), mirgration de ces mêmes VM (attention à Unifi) et enclenchement de la migration vers Debian 11 (Bullseye) qui devrait commencer à se faire tout doucement car Debian 11 sera bientôt stable (~ Juillet 2021 - date non officielle que j'ai sorti de mon chapeau) (à mon avis avant)
- Audit LDAP actuel : audit sérieux des ACL du LDAP, et des groupes actuellement en place dans re2o (notamment ceux utilisés par les comptes fonctionnels), peut-être possibilité de développer/utiliser des outils du type BloodHound/ADCP. Multiples généralisations envisageables
- Pare-feu : revoir la configuration IPTables générée par aurore-firewall, notamment un DNAT parfois trop agressif. Migration à NFTables envisageable (concepts de sets et maps puissants qui permettraient d'avoir un fichier de configuration majoritairement statique — et plus simple à comprendre —, avec les données issues de re2o ajoutées dynamiquement dans des maps/sets) (déjà entâmé par Jeltz, mais ouvert si quelqu'un souhaite venir aider)
¶ Qu'est-ce qu'on a fait depuis le dernier CT
- Monitoring d'Aurore : installation des prometheus manquants, nouveautés sur grafana, monitoring des onduleurs, nouvelles alertes, mise à jour du ansible (présenté par Paul)
- Centralisation des logs : Kibana et Logstash changent de licence, on décide par passer sur un fork, autres avancements (présenté par Jeltz)
- Ansible : revue des changements sur Ansible de manière générale. Attention la branche master est passée en push-protect (présenté par Solal)
- Portail Captif : mise en place d'un portail captif pour les Rives (et du coup pour les autres résidences aussi), testé à GS (présenté par Ynérant et Jeltz)
- Serveur mail : avancement sur le serveur mail et la configration actuelle. En espérant qu'il sera fini d'ici le prochain CT. Des questions diveres à discuter (présenté par Solal)
- Wikijs : un nouveau moteur de wiki a été mis en place (wikijs.auro.re). Il a commencé à être peuplé de quelques pages ; venez participer à l'effort pour le remplir, faire de la documentation, porter et mettre à jour d'anciennes pages.
- Litl : déploiement d'un service de raccourcisseur d'URL fait maison, écrit en Python3/Django, fait maison par Grizzly
- Problème de LDAP : une rotation dans les IP a engendré des problèmes de connexion au LDAP. Attention re2o-ldap.adm.auro.re a changé d'ip de 10.128.0.11 à 10.128.0.21 . On pourra également mentionner des soucis sur les ACL (il faut fouiller un peu avant le CT pour avoir des choses à dire)
- Problème de compte sur étrange (spam ?) sur gitea : apparition de certains comptes étranges sur Gitea depuis qu'on a activé la création de comptes. Apparemment ils sont sur re2o aussi donc c'est peut-être normal, mais ils devraient être supprimés si inactifs (je crois qu'il y a une option pour ça dans le module LDAP de gitea). Par précaution on a tout de même activé la vérification mail et un captcha (présenté par Jeltz et Solal)
- Mises à jour : certains services et serveurs on été mis à jour, comme d'habitude. Les seuls choses qui changent un peu c'est les unattended upgrades déployées sur tous nos serveurs pour au moins les mises à jour de sécurité de Debian (uniquement pour les versions supportées par l'équipe sécurité Debian). On a également déployé un patch rapidement après l'annonce de la CVE-2021-3156 touchant sudo. Gitea est passé en 1.13.1 ce qui casse certains avatars, ça sera normalement fix dans la 1.13.2 (présenté par Jeltz et Solal)
- Compte rendu de la réunion « Mise à plat de l'Infra » : le 2020-01-26 dans la soirée a eu lieu une réunion avec pour but de mettre à plat l'infrastructure pour certains nouveaux (shirenn par exemple) qui voudrait s'investir (ou des moins nouveaux comme Erdnaxe et Ynérant).
- Possibilité de générer des certificats wildcard avec challenge ACME via DDNS : les problèmes sont résolus, on peut générer ces certificats wildcard (il faut quand même voir si c'est une bonne idée), mis en place pour le portail captif (présenté par Ynerant et Jeltz)
- Gestion de la RAM sur les hyperviseurs : gestion de la RAM, désactivation du ballooning, monitoring temporaire de certains hyperviseurs, et test de KSM (voir si on généralise le déploiement) (présenté par Jeltz)
- Correction de plein d'alertes relevées par Prometheus : quelques services n'arrivaient pas à redémarrer (souvent pour des problèmes de permissions), c'est en partie réparé. Reste networking pour interfaces IPv4 + IPv6 (à discuter) (présenté par Paul et Jeltz)
- Points divers qui ne vont pas dans un section à part :
- les dépôts Gitlab FedeRez ne sont plus des mirroirs, maintenant on fait tout en local sur gitea
- webhook gitea fonctionne, on a un bot (git-sur-yvette) qui nous donne des infos pour toutes modifs
- renommage de la VM stream qui s'appelait odin pour une raison que tout le monde ignore
¶ Ordre du jour
- Cooptation : proposition de cooptation de shirenn
- Disques durs : Jeltz a fait l'inventaire :
- on a besoin d'une capacité importante (2 Tio au moins utilisables en RAID) sur escalope notamment ;
- mais aussi sur les hyperviseurs « services » (dont merlin) qui en manquent
- on a deja pleins de disques :
- 1.2 Tio notamment dans freya, marki et thor qui sont des Gen 8 aussi, mais mal repartis.
- on pourrait transférer ces disques dans escalope, et mettre des petits disques de 300 Gio dans marki et thor qui sont des hyperviseurs réseau
- Attention cependant, les caddies Gen 9 sont-ils compatibles avec ceux des Gen8 et inversement ?
- l'inventaire des disques : https://zero.auro.re/?116ed7935a292c96#2fEiYkC1aZbVJGFGrbBD2e6dZEVMrkcw8UdQ9YGb1PVw
- suggestion :
- 4 × 1,2 Tio (marki) + 2 × 1,2 Tio (lancelot) → escalope (si caddie compatible sinon il faudra démonter/remonter, un peu chiant mais faisable raisonnablement)
- 2 × 300 Gio (escalope) → marki : 2 RAID 5/6 à reconstruire sur marki et escalope
- Adressage : déplacer switchs-manager dans le nouveau bloc de gestion re2o (il est encore sur 10.128.0.15 → 10.128.0.25 ?)
- Veille de sécurité : il faudrait peut-être s'abonner à des listes de diffusion/flux Atom/RSS pour être au courant rapidement des mises à jour à effectuer (notamment sur les systèmes qui le font pas tout seul, comme certains conteneurs, les switchs, onduleurs, iLO, …)
- DNS : Certains ont proposé d'utiliser Bind9 à la place de Knot
- Miroirs locaux : discussion sur la création d'un serveur NTP local et d'un miroir APT (dépôts officiels, Proxmox, Unifi, iLO, …)
- on a de magnifiques rôles tout prêts à être déployés https://gitlab.crans.org/nounous/ansible/-/tree/newinfra/roles/nginx-pubftp
- LDAP d'adminstration : création d'un nouveau LDAP indépendant du LDAP de re2o pour les techniciens (et apprentis)
- quelles permissions souhaite t-on donner à quels groupes exactement ?
- une proposition est disponible dans ce document séparé (pour ne pas polluer l'OdJ) : https://codimd.auro.re/UEdKs82WTDm58s3KwHE3GQ
- déjà discuté dans un ancien CT pour le coup, je pense que c'est contre productif de remettre le sujet sur la table. On a déjà dit qu'on voulait faire du tiering LDAP et ça viendra après le nouveau cluster à priori. Discuter de trucs ultra-précis genre « un nouveau système de droit » ça prend du temps et si vous voulez le faire je vous conseille de venir avec des propositons bien préparées car sinon on va passer 1h dessus.
- Projet sauvegardes : Sofamaniac aurait accepté de s'investir dans le projet (encadré par Solal). Discussion autour des outils à utiliser et des serveurs sur lesquels les déployer. Proposition : Borg backup + Borgmatic + ZFS send (pour le NAS)
- Cluster « services » : avec merlin, thor et freya. On fait quoi ? (cf. dernier CT ; NAS ou stockage distribué sur les 3 nœuds GlusterFS)
- lié à la remise à plat de l'infra
- Procédure en cas de panne d'OVH ou de Saclay : certains techniciens ne sont pas à Saclay, beaucoup de mots de passe sont sur Passbolt chez OVH, le moyen de communication principal d'Aurore est chez OVH. Il faudrait déterminer les conséquences de la perte d'un des deux sites (comment d'accéder aux interfaces de recouvrement, à la documentation, …), et inciter les techniciens à disposer d'un compte de « secours », Discord, XMPP, sur une autre instance Matrix (ou un serveur dans chaque site, mais attention aux pannes du serveur LDAP), …
- WiFi : on n'a rien fait. Mais ça veut pas dire qu'il faut rien faire, les chiffres ne sont pas très bon aux Rives et à la Pacaterie ; sans optimisation, les clients se connectent à 80% au 2.4Ghz et saturent le spectre. Dernier CT, on avait décidé de tester 2 SSID : Aurore et Aurore-2.4GHz avec du push to 5 GHz sur le SSID Aurore pour optimiser la distribution des clients. Il* faut aussi envoyer un mailall aux gens quand on le mettra en place pour éviter les problèmes.*
- Achat de sondes : budget achat de sondes d'environnement pour les onduleurs Eaton (d'occasion ?) qui n'en ont pas ? Paul ?
- Fusion des VM réseau de résidence : routage, Radius, DHCP, DNS récursif
- 1 VM pour les DNS des résidences, 1 VM pour le Radius, …
- Achat de bornes WiFi : proposition de rachat d'un carton de 5 in-wall ? Besoin :
- 1 borne à Fleming au sous-sol du bâtiment A village 1 (pas de borne à l'étage),
- 1 ou plusieurs à Emilie du Châtelet ailes est et ouest ?
- 1 ou plusieurs à GS chez des gens qui ont du mauvais WiFi (toujours)
- Traveaux électriques à George-Sand
- Déjà discuté et voté par CA et CT
- Retardé par soucis d'économies
- Remis à l'OdJ par l'inondation à GS
Ordre du jour (items de priorité moindre)
- Conservation des journaux de connexion des pare-feux de résidence ou des règles d'association du SNAT des résidences
- Uniformisation des permissions Proxmox (pas forcément LDAP, mais au moins génération par Ansible)
- Possibilité/intérêt d'isoler le VLAN d'administration (projet plus général de raffinement des VLAN)
- Changement de RTC en juillet/août
¶ Présent·e·s
- Solal
- Histausse
- Jeltz
- Leopold
- ynerant
- sofamaniac
- chirac
- etienne
- erdnaxe (parti à 19h36)
- yberreby (parti à 19h15)
- esum
- gwendal
- Taïssir
- shirenn (18h18)
- Sarcozy (18h41) départ 18h45
¶ Heure
début: 18h00 fin: 21h00
¶ Liste des projets orphelins
¶ Pont OVH/Saclay [encadré par Jeltz]
Hyperviseur chez OVH, le reste à Saclay. Le pont a été installé à l'arrache, et n'est pas mis à jour depuis 2/3 ans. Difficile à maintenir. On envisage d'utiliser WireGuard. yberreby est intéressé.
¶ Gestion de Knot via Ansible [encadré par Jeltz]
Il faudrait ansibiliser. Le secondaire est sur Kdell au Cr@ns, le LDAP passe en clair, il faudrait le chiffrer.
¶ Obsolescence de Debian Stretch [encadré par Solal]
Beaucoup de serveurs sous Debian 9, il serait bien de passer sous Debian 10. Chirac avait mis en garde sur la compatibilité avec Unifi, suivant les indications sur le site de Unifi. On peut quand même mettre à jour les autres VM et ignorer celles avec les controleurs Unifi.
¶ Audit LDAP actuel [encadré par Jeltz]
Problèmes de permissions sur le LDAP. Certains groupes ont la possibilité de lire le hash du mot de passe, d'autres non. Certaines applications sont mieux gérées que d'autres. Changer les noms des groupes pour des trucs sensés et écrire une page sur le wiki.
¶ Pare-feu [encadré par Jeltz]
Le pare-feu basé sur iptables, géré par re2o. On pourrait simplifier les règles du NAT avec nftables. Nftables c'est bien de manière générale, on pourrait passer dessus ! Déployer avec Ansible. On peut faire du logging pour retrouver par exemple les ip.
Leopold est intéressé.
¶ Optimisation Wifi [encadré par Chirac]
Problème : notamment aux Rives, 2/3 sur le 2.4GHz et 1/3 5 GHz à cause de la force du signal, ça surcharge le spectre et détruit le débit. Il faut pousser les gens à utliser le 5GHz, Unifi a une fonction magique pour forcer le passage, ça marche sauf quand ça marche pas. Il faudrait le tester sur une résidence, et le déployer à terme sur l'ensemble des résidences.
¶ Travaux éléctrique à George Sand [encadré par Histausse]
https://wikijs.auro.re/media/administratif/administratif/comptes-rendus/cr_ca_2020_07_26.pdf budget : 2500 € A George Sand on est sur le réseau électrique du CROUS, et on est soit sur le réseau auxiliaire, soit sur le réseau de Wifirst (on a pas le droit). On a eu une innondation, et ça a sauté. Le budget est déjà voté. Il faut demander à Elisabeth Carvhalo sur qui contacter. Il faut s'arranger avec le Crous pour visiter avec l'entreprise, faire des devis. Et regénocier avec le crous pour faire les travaux.
Sarcozy désigné volontaire.
(l'onduleur qui a laché a été remplacé gratuitement par Eaton, et maintenant le nouveau marche) -> on en parle à la prochaine réu du CT
¶ Coeur de la réunion: (projets à discuter et autres choses importantes qui porte à débat)
¶ Proposition de cooptation de shirenn
Solal rappelle le fonctionnement du CT et de cooptation.
Présentation de shirenn:
- à l'ENS
- nounou Crans
- avec Jeltz, ont débuggé l'ip6
- amour prononcé pour l'ipv6 et la couche 2.
Il est compétent et sympa. Personne ne s'oppose à la cooptation.
shirenn est désormais Responsable Technique
¶ Point sur les disques durs
https://zero.auro.re/?116ed7935a292c96#2fEiYkC1aZbVJGFGrbBD2e6dZEVMrkcw8UdQ9YGb1PVw Les disques sont mal répartis. Solution cf https://pad.auro.re/p/ODJ_CT_FEV_2021 , ou alors racheter des disques.
shirenn, ÿnérant et yberreby sont intéressés.
Proposition:
- marki et lancelot tous les 1.2T -> escalope
- deux disques de escalope de 300G -> lancelot/marki
- rachat de disque pour le nouveau cluster
¶ Veille de sécurité : ML et flux RSS
Actuellement la veille de sécurité ne se fait pas. Abonnez-vous à des ML Debian security. On pourrait les passer sur d'autres ML (monitoring par exemple). On peut aussi avoir un bot matrix qui s'abonne aux flux RSS, ça se fait bien. Pour les ML, mettre des separator (mais faut que chacun crée ses filtres).
TODO: Faut faire la liste des ML / RSS auxquels s'abonner
¶ DNS : Bind9 vs Knot
Il y a des trucs qui marchent avec Bind et pas avec Knot. Tous les 2 sont simples à configurer. Bind9 déjà Ansibilisé au Crans. On reste sur Knot.
¶ Mirroirs locaux (APT) et serveur NTP local
Un mirroir local c'est cool et pratique. Le retour du problème de disques. Sinon, mettre en place un proxy, ou faire du caching.
¶ Tiering LDAP proposition de structure par Jeltz
https://codimd.auro.re/UEdKs82WTDm58s3KwHE3GQ 3 niveaux de privilèges. Utiliser des tokens physiques, et les donner aux RT. Il faut éviter que plein de gens aient pleins de droits dont ils n'ont pas besoin. Ça peut permettre d'éviter qui si une machine est corrompu, l'ensemble de l'infrastructure soit corrompue. Les machines HAUT ne sont pas directement exposées à Internet. C'est une mauvaise idée d'utiliser les mots de passe admins pour se connecter aux services/wifi.
TODO : Virer le compte aurore + clef pour root
¶ Procédure en cas de panne
Quoi utiliser ? Discord Aurore ? ou un canal matrix sur matrix.org Passbolt : juste CA, autre chose pour CT
Informer les utilisateurs suite aux pannes
- message statping ?
- l'ajouter dans la page d'accueil re2o
¶ Achat sondes onduleurs : budget
Achats : Pour les onduleurs :
Cartes onduleurs :
- Vérifier présence de carte pour :
-
Fleming, GS (VDI A),
-
Pacaterie (Local nord)
-
- Auquel cas, faut-il budgétiser pour les monitorer ?
Pas de carte
- EDC (*2) (baies réseau),
- Pacaterie Sud Faut-il prévoir des cartes pour les monitorer ?
Pour les sondes :
- Eaton : https://www.ebay.fr/itm/Dell-Environmental-Monitoring-Probe-Eaton-EMP-UPS-Ups-Monitoring-Module-0JY9T4/164102799816 Au total, il en faudrait 4. Je proposerai de commencer par en acheter une, puis de voir si ça marche bien, si c’est bien celle là. Ensuite, acheter les 3 autres pour continuer le monitoring.
- APC : Deux sondes déjà à GS. Ca vaudrait le coup d’en installer une à la pacaterie Nord (déjà monitoré)
- Riello & autres : Pas encore étudié.
Budget total proposé par le Conseil Technique : 450€
¶ Fusion des VMs réseau de résidence
shrienn s'en occupe
¶ Achat de bornes WiFi : budget
Il faut acheter des in-wall pour Emilie du Châtelet (2-3), George Sand (2-3), Fleming (1)
Routeur de test + In Wall
Budget : 600 €
¶ Résumé et information
¶ Monitoring d'Aurore [pz2891]
¶ Centralisation des logs [Jeltz]
Passage à OpenDistro.
¶ Ansible [Solal]
¶ Portail Captif [Ynérant, Jeltz]
¶ Serveur mail [Solal]
Durée de vie limitée pour les clés DMARC / DKIM ?
¶ Wikijs [Ynérant?, Solal]
¶ Litl [Grizzly]
Fonctionne.
¶ Problème de comptes externes Gitea/re2o [Jeltz, Solal]
¶ Mises à jour [Jeltz, Solal]
¶ Compte rendu de la réunion « Mise à plat de l'Infra » [shirenn]
¶ Certificats wildcard [Ynérant, Jeltz]
¶ RAM hyperviseurs [Jeltz]
Activer KSM, activer que à OVH, mais ça marche bien et on pourrait le mettre partout Désactiver le balooning
¶ Corrections alarmes Prometheus [pz291]
¶ Points divers
Vous pouvez commencer à remplir l'ODJ du prochain CT : https://pad.auro.re/p/ODJ_CT_MAR_2021