TeDomum issueshttps://forge.tedomum.net/groups/tedomum/-/issues2024-01-20T12:01:56Zhttps://forge.tedomum.net/tedomum/synapse/-/issues/116Plus de 50Hz de EDU chargent le CPU2024-01-20T12:01:56Zkaiyoupierre@jaury.euPlus de 50Hz de EDU chargent le CPUDepuis le 1/08 à 14h, le taux d'EDU reçus en fédération sur notre HS a été multiplié par plus de 6 jusqu'à 60Hz et impose une forte charge CPU à la machine, qui peine à traiter le flux. En conséquence les messages en envoi et réception s...Depuis le 1/08 à 14h, le taux d'EDU reçus en fédération sur notre HS a été multiplié par plus de 6 jusqu'à 60Hz et impose une forte charge CPU à la machine, qui peine à traiter le flux. En conséquence les messages en envoi et réception sont passés d'un délai d'intégration moyen de 200ms à 5s et plus.
![image](/uploads/f5e825c44f8425d2809ecb4955e8d8de/image.png)
![image](/uploads/e4f76305c0a1bca9a037efdb588627ee/image.png)
C'est le `FederationSendServlet` (contre-intuitif, il gère la réception) qui est en cause.
![image](/uploads/ee4d3961d8f7bfc8a838bad87735edc8/image.png)
![image](/uploads/34d4f4d8d091da3e895af3f4e46cc775/image.png)
Il s'agit bien d'EDU entrants
![image](/uploads/9bd17cac0d4f8f53972df8a3b5f16ac0/image.png)
Il s'agit probablement d'un salon dont on fait partie et pour lequel un HS nous bombarde d'EDU, probablement même pas de façon malveillante.
Pour identifier, je propose un premier tour des salons de support collectifs d'admins de HS savoir si on est les seuls, ainsi peut-être que les issues Github de synapse. Si rien ne ressort, comme les EDU ne sont pas persistés, il faudra peut-être travailler soit avec les logs, soit en réactivant OpenTracing pour synapse et en analysant les traces sur le path des EDU.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
```https://forge.tedomum.net/tedomum/nextcloud/-/issues/450Bug édition fichiers .ods dans Nextcloud2023-06-19T21:50:25ZlamadesboisBug édition fichiers .ods dans NextcloudBonjour,
Dans l'inteface d'arborescence de fichiers de Nextcloud, à la création ou l'ouverture d'un fichier .ods , un onglet s'ouvre mais n'affiche rien (Firefox 114.01 et Chromium 114).
Voilà l'extrait de rapport de console après avoi...Bonjour,
Dans l'inteface d'arborescence de fichiers de Nextcloud, à la création ou l'ouverture d'un fichier .ods , un onglet s'ouvre mais n'affiche rien (Firefox 114.01 et Chromium 114).
Voilà l'extrait de rapport de console après avoir cliqué sur le fichier.
Je suis nouveau sur TeDomum, et mon asso et moi sommes ravis que vous nous permettiez d'accéder à tout ça :smile:
N'hésitez pas à me guider si ce n'était pas ici qu'il fallait rapporter ce bug.
> session heartbeat polling started session-heartbeat.js:103:9
No new notification data received NotificationsApp.vue:381
Polling interval updated to 30000 NotificationsApp.vue:413
FAILED Office.vue:205
loadingTimeout Office.vue:205
(Asynchrone : setTimeout handler)
n Office.vue:204
c Office.vue:74
v Office.vue:74
b Office.vue:74
ve Office.vue:74
o Office.vue:74
Te Office.vue:74
Te Office.vue:74
load Office.vue:208
t Office.vue:190
c Office.vue:74
v Office.vue:74
b Office.vue:74
ve Office.vue:74
o Office.vue:74
(Asynchrone : promise callback)
ve Office.vue:74
o Office.vue:74
(Asynchrone : promise callback)
ve Office.vue:74
o Office.vue:74
Te Office.vue:74
Te Office.vue:74
mounted Office.vue:190
VueJS 19
o Viewer.vue:540
d runtime.js:24
t runtime.js:267
O runtime.js:85
Hm Pencil.vue:19
a Pencil.vue:19
You need to fill either the text or the ariaLabel props in the button component.
Object { text: undefined, ariaLabel: null }
Object { _uid: 32, _isVue: true, __v_skip: true, _scope: {…}, "$options": {…}, _renderProxy: {…}, _self: {…}, "$parent": {…}, "$root": {…}, "$children": [], … }
"$attrs":
"$children": Array []
"$createElement": function $createElement(t, n, r, o)
"$el": <button class="button-vue button-vue--i…tem action-item--single" data-v-4de3abc4="" data-v-0430dd54="" data-v-24c3da0d="" type="button">
"$listeners":
"$options": Object { parent: {…}, _parentVnode: {…}, _componentTag: "NcButton", … }
"$parent": Object { _uid: 31, _isVue: true, __v_skip: true, … }
"$refs": Object { }
"$root": Object { _uid: 1, _isVue: true, __v_skip: true, … }
"$scopedSlots": Object { icon: on()
, … }
"$slots": Object { icon: (1) […] }
"$vnode": Object { tag: "vue-component-29-NcButton", data: {…}, children: undefined, … }
__v_skip: true
_c: function _c(t, n, r, o)
_computedWatchers: Object { "$asyncComputed": {…}, rootElement: {…} }
_data: Object { _asyncComputed: Getter & Setter, … }
_directInactive: false
_events: Object { focus: (1) […], blur: (1) […], click: (1) […] }
_hasHookEvent: false
_inactive: null
_isBeingDestroyed: false
_isDestroyed: false
_isMounted: true
_isVue: true
_props: Object { disabled: Getter & Setter, type: Getter & Setter, nativeType: Getter & Setter, … }
_provided: Object { }
_renderProxy: Object { _uid: 32, _isVue: true, __v_skip: true, … }
_scope: Object { detached: true, active: true, _vm: true, … }
_self: Object { _uid: 32, _isVue: true, __v_skip: true, … }
_staticTrees: null
_uid: 32
_vnode: Object { tag: "button", data: {…}, children: (1) […], … }
_watcher: Object { deep: false, user: false, lazy: false, … }
t: BoundFunctionObject { … }
<get $attrs()>: function get()
<set $attrs()>: function set(t)
<get $listeners()>: function get()
<set $listeners()>: function set(t)
<prototype>: Object { constructor: a(e)
, disabled: Getter & Setter, type: Getter & Setter, … }
index.module.js:2:807410https://forge.tedomum.net/tedomum/kity/-/issues/16Héberger RSS-Bridge2023-06-09T20:03:13ZMickGeHéberger RSS-BridgeVoir pour héberger [RSS-Bridge](https://rss-bridge.github.io/rss-bridge/index.html) comme https://rss-bridge.sans-nuage.fr/.
L'intérêt est notamment de suivre les déploiement d'image.
<details>
<summary>Code pour lister tous les brigde...Voir pour héberger [RSS-Bridge](https://rss-bridge.github.io/rss-bridge/index.html) comme https://rss-bridge.sans-nuage.fr/.
L'intérêt est notamment de suivre les déploiement d'image.
<details>
<summary>Code pour lister tous les brigdes disponibles</summary>
<div>Depuis la page <a href="https://github.com/RSS-Bridge/rss-bridge/tree/master/bridges">rss-bridgebridges at master · RSS-Bridgerss-bridge</a> entrer le code suivant la console du navigateur :</div>
<pre>
{
const titles = Array.from(document.querySelectorAll('.Link--primary[aria-describedby^="item-type"]')).map(el => el.textContent.split('.')[0]).join('\n');
alert(titles);
}
</pre>
<div>Faire le tri dans le résultat pour les bridges à entrer dans le fichier <code>whitelist.txt</code> du dossier <code>/config/</code>.</div>
</detailshttps://forge.tedomum.net/tedomum/mailu/-/issues/33Mise à jour vers v22023-11-21T20:13:26ZMickGeMise à jour vers v2<https://mailu.io/master/releases.html#mailu-2-0-2023-04-03><https://mailu.io/master/releases.html#mailu-2-0-2023-04-03>kaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://forge.tedomum.net/tedomum/pixelfed/-/issues/29Mise à jour vers v0.11.82023-05-31T21:00:00ZMickGeMise à jour vers v0.11.8__Le commit est fait.__
Pour le moment, le build ne passe pas pour une histoire de secret…
```console
ERROR: Job failed (system failure): prepare environment: setting up credentials: secrets is forbidden: User "system:serviceaccount:te...__Le commit est fait.__
Pour le moment, le build ne passe pas pour une histoire de secret…
```console
ERROR: Job failed (system failure): prepare environment: setting up credentials: secrets is forbidden: User "system:serviceaccount:tedomum-runner:runner-gitlab-runner" cannot create resource "secrets" in API group "" in the namespace "tedomum-runner". Check https://docs.gitlab.com/runner/shells/index.html#shell-profile-loading for more information
```
Tag : `v0.11.7+tedomum.1`.https://forge.tedomum.net/tedomum/documentation/-/issues/176Fixer le docker-compose de Forge2023-06-19T19:02:49ZMickGeFixer le docker-compose de ForgeJ'ai commenté la ligne `- ./conf:/etc/ssh:ro` dans le `docker-compose.yml` sans quoi _GitLab_ n'était pas content depuis la mise à jour 16.J'ai commenté la ligne `- ./conf:/etc/ssh:ro` dans le `docker-compose.yml` sans quoi _GitLab_ n'était pas content depuis la mise à jour 16.https://forge.tedomum.net/tedomum/mobilizon/-/issues/14Mise à jour vers la 3.1.02023-06-01T19:53:45ZMickGeMise à jour vers la 3.1.0Le _build_ est actuellement en-cours…Le _build_ est actuellement en-cours…https://forge.tedomum.net/tedomum/etherpad/-/issues/8Upgrade to 1.8.182023-04-23T13:17:44ZMickGeUpgrade to 1.8.18Pour faire la mise à jour, il faut faire le changement dans la base de données.
L'image est plus ou moins prête, il y a un problème de db.
```console
# mysql -u <user> -p
Enter password:
Welcome to the MariaDB monitor. Commands end...Pour faire la mise à jour, il faut faire le changement dans la base de données.
L'image est plus ou moins prête, il y a un problème de db.
```console
# mysql -u <user> -p
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 17
Server version: 10.11.2-MariaDB-1:10.11.2+maria~ubu2204-log mariadb.org binary distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> SHOW SESSION VARIABLES LIKE 'character\_set\_%';
+--------------------------+---------+
| Variable_name | Value |
+--------------------------+---------+
| character_set_client | utf8mb3 |
| character_set_connection | utf8mb3 |
| character_set_database | utf8mb4 |
| character_set_filesystem | binary |
| character_set_results | utf8mb3 |
| character_set_server | utf8mb4 |
| character_set_system | utf8mb3 |
+--------------------------+---------+
7 rows in set (0.006 sec)
MariaDB [(none)]> SHOW SESSION VARIABLES LIKE 'collation_connection';
+----------------------+--------------------+
| Variable_name | Value |
+----------------------+--------------------+
| collation_connection | utf8mb3_general_ci |
+----------------------+--------------------+
1 row in set (0.001 sec)
MariaDB [(none)]> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| etherpad |
| information_schema |
+--------------------+
2 rows in set (0.002 sec)
```
- [docker version of 1.8.18 is failing, 1.8.17 is working fine · Issue 5551 · etheretherpad-lite](https://github.com/ether/etherpad-lite/issues/5551)
- [Consider MySQL UTF8 issues · Issue 2516 · etheretherpad-lite](https://github.com/ether/etherpad-lite/issues/2516#issuecomment-79659984-permalink)
- [MySQL MySQL 8.0 Reference Manual 10.4 Connection Character Sets and Collations](https://dev.mysql.com/doc/refman/8.0/en/charset-connection.html)MickGeMickGehttps://forge.tedomum.net/tedomum/bitwarden_rs/-/issues/16Paramétrage du MFA à base de clé OTP Yubikey2023-04-20T04:49:16ZMickGeParamétrage du MFA à base de clé OTP Yubikey_Demande d'activation par e-mail._
Documentation : [Enabling Yubikey OTP authentication · dani-garciavaultwarden Wiki](https://github.com/dani-garcia/vaultwarden/wiki/Enabling-Yubikey-OTP-authentication).
Seul bémol, il faut être en po..._Demande d'activation par e-mail._
Documentation : [Enabling Yubikey OTP authentication · dani-garciavaultwarden Wiki](https://github.com/dani-garcia/vaultwarden/wiki/Enabling-Yubikey-OTP-authentication).
Seul bémol, il faut être en possession d'une clé Yubikey pour obtenir `YUBICO_CLIENT_ID` et `YUBICO_SECRET_KEY`.HalfaHalfahttps://forge.tedomum.net/tedomum/documentation/-/issues/175Script pour lister les thèmes WP2023-10-23T16:49:29ZMickGeScript pour lister les thèmes WPOne liner par kaiyou :
```shell
read -s MYSQL_PASSWORD; for blog in $(docker-compose exec db mysql -u blogs -p$MYSQL_PASSWORD -A blogs -B -N -e 'select TABLE_NAME from INFORMATION_SCHEMA.TABLES where TABLE_NAME like "wp_%_options" AND T...One liner par kaiyou :
```shell
read -s MYSQL_PASSWORD; for blog in $(docker-compose exec db mysql -u blogs -p$MYSQL_PASSWORD -A blogs -B -N -e 'select TABLE_NAME from INFORMATION_SCHEMA.TABLES where TABLE_NAME like "wp_%_options" AND TABLE_SCHEMA="blogs";'); do echo $blog; docker-compose exec db mysql -u blogs -p$MYSQL_PASSWORD -A blogs -N -e "select * from $blog where option_name='current_theme' or option_name='blogname';" ; done
```kaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://forge.tedomum.net/tedomum/www/-/issues/39Mise à jour de GitLab2023-05-07T08:55:52ZMickGeMise à jour de GitLabMettre à jour la documentation pour préciser de vérifier la page <https://forge.tedomum.net/admin/jobs> avant de lancer la mise à jour.
Le but étant d'éviter d'interrompre un travail.Mettre à jour la documentation pour préciser de vérifier la page <https://forge.tedomum.net/admin/jobs> avant de lancer la mise à jour.
Le but étant d'éviter d'interrompre un travail.kaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://forge.tedomum.net/tedomum/documentation/-/issues/174Documenter le renouvellement des certificats tls avec Traefik2023-11-11T08:15:53ZMickGeDocumenter le renouvellement des certificats tls avec TraefikExplication de kaiyou :
> On a deux modes très différents de gestion des certifs entre Kity et Aegir. Sur Kity on a bien traefik en reverse proxy mais les certificats sont gérés par cert-manager, avec une configuration assez tunable don...Explication de kaiyou :
> On a deux modes très différents de gestion des certifs entre Kity et Aegir. Sur Kity on a bien traefik en reverse proxy mais les certificats sont gérés par cert-manager, avec une configuration assez tunable donc pas de souci.
>
> Sur aegir on a traefik qui fait les deux. Sauf qu'on utilise encore traefik v1, qui était très pauvre en configuration letsencrypt. Notamment letsencrypt accepte des vérifications principalement en callback http(s) (modes http et tls) et en dns avec des record txt à setup. Le http est bien pour les domaines qu'on héberge en général mais il ne fonctionne pas pour les wildcard (le *.tedomum.net, *.blogs.tedomum.net et *.tedomum.org principalement). Le DNS est top pour les wildcard et marche pour tout tant que les domaines sont hébergés chez nous. C'est le cas de 80% de ce qu'on a mais pas de certains blogs par exemple qui pointent vers le WordPress sans mettre le DNS chez nous.
>
> Le problème principal de traefik v1 c'est qu'il ne permet pas de configurer quel mode utiliser en fonction du domaine donc c'est soit tout l'un soit tout l'autre.
>
> Si on mettait tout DNS ça excluerait des blogs WordPress c'est nul, j'avais un peu milité pour diminuer l'emploi de WordPress à un moment mais c'est pas la bonne voie. On pourrait mettre tout http mais ça fait générer beaucoup de certifs en tedomum.net ce qui nous a coûté plusieurs fois de taper les rate limits de letsencrypt, d'autant plus que traefik génère à la vollée quand ça matche un wildcard, ce qui devient drôle quand un bot scanne nos domaines.
>
> Tout ça pour dire qu'il y a deux façons de s'en sortir : upgrade sur traefik v2 qui est plus avancé mais ça prend du temps qu'on n'a toujours pas pris surtout que indispo notable dans l'équation. Ou bien jouer avec la configuration traefik pour basculer d'un mode à l'autre de temps en temps. Les certifs durent 3 mois donc globalement quand on en voit qui approchent parce qu'ils sont gérés en mode http alors qu'on est en dns, on bascule en http, et vice versa.
>
> Cette bascule se gère trivialement mais salement en modifiant la conf traefik sur le serveur, en commentant et decommentant les bonnes lignes et en faisant un restart de traefik. Le restart coupe les connexions en cours pendant 5 secondes environ, l'impact est négligeable même si ça se voit quand on est les yeux rivés sur un client Matrix par exemple.
>
> Tout cela est complété par ce qu'on fait pour Gitlab pages : il gère lui même son reverse proxy et ses certificats, sauf pour le wildcard *.tedomum.org qu'il n'a aucun moyen de gérer. Pour ce dernier, cf. les sujets d'il y a deux semaines, on fait une copie manuelle du certificat généré par traefik à intervalles de trois mois.
> La section précise dans le traefik.toml :
>
> ```toml
> #[acme.tlsChallenge]
>
> [acme.dnsChallenge]
> provider = "pdns"
> ```
> Donc tantôt on commente la première tantôt les deux suivantes.
>
> Donc pour expliquer le souci pour les domaines de crypte-0n là : on est en mode DNS donc traefik gère bien tous les domaines donc le DNS est chez nous, ce qui n'est pas le cas du DNS de crypt-0n.
>
> Les actions simples pour basculer :
> 1. Uncomment et comment dans le `traefik.toml`
> 2. Restart le service `traefik`
Le restart du service se fait avec un `docker-compose down && docker-compose up -d`.
---
Commande pour vérifier les dates de certificats :
```shell
DOMAIN=<domain_name> ; echo | openssl s_client -servername "$DOMAIN" -connect "$DOMAIN":443 2>/dev/null | openssl x509 -noout -enddate
```
_Où <domain_name> est le nom de domaine !_kaiyoupierre@jaury.eukaiyoupierre@jaury.eu