TeDomum issueshttps://forge.tedomum.net/groups/tedomum/-/issues2023-12-03T13:00:17Zhttps://forge.tedomum.net/tedomum/documentation/-/issues/184GitLab Flavored Markdown - rendu Mermaid impossible2023-12-03T13:00:17Zcome_744GitLab Flavored Markdown - rendu Mermaid impossibleBonjour,
J'ai l'impression que Mermaid ne fonctionne pas sur cette instance GitLab. Par exemple:
````
```mermaid
stateDiagram
[*] --> Still
Still --> [*]
Still --> Moving
Moving --> Still
Moving --> Crash
Crash...Bonjour,
J'ai l'impression que Mermaid ne fonctionne pas sur cette instance GitLab. Par exemple:
````
```mermaid
stateDiagram
[*] --> Still
Still --> [*]
Still --> Moving
Moving --> Still
Moving --> Crash
Crash --> [*]
```
````
> Firefox ne peut pas ouvrir cette page
>
> Pour protéger votre sécurité, forge.tedomum.net ne permettra pas à Firefox d’afficher la page si celle-ci est intégrée par un autre site. Pour voir cette page, vous devez l’ouvrir dans une nouvelle fenêtre.
>
> En savoir plus…
>
> Signaler les erreurs similaires pour aider Mozilla à identifier et bloquer les sites malveillants
Ça affiche pareil chez vous ?
```mermaid
stateDiagram
[*] --> Still
Still --> [*]
Still --> Moving
Moving --> Still
Moving --> Crash
Crash --> [*]
```
* https://docs.gitlab.com/ee/user/markdown.html#mermaidhttps://forge.tedomum.net/tedomum/documentation/-/issues/183Gitlab mailroom plante au démarrage2024-01-20T12:01:43Zkaiyoupierre@jaury.euGitlab mailroom plante au démarrageDepuis la 16.6, Gitlab mailroom plante au démarrage, ce qui fait également échouer l'instance entière. Je m'en suis rendu compte en lançant la migration des assets vers Garage.
L'issue est documentée ici : https://gitlab.com/gitlab-org/...Depuis la 16.6, Gitlab mailroom plante au démarrage, ce qui fait également échouer l'instance entière. Je m'en suis rendu compte en lançant la migration des assets vers Garage.
L'issue est documentée ici : https://gitlab.com/gitlab-org/gitlab/-/issues/432257
En attendant le workaround :
```
docker-compose restart gitlab
docker-compose exec gitlab bash
```
Et dans le shell :
```
curl -o /tmp/mailroom.patch https://gitlab.com/gitlab-org/gitlab/-/merge_requests/137279.diff
cd /opt/gitlab/embedded/service/gitlab-rails
patch -p1 < /tmp/mailroom.patch
gitlab-ctl restart mailroom
```kaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://forge.tedomum.net/tedomum/wordpress/-/issues/35Faire le tri dans les thèmes trop anciens2023-12-03T09:22:02ZMickGeFaire le tri dans les thèmes trop anciensDes thèmes utilisés ne sont plus suivis depuis longtemps…
Voici les dates des dernières mises à jour à ce jour de ces thèmes utilisés :
1. __Admired → 2012.07.07__
1. Astra → 2023.11.07
1. Baskerville → 2022.12.23
1. Blog Starter → 202...Des thèmes utilisés ne sont plus suivis depuis longtemps…
Voici les dates des dernières mises à jour à ce jour de ces thèmes utilisés :
1. __Admired → 2012.07.07__
1. Astra → 2023.11.07
1. Baskerville → 2022.12.23
1. Blog Starter → 2023.11.11
1. __ChocoTheme → pas de date…__
1. __Clean Retina → 2021.10.06__
1. Garfunkel → 2023.05.02
1. Graphene → 2022.03.19
1. Hemingway → 2022.12.23
1. Hoffman → 2022.12.23
1. __Matheson → 2017.03.08__
1. Michelle → 2023.08.15
1. __Paradise → 2013.01.05__
1. __Retina → 2021.03.23__
1. Rowling → 2022.12.23
1. __Simppeli → 2017.02.05__
1. __Spun → 2013.12.04__
1. Twenty Eleven → 2023.11.07
1. Twenty Twelve → 2023.11.07
1. Twenty Seventeen → 2023.11.07
1. Twenty Twenty → 2023.11.07
Ci-dessous, la liste des thèmes installés et inutilisés _(si j'ai le courage, je verrai pour automatiser la récupération de la date)_ :
1. Asusena
1. BoldR Lite
1. deCoder
1. Delicate
1. evolve
1. Headless
1. HopScotch
1. inLine
1. Light Clean Blue
1. Lovecraft
1. Northern-Clouds
1. Responsive
1. SEOS Social
1. Shell Lite
1. StartupWP
1. Susty
1. Trending Mag
1. Trend News
1. Twenty Fifteen
1. Twenty Fourteen
1. Twenty Nineteen
1. Twenty Sixteen
1. Twenty Ten
1. Twenty Thirteen
1. Twenty Twenty-One
1. Twenty Twenty-Two
1. Veggie Lite
1. VW Newspaper
<details><summary>Pour mémoire : Script JS</summary>
<pre>{
const used = ["Admired", "Astra", "Baskerville", "Blog Starter", "ChocoTheme", "Clean Retina", "Garfunkel", "Graphene", "Hemingway", "Hoffman", "Matheson", "Michelle", "Paradise", "Retina", "Rowling", "Simppeli", "Spun", "Twenty Eleven", "Twenty Seventeen", "Twenty Twelve", "Twenty Twenty"]
const themes = Array.from(document.querySelectorAll(".theme-title strong")).reduce((acc, el) => {
const txt = el.textContent
if (!used.includes(txt))
acc.push(txt);
return acc;
},[]);
console.log(themes.join('\n'));
}</pre>
</details>https://forge.tedomum.net/tedomum/documentation/-/issues/182Documentation Write Freely à mettre à jour2023-11-11T08:04:34ZAngedestenebresDocumentation Write Freely à mettre à jourTout est dans le titre. Les dernières versions ont apporté quelques nouveautés qui mériteraient d'être documentées, voir : https://github.com/writefreely/writefreely/releasesTout est dans le titre. Les dernières versions ont apporté quelques nouveautés qui mériteraient d'être documentées, voir : https://github.com/writefreely/writefreely/releaseshttps://forge.tedomum.net/tedomum/matrix-media-repo/-/issues/1Timeouts surprenants2023-11-21T20:10:04Zkaiyoupierre@jaury.euTimeouts surprenantsNous avons découvert à nos dépends la logique de timeout de Matrix Media Repo : https://github.com/turt2live/matrix-media-repo/blob/master/util/time.go#L16
Pour toute requête de download de media, il y a un timeout par défaut à 20 secon...Nous avons découvert à nos dépends la logique de timeout de Matrix Media Repo : https://github.com/turt2live/matrix-media-repo/blob/master/util/time.go#L16
Pour toute requête de download de media, il y a un timeout par défaut à 20 seconds, que le client peut étendre en spécifiant `timeout_ms` en query string, mais qui max à 60 secondes. Ce timeout est très fréquemment déclenché dans trois cas :
- lorsqu'un client Matrix récupère un media sur notre media repo et que le chargement dépasse le timeout (quelque valeur, ou bien 60 secondes au pire)
- lorsqu'on récupère un média sur un autre homeserver qui utilise Matrix Media Repo, auquel cas ne précisant rien c'est le 20s qui s'applique
- lorsqu'un autre homeserver récupère le media chez nous, auquel cas ne précisant rien c'est le 20s qui s'applique
Ce défaut soulève aussi la question du pourquoi c'est si lent. En premiers tests il ne semble pas que la performance de Garage soit en jeu, il est très performant en lecture ou écriture directe.https://forge.tedomum.net/tedomum/www/-/issues/40[Hugo] Ajouter le fichier de lock hugo dans le gitignore2023-09-28T15:49:30Zreminec[Hugo] Ajouter le fichier de lock hugo dans le gitignoreHugo a introduit un fichier de lock, qu'il faudrait qu'on ignore pour ne pas le commit sans le vouloir.
Exemple : https://github.com/kubernetes/website/pull/35405/files
Et aussi : https://discourse.gohugo.io/t/what-is-the-hugo-build-lo...Hugo a introduit un fichier de lock, qu'il faudrait qu'on ignore pour ne pas le commit sans le vouloir.
Exemple : https://github.com/kubernetes/website/pull/35405/files
Et aussi : https://discourse.gohugo.io/t/what-is-the-hugo-build-lock-file/35417/6reminecreminechttps://forge.tedomum.net/tedomum/nextcloud/-/issues/451Agenda Nextcloud - Invitation d'un participant à un évènement non envoyée/reçue2023-12-16T07:36:56Zcress1Agenda Nextcloud - Invitation d'un participant à un évènement non envoyée/reçueComme expliqué sur le Matrix.
Adresse email liée au compte Nextcloud.
Via app Agenda intégrée Nextcloud ou via Etar Android, invitation d'un participant à un évènement (case Envoyer mail cochée) non reçue par la personne (à la fois par ...Comme expliqué sur le Matrix.
Adresse email liée au compte Nextcloud.
Via app Agenda intégrée Nextcloud ou via Etar Android, invitation d'un participant à un évènement (case Envoyer mail cochée) non reçue par la personne (à la fois par mail, et dans son appli Agenda non plus).
edit 27/09 22h : ça a fonctionné sur l'app Calendrier MacOS mais côté invité (non client Nextcloud), ça donne ça quand il accepte.
![Capture_d_écran_2023-09-27_à_22.01.40](/uploads/f5165b96a831c2283143e5a443f7e103/Capture_d_écran_2023-09-27_à_22.01.40.png)https://forge.tedomum.net/tedomum/documentation/-/issues/181Documentation Mastodon à mettre à jour2023-11-16T17:33:54ZAngedestenebresDocumentation Mastodon à mettre à jourTout est dans le titre, suite à la dernière mise à jour, il y a pas mal de petits changements au niveau de l'interface qui nécessite que la documentation soit mise à jour.Tout est dans le titre, suite à la dernière mise à jour, il y a pas mal de petits changements au niveau de l'interface qui nécessite que la documentation soit mise à jour.https://forge.tedomum.net/tedomum/bitwarden_rs/-/issues/17Mise à jour vers 1.29.22023-11-07T22:28:39ZMickGeMise à jour vers 1.29.2Le build est en cours.
Le docker-compose est rédigé, mais pas tiré sur Aegir.
Il reste donc à :
```shell
cd /srv/apps/vault
git pull
docker-compose pull tedimg
docker-compose up -d && docker-compose logs -f tedimg
```Le build est en cours.
Le docker-compose est rédigé, mais pas tiré sur Aegir.
Il reste donc à :
```shell
cd /srv/apps/vault
git pull
docker-compose pull tedimg
docker-compose up -d && docker-compose logs -f tedimg
```MickGeMickGehttps://forge.tedomum.net/tedomum/kity/-/issues/18Déménagement de cyprus2023-11-21T20:13:06Zkaiyoupierre@jaury.euDéménagement de cyprusUn déménagement de cyprus était prévu initialement ce samedin. Il a eu lieu en précipitation aujourd'hui.
Hier soir @halfa a drain le noeud, et ce matin j'ai débranché à environ 9h40.
Problèmes :
- Le noeud hébergeait le Minio, ce qu'...Un déménagement de cyprus était prévu initialement ce samedin. Il a eu lieu en précipitation aujourd'hui.
Hier soir @halfa a drain le noeud, et ce matin j'ai débranché à environ 9h40.
Problèmes :
- Le noeud hébergeait le Minio, ce qu'on avait mal anticipé, et cause l'issue https://forge.tedomum.net/tedomum/synapse/-/issues/117
- La machine physique hébergeait toujours `mainecoon`, qui était prêt pour migrer sur la même machine que `bambino` mais la bascule n'avait pas été lancée encore.
A ce stade, `mainecoon` (le master) est arrêté, le transfert des données est en cours pour le relancer à côté de `bambino`.
A priori, `cyprus` sera rétabli le 22/08 ou le 23/08. Une fois le sujet Minio et `mainecoon` déplacé, tous les autres services devraient fonctionner sans problème sur les noeuds restant.kaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://forge.tedomum.net/tedomum/synapse/-/issues/117Stockage des media Matrix sur Minio2023-11-21T20:13:10Zkaiyoupierre@jaury.euStockage des media Matrix sur MinioAujourd'hui nous devons migrer en urgence `cyprus`, ce qui n'était initialement prévu que le 12 avec intervention pour la migration aujourd'hui et demain. Il a donc été drain hier soir sans préavis.
En conséquence, le Minio hébergé dess...Aujourd'hui nous devons migrer en urgence `cyprus`, ce qui n'était initialement prévu que le 12 avec intervention pour la migration aujourd'hui et demain. Il a donc été drain hier soir sans préavis.
En conséquence, le Minio hébergé dessus est arrêté, et il hébergeait les Media Matrix, parmi les derniers binaires que nous ne stockons pas sur notre cluster Garage. En conséquence, l'upload et la réception de pièce-jointe par Matrix est interrompue depuis hier soir également.
Nous allons d'abord basculer le stockage des nouvelles pièces-jointes vers Garage, rétablissant l'upload et l'affichage des nouvelles, mais les pièces-jointes existantes ne seront pas accessibles. Puis dans les jours prochains nous synchroniserons l'historique des pièces-jointes.kaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://forge.tedomum.net/tedomum/peertube/-/issues/60Vidéos non disponibles : "Move to external storage failed, this video may not...2024-03-19T22:37:57ZMickGeVidéos non disponibles : "Move to external storage failed, this video may not work properly."e-Mail du 06/08/2023 01:15 :
> Bonjour,
>
> There is a playlist with these two videos included but they can't play. The error states "Move to External Storage Failed". Is there any chance the videos can be restored?
>
> https://video....e-Mail du 06/08/2023 01:15 :
> Bonjour,
>
> There is a playlist with these two videos included but they can't play. The error states "Move to External Storage Failed". Is there any chance the videos can be restored?
>
> https://video.tedomum.net/w/dxtDSAXZsLgVOE5Ewhe5SC8
>
> https://video.tedomum.net/w/iNUtJr6ZG4RqDy8ow5bYNv
>
> Hope to hear back.
Les vidéos ne sont pas disponibles, bannière :
> Move to external storage failed, this video may not work properly.
infos :
- https://video.tedomum.net/api/v1/videos/1025
- https://video.tedomum.net/api/v1/videos/1019
Les identifiants ne ressortent pas dans le retour de commande lors de la migrations vers _garage_ (https://forge.tedomum.net/tedomum/peertube/-/issues/55#note_68693).kaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://forge.tedomum.net/tedomum/maubot_gitlab/-/issues/1Importation de config d'après `base-config.yaml`2023-12-03T09:21:34ZMickGeImportation de config d'après `base-config.yaml`L'idée est d'importer les `templates` depuis le fichier `base-config.yaml` si les données existent, sinon, l'extension de sert des `templates` par défaut.
Actuellement, d'après le commit https://forge.tedomum.net/tedomum/maubot_gitlab/-...L'idée est d'importer les `templates` depuis le fichier `base-config.yaml` si les données existent, sinon, l'extension de sert des `templates` par défaut.
Actuellement, d'après le commit https://forge.tedomum.net/tedomum/maubot_gitlab/-/commit/de3932d4e297b11a07d497ce5285d69d8fe3978f :
- le fichier `gitlab_matrix/util/config.py` lit la variable `message` du fichier `base-config.yaml` comme un dictionnaire ;
- le fichier `gitlab_matrix/util/template.py` crée les fonctions `ConfigTemplateLoader` et `ConfigTemplateManager`
- le fichier `gitlab_matrix/util/__init__.py` importe la fonction `ConfigTemplateManager` ;
- le fichier `gitlab_matrix/webhook.py` import le fonction `ConfigTemplateManager`.
Actuellement, ça ne peut rien faire…
Beaucoup de code vient de là : https://github.com/maubot/github/tree/master/github/webhookhttps://forge.tedomum.net/tedomum/kity/-/issues/17Intégration de stockage flash sur le cluster2023-11-21T20:13:03Zkaiyoupierre@jaury.euIntégration de stockage flash sur le clusterLes événements des dix derniers jours et le début de résolution aujourd'hui l'ont montré de manière assez franche. On posait la question d'acheter maintenant ou pas du flash pour le cluster (on en aura de toute façon besoin plus tard pou...Les événements des dix derniers jours et le début de résolution aujourd'hui l'ont montré de manière assez franche. On posait la question d'acheter maintenant ou pas du flash pour le cluster (on en aura de toute façon besoin plus tard pour le stockage des BDD). Au final, je suis convaincu que même si l'emploi n'est pas nominal dès aujourd'hui, cela reste essentiel pour soutenir les solutions qu'on emploie, en stockage particulièrement, puisqu'on n'en maîtrise pas finement le comportement IO et qu'il faudra de temps en temps absorber la charge le temps d'optimiser.
Bref : il nous faut du flash, il en faut au moins sur chaque noeud qui héberge aujourd'hui du garage et sur chaque noeud qui hébergera demain des BDD. La question c'est combien et comment ? Je propose de poser ce qui est requis d'abord, en intégrant un schema qui offre de la souplesse.
# Volumétries et répartition
On a besoin de deux types de stockage sur les noeuds : du rapide (plutôt basse latence en random que bon débit, même si ça ne fait pas de mal), et du standard (sur lequel on fait peu de random et on peut patienter quelques ms par accès). Résumé autrment : du SSD/NVMe et du rotatif. L'orientation est à placer sur du rapide les conteneurs, possiblement l'OS s'il n'est pas distinct, et les "métadonnées" (les tables de différentes bases, qu'il s'agisse de relationnel, des meta garage, etc.) ; et sur du standard les données objet, les blobs non structurés.
J'ai fait un bilan des volumétries actuelles et de ce qu'on peut raisonnablement projeter par noeud à 3-5 ans (hautement spéculatif, j'ai fait une grosse loi de Moore à 3 ans, soit peu ou prou x3). Pour le stockage distribué ou répliqué, je prends l'hypothèse de 1 standby sur postgres et 3 réplicas sur garage. Tout est projeté sur un cluster à 5 noeuds (on est à 3, 4 prévu, on aura probablement un 5è dans l'intervalle).
Le stockage objet mesuré est la somme des usages actuels qu'on imagine basculer brutalement sur du stockage objet (images 15Go, mastodon 500Go, matrix 600Go, owncloud 100Go, video 250Go, pixelfed 3Go, artifacts 125Go), c'est à dire 1.6To
| Usage | Volumétrie actuelle | Volumétrie projetée | Brut par noeud, rapide | Brut par noeud, standard |
|-------|---------------------|---------------------|------------------------|--------------------------|
| Objets | 1.6To | 5To | 100Go | 3To |
| Bases relationnelles | 650Go | 2To | 800Go | 10Go (wal attendant archive) |
| Dépôts Git | 10Go | 30Go | 1Go | 30Go (aucune idée de comment on répliquera) |
| Mails | 100Go | 300Go | 1Go | 300Go (idem) |
| OS | 20Go | 60Go | 60Go | |
| Hepto | 80Go | 240Go | 240Go | |
| **Total** | | 6To | 1To | 3.5To |
Cela prèche pour disposer au minimum d'un flash de 1To et un rotatif de 4To par noeud qu'on gérerait maintenant dans le cluster. Tout le monde ne sera pas à ce niveau-là immédiatement mais ce n'est pas un problème. Je propose qu'on fixe comme orientation court-moyen terme : mini 4To de stockage dont 500Go de flash, visant 1To de flash par noeud. Le plus simple pour l'implémenter reste de faire 1To SSD + 4To HDD. Lorsqu'on a plus sans effort on peut. Lorsque le packaging oblige à faire un seul support, on peut faire 4To SSD.
# Intégration dans hepto
Un des enjeux reste que le stockage doit être accessible à hepto de manière gérable dans le temps. Jusqu'ici on montait le HDD (seule support dispo) dans `/hdd` dans hepto.
Avec le recul c'est assez mal informé. Le déplacement des metadata garage vers SSD en témoigne. kubernetes supporte assez mal les points de montage non homogènes dans un cluster, surtout quand on fait du `hostPath` dans un `DaemonSet`. En vérité c'est classique de beaucoup de technos donc il faut uniformiser ça. Pour monter les metadata garage, pour le moment on a surchargé le `/hdd/garage/meta`, puisque tout était monté dans `/hdd` initialement.
Il me semble qu'il faut distinguer le besoin de l'implémentation pour avoir un petit peu de souplesse. Ma proposition à ce stade :
- on stocke tout dans `/mnt` dans hepto, `/mnt/data` pour les données non structurées/indexées, et `/mnt/meta` pour les metadonnées indexées qui ont besoin de stockage rapide ;
- on laisse soin à l'hôte d'exposer des points de montage corrects et unifiés (avec LVM ou autre) et de les monter dans hepto
- en cas de HDD + SSD par exemple, on monte le HDD dans `/mnt/data` et le SSD dans `/mnt/meta`
- en cas de gros HDD mais pas encore de SSD, ou de gros SSD qui couvre tout, on le monde dans `/mnt`https://forge.tedomum.net/tedomum/documentation/-/issues/180Authentification Grafana en défaut2023-08-06T20:59:08Zkaiyoupierre@jaury.euAuthentification Grafana en défautDepuis 4 jours l'authentification Grafana est en défaut du fait de la mise à jour vers Grafana 10.
L'issue est suivie upstream sur : https://github.com/grafana/grafana/issues/70203
Globalement : Grafana s'appuie dorénavant sur l'id env...Depuis 4 jours l'authentification Grafana est en défaut du fait de la mise à jour vers Grafana 10.
L'issue est suivie upstream sur : https://github.com/grafana/grafana/issues/70203
Globalement : Grafana s'appuie dorénavant sur l'id envoyé par l'OP et non plus le mail par défaut, sauf que la table des id ne se met pas à jour magiquement, donc ça ne fonctionne plus pour les utilisateurices déjà inscrits. Le problème était global lors de l'update pour tous les déploiements avec SSO.
La solution fournie d'activer `GF_AUTH_OAUTH_ALLOW_INSECURE_EMAIL_LOOKUP` ne semble pas résoudre le problème. C'est documenté dans l'issue comme un bypass temporaire pour fallback sur le mail, ça semble fonctionner avec Keycloak, mais avec nous sur Hiboo.https://forge.tedomum.net/tedomum/documentation/-/issues/179Expiration des comptes et des données2024-01-20T12:02:03Zkaiyoupierre@jaury.euExpiration des comptes et des donnéesC'est un sujet que nous avons évoqué les dernières années en le conservant en dernier recours. Il est revenu récemment sous l'angle de Matrix (https://forge.tedomum.net/tedomum/synapse/-/issues/115), et il continuera de revenir tant que ...C'est un sujet que nous avons évoqué les dernières années en le conservant en dernier recours. Il est revenu récemment sous l'angle de Matrix (https://forge.tedomum.net/tedomum/synapse/-/issues/115), et il continuera de revenir tant que nous sommes de plus en plus gros, même tout doucement : faut-il conserver les comptes inactifs et les données associées ? Le débat est simplement entre la durabilité des données comme un de nos engagements d'hébergeur d'une part ; les performances, le coût des services et le respect le droit à l'oubli d'autre part.
Dans l'échange récent autour de Matrix, le retour général était plutôt pour la suppression, sous des conditions à discuter et à voter. J'ouvre donc ce ticket pour instruire le sujet. Objectif : converger d'ici mi-juillet pour voter les règles de suppression ensuite.
La première proposition est de fonder des règles génériques par familles de données, puis de préciser éventuellement des règles alternatives pour certaines services. Je propose les catégories suivantes, je vous laisse la main pour les premiers échanges sur des durées entendables.
- Les comptes, c'est-à-dire le moyen d'authentification sur TeDomum, principalement via Hiboo. Non utilisé depuis un temps, il est à peu près sûr que l'utilisateurice ne reviendra pas, sans lien spécialement avec les données publiées.
- Les données privées, c'est-à-dire capitalisées sur nos services mais accessibles à personne d'autre que l'utilisateurice ou les personnes avec qui iel aura partagé explicitement, par ex. les données Nextcloud, Vaultwarden, les MP Mastodon, salons privés Matrix, etc.
- Les données publiques « historiques », c'est-à-dire datées et inscrites dans un historique daté, par exemple une timeline Mastodon ou bien un historique de messages sur Matrix sans nécessairement englober le profil intégral ou le salon lui-même.
- Les données publiques structurelles, c'est-à-dire qui fondent un cadre, qui ne périment pas nécessairement car pas datées, par exemple des images uploadées sans savoir à quoi elles servent, un profil sans savoir s'il est consulté, un salon lui-même indépendamment de ses messages.
Chaque catégorie peut concerner des données dont nous sommes le point de référence, d'autres dont nous n'hébergeont qu'un cache, pour les performances ou en cas de défaillance du point de référence. La durée indiquée varie en fonction.
Evidemment, la règle par défaut peut être interprétée en fonction de ce que propose la solution technique. J'essaie d'illustrer par quelques cas de figure. Imaginons que nous indiquions conserver les données historiques jusqu'à X jours après leur publication, et les données structurelles jusqu'à Y jours après leur dernière activité mesurée. Sur Mastodon cela pourrait militer pour supprimer les toots par défaut après X jours, et les profils sans nouveau toot après Y jours. Nous pourrions constater que Mastodon est mauvais pour configurer une suppression par défaut des toots à X jours, et nous nous contenterions de la règle de suppresion des profils par limitation technique.
Appliquée à Matrix, cette même règle indiquerait la suppression par défaut des messages après X jours et des salons inactifs après Y jours. Pour la suppression des messages, nous pourrions configurer une règle de suppression automatique s'appliquant aux nouveaux salons. Nous pourrions aussi considérer que l'approche est inadaptée aux salons Matrix privés qui relèvent des données privées à conservation plus longue, mais ne pas réussir à distinguer les salons privés des autres avec une règle simple.
La discussion est lancée, vous pouvez également venir en parler sur #home:tedomum.net sur Matrix, et je synthétiserai ici.kaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://forge.tedomum.net/tedomum/garage/-/issues/3Lenteurs et timeouts sur le cluster Garage2023-11-21T20:13:14Zkaiyoupierre@jaury.euLenteurs et timeouts sur le cluster GarageDepuis près de deux semaines, nous avons constaté (par remontée utilisateur principalement) des lenteurs et des défauts (erreurs 503 dues à des timeouts) sur le HTTP et sur le S3 de garage (à la fois en récupération et en upload d'image ...Depuis près de deux semaines, nous avons constaté (par remontée utilisateur principalement) des lenteurs et des défauts (erreurs 503 dues à des timeouts) sur le HTTP et sur le S3 de garage (à la fois en récupération et en upload d'image sur Mastodon notamment).
## Perte du noeud bambino
Le premier niveau d'étude du problème a montré que seuls deux noeuds étaient disponibles sur le cluster. Pour cause : le serveur derrière bambino était éteint depuis le 23/06, probablement pour cause de capteur de température (refroidissement passif sur la machine, 34-35°c ambiant).
kubernetes avait pris le relais sur les services, et garage fonctionnait plutôt bien sur 2 noeuds. La machine a été redémarrée le 30/06 à 18h30 CEST, sans problème particulier. Le tranquility garage a été abaissé pour favoriser le resync, qui s'est achevé le 2/07 à 5h30 CEST environ.
## Americancurl en pointillés
La supervision americancurl montre des points de mesure éparses pour Garage mais pas pour le node exporter. Ceci semble indiquer un souci lié au cluster garage, quelle qu'en soit l'origine.
![image](/uploads/8681c6826bbae4b985cbf726cd8f2db4/image.png)
Le noeud montre un fort niveau d'iotime :
![image](/uploads/2b7e0595995bbbdaec9495e5aea38f79/image.png)
Sur des prises de mesure en volume io, pour autant il y a raisonnablement peu de lecture ou écriture, ici sur 5 minutes en accumulé :
![image](/uploads/8948be2311d801e8d8ad1370e50565d8/image.png)
On constate par périodes (toutes les quelques dizaines de secondes) que l'API garage, le S3 et le Web sont incapables de répondre aux requêtes immédiatement depuis ce noeud précisément. Ce qui explique les trous dans les métriques, ainsi que les erreurs continues malgré le retour du cluster à 3 noeuds.
Dans ces cas, les endpoints finissent par répondre, mais avec un délai notable :
```
curl -v > /dev/null 0.16s user 0.05s system 0% cpu 2:03.98 total
curl -v localhost:3903/metrics 0.00s user 0.02s system 0% cpu 1:00.80 total
```
Constaté plusieurs fois avec exactement 2 minutes, ou exactement 1 minute.
Les logs de garage sur le noeud sont évocateurs également : pas d'activité pendant l'attente, puis de nombreuses requêtes loggées immédiatement. Souvent, après l'attente, un warning particulier est loggé :
```
garage 2023-07-02T11:30:44.711211Z WARN garage_api::generic_server: Response: error 500 Internal Server Error, Internal error (Hyper error): error reading a body from connection: Connection reset by peer (os error 104)
```
Après la reprise le trafic est normal quelques dizaines de secondes, et le noeud lance plusieurs resyncs de blocs, avant de planter à nouveau.https://forge.tedomum.net/tedomum/documentation/-/issues/178Gitlab - Fonction Edit > Web IDE HS2023-12-03T12:58:05ZAngedestenebresGitlab - Fonction Edit > Web IDE HSComme dit dans le titre et sur Matrix, il semble que la fonctionnalité ne soit plus utilisable. Testé avec Firefox et Chromium :
![image](/uploads/3d0510325dbf48f6f31bd445082b483e/image.png)
![image](/uploads/ca3a3b8257588daca988acbf91...Comme dit dans le titre et sur Matrix, il semble que la fonctionnalité ne soit plus utilisable. Testé avec Firefox et Chromium :
![image](/uploads/3d0510325dbf48f6f31bd445082b483e/image.png)
![image](/uploads/ca3a3b8257588daca988acbf9171b363/image.png)
A priori, il y a ce ticket côté Gitlab qui ressemble à notre souci : https://gitlab.com/gitlab-org/gitlab/-/issues/413917https://forge.tedomum.net/tedomum/documentation/-/issues/177Mise à jour de Mobilizon vers 3.1.32023-06-23T20:56:02ZMickGeMise à jour de Mobilizon vers 3.1.3Actuellement le build est en cours.Actuellement le build est en cours.MickGeMickGehttps://forge.tedomum.net/tedomum/synapse/-/issues/115Matrix impose une forte charge à Postgres2023-11-19T13:44:33Zkaiyoupierre@jaury.euMatrix impose une forte charge à PostgresPar plusieurs biais, le service Matrix impose une forte charge à Postgres, qui a été jusqu'à bloquer le service pendant une journée du fait d'effets de bord.
Les principaux effets sont (à compléter au fur et à mesure) :
- Le nombre d'u...Par plusieurs biais, le service Matrix impose une forte charge à Postgres, qui a été jusqu'à bloquer le service pendant une journée du fait d'effets de bord.
Les principaux effets sont (à compléter au fur et à mesure) :
- Le nombre d'utilisateurs, de rooms, et le taux d'événements (10/s fédérés) sont dans l'absolu raisonnable mais commencent à coûter à niveau qui justifie de s'intéresser aux performances
- La complexité de certaines rooms (quelques dizaines, soit < 1% des rooms pour l'essentiel de la complexité du serveur) coûte particulièrement dans l'algorithme de gestion d'état, qui requête beaucoup en base et consomme du CPU en cas de recalcul d'état
- La suppression et le nettoyage continu du serveur (synatainer), en particulier de grosses rooms, génère des requêtes particulièrement longues en DELETE, qui remplissent le wal, s'exécutent sur plusieurs heures ou jours, et imposent des locks sur des centaines de milliers de lignes
- Matrix media repo (mmr) accumule des media depuis plusieurs années sans aucun garbage collecting, ce qui remplit des tables et des index en plus du S3
- mmr a un processus de garbage collection qui liste les media un par un par des SELECT individuels, chargeant un CPU du serveur à 100% pour postgres
Le dernier incident a été en particulier provoqué par les `DELETE` générés par synatainer. Ils ont deux effets délétères principalement : 1. ils consomment des threads du threadpool d'accès à la base, et ralentissent doucement le serveur en causant des temps d'attente de thread bdd disponible puisque plus rares 2. ils s'étendent sur long en posant des locks sur des lignes, bloquant d'autres transactions.
Ce dernier cas a causé le blocage du script de migration de synapse à la mise à jour ce matin. Le `DELETE` s'est poursuivi pendant l'upgrade, synapse en redémarrant a tenté un `ALTER TABLE` sur la table lockée, bloqué par le `DELETE` en cours depuis 3 jours, et synapse n'a pas démarré du fait de la migration bloquée.
En attendant d'avoir amélioré suffisamment la situation, il est possible de redémarrer postgres à tout moment sur le serveur sans effet majeur sur les applications :
```
cd /srv/core/db
docker-compose restart pg
```