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

Heure de début : 18h30

Présences : HgO, Célo, Tharyrok

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 : 21h

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
  • Borgmatic est disponible sur la dernière version de pfsense (normalement)
• Tharyrok doit copier le playbook pour le mail qu'il avait fait de son côté.
  • Ça avance lentement, calmement, doucement
  • https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/merge_requests/327
    • Il reste à créer la génération de certificats https
• Alerting :
  • Tester le plugin Mattermost pour Alertmanager
  • Dupliquer l’envoi des alertes de Neutrinet sur Mattermost
  • Faire le dashboard de monitoring interne des services, vps chez-meme (Tharyrok)
• Documenter les pfsense
• Mobilizon :
  • Essayer d'optimiser Mobilizon vis-à-vis des lenteurs de database (et voir si d'autres on le même soucis) → pas faisable à court terme → https://framagit.org/kaihuri/mobilizon/-/issues/1235
  • Voir si le split lecture/ecriture pgsql est possible
    • Ce n'est pas possible, il faut que Mobilizon l'implémente (faisable dans le framework utilisé, en principe) → ouvrir un ticket (HgO)
  • Migrer les ressources vers s3 (HgO)
• 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 :

• Mettre à jour le switch du stock
• Gestionnaire de mot de passe:
  • Tester Passbolt

    1. Tester Nextcloud Password
    2. 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://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/merge_requests/326

Trois petits changements: - Permettre une liste d'identifiants pour HAProxy - Suppression de Cookie SL qui n'était pas utilisé pour nous - Ajout du port du check pour le backend

Pour la prochaine fois, essayer de prendre 10min pour clôturer quelques tickets.

Il faudrait réfléchir à ce ticket:

• https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/172
• https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/226

Pour la prochaine réunion, on va essayer de mettre des TODOs qui sont en début de réunion dans le Gitlab.

Nous avons été spammés d'alertes ! Plein plein d'alertes ! Avec des noms bizarres et des informations obscures !

C'est parce que Tharyrok a avancé sur la partie alerting. \o/

C'est basé sur : https://samber.github.io/awesome-prometheus-alerts/

https://github.com/samber/awesome-prometheus-alerts/commits/master/

Mais cela pose des questions sur quelles alertes font sens et leur fréquence. Il faudra les rendres pertinentes pour notre usage.

Ce serait bien de partir de ces règles et de les adapter à notre infrastructure. Ne pas oublier de vérifier le repo pour avoir les nouvelles règles et les corrections éventuelles.

Si on fait des changements à une règle, il faudrait clarifier pourquoi dans un commentaire à côté de la règle.

HgO s'est aussi proposé de travailler sur la dépendance entre les différents niveaux d'alertes.

Tharyrok va merger sa MR en actant que ces nouvelles règles sont silencées, dans l'attente que HgO fasse une proposition.

Ensuite cela sera la décomission de télégraf.

Tharyrok est en train d'installer la VM stallwart. Il rencontre deux problèmes.

Le reverse IP pour le serveur mail. Pour le moment c'est

20.181.67.80.in-addr.arpa domain name pointer patata.louise.neutri.net.

Et ça devrait être : mail.neutri.net

host neutrinet.be neutrinet.be mail is handled by 50 mail.neutri.net.

Pour éviter ça, on doit rajouter une IP sur le PfSense. Donc dédier une IP à cela. On ne peut pas changer le reverse IP de 80.67.181.20 parce que c'est une VM réseau et cela empêcherait le debug en cas de problème.

À quel point c'est chiant de rajouter une IP sur le pfsense ? Suffisamment, dit-il.

Nous utilisons 80.67.181.16/28 pour le cluster patata et on n'a plus d'IP dispo, la dernière a été assignée pour le monitoring de Tactic.

On aurait à disposition :

• 80.67.181.32/28 est libre, en principe
  • Les core-patata consomment 3 IP
  • Les pfsense consomment 3 IP

Plan A : Récupéré une IP du range 80.67.181.16/28 en douceur de préférence mais sans coopération on attaquera en coupant la VM.

Plan B : Désagreger le bloc 80.67.181.16/28 & 80.67.181.32/28 en que du /32 et utiliser une IP de 169.254.0.0/16 (link local)

Parmi les ranges cités, il y a celui des VM amies et de monitoring des amis. Et l'adresse link local serait utilisée comme Gateway. On utilise déjà ce genre de range non routable pour les VM core.

Utiliser le plan B est plus pérenne, parce que cela libère des IP et que tout est en /32 avec le link local comme gateway. Mais cela signifie qu'on doit modifier les configurations des “VM amies” pour cela. Si on n'y a pas accès, il faut que les amis s'en occupent.

D'un autre côté, certaines VM iront de toute façon à terme “Chez Mémé”. Donc ce n'est pas forcément une nécessité de récupérer des IP.

/!\ /!\ /!\ avoir des bloc desagrégé risque a terme de foutre un joli bordel

Donc il y a du pour et du contre, l'informatique n'est pas binaire mais rempli de morsures (bytes).

Il y a aussi le plan A & B (compromis bien belgosuisse :fries: :chocolatebar: 🇧🇪🇨🇭 :sunriseover_mountains:)

Récupréré une IP du range 80.67.181.16 pour ne pas consommer deux IP de plus sur les pfsense et mettre 80.67.181.32/28 sur le vm core-patata. On pourrait changer l'IP de la VM Tactic.

Au cas où, on regarde un peu la santé des VM amies et youpie, nos amis on des VM à jour \o/

TODO:

• Changer l'IP de la VM Tactic puis contacter Tactic pour qu'ils changent la config réseau
• Ajouter les ip sur core-01-patata & core-02-patata

Tout ça pour avoir le bon reverse, le ptr devrait-on dire… On va aller élever des lamas dans les montagnes ardennaises… (en parlant de ptr et des ardennes, Célo a croisé Niko en Wallonie l'autre jour).

Avec opensmtpd config comme Tharyrok le propose on a un serveur smtp sur localhost. Est-ce qu'on fait encore un mail par application ? Ou est-ce qu'on utilise le serveur local qui s'authentifie auprès du serveur mail ?

L'enjeu c'est que Tharyrok va recréer tous les comptes mails qu'on a. A priori, on a les mots de passe dans le gopass. On a quelques emails qu'il ne faut potentiellement pas refaire, des adresses perso de memvres qui n'y sont pas par exemple. Mais il faut en garder certaines ou les rediriger parce qu'il y a des trucs qui sont liés à ces comptes mail (le compte twitter par exemple).

Quelles sont les implications entre avoir un compte d'envoi par application ?

On ne doit pas se décider maintenant. Tharyrok peut faire le maximum de configuration, créer les boites mails, etc. Et on passe en revue tout ça lors de la prochaine réunion infra et on fait le switch des DNS.

Pour les applications, en général on envoie d'une adresse noreply@neutri.corp

Côté sécurité, on peut configurer un rate limiting, puis mettre une alerte sur la queue d'envois de mails.

TODO:

• faire en sorte que le VM vpn sache envoyer des mails.

Ce serait le mercredi 25 au final, Célo et HgO vont remplacer le disque de bour.

Deux semaines plus tard, HgO s'occupe de Topi le 06/07.

Ce serait bien qu'HgO ait un badge d'accès.

TODO:

• HgO envoie un mail à Verixi pour demander un badge et voir quand il peut passer pour l'activer

C'est bientôt l'été, le moment où les ports réseaux migrent vers les datacenters.

Ça tombe bien, on avait prévu le 16/08 pour faire visiter la nidification des ports réseaux au datacenter.

En fait ce serait en semaine parce qu'il faut un technicien de Verixi.

TODO:

• Tharyrok planifie en août la maintenance

C'est aussi la saison de migration des lignes internet, quelle chance ! :bird: :electric_plug:

Il faudra faire une session « fabrication de Neutribox » et restructurer le repo destiné au antennes wifi pour les occupations des sans papiers.

TODO:

• HgO restructure le repo pour les appareil openwrt / mikrotik
• Trouver une date pour la session Neutribox (avant 2027)

Tharyrok a passé du temps à optimiser le réseau de Neutrinet pour absorber le traffic de la collecte.

On reporte again.

Convertir ce point en neutriton. wolololo \o/

Neutriton SSO le retour: 28/06 à 10h chez Tharyrok (Monolith)

Visite datacenter : 16/08 au datacenter

Neutriton gestionnaire des mots de passe: 23/08 à 10h chez Hgo (Couque)

Prochaine réunion: 13/08 chez Tharyrok (Monolith)

Garde-Pad : HgO (ça tombe bien on va en manger ce soir)

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.