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

Heure de début : 14h

Présences :

• Tharyrok
• HgO
• 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: Jusqu'au bout de la mi·nuit (19h)

• 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)
• Créer un Neutriton sur la question du suivi des différentes versions logicielles
• 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 avance lentement, il faudrait prévoir un moment pour repasser sur l'article
• Voir comment backuper les pfsense
  • 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
• Décider d'une date pour le Neutriton Redis
  • Après les ateliers Keycloak
• Faire en sorte que accounting se déploie automagiquement avec un pipeline → HgO voit ça avec tbalthazar
• Modification du rôle haproxy pour le header pour la VM VPN
• Tester Passbolt
• 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 clients VPN, VM, …
  • Déplacer le uptime-kuma sur une probe de la fédé (Aquilenet)
    • Il reste à review la MR https://git.domainepublic.net/Neutrinet/infra-ansible/-/merge_requests/262

Migration prévue demain (25/09), il y a un ou deux TODO sur ce pad https://doc.neutrinet.be/atelier-ansible-2023-06-19#

Il faudrait aussi penser à merger https://git.domainepublic.net/Neutrinet/infra-ansible/-/merge_requests/236

Pour le SMTP, c'est assez facile à faire dans modoboa. Penser a mettre les cles dkim dans la zone dns.

HgO a fait des test mais la partie reseau ne marchait point : https://chat.neutrinet.be/neutrinet/pl/g7wy4wzoqpyjmpurta5gw7f4sr

@Tharyrok que fais-tu ?

TODO:

• Revenir sur la config reseaux
• Faire un Neutriton sur les VRF

Tharyrok est retombé (mais pas en trotinette ouf) sur le projet : https://www.ntppool.org/en/

https://www.ntppool.org/zone/be

En gros, il y a quelques membres dans la zone belge du pool ntp. C'est un service qui n'est pas très lourd à mettre en place. Rejoindre ce réseau permet d'équilibrer la charge ntp. On ferait partie du pool belge \o/

On pourrait être stratum2 facilement. Etre stratum2, cela veut dire qu'on relaie la synchronisation ntp d'un serveur stratum1. On peut être un serveur ntp stratum3 qui relaie un stratum2, …

On peut aussi devenir stratum1. Devenir stratum1, ça veut dire qu'on ne relaie pas la synchronisation depuis un autre serveur ntp mais qu'on propose notre propre synchronisation. Par exemple, on peut avoir une horloge atomique mais c'est trop cher pour Neutrinet. Mais cela peut aussi être avoir une antenne gps sur un des serveurs pour avoir une synchronisation de temps fiable (on reçoit l'info des satellites qui eux ont l'argent pour avoir une horloge atomique, on sait calculer la dérive dûe à la position des satellite, c'est donc considéré comme fiable).

Si à 50 ans tu n'as pas ton horloge atomique, c'est que tu as raté ta vie ?

On peut commencer stratum2, mais avoir une antenne gps coûte à peu près 10€.

TODO: test avec un gsm dans la baie la synchro gps/galimene/…

À voir sur quel serveur on mettrait l'antenne. Sur celui qui redémarre le moins, mais comme on va probablement remplacer bour…

https://support.ntp.org/Servers/StratumOneTimeServers

Cela permettrait d'avoir une horloge locale et bio.

Les serveurs de LDN vont fermer prochainement. Les résolveurs DNS sont utilisés dans pas mal de briques internet, ce qui pose problème car il y a régulièrement des downtimes, et on n'est pas sûr que le service va être repris par un membre de la FFDN.

C'est pénible de gérer un résolveur DNS public, parce qu'il y a une partie du trafic qui est légitime.

Par contre, on pourrait le restreindre à nos membres. Et ça, ce n'est pas compliqué. On peut configurer notre serveur pour n'autoriser que nos IP.

Concernant les données auxquelles Neutrinet a accès, ça n'en fait pas plus que ce qu'on connaît déjà sur le trafic de nos membres.

Deux possibilités techniques :

1. Utiliser les résolveurs DNS des pfsense - Avantage: déjà là - Inconvénient: on a mis nos domaines internes qui sont pas censés être publics (typiquement les noms de machine virtuel). Mais ces noms de domaines sont déjà sur le wiki, et le pfsense ne va pas donner accès à la VM qui est derrière l'IP.
2. Créer une VM avec unbound, le resolveur le plus couramment utilisé. - Avantage: on cloisone mieux les DNS - Inconvénient : Cela consomme des IPs, et un peu plus de travail supplémentaire

Si c'est les pfsense, c'est ajouter des règles de firewall et une config unbound à ajouter. Si c'est une VM, c'est un rôle Ansible a créer.

Les VPN sont considérés comme externes pour le pfsense (trafic WAN)

Ce qui est gênant avec pfsense, c'est compliqué de documenter les pfsense. Par contre, les autres VM sont documentées de manière déclarative grâce à Ansible.

Est-ce qu'on est dans une sorte d'urgence pour mettre en place ce résolveur DNS ? Non, car on a choisi de communiquer à propos des résolveurs DNS, et on a ceux de FDN comme alternative.

Le seul risque avec les pfsense, c'est qu'on pourrait avoir des paquets qui viennent des neuds d'interconnexion en se faisant passer pour une IP de Neutrinet mais qui ne viennent pas du réseau de Neutrinet.

Sauf que, sur les edges on a déjà mis en place des règles nftable pour empêcher ce type d'attaque.

	chain my_forward {
		type filter hook forward priority filter; policy accept;
		notrack
		iifname { "lo", "ens20", "ens21", "ens22" } oifname "ens19" ip daddr { 80.67.181.0/24, 80.67.191.0/24 } accept comment "Accept Internet to Neutrinet"
		iifname "ens19" oifname { "lo", "ens20", "ens21", "ens22" } ip saddr { 80.67.181.0/24, 80.67.191.0/24 } accept comment "Accept Neutrinet to Internet"
		iifname { "lo", "ens20", "ens21", "ens22" } oifname "ens19" ip6 daddr { 2001:913:1000::/36 } accept comment "Accept Internet to Neutrinet"
		iifname "ens19" oifname { "lo", "ens20", "ens21", "ens22" } ip6 saddr { 2001:913:1000::/36 } accept comment "Accept Neutrinet to Internet"
		log prefix "[nftables] Forward Denied: " counter packets 0 bytes 0 drop
	}

On part sur les pfsense !

TODO:

• Mettre en place le résolveur DNS sur les pfsense pour nos doux membres
• Documenter les pfsense

Avec les mises à jour de Proxmox bullseye vers Proxmox bookworm, Tharyrok a remarqué un warning concernant systemd-timesyncd.

En fait, timesyncd ne synchronise l'horloge matérielle (RTC) qu'au démarrage du service. Timesyncd fonctionne bien si on n'a pas un serveur (un ordi qu'on redémarre régulièrement), mais pas pour un serveur.

Bref, s'il y a un warning de la part de Proxmox, c'est qu'on peut leur faire confiance.

Autre chose : timesyncd ne synchronise qu'avec un seul serveur de temps (même si on lui en donne plusieurs). Contrairement à Chrony fait une moyenne sur un pool de serveur de temps.

Cela nous rappelle qu'il faudra prendre un moment pour mettre à jour les serveurs vers Bookworm.

TODO: modifier le role commun pour utiliser Chrony. Utiliser le ntp pfsense uniquement pour le cluster patata.

• https://git.domainepublic.net/Neutrinet/infra-ansible/-/merge_requests/226/diffs

Zammad a simplifé les notifications dans mattermost. Du coup HgO a fait un POC.

Le résultat est un peu mitigé. En gros ça donne :

Sauf que quand le mail est en pur texte, ça donne ça :

Pertinence d'avoir les notifications Zammad dans Mattermost ?

• On peut filtrer assez finalement quelles notifications on accepte (par exemple, éviter les vpn renew).
• Ca évite de recevoir les notifications par mails et d'être noyé dans les mails. Ca réduit la masse de mail.
• On configure ce canal-là une seule fois.

Mais le risque : c'est la fuite d'informations personnelles. On a le titre du mail. Même si on fait un canal privé (à contre sens de la démarche d'ouvrir les canaux de Neutrinet quoique pour un salon qui donne des infos sur ce qui arrive sur la boite mail, ça n'est pas choquant non plus), on a des gens qui peuvent mettre des choses un peu problématique.

Si vraiment on veut avoir un canal dans Mattermost, il faut faire attention que seules les personnes qui ont un accès à Zammad aient accès au canal.

C'est un travail qu'on doit de toute façon faire, vérifier que les personnes qui ont accès aux mails dans Zammad sont encore légitimes.

Une piste aussi : séparer les notifications de mattermost. Par exemple, pour les messages dkim ou les messages liés au VPN… de configurer une autre boite mail pour l'envoi pour ne pas avoir les notifications de l'envoi, et configurer pour n'avoir que les réponses qui envoient un mail.

Exemple avec les messages liés au VPN: avoir un groupe dédié, où on coche juste “mise à jour du ticket” pour la notification (et pas “nouveau ticket”).

Pour les mails du NL-IX, c'est important mais ça pourrait potentiellement aussi être dans un groupe dédiée pour ne pas recevoir toutes les notifs.

Mais le risque, à trop faire des groupes… on risque de s'y perdre. Une nouvelle personne qui entre dans le hub infra pourrait aussi désactiver les notifs et les réactiver progressivement.

TODO:

• Fermer le POC de notifications dans Mattermost → HgO
• Creér une addresse specifique au raport dmarc
• Separer l'email noc@ du group hub-infra
• Créer un compte dédié aus notifications du renouvellement du VPN
• Separer les notifications du ring, ripe probe → envoyer sur alert@

Quand tout est down on ne sais plus communiquer aux gens que tout est down.

Ce salon est utile car ceux sur Matrix recoivent plus facilement les notifications.

Les notifications ont des ratés, car quand il y a beaucoup de messages le bot oublie d'envoyer certaines notifications.

C'est aussi lié à la question du monitoring qu'on aimerait proposer aux membres…

Reporte le point, le temps de réfléchir à la question d'améliorer le bot matrix qu'on utilise et enfin proposer de l'alerting à nos membres.

On a reçu plein de serveurs (il paraît), impression de déjà-vu…

Il y a un inventaire quelque part ici: https://doc.neutrinet.be/inventaire-server-recup#

Présentement, nous en sommes à la 15ème génération des serveurs de Dell (2021)

Qu'est-ce qu'on a:

• du gen10 x0x (2007)
• du gen11 x1x (2010)
• du gen12 x2x (2012)

Les serveurs de 10 génération, sont des bons câles-portes, dessous de table, etc. On peut aussi les utiliser comme panneau chauffant en les mettant à la verticale (mais les ventillateurs sont bruyants !).

gen10 : idrac5 → pas de java, pas de console à distance gen11 : idrac6 → java 6 ou 7 + scripts bash (https://github.com/ucomesdag/idrac6-console) gen12 : idrac7 → html5 \o/

Un peu d'explications:

• Le premier chiffre donne la puissance (capacité RAM, puissance CPU, etc). Donc un r6xx est plus puissant qu'un r4xx, mais consommera plus. Après il faut quand même vérifier le CPU pour comparer.
• Le deuxième chiffre donne la génération. Par exemple, r620 = 12ème génération, et r610 = 11ème génération.

Plus d'infos ici : https://en.wikipedia.org/wiki/List_of_PowerEdge_servers

On a 4 serveurs r620 avec 8 caddy 2.5', tous le même CPU sauf un. Ce qui permettrait de remplacer nos serveurs HP bour et nam, ainsi que topi. Avec un serveur de réserve pour l'un d'entre eux.

À voir s'il faudra racheter des cartes réseaux.

On a un serveur r620 avec 10 caddy 2.5', exactement comme ceux déjà présent dans la baie. Il y a juste le CPU qui diffère, mais on peut en acheter un autre. Cela fait un serveur de réserve.

Pour la Maison de la Paix, on a plein d'autres serveurs. On peut partir sur du 12eme génération. On pourrait mettre un r420 en 3.5', voire un r410 (11ème génération) car pas besoin de beaucoup de puissance. En sachant qu'on garde aussi un r410 de remplacement.

Ou alors on met un 2U pour encore plus de données ! Mais ils sont très vieux (10ème génération). À voir s'il y en a un de 11ème génération, et s'il fonctionne…

Au final, on part sur le 2U r520, car on a deux !

Cela remplacerait le serveur Hetzner qui nous coûte 60€/TVAC.

TODO: Tharyrok envoie un mail a info@tacticasbl.be

On pourrait avoir un serveur SAN qu'on ajouterait à la blue tower pour faire des backups de briques. On aurait une machine virtuelle avec borg qui se charge d'y accéder.

Pour l'instant, on a une chiée de 2To en 3.5'… Rien qu'avec ça, on peut avoir jusqu'à 28To de backup.

Mais ça va couter 2A, donc c'est de la consommation électrique. Il faut voir avec le hub admin. Il faut voir comment on déterminerait un prix pour le backup.

Dans Ketupa, Tharyrok pourrait développer la possibilité d'ouvrir un compte avec borg… Mais voir comment suivre les paiements…

À vérifier l'âge du capitaine des disques.

Par contre, cela va demander un switch 10Gb pour faire le lien vers le SAN. On peut partir sur un 16 ou 24 port. Au départ, on visait un 48 port dans l'idée de remplir le rack… mais ce projet est loin de se concrétiser.

TODO: Proposer la solution de backups + l'achat du switch au hub admin

Quelques r610 et r410, et plein de câle portes.

Sachant qu'il y a déjà une demande du Caldarium d'avoir un r410 avec disques 3.5''

Qu'est-ce qu'on fera du reste ? On pourrait voir auprès des ami·e·s si des gens sont intéressés.. Mais en se disant aussi qu'on ne les donnerait pas gratuit non plus car il y a eu tout à un travail de nettoyage, d'inventaire et de réseau humain… donc un peu comme les parping internet, on aimerait bien que ça fasse un peu de sous pour Neutrinet.

On aurait briques / parpain / chape internet… ou alors béton internet ?

Comme priorité, on se dit que cela devrait servir au projet de colocation de la baie.

Pour les Français il y a : https://www.teamrecup.fr/ Pour les Belges il y a : https://neutrinet.be

Et maintenant on réalise qu'il y a beaucoup de boulots, car cela signifie d'acheter des disques, des cartes réseaux, migrer les VM à froid car le CPU est différent, etc. Justement, on s'ennuyait dans Neutrinet !

Dans tout ça, on doit aussi prendre deux switch 10Gbit 16 ports.

TODO: Faire une proposition d'achat matériel au hub admin → Tharyrok

En gros, on ne pouvait pas sortir en udp. Il fallait faire une demande pour sortir en udp, ce que HgO a fait.

Donc les réunions de la Fédé ça sert !

Il ne reste plus qu'une probe à investiguer, c'est celle d'Iloth.

En juillet, Tharyrok et HgO on pris un moment pour faire du peering, et c'était chouette ! On a fait les entités suivantes:

• cloudflare
• RidieHosting
• AMPR Belgium

Quid de : https://support.neutrinet.be/#ticket/zoom/9847 → reste à faire

Il va falloir faire une petite refonte pour l'app Neutrinet, parce qu'elle réécrit la config VPN (ce qui n'est pas normal) : https://gitlab.domainepublic.net/Neutrinet/neutrinet_ynh/-/issues/29

En profiter pour vérifier si le certificat utilise encore l'ancien CA du serveur VPN ? La modification devra se faire dans le script de renouvellement des certificats : https://git.domainepublic.net/Neutrinet/renew_cert

A priori, les personnes qui sont dans ce cas de figure n'ont pas de brique, et peut-être pas de Yunohost, car ils ont fait toute la procédure par eux-même.

Il y a une personne qui serait motivée à faire du dev pour Neutrinet. C'est un projet qu'on pourrait lui proposer.

Ca pourrait être en autre chose qu'en Django. Ca pourrait plutôt être en php. Ketupa est aussi en php, donc les deux projets pourraient se renforcer.

Un développement de backoffice pourrait être lié à Ketupa tout en étant indépendant. Ketupa deviendrait le SI de Neutrinet.

Il faudrait faire un cahier des charge précis pour backoffice.

TODO: Créer le cahier des charges → HgO

Tharyrok a finit le formulaire pour créer une VM. C'est avec des champs plutt que des curseurs, comme ça c'est plus facile. Mais surtout ça marche, si on valide, ça s'enregistre dans la base de donnée et ça lance l'installation.

Moralité : uuu n'est pas une clé SSH valide.

Donc ça avance.

Mais il faut attendre que ce soit prêt pour utiliser les VM. Question d'identifiants des VM.

Avec le formulaire, les liens proxmox - ketupa et ketupa - netbox sont là, pour pas mapper les choses plus tard à la main et devoir tout changer parce que les IP vont changer.

C'est vraiment au niveau du réseau que c'est plus simple d'avoir déjà les VM. On récupère l'adresse mac pour générer l'adresse link local ipv6 et pouvoir attribuer un range ipv6 à la machine.

La question se posera quand on aura des machines privée derrière une machine publique. Est-ce qu'on devra générer des VM au cas où, pour avoir un pool de VM dont on connaît l'adresse MAC ? Ce serait fastidieux mais on pourrait aussi avoir un script qui regarde s'il y a des VM dispo.

Prochaine réunion : 25/11 à 14:00

Lieu : Caldarium

Maintenant, il reste à caser toutes ces réunions:

• Labo:
  • Keycloak:
• Passation de connaissance (jet de connaisances):
  • VRF + énième refonte du reseau 4.0 (ISPng): 04/11 à 14h, au Caldarium
  • Pfsense:
• Réflexions (jet d'initiative):
  • Alerting: 02/12 à 11h + brunch avec une soupe d'alertes, chez Célo
  • Redis:

Garde-Pad: Célo + préparer les différents (pates) pads

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.