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

Heure de début : 14h

Présences :

• HgO
• Célo
• Tharyrok

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

• Créer le playbook Ansible pour Keycloak → Tharyrok
• Créer le playbook Ansible pour oauth2-proxy (dépend de Keycloak)
• Créer le playbook Ansible pour Netbox (dépend de Keycloak)
• Créer le playbook Ansible pour Peering Manager (dépend de Keycloak)
• ~~Faire l'article de blog sur le chiffrement des serveurs → Célo et HgO : https://git.domainepublic.net/Neutrinet/website-grav/-/merge_requests/10~~
  • Ça n'avance plus, il faudrait prévoir un moment en janvier pour repasser sur l'article
  • En faire autre chose qu'un artictle de blog, peut-être une page sur l'infra de Neutrinet
• Voir comment backuper les pfsense → HgO
  • Il y a deux possibilités : https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/211
  • ~~Mettre à jour les pfsense, pour avoir borg → fixer une date~~
• Tharyrok doit copier le playbook pour le mail qu'il avait fait de son côté.
  • Ça avance lentement, calmement, doucement
• Alerting :
  • Tester le plugin Mattermost pour Alertmanager
  • Dupliquer l’envoi des alertes de Neutrinet sur Mattermost
  • Désactiver la vue de l’alerting dans le grafana publique
  • Faire le dashboard de monitoring interne des services, vps chez-meme
• ~~Mettre en place le résolveur DNS sur les pfsense pour nos doux membres~~
  • 80.67.181.21 & .22 & 2001:913:1000:11::21 & ::22
    • Accessible uniquement dans le réseau Neutrinet (80.67.181.0/24 & 80.67.191.0/24 & 2001:913::/36)
    • Ceci resout aussi nos nom d'hôte interne
• Documenter les pfsense
• Modifier le role commun pour utiliser Chrony → Tharyrok
• ~~HgO met en place la config logrotate pour dokuwiki~~
  • Je ne dirais pas que ça n'a pas marché
  • mais que c'est plus d'actualité

Trouver une date pour :

• Créer un Neutriton sur la question du suivi des différentes versions logicielles
• Décider d'une date pour le Neutriton Redis
  • Après les ateliers Keycloak
• Choisir un gestionnaire de mot de passe (Passbolt vs Vaultwarden vs Gopass)
• Faire l'inventaire des switchs avant octobre

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

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

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

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:

• Mettre à jour Mobilizon → Célo
• Essayer d'optimiser Mobilizon (et voir si d'autres on le même soucis) → HgO
• Voir si le split lecture/ecriture pgsql est possible

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.

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

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.

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

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:

• HgO et Célo demandent au hub admin.

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:

• Mobilizon
• Sauvegardes
• VPN

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:

• Soit on met en place nftables sur chaque VM
• Soit on met chaque IP en /32 et /128 pour forcer à passer par le pfsense à chaque fois

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

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.

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.

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.

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

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:

• Soit avoir une app Neutrinet Monitoring pour Yunohost qui serait un agent qui envoie des metrics au VictoriaMetrics et fait quelques checks pour vérifier l'accès internet
• Soit exposer une config blackbox exporter dans Matrix Alertbot
  • Faire un ping sur l'IP
  • Faire une requête http sur le reverse DNS

Dans les fonctionalités:

• Permettre aux utilisateurices d'inviter le bot dans un salon et donner son userID au bot pour qu'il fasse le lien. Attention en terme de sécurité, s'assurer que l'user soit bien le propriétaire du compte
  • Demander login/pass et faire un call api a ISPng pour récupere les ips et ensuite supprimer le message qui contien le mots de passe
• Gérer les salons privés de manière plus dynamique (actuellement uniquement au démarrage du bot)
  • Nécessite une db

Tharyrok doit mettre au propre le reboot de l'exporter

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.

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.

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.

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)

• Protocole qui supporte Borg (SSH, et pas uniquement sftp, nécessite une TTY)
• SFTP (si on veut utiliser autre chose que Borg, par ex rustic, rsync, …)
• Isoler les données utilisateur·ices des autres utilisateur·ices
• Chiffrement:
  • Soit on considère que les utilisateur·ices chiffres leurs backups via Borg, etc.
  • Soit on chiffre aussi le disque du SAN, pour les mêmes raisons qu'on chiffre les disques des autres serveurs.
    • Configurer dm-crypt dans GFS2
    • Comme pour Ceph, la clé se trouvera dans la VM backup-storage
    • https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/configuring_gfs2_file_systems/index#proc_configuring-encrypted-gfs2.adoc-configuring-gfs2-cluster
      • En gros, on configure LVM, on chiffre en luks, et on formate en GFS2
• Quotas softs / hards : idée de mettre des quota, pour éviter que quelqu'un remplisse tout le disque. Soft, c'est le quota décidé, hard c'est la limite qu'on ne peut pas dépasser - à partir de là, on ne peut plus écrire sur le disque. Ca permet de dépasser un peu le quota, mais évite que quelqu'un remplisse tout l'espace dispo…
  • Cela questionne où on met le Curseurs, entre on tolère de dépasser son quota et le fait que c'est une ressource limitée. Ne pas oublier l'humain dans tout ça (il est derrière un PC).
  • Se baser sur le déclaratif : je désire 500Go de backups
    • Avoir une alerte soft à 500Go (au niveau du file system, on ne parle pas ici de notifier la personne par mail ou autre)
    • Avoir une alerte hard à 625Go (125%, mais peut-être que plus tard on changer à 110%) → on ne peut plus écrire
    • Le total des declaratif ne peux depassé le total réel sur les disques.
    • Afficher ce qu'il reste de disponible pour tous les membres en fonction de la déclaration de son quota
  • Avoir un check toutes les x heures pour envoyer une alerte si on arrive à 80%, 90%… de son quota déclaratif, ou si on le dépasse, ou si on atteint le quota hard.
• Rate limiting
  • Combien de connexions SSH on accepte ?
  • Est-ce qu'on limite les ressources systeme par utilisateur·ice
• Alertes sur le SAN
  • Disque mort ou en train de mourir
  • Stockage presque plein
  • I/O par utilisateur·ices
  • Utilisation disque par utilisateur·ices
• Suppression des données
  • Après demande de suppression, est-ce qu'on garde les données pendant un temps ? Oui, pendant 30 jours

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:

• Si on fait en fait en passif/actif on utilise la même solution que les haproxy, c'est a dire ip vip avec keepalived
• Si on fait du actif/actif il faudrait haproxy sur les pfsense pour faire du spoof ip sur les paquets tcp afin d'avoir l'ip publique dans containerssh (permet d'utiliser un fail2ban par exemple)

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:

• Déployer Sémaphore
• Déployer OpenObser
• Déployer VictoriaMetrics
• Déployer Keycloak
• Déployer et configurer ContainerSSH
• Configurer GFS2
• Déployer ketupa
• Tester tout ça / faire crasher Ketupa
• Atelier UX

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

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

Lieu : Chez Celo

Trouver une date pour:

• Créer un Neutriton sur la question du suivi des différentes versions logicielles
• Décider d'une date pour le Neutriton Redis
  • 05/10 à 14:00 au Caldarium
• Choisir un gestionnaire de mot de passe (Passbolt vs Vaultwarden vs Gopass)
  • 24/11 à 14:00
• Faire l'inventaire des switchs avant octobre → courant septembre, durant l'install party du 15 septembre
  • Mettre à jour le switch
  • Vérifier s'il crashe
  • Regarder si carte 10Gbps

Garde-Pad : HgO

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.