Table des matières

2024/08/25 (Hub Infra)

Heure de début : 14h

Présences :

Météo

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 🙂

Attente(s) forte(s)

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é.

Anciens todo

Trouver une date pour :

Suivi des MR

Upgrade Ansible 9

https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/merge_requests/302

Juste une remarque “bloquante” mais sinon on peut merger.

Hub Infra

Pour le maintien et l'évolution de l'infrastructure de Neutrinet

Hub services

Mobilizon

Quand est prévue la mise à jour ? Quand il y aura du temps.

Actuellement, le cluster PostgreSQL est fortement sollicité par Mobilizon, ce qui consomme beaucoup de ressources.

C'est une des raisons de pourquoi les etcd perdent leur leader et se retrouvent en échec. Il faut voir si une mise à jour de Mobilizon peut résoudre ça. On a déjà aumgenté les ressources des machines pgsql.

TODO:

Telegraf (reporter)

Nous recevons des métriques de Telegraf, mais la plupart des tableaux de bord Grafana sont conçus pour le couple InfluxDB/Telegraf. De plus, en cas de perte de réseau, Telegraf ne réalise pas de backfill, ce qui peut entraîner la perte de métriques précieuses.

Tharyrok aimerait que nous envisagions l'utilisation du couple Vector/Prometheus Exporter. Nous pourrions utiliser les exportateurs classiques de Prometheus et Vector pour les envoyer en mode Prometheus Remote.

Ansible

Structure

L'idée de base du repo Ansible est de pouvoir gérer en un seul endroit nos playbooks Ansible pour les besoins de Neutrinet, et de ne pas devoir chercher l'information dans différents repos.

Actuellement, infra-ansible est orienté cluster patata, plus quelques machines en dehors de ce cluster. Par exemple, il n'est pas possible de lancer les playbooks sans la clé de chiffrement des vaults. On utilise des variables définies dans certains rôles qui sont réutilisées dans d'autres rôles (web, php-fpm qui sont à refactorer, borgmatic qui inclus les variables du rôles postgresql). Les groupes de variables embarquent différents rôles (haproxy et keepalived, letsencrypt et haproxy, etc.)

Dans Ketupa, on se base sur le playbook de base pour configurer les VMs.

Du coup, Tharyrok aimerait savoir si c'est ok de refactorer ce qu'il faut, en sachant que cela fera une grosses Merge Request. Par exemple : https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/merge_requests/287/diffs

Et aussi : https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/merge_requests/281

Le constat est partagé, des propositions vont suivre.

Pour les différents clusters que Tharyrok envisage, nous aurions au minimum Vagrant et GNS3, voire plus en fonction de nos discussions futures.

TODO: Tharyrok termine les MR et HgO les reviews

Mitogen (reporter)

https://mitogen.networkgenomics.com/ansible_detailed.html

Avec la PR suivante : https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/merge_requests/302, nous pouvons utiliser Mitogen.

Mitogen optimise les sessions SSH et apporte un véritable confort d'exécution. Les mainteneurs de Mitogen ont repris le projet en main et s'en occupent activement.

Proxmox : désactivation de l'apprentissage MAC (reporter)

https://pve.proxmox.com/wiki/Network_Configuration#_disabling_mac_learning_on_a_bridge

Il est possible de désactiver l'apprentissage local des adresses MAC dans un bridge Linux et de laisser Proxmox injecter les adresses MAC locales dans le bridge. Cela permet d'éviter le spoofing d'adresses MAC et d'améliorer la sécurité.

Hub DC

Hub Network

Le switch a (très) chaud (cacao)

SFP+:

TOTAL :

CPU :

La petite ligne en traitillé est la limite théorique… Tharyrok a pu optimiser un peu pour qu'on ne soit pas trpo au dessus.

Actuellement, le switch a chaud et les modules SFP sont à leur limite de température. Il serait préférable de les séparer, mais cela n'est pas possible en raison du manque de place. Une solution serait d'acheter un autre switch.

Je suspecte que cela pourrait être à l'origine des freezes du switch. Nous pourrions également remplacer les SFP par des modèles FS.com (on en a encore un peu), qui semblent supporter des températures plus élevées.

On peut mitiger la situation. Mais la solution la meilleure resterait d'acheter tout de même un second switch.

Nous attendons la prochaine réunion des hub le 17 septembre pour aviser si on retirer les sfp de chez-mémé

TODO:

Séparation réseau pour Ketupa

La question de créer des VM sur le cluster Patata se pose. Tharyrok aimerait que nous discutions de la manière dont nous pourrions structurer le réseau.

C'est ketupa, mais c'est aussi plus global : tous les services qui ne sont pas internes à Neutrinet. Le VPN, par exemple, est déjà une VM qui sort des machines interne (il a une ip publique). Les services qu'on fournit à nos membres sont en dehors du cluster interne.

Pour le service de sauvegardes, c'est un peu différent, on va proposer un service à nos membres. Se pose la question de la sécurité et du partage des ressources.

Soit Ketupa (web application) réutilise le cluster Postgres dans Patata, qui est utilisé par nos services internes, soit ça se fait dans un segment réseau séparé. Mais ce risque, on le prend déjà pour Mobilizon, Nextcloud…

Mais si ketupa sollicite trop et bloque les services internes, c'est problématique.

Les services Chez Mémé pourraient aller dans un vlan dédié. Les services de sauvgardes peuvent être vus comme faisant partie de Chez Mémé, car c'est un service d'aide à l'hébergement (et Mémé aime accueillir les gens chez elle)

On aurait alors le cluster Postgresql “patata” pour les services internes de Neutrinet et les services externes, càd un service que l'on met à disposition de nos membres ou du public.

Les services qui seraient externes:

Quel est notre modèle de menace ?

Pour démarrer, avoir un vlan séparé pour les services externes, ce serait déjà une bonne étape.

Une autre solution c'est de considéré que tout le monde est hostil et de faire du firewall sur chaque vm avec une whitelist de port.

Le risque c'est qu'on bypass les pfsense pour l'authentification SSH.

À part les clusters qui doivent se parler entre-eux, les seuls où une VM doit pouvoir parler dans le réseau interne c'est : haproxy (pour http et postgresql), pfsense, S3, etcd, …

Pour mettre en place tout ça:

On choisit de mettre des nftables parce qu'on veut pas tuer nos pfsenses.

Automatisation des demandes de peering (reporter)

Tharyrok finalise un script pour demander aux membres des IX de faire du peering avec nous. Les sessions BGP sont configurées en mode passif jusqu'à ce qu'ils acceptent.

Disparité des cartes réseau (reporter)

Actuellement, nous avons trois modèles différents de cartes réseau sur le cluster Patata. Tharyrok a remarqué que le ping et la gigue (jitter) deviennent instables à certains moments. La seule solution que j'ai trouvée est de redémarrer chaque nœud.

SR-IOV pour les VM Edge (reporter)

https://forum.proxmox.com/threads/enabling-sr-iov-for-intel-nic-x550-t2-on-proxmox-6.56677/

Une des pistes pour améliorer les performances, si nous disposons des mêmes cartes réseau, est d'utiliser la technologie SR-IOV. Cette technologie permet d'exposer une véritable carte réseau dans la VM, car la carte physique peut créer des cartes virtuelles. Cela améliore considérablement les performances nord-sud, ce qui est particulièrement pertinent pour les VM Edge.

Hub Dev

Cahier des charges Backoffice et VPN

https://doc.neutrinet.be/backoffice-cahier-des-charges#

De l'avancement a eu lieux sur le CDC de backoffice, le projet a été phasé en plusieurs étapes.

Il faudrait reprendre contact avec Alyve pour lui demander si elle est toujours motivée / dispo pour ce genre de trucs.

Sinon, faire un appel plus général à des développeurs.

TODO: On se donne pour la fin de l'année pour trouver des devs.

Pour la partie VPN, on n'a pas encore avancé sur le cahier des charges:

https://doc.neutrinet.be/vpn-cahier-des-charges

TODO: On se donne aussi la fin de l'année pour finir le cahier des charges

Bot d'alerting Matrix et exporter vpn

L'envoi d'alertes en privé pour que les membres puissent être informé lorsque leur client VPN est déconnecter est en cours de tests.

Dans les choses qui doivent être améliorées, il y a l'ajout des membres via une commande d'un admin, et la gestion des salons privés (actuellement le bot les trouve automagiquement au démarrage)

Il faut détecter lorsqu'un client VPN se reconnecte en boucle / très souvent.

Voir aussi comment intégrer le ping des domaines des membres:

Dans les fonctionalités:

Exporter VPN

Tharyrok doit mettre au propre le reboot de l'exporter

Ketupa

Hub Chez Mémé

Service de sauvegarde

On va commencer avec ça : https://gitlab.domainepublic.net/Neutrinet/ketupa

Mais pourquoi ?? Parce que Tharyrok est en train d'orienter ketupa vers le système de backup. Il y a des README partout, même des README pour expliquer les README, et des README qui expliquent les…

Bref, il y en a un sur le groupe Ketupa. Il a un environnement qui tourne bien, et cela lui permet de clôner son projet sur plein de machines!

Parmi les machines, il y a une machine backup-storage. Il faut maintenant voir qu'est-ce qu'on utilise pour ces backups.

Docker

https://github.com/mjaepel/ssh_user_jail_with_docker

HgO a fait des test avec la solution docker en mode jail, des test on été fait dans une VM backup sur le cluster patata. Cette solution permet de cloisonner les utilisateurs en les mettant dans un conteneur docker.

Lors de l'AG nous avons promis une solution rapide. Peu importe la soltuon choise tant qu'on y arrive. On verra le cloisonement des utilisateurs plus tard si nécessaire.

Il faut provisionner les jails via par exemple Ansible pour décrire quel point de montage pour tel utilisateurice, quels quotas, etc.

ContainerSSH

https://containerssh.io/v0.5/

ContainerSSH est un outil permettant de démarrer des conteneurs à partir d'une session SSH. Ce qui est intéressant, c'est que toute la partie authentification peut se faire via un webhook, ce qui permet à Ketupa de gérer l'authentification et d'avoir un webhook pour la configuration du conteneur.

Donc on aurait une authentification par SSH, ce qui enverrait une requête http sur Ketupa, qui dit si l'authentification est ok ou non, et si ok crée le conteneur.

Il y a aussi un webhook configuration qui permet de dire comment on va créer le conteneur. Du style les points de montage, le binding user, etc.

Il faut provisionner aussi pour créer les dossiers et les quotas.

Cet outil a rejoint la SNCF (tung tung tudoung) euh non la CNCF, qui est la Cloud Native Computing Foundation.

On part vers cette solution pour le cloisonnement et authentification.

GFS2

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/configuring_gfs2_file_systems/index

GFS2 est un système de fichiers en mode cluster, ce qui signifie que deux VM peuvent monter le même système de fichiers via une connexion iSCSI.

Il est pris en charge par le kernel.

Le système de fichiers va s'occuper de gérer les conflits d'écriture.

On aurait donc deux VMs, mais on peut choisir d'être en actif/actif ou actif/passif.

On peut mettre des quotas sur le filesystem, on peut aussi chiffrer le disque iSCSI (question à trancher)

Nos besoins pour le service de sauvegardes

Pour rappel, on s'était dit qu'on mettrait à 0,05€/Go/mois pour commencer. Le prix est calculé sur base du quota déclaratif, ce qui permet d'éviter de bloquer les ressources pour rien. À charge des membres d'estimer ce qu'iels ont besoin.

On se donne comme deadline fin septembre pour avoir une alpha.

Est-ce qu'on fait de l'actif/passif ou de l'actif/actif:

Le actif / actif permet de mieux équilibrer les deux VM qui feront les backup. Mais à un moment, ce qui va bloquer, c'est les accès disques… Donc est-ce vraiment utile ?

Le passif / actif, c'est déjà des technologies qu'on utilise donc ça demande pas trop de changement.

Le port ssh utiliser pour les sauvegardes : 3615

Dans les prochaines étapes:

TODO: HgO fait le playbook pour déployer Sémaphore

Prochaine réunion

Prochaine réunion : 19/10 à 14:00

Lieu : Chez Celo

Trouver une date pour:

Garde-Pad : HgO

Météo de fin

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.