2025/01/26 (infra)

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

Heure de début : 14h

Présences :

• HgO
• Célo
• Tharyrok

BBB : https://talk.domainepublic.net/b/neu-er0-cbd-8in

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

Fin: 16h

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)
• Voir comment backuper les pfsense → HgO
  • Il y a deux possibilités : https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/211
• 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~~ → c'est payant
  • Faire le dashboard de monitoring interne des services, vps chez-meme (Tharyrok)
• Documenter les pfsense
• Modifier le role commun pour utiliser Chrony → Tharyrok
• Mobilizon :
  • Mettre à jour Mobilizon (on est en v3, ils sont en v5, HgO fait la v4) → Célo
  • Essayer d'optimiser Mobilizon vis-à-vis des lenteurs de database (et voir si d'autres on le même soucis) → HgO
  • Voir si le split lecture/ecriture pgsql est possible
• Tharyrok termine les MR pour Ansible et HgO les reviews
  • https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/merge_requests/287
  • https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/merge_requests/281
• On se donne pour la fin de l'année pour trouver des devs pour Backoffice.
• On se donne aussi la fin de l'année pour finir le cahier des charges du VPN

Trouver une date pour :

• Créer un Neutriton sur la question du suivi des différentes versions logicielles
• Faire l'inventaire des switchs avant octobre 2025
  • ~~courant septembre, durant l'install party du 15 septembre~~ A redefinir
  • Mettre à jour le switch
  • Vérifier s'il crashe
  • Regarder si carte 10Gbps
• Pour le 26/01 :

  1. Tester Passbolt
  2. Tester Nextcloud Password
  3. Contacter Passbolt pour savoir si nous sommes éligible a une licence pour les pauvres ou les radins.
     1. 30% de reduction
     2. On n'a pas les sous

https://support.neutrinet.be/#ticket/zoom/21706

https://lebureau.coop/tarifs/

https://mastodon.scop.coop/@lebureau_coop

Après discussion, on va migrer juste les noms de domaine de nos adhérents (donc pas les noms de domaine utilisés par Neutrinet). Il faut encore attendre qu'ils aient une infra solide pour qu'on puisse transférer les noms de domaines de Neutrinet.

TODO: HgO s'occupe de transférer les noms de domaine

Ça fait un moment que Bookworm est sorti, ce serait bien qu'on commence à migrer les serveurs qui sont encore en Bullseye. Pour voire le date de support : https://endoflife.date/debian

Il y a aussi la montée de version de PostgreSQL 13 qu'il faudrait faire. Sa fin de vie est pour bientôt. Pour voire le date de support : https://endoflife.date/postgresql

TODO: Trouver une date de Neutriton pour les mises à niveau \o/ À combiner avec le Neutriton sur le suivi des versions

On se fait jeter par Nubo à cause de la blocklist barracuda:

host mail.nubo.coop[79.99.201.10] said: 550 5.7.1Service unavailable; client [116.203.253.98] blocked usingb.barracudacentral.org (in reply to RCPT TO command)

Et effectivement on a mauvaise réputation sur https://barracudacentral.org/lookups/lookup-reputation

À court terme, il faut dire à Barracuda qu'on n'est pas des spammers.

Mais ça relance la question d'avoir notre mail avec une IP de Neutrinet. On fait déjà le boulot de nettoyer notre range IP pour les membres, cela ne devrait pas rajouter beaucoup plus de travail.

On va devoir rendre visite au datacenter !

Verixi a changé l'ATS (voir la réunion des hubs pour rappel).

On a donc maintenant deux arrivées électriques.

Il faut qu'on trouve une date pour venir mettre des multiprises. Ça devrait être plus facile que les autres fois. On en profiterait pour organiser des visites au datacenter.

Il faut encore que Verixi fasse tomber en marche le monitoring de notre consommation électrique. Pour le moment, on n'a pas de vue là-dessus, mais eux non plus ? De toute façon, a priori les multiprises ça consomme pas grand chose, et c'est tout ce qu'on veut rajouter prochainement.

Est-ce qu'on propose de faire une visite au DC pendant le OFFDEM ? Bah oui

TODO: Trouver une date pour remplacer les multiprises

L'IPv6 est retombé en marche \o/ Youpi

Comment ça se passe la collecte ?

Classiquement, ce qui se fait avec Verixi pour coaxial, fibre ou vdls, c'est qu'on fait un lien pppoe (point to point protocole over ethernet). Cela permet, sur une couche bas niveau (couche L1, au dessus d'ethernet, mais en dessous des mac address). Cela permet qu'on ait des trames qui partent du modem, du routeur, qui contactent ensuite l'équipement de Verixi. Verixi voit des trames, reçoit le login en @neutrinet et renvoie au serveur radius de Neutrinet.

Neutrinet reçoit la demande et répond une IPv4, une IPv6, etc., toutes les infos nécessaires pour qu'une connexion internet fonctionne. C'est compatible avec tous les routeurs, modems existants. C'est un vieux protocole de la nuit des temps, mais il n'est pas chiffré.

MTU PPPoE : le MTU de base d'un lien PPPoE est (en octets) MTU Normal sur internet : 1500 Mais Proximus supporte quand à lui un MRU supérieur.

MRU PPPoE : 1512

MTU PPPoE : 0008

MTU VLAN : 0004

MTU abon : 1488

MTU abonn : 1500

Ainsi, on peut avoir un abonné avec un MTU de 1500 plutôt que 1488.

MRU : Max taille du paquet, MTU minimum de la taille du paquet

Avoir un MTU de 1500 chez l'abonnée permet de pas avoir de TCP MSS Clamping (rien à voir avec le festival Espéranzah, ni avec Médecins sans frontière), le TCP MSS c'est la taille maximum de la charge du paquet réseau, qui est de 1480 en IPv4 et 1460 en IPv6.

En gros, c'est compliqué de faire rentrer des paquets s'ils ont pas la bonne taille. Si on veut faire du chiffrement, cela rajoute 20 octets, et donc on tombe à 1532. Il manque aussi d'autres calculs savant à faire, mais au final on arrivait à 1560 / 1580 octets. Or, Proximus supporte que 1548 octets. Tristitude.

Pour avoir une connexion entre Neutrinet et l'abonné qui est chiffrée :

MTU abonn : 1400 MTU IpSEC : 28 MTU GRE : 20

On peut le faire mais avec un reduction importante des paquets ce qui en soit n'est pas grave c'est juste que cela en genère plus de trafic vu qu'on transporte moins de donnée par paquet.

L'idée de wireguard initial n'est pas possible car on utilise des vrf, ce que ne suporte pas wireguard.

Par contre, avec la méthode IpSEC/GRE, ce n'est pas compatible Fritzbox. Les autres appareils (pfsense, opensense, vyos, openwrt) sont compatibles.

Il y a des soucis de connexion avec cette occupation. On se dit qu'on passerait ce soir pour voir ce qu'il en est.

La question est de comprendre ce qui ne marche, si c'est le modem c'est étrange car personne est censé y avoir accès. Est-ce que c'est le switch (qui est censé être derrière une porte verrouillée) ? Ou alors les antennes qui serait trop basses ?

Le bot aujourd'hui ne permet pas de rejoindre un salon créé précédamment, il en récréer un a chaque reconnexion.

Comme c'est le bot qui crée le salon et invite la personnen on constate qu'il recrée régulièrement le salon.

HgO va donc changer ce comportement.

L'utilisateur crée un salon privé avec le bot. Le bot rejoint le salon. Si c'est le premier salon que l'user a avec le bot, alors cela déclenche la commande “register” qui dit au bot d'inscrire l'utilisateur et ce salon en base de données. Sinon, si l'user a plusieurs salons, il peut lancer la commande register manuellement, et cela désinscrit du précédent salon.

Côté admin: Les admins sont les personnes qui se trouvent dans le salon officiel des alertes. Il n'y a pas de check sur les noms des utilisateurs des admins, c'est tout le salon qui est pris en compte. L'admin associe l'uuid du client VPN à un nom d'utilisateur matrix, avec la commande “associate client_vpn=uuid user:matrix.org”.

Quand il y a une alerte avec le label correspondant à l'uuid, le bot envoie l'alerte dans le salon inscrit par l'user. Il n'y a qu'un seul salon possible.

Passage de diskcache a sqlalchemy pour géré les données persistantes.

Dans les changements, il y a eu aussi la config qui est devenue un singleton.

Dans les étapes qui restent à faire : - Mettre à jour les tests - Vérifier que les exceptions sont bien gérées - Refactoring du logging

Prochaine réunion : 13/04 à 14:00 lieu à confirmer

Date pour une visite au data center : 23/02 à 17h (heure à confirmer)

Date pour un neutriton de mise à jours des serveurs et suivi des versions : 5/04 à 10h lieu à confirmer

Garde-Pad : Célo

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.