feat(stacks): readme 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
 
@@ -127,10 +125,16 @@ vérifie). Deux valeurs différentes ne produisent aucune erreur au démarrage
 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
+sops edit secrets.env.yaml          # TURN_STATIC_AUTH_SECRET
+
+# 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,9 +194,6 @@ 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`.
-
 ## Défauts connus
 
 **Trois images en tag flottant** : `nginx:latest`,