Outils pour utilisateurs

Outils du site

Piste : • 06-11
fr:rapports:2023:06-11

Table des matières

2023/06/11 (hub-infra)

Heure de début : 14h FIN : 17h

Présences :

  • HgO
  • Tharyrok
  • Célo

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

Anciens TODOs

Hub service

Merge Request en cours

Ne plus supprimer le mdp root pour PBS

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

L'idée est de mettre les mots de passe dans des vault. Aussi pour Chez Mémé. Cela permet de se forcer à noter ou changer le mot de passe root.

Headers sur HA proxy

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

HgO a fait un test sur les applications avec les header dans les haproxy.

Cela surtout été testé avec user.neutrinet.be et pas de problème détecté.

Pour user.neutrinet.be d'ailleurs, on doit rajouter un Allow-Origin sur le haproxy de la VM VPN. Ce header sert à indiquer au navigateur qu'il joindra un autre domaine pour l'api. Il faut mettre ce header dans la partie backend de haproxy.

https://observatory.mozilla.org/analyze/neutrinet.be

HgO s'est inspiré de https://caddy.community/t/security-headers/126

Il faudrait encore rajouter le header Content Security Policy, à mettre dans le backend et à regarder pour chaque application. L'idée c'est de dire pour chaque ressource d'où il est censé la télécharger. Dans notre cas, cela devrait souvent être depuis self (le site même), et dans de rare cas un sous-domaine.

TODO: Modifier le rôle haproxy pour rajouter ce header pour la VM VPN.

Mobilizon

Il y a eu deux rencontres, le 14 et 18 mai. Globalement le playbook est terminé, la prochaine étape ce sont des tests avec les vraies données.

Il y a une liste de TODO à la fin du dernier pad.

On avait prévu de se voir le 22 mai, mais on n'a pas pu. Il faudrait encore un atelier pour terminer, et peut-être une réunion pour la migration.

Pour le nom de domaine, c'est en cours. On est en train de voir comment on peut transférer le domaine avec Alyve.

Mobilizon est déjà dans notre alertmanager, on reçoit une notification quand le site est down.

On aimerait faire la migration avant la mi-juillet.

Bitwarden vs Vaultwarden vs Passbolt

HgO a commencé à faire une VM en local pour tester Passbolt.

Pour rappel, c'est dans l'objectif de se passer de gopass et d'avoir quelque chose de plus accessible dans Neutrinet.

https://wiki.neutrinet.be/fr/rapports/2023/04-08#vaultwarden

Bitwarden permet d'avoir le SSO, tandis que Vaultwarden non. Pour Passbolt, le SSO est disponible uniquement dans la version payante, laquelle est sponsorisable pour les associations.

Bitwarden peut s'installer sur un serveur: https://github.com/bitwarden/server

Pour Bitwarden, la licence c'est compliqué : https://github.com/bitwarden/server/blob/master/LICENSE_FAQ.md En gros, AGPL sauf pour les parties commerciales.

Pour Passbolt, la licence c'est AGPL : https://github.com/passbolt/passbolt_api/blob/master/LICENSE.txt

Et Vaultwarden, c'est AGPL aussi : https://github.com/dani-garcia/vaultwarden/blob/main/LICENSE.txt

On peut faire un test avec passbolt, et si ça nous convient et qu'on arrive à avoir le SSO, on part là-dessus. Sinon, on prospectera du côté de Bitwarden.

Où on mettrait cette VM ? On en reparle dans quelques instants ! Restez avec nous !! Après cette page de pub de nos acteurs libre.

Parce que c'est la même question qui se pose pour la status page et le wiki.

Quelles sont les usages un peu spéciaux que l'on fait avec Gopass:

  • Pouvoir mettre des commentaires
  • Rajouter des clés privées / fichiers
  • Copie locale

Un problème de Gopass (outre que c'est difficilement accessible) : si on perd son gopass, on perd son mot de passe pour Git et on ne peut plus re-cloner son gopass…

Ne plus gérer son gestionnaire de mot de passe pour ne pas se reposer sur notre infra pourrait être un choix aussi. Mais ça veut dire reporter la confiance chez quelqu'un d'autre.

C'est peut-être plus intéressant que ce soit redondé, à voir.

Passbolt utilise GPG mais de manière complétement transparente : il crée une paire de clé GPG au moment de la création du compte. Voir la doc qui est assez bien faite : https://help.passbolt.com/faq/discover/how-does-it-work

TODO: Tester Passbolt

Akvorado

PUB: Connaissez-vous Akvorado ? C'est merveilleux \o/

Pour le moment, on n'a pas acté quoi que ce soit.

C'est assez pénible à maintenir. Il y a une db un peu spécifique pour Akvorado (clickhouse), et elle n'est pas facile à mettre à jour.

Ça a aussi cassé l'analyse de l'IPv6. (https://github.com/akvorado/akvorado/issues/717, mais c'est toujours pas released)

Pour l'instant, on ne garde que 24h avec toutes les informations de chaque client (port source / destination, ip source / destination, et protocole)

https://akvorado.neutrinet.be/

Cela pose de grosses questions de vie privée, mais en même temps c'est aussi une obligation légale. On devrait avoir une solution pour garder ces données pendant 1 an.

En terme de stack, comment dire, c'est lourd.

On a du kafka, du clickhouse, 3 services (Inlet, Orchestrator, Console), etc. Ça fait le tour, mais c'est pas des trucs qu'on utilise chez Neutrinet.

Pour le moment, tout est installé sur la même VM, comme un gros blob binaire (ou non-binaire, quel est le genre du blob ?).

Donc d'un côté, cela permet de remplir nos obligations légales, et de l'autre, cela permet de faire de l'ingénierie réseau.

Cela permet de faire ce genre de graph, la source est gauche et la destinaion a droite :

Donc c'est aussi un outil de vulgarisation et démystification du réseau.

Quelles alternatives à Akvokado pour les obligations légales ?

On a les sondes S-flow qui récupèrent les headers d'un paquet réseau. On pourrait récupérer ces métriques pour les mettre dans un Loki / ELK.

On n'a pas les switches qu'on mérite, mais il serait aussi possible de déporter la capture des flow avec de bons switches.

Par rapport à la config dans le HAProxy, ce n'est pas trop grave si Akvorado ce fait jarter, car le plus important c'est la partie collecte des données (le fameux Inlet).

Cela permet aussi de voir le trafic qui passe par le serveur VPN, et sur quel port les gens se connectent.

ISPng sur ~~Bullseye~~ Bookworm

Un POC pour utiliser ISPng sur Bullseye a été fait sur ispng.patata.louise.neutri.net.

Pour rappel, on était resté bloqué sur l'installation d'un OpenVPN 2.3.x, car il manquait une dépendance (libssl 1.0), il se trouve qu'elle est installable sans dépendance, en prenant le .deb de Buster ou Stretch. C'est dégueu mais ça marche.

Tant qu'à faire, autant passer sur Bookworm car c'est l'avenir.

HgO va essayer de refaire la partie réseau. Il faut d'abord regarder comment OpenVPN route les paquets dans le kernel.

Application du fix Bios/Uefi

https://community.hpe.com/t5/proliant-servers-ml-dl-sl/gen8-dmar-firmware-bug-your-bios-is-broken-bad-rmrr/m-p/7177936#M179789

Si bour crash, on peut appliquer le fix. On se connecte à l'iLo, et de là, on peut aller dans le bios via l'interface web (console html5).

Pour nam, on le fera de manière collégiale ensemble, un jour de pluie.

Applications d'urgence

Le serveur storage-01 commence à recevoir beaucoup d'applications et de responsibilités, et donc de grands pouvoirs.

Documentation

Le wiki sur le serveur storage-01 ? Le wiki dans git ? Utilisation du wiki de gitlab ?

Le wiki est synchronisé sur le Gitlab de domaine public. Donc il est à deux endroits. Le repo : https://gitlab.domainepublic.net/Neutrinet/dokuwiki/

Si on commence à mettre des schémas, cela devient moins lisible. Une solution pourrait être de synchroniser le repo sur une autre machine, mais on retombe sur la question de : quelle machine ?

Dokuwiki fait un pull du repo git toutes les heures, mais parfois ça se casse la figure. On a configuré l'envoi de mail en cas de problème, mais le problème c'est que ce mail ne donne aucune info sur l'erreur. HgO aimerait se renseigner là-dessus.

Après, on peut désactiver le pull du repo git, car on n'est pas censé le modifier, et il n'y aura pas d'autre wiki qui écrira dessus.

Si on héberge une copie du wiki quelque part, ce sera en read only aussi (on peut désactiver les logins).

Mais où mettrait-on le wiki ? Ça pourrait être une VM prob ?

Serveur de backup Maison de la Paix

Ou alors on est sur du temps long, et on met un serveur chez Tactic / Domaine Public. On compte déjà mettre un PBS. Si on veut mettre un Proxmox, il faudra mettre le PBS dans une VM et configurer les disques en passthrough.

La question, c'est quel sont les capacités en RAM et CPU des serveurs à disposition, car si on veut mettre des VM, il faut quand même avoir suffisamment de puissance et de RAM.

Pour la virtualisation, il faut regarder le NUMA : ça indique ce qu'il se passe si un processeur n'a pas suffisamment de RAM, s'il doit passer par le second processeur.

Côté Tactic / DP, on peut placer un serveur quand on veut. Il faut néanmoins acheter des disques et de la RAM, mais c'est un autre point.

En terme d'applications, on pourrait avoir un dokuwiki en read-only, un gestionnaire de mot de passe synchronisé (read-only ?), un IPAM en read-only.

Si un jour la Maison de la Paix souhaite une connexion Neutrinet, on sera capable d'avoir un tunnel L2, c'est-à-dire un lien sans IP. Et donc avoir un VLAN pour notre usage et relier les deux usages.

Pour en faire un datacenter utilisable par Neutrinet, il faudrait deux chemins optiques, donc 2 FTTO (fibre jusqu'au bureau). Mais cela reste un bon endroit pour du backup pas cher.

TODO:

  • Valider en réunion des hubs la proposition de déplacer le serveur Hetzner chez Tactic

Gestionnaire de mot de passe

Le gestionnaire de mot de passe pourrait aussi être en read-only à la Maison de la Paix.

IPAM

À terme, on va pas garder sur le wiki. On utilisera Netbox, à voir si on peut le répliquer en lecture seule. À voir si la correspondance IP / usage sera publique ou privée. Actuellement, elle est publique.

La partie Chez Mémé, VPN et Collecte devront être privés, car ce n'est pas à destination de Neutrinet interne.

Status Page

Pour la status page, ce serait mieux que ça soit sur une VM de la fédé pour que ce soit sur une infrastructure qu'on ne gère pas du tout.

HgO avait fait des tests avec uptime-kuma l'an passé, et l'outil commence à être utilisé pour envoyer des alertes lorsque une brique perd sa connexion.

Il y a aussi une volonté de bouger la VM de Source, sur laquelle est installé uptime-kuma, pour le cluster Chez Mémé. Il faudra donc mettre uptime-kuma ailleurs, par ex sur la VM storage-01 ?

Bref, la question d'une status page se pose à nouveau… Est-ce qu'on va vers uptime-kuma ? ou est-ce qu'on choisit un outil qui se couplerait avec notre alertmanager ?

Pour rappel, les dernières discussions sur ce sujet : https://wiki.neutrinet.be/fr/rapports/2022/04-30#status_page_uptime-kuma

Uptime kuma pourrait aussi communiquer avec un Mattermost. HgO a fait un test dans un salon privé uptime.

Actuellement, le monitoring des briques est sur Matrix. Il pourrait être plutôt sur Mattermost. Cela évite que les personnes qui veuilent bénéficier du monitoring doivent se créer un compte sur Matrix.

https://uptime.src.brussels/status/all

Qu'est-ce qu'on veut monitorer ?

  • les briques internet
  • les VPS
  • Éventuellement d'autres services des gens.

Ce serait un outil de monitoring pour nous, pour nous faciliter la vie pour dépanner les briques, et comme un service à offrir à d'autres personnes.

Il faut que ce soit facile de rajouter une nouvelle brique à monitorer.

Ce serait peut-être plus malin d'utiliser blackbox exporter, et avoir juste la metrics de ping, route disponible dans le vm vpn. Ces informations seraient disponibles dans grafana avec un dashbord privé. Ce serait le premier niveau, pour pouvoir faire du support, et il serait là par défaut pour les VPN, les VPS, tout.

On monitorerait nos propres IPs. Ce serait plus propre de ne monitorer que les IPs qui sont allouées. Pour la granularité, on peut faire un ping toutes les minutes voire 30 secondes (c'est le cas actuellement pour uptime kuma)

A la demande, et avec le consentement, on pourrait avoir aussi un monitoring sur l'URL, et donc un alerting les briques qui le souhaitent. Par contre, si on réutilise le bot matrix, ce sera sur matrix. Il faudrait donc utiliser un autre receiver avec un bot pour mattermost : https://github.com/cpanato/mattermost-plugin-alertmanager/blob/main/README.md

Question : est-ce que ce serait dans un canal privé ou public ? On peut commencer par faire un salon privé, et puis éventuellement le passer en public pour la suite.

TODO:

  • Configurer uptime-kuma pour envoyer les alertes sur Mattermost dans un canal privé
  • 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)

Hub DC

Hub Network

Stabilité IPv6

Nous avions le multicast snooping actif sur les bridges linux qui empêche l'émission de paquet IPv6 ICMP Neighbor Advertisement. (Cela permet l'autodécouverte des IP voisine)

Sur les bridges de Proxmox, une option est activée par défaut, c'est l'IGMP snooping, qui fonctionne bien pour l'IPv4, mais pas du tout pour l'IPv6.

Cela avait pour conséquence que les paquets ICMPv6 neigbourg advertisement ne fonctionnaient pas, du coup, les voisins IPv6 ne savaient pas où on n'était. Et donc on ne pouvait pas se parler.

C'est corrigé depuis que c'est corrigé.

Avant, on avait souvent des mails du ring disant que certains membres n'arrivaient pas à nous joindre en IPv6, maintenant ça n'arrive plus.

Donc c'est merveilleux \o/ Les paquets IPv6 peuvent à nouveau gambader dans les prairies verdoyantes du réseau.

PUB: vous connaissez l'IPv6 ?

Décommission lien de transit Hurricane Electric

Sur le lien de peering BNIX / BelgiumIX on recevait un full view ipv6. On l'a décommissionné parce que c'est crade, enfin c'est pas propre.

Dans Akvorado, le lien de notre traffic avec Hurrican Electric faussait nos statistiques peering / transit.

La vraie solution, ce serait de créer un lien privé avec HE via BelgiumIX, et voir si HE voudraient bien nous filer du transit v6 gratuit.

Ce serait cool de pouvoir faire ça, car HE est un transitaire tier1 en IPv6. On passe déjà par HE pour beaucoup de trafic IPv6, mais là l'idée, ce serait de dire que tout le trafic passe par eux.

Il reste plus qu'à boire une bière avec un admin réseau de HE.

Hub Dev

Avancement Ketupa

Tharyrok a super bien avancé sur l'interface de commande de VPS. Il manque encore quelques détails UX, et la partie ajout de disque supplémentaire, de réseau privé.

On peut déjà choisir les informations de VM (CPU, RAM, taille du disque), l'ajout des clés SSH et le choix de la distribution Linux.

Pour automatiser l'installation de la VM, on utilise packer. C'est ce dernier qui génère les images des OS.

Cela permet de construire une deuxième image, un live de Debian, avec deux modes : installation (lance le playbook Ansible) et rescue pour avoir une console SSH de secours.

Il y a du code presque à jour sur le repo build-images de Ketupa (= nom de code du logiciel de création de VPS).

Dans les choses à ajouter, il y aura les coûts des VMs qui seront spécifiés dans l'interface.

Quand la VM démarre, elle va chercher sa config sur le serveur Ketupa. Ensuite elle fait le partitionnement, configure le réseau, et ensuite démarre. Et c'est prêt, en moins de 3min ! C'est plus rapide qu'une brique (12min) !

Quelques éléments important lors de la création de la VM:

  • start.pxe : permet de venir chercher la config depuis un serveur
  • config.json : utilisé par Ansible pour configurer la VM
  • root.tar.zstd : le filesystem qui avait été créé par packer

On voit l'appel de ces fichiers dans les logs d'accès de nginx.

Pour les distributions qu'on aimerait proposer, il y aura au début juste debian, mais par la suite il y a aura ubuntu, yunohost, centos, rocky, etc.

Pour Yunohost, c'est un peu compliqué car il y a des modifications à faire sur une debian classique. En gros, toute la partie qui se trouve sur : https://install.yunohost.org. On peut le voir sur le repo : https://git.domainepublic.net/Neutrinet/ketupa/build-images/-/tree/main/ansible/roles/yunohost/tasks

Ensuite, on pourra laisser l'utilisateur lancer la postinstall, mais le laisser se connecter à l'IP.

Pour l'accès à Ketupa, ce sera sur invitation. On a une partie admin, et on peut rajouter des utilisateurs. Il y a un lien d'inscription qui est valide une seule fois.

Les actions faites dans Ketupa sont logguées dans Zinc mais en vrai maintenant c'est openobserve

Hub Chez mémé

Création des VM en statique

Les VMs sont créées ! \o/

1Go de RAM, 2 vCPU, 5 Go SSD, mais c'est temporaire.

Au moment où la personne commande sur l'interface web, le disque sera redimensionné et les données de la VM modifiées.

Quand on ouvrira au grand public, il faudra penser à la limite des ressources. Pour le moment, ce n'est pas pris en compte.

Prochaine réunion

Prochaine réunion : 24/09 à 14:00 au Caldarium

Prochain atelier Mobilizon / Ansible : 19/06 à 14h chez célo → on repassera aussi sur l'article chiffrement

Réunion future du VPN : 30/09 à 14h au Caldarium

Garde-Pad : Célo

Météo de faim

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.

C'est l'heure de l'apéro !

fr/rapports/2023/06-11.txt · Dernière modification : 2023/06/26 13:09 de hgo