• Réunion précédente
• Pad de la réunion

Présences :

• HgO
• Tharyrok
• Célo

Jitsi: https://conf.domainepublic.net/neutrinet

Moment informel durant lequel on exprime en peu de mots comment on se sent et si on a une attente forte pour la réunion. Ce n'est pas un moment de discussion mais d'expression individuelle et ce n'est pas obligatoire

Si l'une ou l'autre personne exprime une attente forte, merci de vous en occuper en priorité ou de la noter dans le hub ou dans un point approprié.

FIN: 17h

Mettre en place des ateliers pratiques (ansible, ssh, gopass, git…)

TODO: Sondage pour la date après la prochaine réunion hub infra (ou dans 2 mois) du Neutriton Keycloak v2 → HgO

TODO: Créer le playbook Ansible pour Keycloak → HgO et Célo

TODO: Créer le playbook Ansible pour oauth2-proxy

TODO: Créer le playbook Ansible pour Netbox (dépend de Keycloak)

TODO: Créer le playbook Ansible pour Peering Manager (dépend de Keycloak)

TODO: Créer le message de bienvenue pour Moattermost → Célo

• De mémoire, il se configure sur le serveur, et il faut un plugin welcome-bot
• https://github.com/mattermost/mattermost-plugin-welcomebot/blob/master/README.md

TODO: Agresser à nouveau le support Mattermost pour avoir la licence sur 3 ans et pas 1 ans → Tharyrok

TODO: Créer un Neutriton sur la question du suivi des differentes versions logicielles

TODO: Faire l'article de blog sur le chriffrement des serveur → Célo

TODO: Wikifié le pad https://doc.neutrinet.be/hib-dc-2022-06-11# → Célo

TODO: Chiffré les disques de 1To de Backup → Tharyrok

TODO: Voir comment backuper les pfsense

TODO: Ajouter dans ansible la persistance des logs systemd → HgO

Elastic search a changé de licence et n'est plus considéré comme open-source. Le problème, c'est que Zammad ne supporte pas son alternative OpenSearch.

Deux solutions : soit on reste sur la version 7.11 d'ElasticSearch (open source), soit on installe une version supérieure. C'est en particulier le xpack qui concerne la sécurité et qui est propriétaire (mais on en a pas besoin car on ne fonctionne qu'en local). On pourrait donc continuer à utiliser ElasticSearch en se passant du composant propriétaire.

Pour la compatibilité avec Zammad : https://docs.zammad.org/en/latest/prerequisites/software.html#elasticsearch-optional

HgO a commencé un playbook pour Zammad. L'idée serait aussi de se passer d'Hetzner et donc de déplacer ça et le mail de la VM Hetzner.

Il y a un script (salmon) qui se connecte à Zammad pour détecter tous les mails en spam pour faire de l'éducation contre les spammeurs. https://gitlab.domainepublic.net/Neutrinet/salmon

Question que si on fonctionne sur notre propre infra pour les mails, si elle n'est pas fonctionnelle, les mails ne fonctionne plus → mais on a tous au moins un mail qui ne dépend pas de Neutrinet et la mailing list n'est pas hébergée par nous. Donc on peut prendre cette décision.

TODO: Tharyrok doit copier le playbook pour le mail qu'il avait fait de son côté.

Cela complèterait le playbook qu'il avait commencé pour le relay smtp : https://git.domainepublic.net/Neutrinet/infra-ansible/-/merge_requests/176/diffs

Désactiver toute la partie “probe” pour ne les avoir que sur les VM de la FFDN, càd les sondes http, certificats et le ping du VPN, ainsi que le plugin nagios pour savoir si le VPN est up ou down.

En effet, on a eu 4 endroits où on a une VM :

• tetaneutral
• aquilenet
• grifon
• rezel

Il faudrait ne plus utiliser le système de probe de telegraf, mais à la place utiliser blackbox de Prometheus :

https://github.com/prometheus/blackbox_exporter

La raison est que les métrics sont plus fines et on peut avoir plus de types de target. Cela remplacerait ping http de telegraf.

Blackbox est un outil de monitoring réseau.

HgO a modifié le template des mails qui notifient l'expiration des certificats. En prenant en compte les remarques pour rendre le message plus clair.

https://git.domainepublic.net/Neutrinet/vpn/cleaning_old_certificate/-/merge_requests/3

On vérifie si le script fonctionne toujours

… ça ne créé pas le ticket dans Zammad.

Cas qui fonctionne bien : /opt/cleaningoldcertificate/logs/clean-2022-01-31.log Cas qui fonctionne moins bien : /opt/cleaningoldcertificate/logs/clean-2022-09-06.log

HgO va regarder pourquoi le ticket n'a pas été créé dans Zammad le 06/09…

HgO travaille sur la migration de jessie à buster de la vm ISPNG.

Le POC se trouve sur la VM ispng.patata.louise.neutri.net, et on peut se connecter dessus avec l'IP 80.67.181.132

Le test a été fait avec Raoul (la brique !), on peut le voir sur son IP : 80.67.181.183

Il y a juste que le VPN se déconnecte tout le temps ^^ mais c'est un peu le comportement attendu

La question, c'est quand qu'on fait le switch d'un VPN

En gros, il faut prévenir les gens qu'il y aura une petite interruption. L'IP changera pas mais on la basculera vers la nouvelle VM.

On utilise un Postgresql en local, parce que la VM se trouve dans le réseau management, routage, patata mais du coup le vrf empeche de contacter le cluster pgsql.

On pourrait avoir deux ISPng en primaire - primaire. ISPng 1 recevrait une connexion VPN, la rajouterait dans la table de routage, et devrait expliquer à ISPng 2 de faire pareil.

Mais la question, c'est aussi de savoir quel niveau d'énergie on veut mettre là-dedans sachant qu'on va virer ISPng un jour…

En réinstallant ISPng, cela permet de tester des choses. HgO a constaté qu'il mettait 10 minutes à se mettre en route. C'est probablement en raison de la full view BGP et de ISPng qui doit scanner toutes les routes.

Cela n'est pas très gênant, c'est quand ça crash que ça peut être un peu long.

Parce que si on redémarre ISPng, les gens ne peuvent plus créer de nouvelles connexions, mais les autres restent connectés (tant qu'ils sont connectés). Pareil pour la création de compte VPN.

TODO : Faire un sondage après octobre pour faire le switch vers buster.

Tharyrok voit Verixi vendredi prochain, donc il pourra les relancer à ce moment-là.

Pas vraiment le temps en ce moment ni les finances.

Et pour domaine public, il y a déjà des backups de leur côté, donc a priori ils en auront pas besoin.

À la base, l'idée c'était d'avoir une échange à somme nulle, et donc de ne rien facturer, mais cela impliquerait d'ajouter un serveur, ce qui n'est financièrement pas faisable pour Neutrinet cette année.

Tharyrok va se rendre à la frnog36 à Paris, et donc il croisera Verixi là-bas, et sans doute plein d'autres gens (la FFDN est-ce que tu seras là ?).

L'interface est maGNUfique.

Tharyrok a même cherché des belles photos pour le login.

Le logo est trop bien, c'est un rj45 retourné, qui ressemble à un space invader.

Il y a encore beaucoup de travail mais ça prend forme et plusieurs briques commencent à être fonctionnelles. Toutes les briques techniques sont en place.

L'idée est d'avoir le minimum pour commander une VM. On pourra choisir le type d'installation (manuel ou d'après un template de Neutrinet), choisir l'OS,… et ça appelle les fonctionalités de Proxmox. Cela permettra la gestion de machine en tant que personne ou organisation.

Et bien entendu, si quelqu'un veut reprendre l'interface pour l'améliorer, c'est possible

L'outil est pensé pour faire du microservice, même si c'est du monolithique pour le moment. Mais par exemple, pour les rDNS c'est un service qui est appelé plutôt que de regarder dans la db directement.

Donc Tharyrok MENT quand il dit qu'il fait un peu moins d'infra

Pourquoi développer un outil maison ?

L'interface de Proxmox n'est pas prévue pour être mutualisée et un outil comme ISPconfig ne gère pas les backups ou les snapshots par exemple. Il est aussi sûrement pensé pour des entreprises et s'intègrerait mal dans un modèle associatif.

Prochaine réunion hub infra : 14h00, le 12 novembre 2022

Lieu : Jitsi & Caldarium

Moment informel durant lequel on exprime en peu de mots comment, à titre personnel, la réunion a été vécue que ce soit positif ou négatif. Si une ou plusieurs tension est née durant la réunion, il est peut-être nécessaire d'envisager l'une ou l'autre réunion pour y remédier.