Table des matières

2022/01/09 (infra)

Présences :

Excusé·e·s :

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

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

Fin vers 16H / avant 19h

Neutriton

Retour sur les différents Neutriton et des décisions prises/à prendre https://wiki.neutrinet.be/fr/infra/start#reunions

Pour chaque Neutriton, on traitait un sujet technique dans le but d'avoir des solutions techniques pour Neutrinet.

PFSense

Pour utiliser CARP avec proxmox il faut une interface physique par vlan pour avoir une adresse mac par vlan.

Actuellement, des soucis avec edge-[01,02] et pfsense-[01,02] car edge-02 répond sur l'ip vip même s'il est en slave. pfsense-02 est éteint.

Pour que la HA fonctionne, il faut attendre la refonte des réseaux (cf. plus bas).

wget: dispose d'une version Entreprise de OPNsense avec des heures de consultances.

À l'époque, il y avait des instabilités avec OPNsense, mais elles ont été résolues depuis, normalement.

Il n'y avait pas non plus de séparation claire entre les groupes de règle.

Configuration management

Nous avons choisi ansible et le repos est ici : https://gitlab.domainepublic.net/Neutrinet/infra/

Parmi les raisons :

Les secrets sont dans le password store de Neutrinet, lui aussi sur un repo git.

HgO et Tharyrok ont écrit des playbooks Ansible en 2021 pour compléter les besoins de l'infra et mettre en pratique les décisions des Neutriton.

Pour contribuer, on peut relire des merge request ou en proposer, ou encore ouvrir des tickets.

Il y a aussi encore beaucoup de documentation à faire. Ce n'est pas forcément très technique et c'est quelque chose qu'on peut faire ensemble.

TODO : Reunion sur les belles et bonnes pratiques Ansible

Reverse proxy

Choix de haproxy comme frontend et caddy2 pour les backend.

Quand c'est possible, on privilégie haproxy, et s'il faut servir du PHP ou des pages statiques, on utilise caddy2.

wget: quid du point d'entrée si plusieurs DC. → La question ne se pose pas car un seul DC pour l'instant.

PostgreSQL HA

Choix de patroni.

L'idée était de mutualiser la base de données PostgreSQL avec tous les services de Neutrinet. Pour ce faire, on a choisi Patroni pour avoir un cluster en HA.

Monitoring

Utilisation de telegraf, prometheus, altermanager, grafana, Loki.

Pour le moment, on a telegraf, prometheus et altermanager. Il reste encore Loki à mettre en place, et on a un soucis sur la rétention long terme des metrics Prometheus.

Backup

Choix a définir entre borgbackup et restic.

SSO

On a choisi Keycloak.

Permet d'avoir un identifiant unique dans tout Neutrinet.

Pour le moment, ça n'est pas encore mis en place.

wget: intéressé de suivre ce projet, mais la lecture de la pull request répond à la question. tharyrok: faire un neutriton en reviewant une merge request et en regardant comment c'est configuré.

TODO: Neutriton pour review la merge request et regarder comment on configure Keycloak.

DDOS

On a choisi FastNetMON.

Permet de mitiger les attaques DDoS. Suite à ce Neutriton, Verixi nous a contacté pour nous donner quelques astuces pour mitiger les DDoS.

Structure des services et VM

Avant tous les services étaient sur la meme machine, on a séparé ça avec une VM par service.

Reste à déplacer Mattermost et l'admin de ISPng (frontend statique). Et bien entendu, ISPng lui-même.

Ce qui reste

Finance

Host Lieux CPU RAM Disk Cout/mois Periodicité Rôle
probe-01 FirstHeberg 2 1G 20G 0 € neant peering verixi
probe-02 OVH 1 2G 20G 3.63 € annuel peering belgiumix / bnix
monitoring Hetzner 2 4G 40G 7.2 € mensuel transit verixi
storage box Hetzner N/A N/A 500G 5.93 € mensuel storage monitoring
runner Hetzner 1 2G 20G 4.21 € mensuel Gitlab runner
mail Hetzner 2 8G 80G 13 € mensuel serveur SMTP
pbs Hetzner 8T 3,80 GHz 32G 4x2T 58 € mensuel Proxmox Backup
Total 91.97 € mensuel

Pour économiser, on pourrait déplacer runner et mail assez facilement pour les mettre dans LouiseDC.

Infrastructure

Listons les tâches à faire, service à améliorer.

Les backups

Choix entre restic et borg ?

Petit rappel, les deux outils sont assez similaire (déduplication, etc.).

Différence :

Borg est un outil que plusieurs d'entre nous ont utilisé. Restic moins, donc c'est peut-etre mieux de commencer avec borg. Par ex: https://wiki.gnuragist.es/documentation:borg

Le jour ou on change, ça se fait facilement. On perdra la rétention mais on peut garder les anciens backup.

Décision : Utiliser Borg (borgmatic) soit avec une storage box, soit sur une machine avec beaucoup d'espace disque.

Pour le S3, le mieux pour le backuper est d'avoir un clone en utilisant rclone vers un autre service compatible S3.

Choix à faire pour les bases de données:

TODO: Faire une demo de ces outils et choisir a la prochaine réunion. On active les dump avec borgmatic

Choix des lieux pour les backups + budget

Est-ce que la storage box se trouve dans le même DC que le serveur utilisé pour les backups Proxmox (PBS) ?

On peut aussi utiliser le Cold Storage s3 de Scaleway : https://www.scaleway.com/fr/c14-cold-storage/

Décision : Faire un backup toutes les semaines dans un nouveau bucket, et en conservé 52 (1 an). Par exemple, pour 50Go de backup, ça revient à 5.2€ / an.

Mattermost board

https://docs.mattermost.com/guides/boards.html

Pour avoir une meilleure vue des tâches à faire dans le hub infra, et permettre plus facilement aux nouveaux venus de participer.

Gitlab serait toujours utilisé pour la gestion au niveau du code (Ansible, Neutrinet app, etc.), et Mattermost board serait pour la gestion quotidienne.

Monitoring

Durée de rétention des données (promscale)

Sur la VM monitoring, il y a une storage box pour accueillir les metrics de prometheus.

On voulait faire sur le mode fédération pour recueillir toutes les métriques, y compris avec coupure réseau.

Cependant, ce n'est pas comme ça que fonctionne la federation dans Prometheus.

En mode fédération c'est le prometheus principal qui va récupérer les données des prometheus distant. En mode remote c'est les prometehous locaux qui envoient les données au remote storage. On stocke en local et puis on envoit les métrics chez Hetzner. Du coup, en cas de coupure, cela se re-synchronise.

Il y a promscale qui propose cela. En combinant promscale et prometeus et postgresl on a le meilleur des mondes.

Tharyrok est en train de faire un POC avec une Kimsufi (21.76€/mois) et 4To de stockage comme alternative à la storage box.

À noter que cela pourrait être aussi un 3ème lieux pour les backups.

TODO:

Alerting

On utilise un bot maintenu par l'équipe de Matrix pour envoyer les alertes dans un salon matrix :

On utiliserait le matrix de domainepublic. Attention de ne pas créer une trop grande dépendance dans l'infra de domaine public.

On est favorable à arreter les adresses mails quand c'est mis en place.

Par contre, il manque un outil de gestion des alertes (acknowledgement, pagerduty, alerta, etc.) et d'escalation.

Solution de classer les alertes en fonction de la criticité, et envoyer un sms uniquement pour les trucs vraiment important.

Ordre de priorité d'implémentation

Status Page

On avait parlé d'avoir une status page, un peu comme status.gnuragist.es (statping) ou via un autre outil (cachet, uptime kuma)

En travaillant sur le bot matrix, on se dit qu'on pourrait avoir un channel public avec des alertes assez simple (du style Mattermost est down, VPN est down, etc.), et cela permettrait aussi de discuter du problème sur ce cannal quand tout est cassé.

Mais peut-être que uptime-kuma permet aussi tout ça, donc à tester.

TODO : Exprimenter uptime-kuma et/ou salon public matrix

Ansible

Utilisation d'un agent comme Ansible Semaphore ?

Pour le projet ketupa, on a besoin de lancer des playbooks Ansible à intervalle régulier pour faire des modifications de config. C'est soit ça, soit avoir un autre outil de config management.

Autre problème, ansible-pull ne permet pas de se déclencher à distance, mais uniquement via ligne de commande. Par ex, via un cron job.

Semaphore date d'il y a quelques années mais intègre des fonctions intéressantes : api, pouvoir lancer des playbook sur tous les serveurs tous les jours ou tous les deux jours. Comme ça, si un humain modifie quelque chose, ça n'est pas persistent, ça oblige a passer par ansible (avec le risque que c'est plus exigent pour faire les playbook).

La gestion des vaults est un peu hacky mais ça marche bien.

Pourquoi on a besoin de ces fonctionement de ketupa, que ce soit provisionner un nouveau vpn ou une vm, il faut modifier une config… on préfère appliquer alors un playbook.

Semaphore serait cependant une vm qui aurait vue sur tout les réseaux, ou alors on limite sa vue avec du routing. Mais cette machine ne serait pas accessible de l'extérieur, mais uniquement en passant par les pfsense.

On pourrait aussi avoir besoin de semaphore pour déployer le nouveau vpn.

Pas d'objection forte pour tester.

Postfix vs Opensmtpd

Il y a deux cas d'utilisation :

Exemple opensmtpd en mta : 

listen on localhost

table aliases file:/etc/aliases
table secrets file:/etc/smtpd-secret

action "relay" relay host "tls+auth://label@example.com" auth <secrets> mail-from "toto@example.com"
match for any action "relay"

VM a déplacer/créer

Passage de buster vers bullseye

OOB via 4G

Obé ? Obééé ?
Pano ? Non c'est Obé…
Out-of-band management : https://en.wikipedia.org/wiki/Out-of-band_management

Tharyrok a testé la 4G dans le datacenter, et en tout cas avec son smartphone et Orange, il avait du réseau.

https://www.thingsmobile.com/business/plans/individual-sim-card-data-packages Nous permettrait d'avoir une carte sim sur topi, et d'avoir un VPN fournit par thingsmobile.

On a droit à 1Go de traffic sur un an pour 50€/an. Cela permettrait de se connecter en ssh à topi quand tout est cassé. De manière à pouvoir réparer les edge.

On n'a pas le prix du VPN par contre.

Que ce passe-t-il quand topi n'est plus disponible ? Est-ce que c'est nécésaire ?

TODO : Reporté a la prochaine réunion

Version tracker

https://release-monitoring.org/

C'est un projet fedora qui permet de suivre les versions des projets.

Journée cabelporn

TODO: Créer un sondage pour fin janvier

Miam miam plus de ram

TODO: prochaine réunion

Refonte des réseaux

La problématique est de pouvoir monter une vingtaine de sessions BGP. Et FRR ne garde pas l'ordre des règles, ce qui rend compliqué la notion d'idempotence nécessaire à Ansible.

Problème des PfSense qui répondent à la place de l'autre… et du coup les requêtes sont rejetées.

Questions :

TODO: choisir une date pour appliquer la nouvelle config, en février

Chez-mémé

Chiffrer ou pas les disques des serveurs ? TODO : Apres le neutriton, qui sera donc après la refonte des réseaux

Mais il faudrait le faire avant qu'on mette nos vm… donc à faire plus ou moins dans le meme timing que la refonte du réseau. Si on le fait après, ce sera plus long mais pas impossible.

Collecte

Chiffrer la communication entre le TPE (microtik dans les ménages) et Neutrinet, ou pas ?

On peut faire la communication p2p (point to point) entre Neutrinet et le TPE avec ou sans chiffrement.

On utiliserait :

Sans chiffrement :

Avec chiffrement :

TODO: La journée de la collecte

Ketupa

L'etat actuel de ketupa n'est pas exploitable et il ne faut pas compter dessus ni utiliser son code.

Le but initial est de remplacer ISPng, mais aussi backoffice pour les commandes de brique, car ces deux projets ne sont plus du tout maintenus.

Il y a aussi la question d'avoir un outil de commandes des VMs, etc. Bref, c'est le futur SI de Neutrinet.

TODO:

Prochaine réunion

TODO: réunir les TODOs (ne pas oublier celui qui suit)

Prochaine réunion hub infra : réunion en mars

TODO: Après la refonte des réseaux, on se planifie la réunion hub-infra en mars

Lieu : Jitsi & Caldarium

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.