17/12/2023 - Màj de Matrix synapse

[GautGaut]

17 Décembre 2023 - Màj de Matrix synapse

Une mise-à-jour de synapse est en cours. Un problème dans le paquet YunoHost fait qu’elle peut durer plusieurs heures… https://github.com/YunoHost-Apps/synapse_ynh/issues/433

[GautGaut]

Les messages et médias de plus d’1 an et les médias venus d’autres serveurs de plus de 30 jours ont été supprimés.

J’ai activé la purge automatique des messages plus vieux qu’un an dans la configuration de synapse.

J’ai désactivé le « presence tracking » des comptes → on ne voit plus si une personne est présente/connectée ou non

J’ai limité la complexité des salons qu’on peut rejoindre → 1

bon j’ai lancé, c’est parti pour la purge de toutes les rooms qui n’ont pas de user local
jq -r '.rooms | map(select(.joined_local_members == 0)) | .[].room_id' < rooms.json | xargs -ti $SHELL -ic "synadm DELETE 'v1/rooms/{}' -d '{"purge": true}'"

cf. https://wiki.chatons.org/doku.php/services/messagerie_instantanee/matrix#nettoyage_d_un_serveur_synapse

A supprimer au total :

• state events: 428688
• total rooms : 3041

Le 23/12

head -n 20 /tmp/rooms_to_clean | cut -d, -f1 | xargs -ti $SHELL -ic 'synadm POST '"'"'v1/purge_history/{}'"'"' -d '"'"'{"purge_up_to_ts":'"$(date -d-30days +%s000)"'}'"'"

https://github.com/YunoHost-Apps/synapse_ynh/issues/354#issuecomment-1861298549

Purger tous les salon bridgés WhatsApp à 1 an :

jq -r '.rooms | map(select(.creator == "@whatsappbot:sans-nuage.fr")) | .[].room_id' < rooms.json | xargs -ti $SHELL -ic 'synadm POST '"'"'v1/purge_history/{}'"'"' -d '"'"'{"purge_up_to_ts":'"$(date -d-365days +%s000)"'}'"'"

faudrait rajouter de purger tous les salons où il y a whatsappbot et que 2 utilisateurices. C’est peut-être nettoyable par le bridge whatsapp mais je sais pas si ça purge

je lance un reindex de la base synapse, et j’ai besoin de stopper synapse pour ça, merci de ne pas redémarrer avant demain matin

matrix_synapse=# REINDEX DATABASE matrix_synapse;
ATTENTION:  ne peut pas réindexer l'index invalide « pg_toast.pg_toast_47553_index_ccnew » sur une table TOAST, ignoré
REINDEX

et on a gagné 10GB de 39 à 29 GB
On peut aussi ne pas couper, ça réindexe quand même, pas toutes les tables, mais les plus importantes :

matrix_synapse=# REINDEX DATABASE CONCURRENTLY matrix_synapse;
ATTENTION:  ne peut pas réindexer les catalogues système de manière concurrente, ignore tout

j’espérais plutôt passer sous les 10G, donc faut encore appliquer mes idées sur les salons bridgés, et éventuellement supprimer ou compresser l’historique des gros salons

Le 24/12

cette nuit j’ai VACUUM la BDD synapse et on est passés à 18G d’espace disque contre 38G avant l’opération.

[GautGaut]

Propositions :
Que pensez-vous de purger :

• toutes les rooms distantes → comme ça je suis sûr de respecter la politique de rétention des données des serveurs distants
• les rooms locales créées par un robot whatsapp/signal et où il n’y a que des robots, 1 utilisateur et pas de puppets
• les rooms locales où il n’y a qu’1 utilisateur
• l’historique des rooms locales par défaut à 180 jours pour Matrix
  • Jusqu’à 360 jours autorisés en lançant une commande spécifique dans une room
  • 120 jours pour signal
  • 60 jours pour telegram
  • 60 jours pour whatsapp
• historique des grosses rooms à 30 jours (Celles qui ont le plus de state_event)

cela me fait dire qu’on ferait mieux d’avoir un serveur synapse dédié aux bridges, on saurait que toutes les rooms qui y sont créées sont des rooms bridgées. Et on n’aurait qu’à purger les rooms distantes. Mais tout serait dupliqué 2 fois sur sans-nuage et le serveur du bridge…

J’ai cru voir passer qu’il y avait la possibilité de créer une room d’annonces pour notre serveur. Ce serait le mieux je pense

[GautGaut]

Une question qui me vient, le problème c’est la place prise par le dump de la BDD synapse pendant les backup et upgrade. Libérer l’espace pris par la DB on s’en fiche un peu tant qu’elle ne grossit pas au-dessus de 20-30G. Est-ce que le VACUUM de la BDD est nécessaire pour que le dump soit plus petit ? ou purger l’historique et réindexer est suffisant ?

[Optogram]

Mes modifications en gras

• l’historique des rooms locales à 180 jours
• l’historique des salons bridgés à 180 jours
• historique des grosses rooms à 30 jours (Celles qui ont le plus de state_event)
  • Qu’est ce qu’une room avec beaucoup de state_event ? Tu as un chiffre ? ça se mesure ?

Et la room d’annonce est une bonne idée, je crois qu’on peut faire un pont entre Discourse et Matrix, pour qu’un sujet du forum soit dispo en chat, ce serai super On peut restreindre l’écriture à un nombre limité de personnes dans une room ? En lecture seule ?

[irina]

Parcontre si c’est des salons bridgés uniquement avec IRC faux pas les concidérers comme les autres salons bridgés vue qu’il n’y a pas d’historique sur les serveur IRC.

[GautGaut]

Oui je parlais des salons bridgés avec nos bridges. Les salons bridgés IRC sont de toutes façons des salons originaires du serveur Matrix FDN, donc « salons distants », c’est la politique de rétention de FDN qui s’appliquera donc.

[GautGaut]

@Optogram

l’historique des salons bridgés à 180 jours

Je pensais faire un historique des salons bridgés à 30 jours, à condition que l’historique ancien puisse être récupéré sur demande via une commande du bridge. Mais en fait ce n’est pas possible salon par salon. Mais pour encourager les gens à migrer vers les autres réseaux, j’aurais tendance à mettre :

• 180 jours pour matrix
• 120 jours pour signal
• 60 jours pour telegram
• 60 jours pour whatsapp

Pour la room d’annonce je veux bien que tu creuses/expérimentes.