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

Présences :

• HgO
• Célo

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:

Peut-être un truc à suivre : https://www.webfoobar.com/node/52

Au final on pense que c'est le file system qui est corrompu, on va faire un reboot, voir un fsck pour tenter de réparer tout ça. En espérant que ce ne soit pas un problème matériel

On boot sur une clé USB avec Ubuntu, on installe cryptsetup:

apt install cryptsetup

Ensuite on déchiffre la partition:

cryptsetup luksOpen /dev/nvme0n1p2 recovery

Et on fait un fsck sur la partition virtuelle:

fsck /dev/mapper/recovery

On s'est arrêté là car il faut une version récente de e2fsck.

Mais c'est probablement l'ordi de Célo qui est kaput.

• Supprimer la VM et la recréer, pour voir si tous les handlers (notamment la migration de la DB) se déclenchent correctement → fait, et snapshot créé
• Installer le paquet postgresql-13-postgis sur tous les serveurs du cluster (variable postgresql_patroni_hosts + boucle), car delegated_to ne peut recevoir qu'un seul
• Pour le moment, on a postgresql-13-postgis et la version majeure de PostgreSQL est hardcodée, il faudrait définir une variable pour ça, ou réutiliser la variable postgresql_major_version → Célo a testé des trucs, on va regarde ça
• Configurer le HAProxy de Neutrinet
• Tester le redémarrage de la VM

Célo a rajouté une variable postgresql_major_version: 13 dans les variables par défaut du rôle, afin de pouvoir facilement mettre à jour PostgreSQL le moment venu.

On a un problème lors de la création des backups : il ne veut pas en créer, car selon lui un backup existe déjà avec une autre clé ! C'est normal, on avait recréé la VM.

En temps normal, on stocke la clé de chiffrement dans le password store de Neutrinet. Bon, ici on ne l'avait pas fait car ce n'est encore que des tests. On va donc devoir supprimer les backups de Mobilizon sur la VM storage-01.ovh.neutri.net:

rm -rf /media/backups/mobilizon-patata-louise-neutri-net/

On relance le playbook commun sur la VM, et on prend bien soin de mettre la clé de chiffrement de borg dans le password store, qui se trouve dans le dossier /root/.config/borg/keys/. Si la VM devait être détruite et qu'on n'avait pas cette clé, il serait impossible de récupérer les backups (à moins d'être très bon en cryptographie).

On relance le playbook mobilizon sur la VM.

On voit deux erreurs lors de la migration de la db:

• Il ne parvient pas à se connecter au haproxy-00, mais on règle le problème en passant en IPv4 au lieu d'IPv6. Mais c'est étrange que ça ne marche pas en IPv6
• Le mot de passe était encore hardcodé dans la config Mobilizon, on fait en sorte d'utiliser la variable.

Tel que le playbook est écrit, la migration de la DB se fait juste au moment où on télécharge une nouvelle version de mobilizon. Il faut aussi ajouter ce handler au moment où l'on installe la config, comme ça, si celle-ci a changé, la migration est ré-effectuée.

On regarde quel HA_proxy a l'ip VIP pour choisir l'autre pour faire nos tests. Pour cela, on essaie de s'y connecter avec :

ssh haproxy-00.patata.louise.neutri.net

Là on voit que c'est le haproxy-02 qui a la VIP, donc on se connecte au haproxy-01.

On modifie la config. On peut copier les parties de configs des autres services :

On copie aussi une acl

    acl mobilizon-neutrinet-be-acl hdr(host),field(1,:) mobilizon.neutrinet.be

Cela signifie qu'on définie un match pour le domaine mobilizon.neutrinet.be. Le hdr(host) signifie “regarde dans le header HOST”, puis le field(1,:) signifie “ne prend que la partie avant le port, qui est délimité par :”.

Ensuite, on dit que si le domaine matche, on utilise le backend adéquat:

    use_backend mobilizon-neutrinet-be-backend if mobilizon-ne`trinet-be-acl

On reprend la config du backend de dokuwiki car derrière il y a aussi un Caddy, donc on doit renommer des trucs:

backend mobilizon-neutrinet-be-backend
    http-request add-header X-Forwarded-Proto https if { ssl_fc }
    mode http
    option httpchk GET /healthcheck
    option forwardfor
    option http-server-close
    server mobilizon-patata-louise-neutri-net mobilizon.patata.louise.neutri.net:80 check  cookie sl

On vérifie si la config est correcte:

haproxy -c -f /etc/haproxy/haproxy.cfg

On recharge la config de haproxy:

systemctl reload haproxy

Pour effectuer nos tests, il y a plusieurs solutions, mais la moins casse-tête c'est de faire une redirection de port sur sa machine vers le haproxy de test:

ssh -L 8443:localhost:443 haproxy-01.patata.louise.neutri.net

Ensuite, on rajoute le domaine mobilizon.neutrinet.be dans /etc/hosts pour que ça pointe vers localhost.

Et enfin, on peut se connecter à https://mobilizon.neutrinet.be:8443 \o/

A priori tout semble correct quand on se connecte

On va tenter de créer un utilisateur et un évènement. On verra plus tard pour la fédération…

On se place dans le dossier de Mobilizon:

cd /var/www/mobilizon-neutrinet-be/dist

Et on crée un utilisateur admin random:

sudo -u mobilizon-neutrinet-be -HE ./bin/mobilizon_ctl users.new "your@email.com" --admin --password "neutrinet"

On constate qu'on peut créer un compte et ajouter des événements. On a un souci avec les images, mais cela semble lié au fait que Firefox ne veut pas les récupérer sur le port :8443.

Pour les images, on a dû rechanger le path des médias de Mobilizon, car par défaut, Mobilizon les stocke dans /var/lib/… C'est comme la config qui revoie à /etc/.

Pour Caddy et HAproxy, cependant, c'est ok. Mais maintenant, il faut ajouter la config via Ansible et non directement dans le fichier de config de HAproxy.

C'est dans le rôle HA Proxy, dans le dossier des templates.

On voit plusieurs parties dans le fichier haproxy.conf.j2:

• Une première partie qui gère les redirections, avec une boucle sur la variable haproxy_redirect. Cette variable contient une liste de redirections, avec à chaque fois comme attributs from: domaine1 et to: domaine2
• Une autre partie qui définit les ACL pour matcher les noms de domaine. Cela utilise la variable haproxy, qui est une liste contenant au moins l'attribut hostname (= le nom de domaine du site web)
• Ensuite, on peut gérer divers trucs comme le basic auth, une 403 sur un chemin, etc.
• Il y a également une partie qui définit quel backend correspond à quel domaine (c'est le bloc avec le use_backend)
• Enfin, la dernière partie crée les différents backend, toujours en parcourant la variable haproxy. Là, on a besoin de l'attribut target qui est une liste de serveurs et l'attribut target_port qui est le port sur lequel écoute notre service.
• On peut aussi définir des checks pour voir si le backend est en vie ou non, via healthcheck: true et healthcheck_url pour dire quelle requête exécuter (ex: GET /healthcheck si on utilise Caddy)
• La dernière partie concerne les serveurs PostgreSQL

Dans le template, on a à chaque fois des boucles avec des variables liées aux dommaines et au port utilisé. Ces varialbes sont définies dans groupe_vars → haproxy.

On va créer un nouveau élement dans la variable haproxy, dans le fichier inventories/group_vars/haproxy/vars.yml:

  - hostname: mobilizon.neutrinet.be
    target:
      - mobilizon.patata.louise.neutri.net
    target_port: 80
    healthcheck: true
    healthcheck_url: GET /healthcheck

On cible le port 80 car c'est Caddy qui se trouve derrière, et active les checks pour vérifie que le serveur est vivant.

Enfin, on peut exécuter le playbook sur le haproxy-01 qui est celui qui n'a pas la VIP, ceci afin de continuer nos tests:

ansible-playbook playbooks/apps/haproxy.yml -l haproxy-01.patata.louise.neutri.net --diff

Quand on constate que tout est ok, on peut casser l'autre haproxy:

ansible-playbook playbooks/apps/haproxy.yml -l haproxy-02.patata.louise.neutri.net --diff

Il reste encore à configurer Mobilizon pour envoyer des mails.

On peut regarder comment c'est fait sur mobilizon.be

Sur le serveur, cela se trouve dans le dossier live/config/runtime.exs. Il y a une partie pour le SMTP:

config :mobilizon, Mobilizon.Web.Email.Mailer,

Sur mobilizon.be, on utilise un geocoder spécifique, à voir dans la doc s'il faut installer des trucs: https://docs.joinmobilizon.org/administration/configure/geocoders/

• Explication du password manager
• Installation et configuration
• Explication du concept de « password store »
• Comment récupérer un mot de passe
• Comment rajouter un nouveau mot de passe
• Comment modifier un mot de passe
• Comment supprimer un mot de passe
• Ajouter et supprimer des personnes

TODO:

• Demander à Alyve pour récupérer la gestion des DNS (elle est sur Matrix et Mastodon) → demander un transfert du domaine
• Rajouter la gestion du SMTP dans le playbook
• Rajouter le bon Geocoder dans le playbook
• Rajouter la config pour l'IPv6 dans la BDD : https://community.fly.io/t/failed-to-connect-to-database-cluster-non-existing-domain/1223
• Scratcher la VM et tester les backups (penser à copier la clé de chiffrement avant)
• Installer le paquet postgresql-13-postgis sur tous les serveurs du cluster (variable postgresql_patroni_hosts + boucle), en utilisant une boucle car delegated_to ne peut recevoir qu'un seul host.
• Réparer l'ordinateur de Célo
• Préparation de la migration de Mobilizon, càd copier les données de mobilizon.be et les placer sur la nouvelle VM

Prochain atelier Ansible: 22/05, heure à confirmer

Lieu : Chez Célo

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.