2024/10/19 (Hub Infra)

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

Heure de début : 14h

Présences :

• HgO
• Tharyrok
• Célo

BBB: https://talk.domainepublic.net/b/hgo-j1c-pp4-sb9

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

Si on se rend compte vers 16h qu'on ne voit pas le bout, on entame la présentation de Ketupa.

• 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
• Décider d'une date pour le Neutriton Redis
  • 24/11 à 14:00
• Choisir un gestionnaire de mot de passe (Passbolt vs Vaultwarden vs Gopass)
  • 05/01/2025 à 14:00
• Faire l'inventaire des switchs avant octobre
  • ~~courant septembre, durant l'install party du 15 septembre~~ A redefinir
  • Mettre à jour le switch
  • Vérifier s'il crashe
  • Regarder si carte 10Gbps

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

A priori bon pour merger? Ok, HgO fait ça après la réunion

Pour le maintien et l'évolution de l'infrastructure de Neutrinet

Nous recevons des métriques de Telegraf, mais la plupart des tableaux de bord Grafana sont conçus pour le couple InfluxDB/Telegraf. De plus, en cas de perte de réseau, Telegraf ne réalise pas de backfill (= continue à récupérer des metrics même si je sais pas les envoyer, et quand je récupère la connexion j'envoie tout d'un coup), ce qui peut entraîner la perte de métriques précieuses. On avait pensé à vmagent qui était censé résoudre le problème, mais on n'a pas avancé là-dessus. Et ce serait une réponse partielle.

Tharyrok aimerait que nous envisagions l'utilisation du couple Vector/Prometheus Exporter. Nous pourrions utiliser les exportateurs classiques de Prometheus et Vector pour les envoyer en mode Prometheus Remote.

Si jamais Vector ne peut pas exporter sa metrics, il l'a store sur son sink.

Il peut aussi lire les logs systemd, ce qui permettrait de centraliser les logs des serveurs à un seul endroit.

Mais si on passe à Vector, on devra refaire des choses pour les dashboard, refaire les alertes. Mais peut-être pas grand chose parce que c'est aussi du Prometheus.

Une possibilité c'est de faire un poc en paralele de telegraf, sur les postresql puisqu'il manque des metrics de ce côté-là.

La proposition est donc que Tharyrok fasse un playbook Ansible pour déployer Vector, et HgO review.

sources:
  my_source_id:
    type: opentelemetry
    http:
      address: 0.0.0.0:4318
      keepalive:
        max_connection_age_jitter_factor: 0.1
        max_connection_age_secs: 300

sinks:
  my_sink_id:
    type: prometheus_remote_write
    inputs:
      - my_source_id
    endpoint: https://localhost:8087/api/v1/write

On peut se re-baser sur les templates d'alertes (qui se basent sur du node-exporter): https://samber.github.io/awesome-prometheus-alerts/rules.html

https://mitogen.networkgenomics.com/ansible_detailed.html

Avec la PR suivante : https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/merge_requests/302, nous pouvons utiliser Mitogen. La MR a été mergé \o/

Mitogen optimise les sessions SSH et apporte un véritable confort d'exécution. Les mainteneurs de Mitogen ont repris le projet en main et s'en occupent activement.

Dans Codium il y a un plugin direnv qui permet de charger le fichier .envrc, lequel s'occupe de charger Mitogen. L'extension en question est : mkhl.direnv

https://pve.proxmox.com/wiki/Network_Configuration#_disabling_mac_learning_on_a_bridge

Il est possible de désactiver l'apprentissage local des adresses MAC dans un bridge Linux et de laisser Proxmox injecter les adresses MAC locales dans le bridge. Cela permet d'éviter le spoofing d'adresses MAC et d'améliorer la sécurité.

Concrètement, cela évite que les gens changent la MAC adresse de leurs VM.

Un switch est en commande ! \o/

Que faites-vous le 2 novembre à 11h ?

Rien ? Super, on peut configurer le switch !

Il fera sans doute plein soleil, donc on va se planquer dans un datacenter. Il pourrait y avoir des coupures, il faudra communiquer pour prévenir nos adorables membres.

TODO :

• Communiqué sur la possibilité d'une coupure
• Acheter le switch (oups)

Tharyrok finalise un script pour demander aux membres des IX de faire du peering avec nous. Les sessions BGP sont configurées en mode passif jusqu'à ce qu'ils acceptent.

En gros, le script va générer la config à copier/coller dans Ansible, puis un humain doit aller envoyer un mail pour demander si on veut bien peerer avec nous. Et quand c'est ok, on change la config ansible pour mettre la connexion BGP en active (passive: false)

Bon, pour BelgiumIX c'est facile, il y a pas trop de monde. Mais pour NLIX il y a plus de 400 personnes, c'est beaucoup trop, il faudrait automatiser l'envoi de mails par Zammad. Il faudrait aussi que le script puisse détecter les peers morts, disparus, et les nouveaux membres.

Est-ce qu'il faudra un monitoring pour les connexions actives qui sont mortes ? On a déjà les metrics via bird-exporter, mais il faudrait de l'alerting et des dashboards. Il faut aussi comprendre quel est le statut des sessions BGP qui flappent ? C'est nécessaire pour pouvoir créer des alertes.

https://grafana.neutrinet.be/d/s0ZQdGB7k/bgp

Dans les sessions “DOWN” il y a aussi les session bgp passive, ce qui n'as pas d'intérêt de les voir down.

TODO:

• Tharyrok va faire une MR avec le script

Tharyrok a suivi un lapin avec une montre et un petit gilet.

Actuellement, nous avons trois modèles différents de cartes réseau sur le cluster Patata. Tharyrok a remarqué que le ping et la gigue (jitter) deviennent instables à certains moments. La seule solution que j'ai trouvée est de redémarrer chaque nœud.

On a les flux réseaux Nord-Sud et Est-Oest (si, si !) Nord - Sud : flux réseau qui viennent de l'extérieur et vont dans notre réseau. Les pfSense sont une barrière Nord-Sud.

1. SR-IOV (voir après) permettrait d'améliorer les performances

Est - Ouest : flux réseau qui restent dans notre réseau

Est-ce qu'on achète deux cartes réseaux pour avoir la même carte réseau partout ? (cela nous coûterait 150-200€)

Ou est-ce qu'on se dit que les optimisations que Tharyrok a trouvées sont suffisantes ?

auto enp4s0f0
iface enp4s0f0 inet manual
	mtu 9100
        pre-up ethtool -K enp4s0f0 tso off gso off gro off rxvlan off txvlan off rx-vlan-filter off ntuple on lro off
        pre-up ethtool -K enp4s0f0 tx-gso-partial off
        pre-up ethtool -G enp4s0f0 rx 8192 tx 8192
        pre-up ip link set enp4s0f0 txqueuelen 10000   

La config reseau est basé sur : https://docs.accel-ppp.org/guides/BRAS_tuning.html#network-tuning

En gros, cela veut dire “pas touche aux paquets”, parce que c'est le rôle du routeur pas des intermédiaires.

Pourquoi Tharyrok a-t-il fait ces recherches ? Parce qu'il ~~fait des insomnies~~ s'est rendu compte que la connexion de la ligne du Caldarium n'avait pas un gros débit et n'était pas toujours stable. Donc ce type d'optimisation est utile pour la collecte.

En tout cas, depuis qu'il a fait ça la vie est plus belle et le réseau plus doux.

https://serverhome.nl/parts-ndc-dell-c63dv/

Il y a aussi: https://it-user.be qui propose du reconditionné

https://forum.proxmox.com/threads/enabling-sr-iov-for-intel-nic-x550-t2-on-proxmox-6.56677/

Une des pistes pour améliorer les performances, si nous disposons des mêmes cartes réseau, est d'utiliser la technologie SR-IOV. Cette technologie permet d'exposer une véritable carte réseau dans la VM, car la carte physique peut créer des cartes virtuelles. Cela améliore considérablement les performances nord-sud, ce qui est particulièrement pertinent pour les VM Edge.

HgO a le problème suivant de manière aléatoire:

debug1: kex_exchange_identification: banner line 0: Exceeded MaxStartups
kex_exchange_identification: Connection closed by remote host
Connection closed by 80.67.181.20 port 22
kex_exchange_identification: Connection closed by remote host
Co`nection closed by UNKNOWN port 65535

Mais peut-être ce n'est que lui… Peut-être que c'est juste lié à la config SSH. Ou peut-être a-t-il tout inventé de toute pièce, qui sait ?

À creuser du côté des MaxSessions : https://serverfault.com/questions/877517/will-maxsessions-maxstartups-fix-ssh-connection-refused-message (oui HgO se répond à lui-même)

2min : Tharyrok a fait une config freeradius qui lui plaît et qui est ultra-minimaliste.

Il y a “juste” à créer le playbook et déployer les VM pour faire notre Radius. YAKA !

Et après ça on pourra libérer délivrer radius.

Le plan c'est :

1. Trouver plus de 24h dans une journée
2. Déployer
3. Tester
4. Douter

La config radius ressemble à ça :

# /etc/freeradius/3.0/radiusd.conf
prefix = /usr
exec_prefix = /usr
sysconfdir = /etc
localstatedir = /var
sbindir = ${exec_prefix}/sbin
logdir = /var/log/freeradius
raddbdir = /etc/freeradius/3.0
certdir = ${raddbdir}/certs
cadir   = ${raddbdir}/certs
run_dir = ${localstatedir}/run/${name}

# Modules
$INCLUDE ${raddbdir}/mods-enabled/

# Clients
$INCLUDE ${raddbdir}/clients.conf

# Users (for static configuration)
$INCLUDE ${raddbdir}/users

# Minimal thread pool configuration
thread pool {
    start_servers = 5
    max_servers = 32
    min_spare_servers = 3
    max_spare_servers = 10
}

server default {
    authorize {
        files
        pap
    }

    authenticate {
        pap
    }

    post-auth {
        update {
            &reply: += &session-state:
        }
    }
}

# /etc/freeradius/3.0/clients.conf
client mikrotik {
    ipaddr = 192.168.1.1
    secret = neutrinet
}

# /etc/freeradius/3.0/users
test_user Cleartext-Password := "password123"
    Framed-IP-Address = 192.168.1.100,
    Framed-IPv6-Prefix = 2001:db8:1:1::/64,
    Delegated-IPv6-Prefix = 2001:db8:2::/60

Ne serait-ce pas un sujet de Neutriton, se demande le brocoli ? Tout à fait !

TODO:

• Trouver plus de 366 jours dans une année.
• Envoyer le hub infra sur Mars pour cultiver des patates

Demo : Tharyrok a fait plein de trucs !

Dans les outils, on a:

• Authentik pour le SSO, à confirmer qu'on choisit cet outil à la place de Keycloak
• ContainerSSH pour la création de conteneurs Docker pour les backups storage de chaque utilisateur
• Semaphore pour lancer les playbook
• Mercure pour la communication entre le client et serveur
• Turbo pour les connexions xhr (pour ne pas rafraichir les pages)
• Création d'un conteneur minimaliste avec buildroot (make menuconfig) et busybox https://buildroot.org/

Prochaine réunion : 26/01/2025 à 14h

Lieu : Chez Célo

Neutriton Redis: 24/11 à 14h au Caldarium ?

Neutriton Gestionnaire de mot de passe: 05/01/2025 à 14h au Caldarium

Garde-Pad : Tharyrok gratte gratte gratte

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.