feat(stacks): fix version for matrix

stacks/matrix.poneyworld.net/README.md

@@ -77,10 +77,9 @@ Cinq valeurs dans `secrets.env.yaml`, injectées par `sops exec-env` :
 | `LIVEKIT_KEY`, `LIVEKIT_SECRET` | `livekit` (via `LIVEKIT_KEYS`) et `lk-jwt` |
 | `TURN_STATIC_AUTH_SECRET`, `TURN_CLI_PASSWORD` | `coturn` |
 
-`LIVEKIT_KEY` est un identifiant plus qu'un secret, et la convention du dépôt
-laisserait ce genre de valeur en clair. Il est chiffré quand même : il ne se
-tourne jamais seul, toujours en paire avec son secret, et le séparer sur deux
-mécanismes rendrait la rotation facile à rater à moitié.
+`LIVEKIT_KEY` tient plus de l'identifiant que du secret. Il est chiffré avec
+son secret parce que les deux se tournent toujours ensemble : les séparer sur
+deux mécanismes rendrait la rotation facile à ne faire qu'à moitié.
 
 ```bash
 sops edit secrets.env.yaml
@@ -110,14 +109,13 @@ command:
   - --cli-password=${TURN_CLI_PASSWORD:?}
 ```
 
-Le compromis est explicite : les valeurs ne sont pas dans un fichier
-versionnable, mais elles sont visibles dans `docker inspect coturn` et dans la
-table des processus de l'hôte. C'est strictement mieux qu'un fichier
-versionné, ce n'est pas aussi bon qu'un secret Compose.
+Le compromis est là : les deux valeurs sont visibles dans `docker inspect
+coturn` et dans la table des processus de l'hôte. Un secret Compose ferait
+mieux, coturn ne sait pas le lire.
 
-`turnserver.conf` ne doit donc jamais reprendre de lignes
-`static-auth-secret=` ou `cli-password=` : ce serait à la fois un secret en
-clair dans le dépôt et une seconde source concurrente.
+`turnserver.conf` ne doit jamais porter de ligne `static-auth-secret=` ou
+`cli-password=` : ce serait un secret en clair dans le dépôt, et une seconde
+source concurrente de celle du `command:`.
 
 ### Rotation
 
@@ -128,9 +126,15 @@ les appels échouent simplement à établir un relais.
 
 ```bash
 sops edit secrets.env.yaml          # TURN_STATIC_AUTH_SECRET
-docker compose exec synapse vi /data/homeserver.yaml   # turn_shared_secret
-sops exec-env secrets.env.yaml 'docker compose up -d --force-recreate coturn'
-docker compose restart synapse
+
+# homeserver.yaml s'édite depuis l'hôte : l'image Synapse n'a pas d'éditeur.
+sudo vi "$(docker volume inspect matrix_poneyworld_matrix_data \
+             --format '{{.Mountpoint}}')/homeserver.yaml"   # turn_shared_secret
+
+sops exec-env secrets.env.yaml '
+  docker compose up -d --force-recreate coturn &&
+  docker compose restart synapse
+'
 ```
 
 `macaroon_secret_key` (dans `homeserver.yaml`) signe les jetons d'accès : le
@@ -156,23 +160,19 @@ retirer un ne changerait rien au volume réel, mais ferait diverger sa
 déclaration, et Compose proposerait alors de le **recréer**. Ne pas toucher au
 bloc `volumes:` du compose.
 
-### Pourquoi `POSTGRES_DB` est indispensable
+### `POSTGRES_DB` conditionne le dump
 
-`backup_docker.sh` détermine la base à dumper ainsi :
+`backup_docker.sh` lit la base à dumper dans l'environnement du conteneur
+`db` :
 
 ```bash
 db_name=$(docker exec "$container" printenv POSTGRES_DB 2>/dev/null || echo "postgres")
 ```
 
-Sans `POSTGRES_DB` dans l'environnement du conteneur `db`, `printenv` sort en
-erreur, le repli s'applique, et le script dumpe `postgres` — la base système,
-vide — avec succès et sans le moindre avertissement. Le dump obtenu fait
-quelques centaines d'octets et ne contient aucune table.
-
-`POSTGRES_DB=synapse` dans l'`env_file` est ce qui garantit que le dump porte
-sur la bonne base. La variable n'est lue par PostgreSQL qu'à l'initialisation
-du cluster : elle est sans effet sur une base existante, sa seule fonction ici
-est d'être visible par `printenv`.
+Sans `POSTGRES_DB`, le repli s'applique : le script dumpe la base système
+`postgres`, vide, et journalise un succès. `POSTGRES_DB=synapse` dans
+l'`env_file` n'a pas d'autre fonction que d'être visible par ce `printenv` —
+PostgreSQL, lui, ne lit cette variable qu'à l'initialisation du cluster.
 
 Vérification, après tout changement touchant `db` :
 
@@ -194,15 +194,16 @@ elle.** Aucun des deux ne le signalera : coturn et LiveKit démarrent
 normalement en annonçant une adresse erronée, et seuls les appels échouent —
 sans erreur dans les logs, puisque du point de vue des serveurs tout va bien.
 
-C'est déjà arrivé : `external-ip` a pointé pendant des mois sur
-`91.121.90.228`, l'adresse d'`admin.opytex.org`.
+## Versions d'images
 
-## Défauts connus
+Toutes les images sont épinglées au patch. Les tags d'amont ne suivent pas la
+même forme : `livekit-server` préfixe d'un `v`, `lk-jwt-service` non — bien
+que son tag *git* le porte. Le label OCI
+`org.opencontainers.image.version` du conteneur donne la forme du tag d'image,
+c'est lui qui fait foi.
 
-**Trois images en tag flottant** : `nginx:latest`,
-`livekit/livekit-server:latest`, `ghcr.io/element-hq/lk-jwt-service:latest`.
-La convention du dépôt veut une version en dur, et Renovate ne sait rien faire
-d'un `latest`.
+`livekit` et `lk-jwt` se montent ensemble : ils s'authentifient mutuellement et
+suivent le même protocole MatrixRTC.
 
 Références :
 

stacks/matrix.poneyworld.net/docker-compose.yml

@@ -46,7 +46,7 @@ services:
       - default
 
   nginx:
-    image: nginx:latest
+    image: nginx:1.29.7
     restart: unless-stopped
     volumes:
       - ./nginx/matrix.conf:/etc/nginx/conf.d/matrix.conf:ro
@@ -79,7 +79,7 @@ services:
       - traefik.http.services.element.loadbalancer.server.port=80
 
   livekit:
-    image: livekit/livekit-server:latest
+    image: livekit/livekit-server:v1.10.1
     command: --config /etc/livekit.yaml
     restart: unless-stopped
     environment:
@@ -103,7 +103,7 @@ services:
       - traefik.http.services.livekit.loadbalancer.server.port=7880
 
   lk-jwt:
-    image: ghcr.io/element-hq/lk-jwt-service:latest
+    image: ghcr.io/element-hq/lk-jwt-service:0.4.1
     restart: unless-stopped
     environment:
       LIVEKIT_JWT_BIND: ":8081"