Outils pour utilisateurs

Outils du site

Piste : • 03-12
fr:rapports:2023:06-19

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Prochaine révision		Révision précédente
fr:rapports:2023:06-19 [2023/11/06 14:50] – créée hgofr:rapports:2023:06-19 [2023/11/23 13:43] (Version actuelle) – hgo
Ligne 1: Ligne 1:
-# 2023/06/19 (migration) : Mobilizon+# 2023/06/19 (atelier) : Ansible
  
-* [Réunion précédente](https://doc.neutrinet.be/atelier-ansible-2023-06-19) +* [Réunion précédente](https://doc.neutrinet.be/atelier-ansible-2023-05-18) 
-* [Pad de la réunion](https://doc.neutrinet.be/migration-mobilizon-2023-09-25#) +* [Pad de la réunion](https://doc.neutrinet.be/atelier-ansible-2023-06-19#)
- +
-Heure de début : 14h+
  
 Présences : Présences :
Ligne 24: Ligne 22:
 ## Anciens TODOs ## Anciens TODOs
  
 +- Demander à Alyve pour récupérer la gestion des DNS (elle est sur Matrix et Mastodon) -> demande du transfert du domaine -> en cours
 +- Rajouter la gestion du SMTP dans le playbook -> Célo a fait des trucs
 +- Rajouter la config pour l'IPv6 dans la BDD : https://community.fly.io/t/failed-to-connect-to-database-cluster-non-existing-domain/1223
 - Préparation de la migration de Mobilizon, càd copier les données de mobilizon.be et les placer sur la nouvelle VM - Préparation de la migration de Mobilizon, càd copier les données de mobilizon.be et les placer sur la nouvelle VM
-- Mettre en place un cronjob avec l'outil geoipupdate (peut se faire à la main dans un premier temps)+- Tester le redémarrage de la VM
  
-## Configuration+## Configuration 
  
 ### GeoCoder ### GeoCoder
 +
 +Sur mobilizon.be, on utilise Nominatim comme geocoder, à voir dans la doc s'il faut installer des trucs: https://docs.joinmobilizon.org/administration/configure/geocoders/
 +
 +D'autres Géocoders sont possibles mais c'est vite assez cher.
  
 Pour le moment on garde Nominatim, et on verra plus tard s'il faut changer. Il faudra regarder combien de requêtes par mois sont faites vers Nominatim. Pour le moment on garde Nominatim, et on verra plus tard s'il faut changer. Il faudra regarder combien de requêtes par mois sont faites vers Nominatim.
Ligne 35: Ligne 40:
 ### SMTP ### SMTP
  
-On réutilise la config SMTP existante, mais on la changera sans doute plus tard quand on aura les accès au nom de domaine (création d'une boîte mail chez Neutrinet ?)+Il reste encore à configurer Mobilizon pour envoyer des mails.
  
-### Préparation de la migration+On peut regarder comment c'est fait sur mobilizon.be
  
-On va devoir récupérer un dump de la base de données de 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, 
 +```
  
-Il nous faudra aussi les médias (uploads, etc.), qui se trouvent dans `/home/mobilizon/live/uploads`.+On réutilise la config SMTP, mais on la changera sans doute plus tard quand on aura les accès au nom de domaine (création d'une boîte mail chez Neutrinet ?)
  
-Pour savoir combien d'espace tout cela occupe, il y a une chouette commande qui s'appelle ncdu, et qui affiche de manière "graphique" l'espace utilisé par chaque dossier.+### Postgis
  
-On voit que la taille des dossiers fait 2Gb à tout casser.+Il faut qu'on installe le plugin `postgresql-13-postgis` sur tous les hosts postgresql, car sinon la base de données de Mobilizon se casse la figure lorsqu'un autre serveur devient le serveur primaire.
  
-On commence par vérifier que notre repo git est à jour. On fait `git pull origin main`. On remarque qu'on a un conflit avec l'inventaire. VSCodium nous permet de régler les conflits assez facilement, donc pourquoi se priver ?+On doit faire une boucle dans le rôle ansible, car la directive `delegated_to` ne permet pas d'indiquer plusieurs hosts.
  
-On vérifie que la config haproxy (ici, c'est dans le dossier `haproxy_keepalived`) contient bien le nom de domaine mobilizon.be. On rajoute aussi dans la variable `letsencrypt_domains_gandi` le domaine mobilizon.be.+On peut utiliser la variable `postgresql_patroni_hosts` qui contient la liste des serveurs du cluster patroni.
  
-On va d'abord tester le playbook haproxy sur celui qui n'est pas actif. Pour cela, on se rend sur un des haproxy, et on regarde qui a l'IP flottante (ou VIP pour virtual IP). Ici, on voit que c'est `haproxy-02.patata.louise.neutri.net`, donc on va faire nos tests sur l'autre. +On utilise la directive `loop` pour parcourir la liste des serveurs postgresql définis dans la variable `postgresql_patroni_hosts`, et pour chaque serveur dans la liste on délègue la tâche vers celui-ci: 
- +```yaml 
-On active notre virtualenv: +delegate_to: "{{ postgresql_host }}" 
-``` +loop: "{{ postgresql_patroni_hosts }}" 
-source env/bin/activate+loop_control: 
 +  loop_var: postgresql_host
 ``` ```
  
-On lance le playbook haproxy: +Le problème, c'est qu'il y a deux cas différents. Lorsque le playbook est exécuté sur une machine qui fait partie d'un cluster patroni, la liste définie dans la variable `postgresql_patroni_hosts` n'est pas vide et la tâche se déroule bien. Cependant, lorsque le rôle est lancé localement avec molécule, la tâche n'est pas effectuée car la liste des hosts patroni est vide.
-``` +
-ansible-playbook playbooks/apps/haproxy.yml -l haproxy-01.patata.louise.neutri.net --diff  +
-```+
  
-Comme ça se passe bien, on lance sur l'autre haproxy : +Une première possibilité est d'écrire deux fois la tâche. Une première fois pour le cas où le playbook est lancé sur une machine qui fait partie d'un cluster (on ne lance alors la tâche que lorsque la variable contient plus d'éléments que 0 en utilisant l'opérateur `when`).
  
-``` +```yaml 
-ansible-playbook playbooks/apps/haproxy.yml -l haproxy-02.patata.louise.neutri.net --diff +- name: Installation de la dépendance postgresql pour postgis 
 +  ansible.builtin.package: 
 +    name: 
 +      - postgresql-{{ postgresql_major_version }}-postgis 
 +    state: present 
 +  delegate_to: "{{ postgresql_host }}" 
 +  loop: "{{ postgresql_patroni_hosts }}" 
 +  loop_control: 
 +    loop_var: postgresql_host 
 +  when: postgresql_patroni_hosts | length > 0
 ``` ```
  
-Là on a une erreur lors de la création du certificat. Pas grave, on relance le playbook, c'est ça qui est chouette avec Ansible \o/+Puis une seconde fois pour le cas où la liste est vide et où la tâche n'a pas été appliquée, en spécifiant de ne faire cette opération que lorsque la liste est vide : 
  
-Ensuite, on met l'IP de Neutrinet dans notre `/etc/hosts` pour tester: + 
-``` +```yaml 
-80.67.181.20 mobilizon.be+- name: Installation de la dépendance postgresql pour postgis 
 +  ansible.builtin.package: 
 +    name: 
 +      - postgresql-{{ postgresql_major_version }}-postgis 
 +    state: present 
 +  delegate_to: "{{ inventory_hostname }}" 
 +  when: postgresql_patroni_hosts | length == 0
 ``` ```
  
-Pour le moment, on n'a rien.+(On note l'opérateur `when` qui change, dans un cas avec `length > 0` et une boucle, et dans l'autre avec `length == 0` sans boucle)
  
-On doit encore lancer le playbook Mobilizon pour adapter le nom de domaine dans la config Caddy: +L'avantage de cette méthode : cela rend le code lisible. L'inconvénient, c'est que ce n'est pas très optimisé et c'est très verbeux. 
-``` + 
-ansible-playbook playbooks/apps/mobilizon.yml -l mobilizon.patata.louise.neutri.net --diff+ 
 +```yaml 
 +- name: Installation de la dépendance postgresql pour postgis 
 +  ansible.builtin.package: 
 +    name: 
 +      - postgresql-{{ postgresql_major_version }}-postgis 
 +    state: present 
 +  delegate_to: "{{ postgresql_host }}" 
 +  loop: "{{ postgresql_patroni_hosts if (postgresql_patroni_hosts | length > 0) else [inventory_hostname] }}" 
 +  loop_control: 
 +    loop_var: postgresql_host
 ``` ```
  
-On remarque une erreur 502, c'est Mobilizon qui se casse la figure… On va réessayer en partant d'une VM toute neuve, car on avait fait des modifs la dernière fois.+Dans la directive `loop`, on dit : « Prend la liste définie dans la variable `postgresql_patroni_hosts`, uniquement si la liste contient des éléments. Sinon, prend la liste qui contient l'élément `inventory_hostname` ». On doit en effet définir dans les deux cas une liste pour que la boucle fonctionne.
  
-Ça marche !+Dans ce genre de situation, soit on privilégie la lisibilité, soit on rajoute plein de commentaire pour ne pas oublier dans 3 mois.
  
-Problème : mobilizon.be est encore en version 2.0.2, alors que nous avons fait un test avec la version 3.0.1 :/ On va donc refaire un test avec la bonne version, en espérant qu'il ne faille pas modifier le playbook :grimacing:+En général, on utilise plutôt les `if` / `else` dans des templates, et on évite de les utiliser dans les tâches. Donc on va partir sur la solution plus verbeuse.
  
-On supprime la DB, les medias, et la config, puis on relance le playbook en ayant modifier le numéro de version:+### Connexion base de données en IPv6 
 + 
 +On doit rajouter l'option `socket_options` dans la config de Mobilizon pour que la connexion puisse se faire en IPv6: 
 + 
 +```ruby 
 +config :mobilizon, Mobilizon.Storage.Repo, 
 +  adapter: Ecto.Adapters.Postgres, 
 +  socket_options: [:inet6],
 ``` ```
-mobilizon_version: 2.0.2 
-``` 
-Attention à bien modifier la variable à la fois dans l'inventaire et dans les variables defaults du rôle.  
  
-Malheureusement, la migration de la base de données ne fonctionne pas… On va donc essayer autrement, en partant d'un dump de la db existante sur mobilizon.be.+### SSH agent 
 + 
 +On configure le SSH agent pour qu'il arrête de nous embêter avec les clés SSH et les mots de passe dans tous les sens: 
 + 
 +https://wiki.archlinux.org/title/SSH_keys#Start_ssh-agent_with_systemd_user
  
-Pour cela, on supprime d'abord la base de donnée sur pgsql-03.patata.louise.neutri.net (qui est le serveur primaire actuellement):+Il faut sans doute créer le dossier pour pouvoir y mettre la config:
 ``` ```
-sudo -u postgres dropdb mobilizon-be+mkdir -p ~/.config/systemd/user
 ``` ```
  
-Et on recrée la db:+On crée la config `ssh-agent.service`:
 ``` ```
-sudo -u postgres createdb mobilizon-be+[Unit] 
 +Description=SSH key agent 
 + 
 +[Service] 
 +Type=simple 
 +Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket 
 +ExecStart=/usr/bin/ssh-agent -t 1h -D -a $SSH_AUTH_SOCK 
 + 
 +[Install] 
 +WantedBy=default.target
 ``` ```
  
-Ensuite, on donne les privilèges à l'utilisateur mobilizon-be:+Avec l'option `-t` on peut définir la durée de validité des clés SSH, c'est pratique pour ne pas avoir une dizaine de clés actives à la fin de la journée. 
 + 
 +Lorsque la config a été créée, on fait:
 ``` ```
-sudo -u postgres psql mobilizon-be +systemctl start --user ssh-agent 
-GRANT ALL PRIVILEGES ON DATABASE "mobilizon-be" to "mobilizon-be";+systemctl enable --user ssh-agent
 ``` ```
  
-On vérifie que les extensions sont les mêmes que sur mobilizon.be avec la commande `\dx` en étant connecté à la db. +Dans la config `~/.bashrc` ou `~/.zshrc`, on rajoute:
- +
-Dans notre cas, on doit rajouter les trois extensions:+
 ``` ```
-CREATE EXTENSION "postgis"; +export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket"
-CREATE EXTENSION "pg_trgm"; +
-CREATE EXTENSION "unaccent";+
 ``` ```
  
-Enfin, on fait un dump de la base de données de mobilizon.be:+Enfin, on ouvre un nouveau terminal et on vérifie que le ssh-agent tourne:
 ``` ```
-pg_dump -U mobilizon mobilizon_prod | gzip > $(date +%Y-%m-%d).mobilizon_prod.sql.gz+ssh-add -l
 ``` ```
-Que l'on copie sur la VM mobilizon. 
  
-Et on restaure la db à partir de ce dump:+On rajoute également la commande magique dans `~/.ssh/config` pour que SSH rajoute les clés qu'il utilise directement dans le SSH agent:
 ``` ```
-psql -h haproxy-00.patata.louise.neutri.net -U mobilizon-be < 2023-09-25.mobilizon_prod.sql+AddKeysToAgent  yes
 ``` ```
  
-On doit à présent copier les données d'uploads, on peut le faire avec un rsync (on aura de toute façon besoin de rsync au moment de la migration définitive, donc c'est bien de le configurer directement). On place d'abord notre clé SSH sur mobilizon.be pour pouvoir s'y connecter depuis la nouvelle VM.+### Tests du playbook
  
-Pour se faciliter la vie, on ajoute ceci dans la config du client SSH:+On a pu lancer le playbook en local via molécule, maintenant on va le lancer sur la VM mobilizon.patata.louise.neutri.net qu'on avait créé le mois passé. 
 + 
 +Ensuite, on lance manuellement un backup borgmatic, ceci afin de pouvoir tester la restauration des backups.  
 + 
 +On vérifie qu'on a bien sauvegardé la clé Borg qui se trouve dans `/root/.config/borg/keys`. 
 + 
 +On supprime la base de donnée :scream_cat: en se rendant sur le postgresql primaire. Ici, c'est pgsql-03.patata.louise.neutri.net. On fait un beau drop database:
 ``` ```
-Host mobilizon.be +sudo -u postgres dropdb mobilizon-neutrinet-be
-        User mobilizon +
-        IdentityFile /chemin/vers/la/cle/ssh +
-        AddressFamily inet+
 ``` ```
  
-A noter qu'on a du ajouter une IPv4 à la vm qui par défaut n'a qu'une IPv6 car le VPS n'avait qu'une IPv4.+Il nous dit que quelqu'un est en train d'utiliser la db, donc on stop Mobilizon et on recommence.
  
-Et on fait le rsync:+Ensuite, on se connecte au Proxmox pour repartir d'un snapshot de la VM Mobilizon. 
 + 
 +Maintenant, on lance le playbook commun pour provisionner à nouveau la VM 
 + 
 +Pour faire un restore des backups, voir la doc: https://torsion.org/borgmatic/docs/how-to/extract-a-backup/ 
 + 
 + 
 +~~Par contre, pour le moment on n'a pas encore la config borgmatic de Mobilizon… Il faut donc lancer le playbook pour au moins avoir cette config:~~
 ``` ```
-rsync -az mobilizon.be:/home/mobilizon/live/uploads/ /var/lib/mobilizon/uploads/ --progress+ansible-playbook playbooks/apps/mobilizon.yml -t borgmatic_config -l mobilizon --diff
 ``` ```
  
-Et on modifie les permissions:+En fait on n'a pas besoin de cette étape :) 
 + 
 +~~Lorsque c'est fait,~~ on peut restaurer les fichiers de Mobilizon:
 ``` ```
-chown mobilizon-be: /var/lib/mobilizon/uploads/ -R+borgmatic extract -c /etc/borgmatic.d/common.yml --archive latest --destination / --progress
 ``` ```
  
-Mais ça ne marche pas. On se dit que c'est peut-être lié à l'ancienne config de la version 2.0.2 qui n'est pas compatible avec les autres configurations faites via le playbook. On décide donc de tenter de faire la mise à jour vers une version plus récente 3.x.+On doit préciser où le backup doit être restaurer (sinon il le fait par défaut à l'endroit où on lance la commande). On peut ajouter le flag ```--progress``` pour que borg indique ce qu'il fait et où il en est.
  
-On décide de d'abord faire une mise à jour de Mobilizon vers la 2.1.0 (pour commencer), puis vers la 3.0.1 pour voir si cela règle les problèmes qu'on a... On va le faire à la main plutôt que via le playbook, pour être sûr de faire l'ensemble des migrations nécessaires.+Il faut encore restaurer la db postgresql, le dump se trouve dans `/root/.borgmatic/postgresql_databases`.
  
-Pour se faire, on coupe le service mobilizon sur mobilizon.be:+Il y a une commande magique de borgmatic pour faire ça, mais malheureusement il faut que le client postgresql soit installé (ou du monis le paquet `pg_restore`). On va d'abord le faire manuellement sur pgsql-03, et on testera la commande magique plus tard. 
 + 
 +On crée la base de données:
 ``` ```
-sudo systemctl stop mobilizon+sudo -u postgres createdb mobilizon-neutrinet-be
 ``` ```
-On fait pareil sur la VM. +Ensuite on restaure les données:
- +
-On fait un dump (voir plus haut), et on recrée la db (voir plus haut). +
- +
-On télécharge la release 2.1.0 de mobilizon à la main:+
 ``` ```
-wget https://packages.joinmobilizon.org/2.1.0/mobilizon_2.1.0_amd64.tar.gz -P /tmp/ +sudo -u postgres pg_restore -d mobilizon-neutrinet-be /tmp/mobilizon-neutrinet-be
-mkdir /var/www/mobilizon-be/mobilizon-2.1.0 +
-tar xvf /tmp/mobilizon_2.1.0_amd64.tar.gz --strip-components=1 -C /var/www/mobilizon-be/mobilizon-2.1.0 +
-ln -sf /var/www/mobilizon-be/mobilizon-2.1.0/ /var/www/mobilizon-be/dist +
-chown mobilizon-be: mobilizon-2.1.0/ -R+
 ``` ```
  
-Et on applique la migration:+Et enfin, on vérifie que les données sont bien là:
 ``` ```
-bin/mobilizon_ctl migrate+sudo -u postgres psql mobilizon-neutrinet-be`
 ``` ```
  
-Comme ça se passe bien, on fait de même pour la 3.0.1, et on démarre mobilizon sur la VM. Et ça marche \o/+On lance le playbook qui rajoute Caddy et le client Posgresql mais ne fait pas grand chose d'autre à part changer le masque sur ```/var/www```.
  
-On fait un dernier rsync pour avoir les derniers uploads: +Par contre, on remarque qu'on a des problèmes de permissions sur les fichiers de Mobilizon (ex: /var/www/mobilizon-neutrinet-be appartient à root).
-``` +
-rsync -az mobilizon.be:/home/mobilizon/live/uploads/ /var/lib/mobilizon/uploads/ --delete --progress +
-chown mobilizon-be: /var/lib/mobilizon/uploads/ -R +
-``` +
-Le delete permet d'effacer les fichiers qui auraient été supprimé depuis la dernière fois.+
  
-Maintenant, on fait nos tests:+En fait, c'est parce que borgmatic restaure les fichiers avant la création de l'utilisateur mobilizon (puisque celui-ci n'a pas encore été créé avec le playbook). Le mieux est donc de lancer d'abord le playbook puis de restaurer les données via borgmatic.
  
-- Création d'un évènement: https://mobilizon.be/events/9f28279e-450b-4096-9fde-34f7709bca23 +Néanmoins, il semble que même lorsque pg_restore (lié au client postgresql) est installé, la restauration de la DB via borg ne fonctionnent pas. Ce n'est pas grave puisqu'on peut le faire à la main.
-- Ajout d'un admin: ça marche, on a juste eu peur avec quelques erreurs +
-- Envoi de mail: on a dû un peu changer la config, cf. https://github.com/framasoft/mobilizon/blob/main/UPGRADE.md +
-    - Note: Célo n'a pas reçu de mail, mais HgO oui+
  
-On procède à la mise à jour vers 3.2.0 en testant cette fois le playbook Ansible.+### Geolix
  
-Il reste quelques détails à régler. Par exemple, la base de données GeoLite2-City qui permet de proposer des évènements proche de l'utilisateur… Pour le moment, c'est pas géré par le playbook, mais Célo va y travailler. En attendant, on l'a juste copié dans `/var/lib/mobilizon/geo`+Il y a un machin, ça s'appelle Geolix mais on sait pas trop à quoi ça sert : 
  
-Autre truc bizarre, c'est les mails : mobilizon envoie des mails à HgO mais pas à Célo :( . Mais bon, comme on va changer la config mail pour que ce soit géré par Neutrinet, on peut-être attendre un peu avant d'investiguer+https://hexdocs.pm/geolix/Geolix.html
  
-On a rajouté un dossier `/var/lib/mobilizon/sitemap` parce qu'il y avait une erreur de permissions dans les logs.+Au passage, on découvre la doc des CÉMÉA qui a l'air super complète \o/
  
-TODO:+https://ladoc.cemea.org/mallette/mobilizon
  
-- Gérer les mails chez Neutrinet +Cela permet de montrer des évènements en se basant sur la localisation de l'IP. En fait, c'est à la fin de la doc de mobilizon : https://docs.joinmobilizon.org/administration/install/release/#geolocation-databases
-- Tester la config mail pour Célo +
-- Gérer la db GeoLite2-City dans le playbook +
-- Mettre en place un cronjob avec l'outil geoipupdate +
-- Créer le dossier /var/lib/mobilizon/sitemap via Ansible +
-- Configurer Mobilizon pour permettre les notifications push : https://docs.joinmobilizon.org/administration/configure/push/+
  
 +Donc si l'IP est sur Bruxelles, on verra tous les évènements de Neutrinet en premier.
 +
 +On doit juste télécharger la base de données: https://download.db-ip.com/free/dbip-city-lite-2023-06.mmdb.gz
 +
 +Et la décompresser.
 +
 +Il y a moyen de mettre en place un cronjob pour mettre à jour cette base de données (voir doc des CÉMÉA), mais on le fera plus tard...
 +
 +TODO: Mettre en place un cronjob avec l'outil geoipupdate (peut se faire à la main dans un premier temps)
 +
 +### Préparation de la migration
 +
 +On va devoir récupérer un dump de la base de données de mobilizon.be
 +
 +Il nous faudra aussi les médias (uploads, etc.), qui se trouvent dans `/home/mobilizon/live/uploads`.
 +
 +TODO:
 +
 +- Tester avec un dump de la db, une copie des uploads, et voir si on peut se connecter.
 +- Tester l'envoi de mails
 +- Tester la création d'un évènement avec localisation (geocoder)
  
 ## Gopass ## Gopass
Ligne 229: Ligne 288:
 ## Prochaine réunion ## Prochaine réunion
  
-Prochain atelier Gopass + Keycloak: 07/10+TODO: Mettre en place un cronjob avec l'outil geoipupdate (peut se faire à la main dans un premier temps) 
 + 
 + 
 +Prochain atelier Ansible: On attend le transfert du nom de domaine
  
 Lieu : Chez Célo Lieu : Chez Célo
fr/rapports/2023/06-19.1699278654.txt.gz · Dernière modification : 2023/11/06 14:50 de hgo