2023/12/02 (Hub infra)

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

Heure de début : 11h30

Présences :

• Célo
• Tharyrok
• HgO

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: 15h, pause miam inclue

• 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 n'avance plus, il faudrait prévoir un moment en janvier 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
• 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, …
• Pour ISPng sur Bookworm, revenir sur la config reseaux
• Mettre en place le résolveur DNS sur les pfsense pour nos doux membres
• Documenter les pfsense
• Modifier le role commun pour utiliser Chrony → Tharyrok
• Proposer la solution de backups via le san au hub admin

https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/211

On regarde si en ligne de commande le paquet borgbackup est présent. https://www.freshports.org/archivers/py-borgbackup/

Soit on installe borg via les fresh ports, soit on l'installe via pip.

Quand on veut mettre à jour pfsense, il faudra faire attention à garder borg. En effet une des manières de mettre à jour est de tout réinstaller (et donc on perd borg). Mais la dernière mise à jour s'est faite en simple upgrade.

Une monté de version de PHP est faite, pour le Dokuwiki nous sommes en 8.2. Mais ça ne foncitonnait pas avec le plugin qui évite les spams dans les inscriptions. Du coup, les inscriptions sont maintenant désactivées.

Mais là où il râle, c'est sur le plugin de traduction :

https://github.com/splitbrain/dokuwiki-plugin-translation/issues/293

Il enregistre beaucoup d'erreurs du coup les logs grossissent et remplissent le disque.

Les logs sont mis dans /path/to/dokuwiki/data/logs/errors, avec la date du jour pour chaque fichier de log (ex: 2023-12-02.log). Ça rend difficile l'utilisation de logrotate pour nettoyer les logs…

Une solution serait d'utiliser find et se baser sur la date de modification pour nettoyer les derniers logs.

Dans logrotate on peut utiliser des patterns comme ceci : ????-??-??.log

On vient de patch le plugin avec la solution proposer dans le tikcets, nous n'avons plus d'erreur.

TODO: HgO met en place la config logrotate pour dokuwiki

Il faut un plugin pour bloquer les spams lors de l'inscription.

Il existe ce plugin, sur lequel l'ancien plugin preregister se basait:

https://www.dokuwiki.org/plugin:captcha

TODO: Tester et mettre en place le plugin captcha pour dokuwiki

HgO a ajouté le domaine Mobilizon pour les mails dans modoboa. Il a créé la boite no-reply pour Mobilizon.

Bon à savoir : c'est mieux de créer une boîte mail différente de no-reply, parce qu'on peut ensuite dire que la boîte mail peut utiliser cette adresse pour envoyer des mails. Mais bon, ici comme il n'y aura que Mobilizon qui envoie des mails, ce n'est pas trop grave.

Il reste la MR à merger : https://git.domainepublic.net/Neutrinet/infra-ansible/-/merge_requests/236

Cela ne devrait pas prendre trop de temps, HgO et Célo vont le faire ensemble.

TODO: Trouver une date pour merger la MR sur Mobilizon

Il y a toujours un blocage sur la config réseau.

Les parties VRF fonctionnent, a priori. Mais pour la config BGP, la config VPN est dupliquée un peu partout, sur les bra, les core, les edges… C'est pas évident de s'y retrouver.

TODO: Tharyrok doit terminer la config BGP

https://github.com/orgs/cachethq/discussions/4342

Historiquement, Cachet était un outil de status page utilisé par Neutrinet, mais le logiciel a été revendu à une entreprise, et depuis le développement s'était arrêté. Donc le projet est resté au point mort pendant 4-5 ans… Récemment, l'auteur a pu récupérer les droits et a commencé à retravailler dessus.

Les statuts dans Cachet se mettent à jour manuellement, mais il est possible de parler à une API pour automatiser tout ça. Cela donne plus de travail, mais aussi plus de flexibilité. C'est qu'on faisait à une époque dans Neutrinet : un cron qui updatait Cachait via les alertes d'Alertmanager.

On pourra en discuter lors du Neutriton sur le monitoring.

On a reçu 20 switchs \o/ Ils fonctionnent tous, Verixi les a réinitialisés.

Il y en a deux qui vont aller à la Maison de la Paix.

Et donc que faire des 18 autres ? On a déjà des câles portes avec les serveurs…

C'est du 1 Gbps, des ports SFP, etc. La différence entre SFP+ et SFP : 10 Gbps pour le premier et 1 Gbps pour le deuxième.

Il y en aura un ou deux qui pourront aller au Caldarium.

On n'en aura pas besoin pour LouiseDC, mais on pourra en proposer pour les personnes qui souhaitent rejoindre la baie.

Après qu'on aura fait l'inventaire, on pourra en proposer dans la Fédé, en précisant qu'ils viennent les chercher (comme Macron).

On songe à lancer une team récup belge… À voir si teamrecup.be est libre, ce qui est le cas !

TODO: Faire l'inventaire des switchs

L'idée c'était de devenir stratum 1, l'équivalent d'un tier 1 en réseau, mais pour le NTP.

On a testé, ça ne marche pas malheureusement. On ne pourra donc pas devenir stratum 1.

On sera en stratum 2, le pfsense se synchronisera avec des horloges de temps officielles, et on pourra proposer un serveur NTP public en rejoignant le ntppool.org.

(source Wikipédia)

Pad du Neutriton où l'on a commencé à évoquer la 42e refonte du réseau : https://doc.neutrinet.be/hub-infra-2023-11-25?view#

Cela nécessite l'achat de matériel, mais ça serait cool de planifier tout ça car nos agendas sont plus denses que ceux de nos chers ministres.

Il y a trois choses à faire:

• Les nouveaux switches pour le réseau (en attente du hub admin)
• Les nouveaux serveurs Dell et SAN
• La refonte réseau

Lorsqu'on place les switchs, autant préparer l'espace pour les nouveaux serveurs. Les serveurs ne seront pas placé tout de suite, sinon on augmenterait l'occupation de la baie (cf. contrat Verixi).

Pour rappel, on a:

• Topi, nam, et bour en haut
• Un espace pour passer les câbles
• Les switches et multiprises
• Chez mémé en bas

On peut le faire en trois étapes, donc trois dates:

1. 10 février 14h-18h : On vient mettre le(s) nouveau(x) switchs, on laisse de l'espace pour les serveurs Dell
   1. Retirer un switch
   2. Descendre pour faire la place en haut de la baie
   3. Placer le nouveau
   4. Casser les réseaux internes de chez mémé et patata
   5. Déplacer les liens de peering et transit
   6. Reconfigurer le tout
2. 2 mars 10h00 : On place les nouveaux serveurs Dell, on les installe et tout
   1. Avoir une voiture du pere noel, limite la semaine avant
   2. Mettre un serveur dans la baie
   3. Configurer son reseau et osd (retirer un ssd du serveur HP)
   4. Faire la synchro ceph (12h)
   5. Rejoindre le cluster Proxmox
   6. Éteindre les VMs
   7. Déplacer les VMs
   8. Décommissioner un serveur HP
   9. Revenir au point 1 mais avec un autre serveurs
3. 6 avril 10h00 & 7 avril 10h00 : On fait la refonte du réseau
   1. Installer tous les edge
   2. Reinstaller les cores
   3. Faire le vlan bridge untagg
   4. Faire la bascule entre l'ancien et le nouveau

Tharyrok a mis à jour vers la 2.7.0, mais la version 2.7.1 est déjà sortie donc il va sûrement refaire une mise à jour.

Il a également activé les patches, ce qui permet d'appliquer les corrections sans devoir attendre une mise à jour du pfsense

https://provya.net/?d=2023/10/26/17/24/01-pfsense-maintenir-son-firewall-a-jour-avec-les-patches

Pour la mise à jour, c'est assez facile, comme expliqué dans la doc, on se connecte en SSH et on fait “update from console”. Comme on utilise CARP, il faut d'abord le mettre en mode maintenance avant de faire les mises à jour. Il est préférable de faire une snapshot de la VM avant.

Libéwer Wadius!

Tharyrok a pu discuter de la Collecte avec Piery. L'IPv6 fonctionne sur les tests de la Collecte.

Maintenant, il faut voir comment Neutrinet peut pousser la connexion sur les équipements.

Il y a deux méthodes pour ça:

Première méthode, on crée une délégation syndicale pour Radius.

Radius est un protocole dit AAA (pour Accounting Authorization Accounting, rien à voir avec les piles ou les andouillettes donc). Cela permet d'avoir, lorsqu'un client se connecte, une notification. Radius peut alors pousser la configuration pour le matériel de la personne qui se connecte. Dans ce cas, le BRAS de Verixi à une connexion PPP qui arrive avec un login en @neutrinet. Du coup, il renvoie au serveur Radius de Neutrinet. Et là Neutrinet valide les infos de connexion et répond la configuration que le matériel (le routeur de Verixi) doit appliquer.

L'autre méthode, en gros, c'est d'avoir entre le BRAS de la personne qui fait la collecte (Verixi) et le CPE, on est en PPP, puis entre les deux BRAS (avec coude \o/) de l'opérateur c'est du L2TP. C'est ce qui est fait classiquement dans l'Hexagone.

Verixi n'aime pas cette méthode, parce que pour chaque connexion, on a deux tunnels. Un tunnel entre la connexion et l'abonné, et un entre les opérateurs. Il propose donc d'utiliser la délégation Radius (première méthode).

Du coup, Tharyrok est en train de tester FreeRadius.

Pour le moment, il manque une vue d'ensemble du projet collecte. Le hub admin doit proposer quelque chose pour que ce soit faisable, que ce ne soit pas le hub infra qui mène le projet. On pourrait aussi imaginer avoir un NeutriCamp, donc un w-e sur la question (pourquoi, pour qui, comment, quelles priorités, etc.)

Suite au prix délirant de Gandi, on parlait de solutions alternatives…

Il y en a une qui n'est pas trop difficile à mettre en place, c'est prendre des noms de domaine chez bookmyname.com, de mettre chez eux les serveurs NS de Neutrinet, et de gérer la zone DNS depuis les serveurs de Neutrinet.

On peut partir sur du Power DNS avec une API REST. On peut aussi nous-mêmes construire les fichiers de zone sans passer par des API.

Dans les critères qu'on souhaite avoir, c'est de pouvoir gérer des certificats wildcard. Parce qu'on utilise cerbot qui a besoin de l'API pour communiquer avec Gandi. Le problème, c'est que pas tous les registrar proposent cela.

Après, il faut aussi voir si vu le nombre de domaine qu'on gère pour Neutrinet, c'est une nécessité de tout automatiser.

Comme serveur DNS existant:

• PowerDNS : https://www.powerdns.com/
• KNOT : https://www.knot-dns.cz/

Il faudra:

• Playbook pour les zones primaires
• Playbook pour les zones secondaires
• L'interface dans ketupa pour piloter les zones

Pour se donner du temps, on peut transférer les noms de domaine vers OVH. C'est un peu nul, mais de toute façon ce serait temporaire. En terme d'éthique, BookMyName c'est une entreprise qui est dans le même groupe que Free… donc c'est pas non plus la panacée de l'éthique… La grosse différence avec BookMyName c'est qu'on s'autonomiserait par rapport à un registrar (peu importe lequel, vu qu'on gérera nous-même la zone DNS), et c'est un peu moins cher.

On se dit que ce serait un bon sujet pour un Neutriton, donc on lance un dé 366 et on tombe sur le 10 mars !

Relecture et finalisation

• Backoffice: https://doc.neutrinet.be/backoffice-cahier-des-charges#
• VPN: https://doc.neutrinet.be/vpn-cahier-des-charges

HgO a commencé, il faut continuer. Pour chaque fonctionnalité, il faut tout expliquer. Pour le moment, on a le contexte et les objectifs, c'est déjà un bon début.

C'est lourd à faire, mais cela permet à un développeur ou une développeuse d'être autonome.

Pas beaucoup avancé

Pour suivre un sujet dont on avait parlé il y a suuuper loooongteeemps.

On a les VMs, on a des IP, mais assez peu parce qu'on aimerait en garder pour des trucs intéressant. L'idée, c'est donc de faire comme pour Neutrinet, avoir plusieurs sites derrière un HAProxy mutualiser. ON aurait donc différents sites derrière un HA Proxy mutualisé.

Lorsqu'on fait ça, il faut gérer les certificats Let's Encrypt. Cela se fait soit sur HA Proxy, soit sur la VM. Si on le fait sur HAproxy, comme c'est le cas dans Patata, on voit tout le trafic en clair et en plus on doit géré le certificat (c'est pas ouf). Soit les certificat sont gérés sur la VM du membre, on ne voit plus le trafic en clair sur les HAProxy. Mais on doit encore avoir un moyen de comprendre le hostname.

Là, on a une technique qui s'appelle le SNI. Entre autre, cela permet d'avoir le nom de domaine de destination en clair, et donc de forwarder la requête chiffrée vers la bonne VM.

Le problème à nouveau, c'est que cela peut créer un risque de vie privée. Quelqu'un qui écoute le traffic voir l'IP de destination et le nom de domaine de destination. Si on va sur un site marxiste, cela apparait et cela donne donc une info sur la personne.

Actuellement, dans TLS 1.3, il y a un draft pour chiffrer le SNI. La technique est barbare (voir le podcast : https://www.nolimitsecu.fr/encrypted-client-hello-ech/).

La technique qui est proposée implique que beaucoup de sites soient derrière la même IP (car cela, on sait toujours le voir). C'est donc par la masse que le comportement individuel est masqué.

Mais cela a peu de sens chez Neutrinet, car le site derrière une IP va être restreint. On n'empêche donc pas une fuite de la vie privée.

Lorsqu'on en avait discuté, on pensait que ECH allait être progressivement imposé par les navigateurs. Mais ce n'est pas le cas, vu la méthode utilisée pour permettre ECH.

Wikipédia explique bien l'historique : https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypted_Client_Hello

La manière d'utiliser ECH est beaucoup trop lourde pour l'imposer partout, ECH restera toujours optionnel.

Tout cela pour en arriver à la bonne nouvelle : on pourra proposer des HAproxy mutualiser.

En plus de ça, Yunohost a la même idée et travaille aussi sur un SNI forward: https://github.com/YunoHost/yunohost/pull/1697

L'idée est d'avoir deux yunhost, dont un qui joue le rôle de HAProxy. C'est probablement à suivre aussi. Cela veut aussi dire qu'ils vont tester un Yunohost derrière un HAProxy.

Tout ce que l'on vient de dire c'est uniquement possible pour HTTPS. Et on va se limiter à ce protocole pour les HAProxy mutualisés (pas de TCP, ni de STARTTLS, par exemple)

Pour l'accès SSH, deux possibilités pour l'instant:

• Un port SSH par VM
• Utiliser un bastion SSH

Prochaine réunion : 24/02 à 14:30

Lieu : Caldarium

Garde-Pad: Célo (continue après avoir gardé les pâtes)

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.