TeDomum issueshttps://git.tedomum.net/groups/tedomum/-/issues2024-01-18T22:27:16Zhttps://git.tedomum.net/tedomum/element/-/issues/59Mise à jour vers v1.11.532024-01-18T22:27:16ZMickGeMise à jour vers v1.11.53Le build est fait.
Je veux avoir la confirmation de devoir faire la modification dans la configuration de _kitty_, puis :
```bash
flux -n kube-ops reconcile kustomization flux --with-source
```Le build est fait.
Je veux avoir la confirmation de devoir faire la modification dans la configuration de _kitty_, puis :
```bash
flux -n kube-ops reconcile kustomization flux --with-source
```MickGeMickGehttps://git.tedomum.net/tedomum/peertube/-/issues/62v6.0.3 à installer2024-01-18T21:38:08ZAngedestenebresv6.0.3 à installerVoir: https://github.com/Chocobozzz/PeerTube/releasesVoir: https://github.com/Chocobozzz/PeerTube/releaseshttps://git.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://git.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://git.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://git.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://git.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://git.tedomum.net/tedomum/synapse/-/issues/114Migrer les assets Matrix vers garage2023-11-21T20:12:46Zkaiyoupierre@jaury.euMigrer les assets Matrix vers garageA attendre quelques jours qu'on ait bien stabilisé le synapse.A attendre quelques jours qu'on ait bien stabilisé le synapse.kaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://git.tedomum.net/tedomum/kity/-/issues/15Préparer un noeud chez kaiyou-bis2023-11-21T20:12:29Zkaiyoupierre@jaury.euPréparer un noeud chez kaiyou-bis- [x] Trouver une machine
- [x] Acheter ou trouver du stockage
- [x] Confirmer la disponibilité de la fibre
- [x] Confirmer la disponibilité IPv6
- [x] Déployer le noeud- [x] Trouver une machine
- [x] Acheter ou trouver du stockage
- [x] Confirmer la disponibilité de la fibre
- [x] Confirmer la disponibilité IPv6
- [x] Déployer le noeudkaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://git.tedomum.net/tedomum/kity/-/issues/13Runner Gitlab sur Kity2023-11-21T20:12:27Zkaiyoupierre@jaury.euRunner Gitlab sur KityJae Lo PrestiJae Lo Prestihttps://git.tedomum.net/tedomum/kity/-/issues/12Nouvelle version d'element ne run pas2023-11-21T20:12:18ZayinihoNouvelle version d'element ne run pasDepuis la v1.11.3, kity ne parvient pas à faire tourner nos nouvelles version d'element. Nous n'avons rien changé sur notre dépôt, ni rien côté config helm/kity.
Je joins les logs kubectl logs et describe.
[kubectl_logs.txt](/uploads/739...Depuis la v1.11.3, kity ne parvient pas à faire tourner nos nouvelles version d'element. Nous n'avons rien changé sur notre dépôt, ni rien côté config helm/kity.
Je joins les logs kubectl logs et describe.
[kubectl_logs.txt](/uploads/73992c54de328c69fcbd1855bac2b6c7/kubectl_logs.txt)
[kubectl_describe.txt](/uploads/1b730210c39819a54c365ed6ff258f37/kubectl_describe.txt)kaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://git.tedomum.net/tedomum/synapse/-/issues/110Suppression du `keyserver_warning`2023-11-21T20:12:11ZMickGeSuppression du `keyserver_warning`Le log de `matrix_synapse_1` renvoie :
```shell
Starting synapse with args -m synapse.app.homeserver --config-path /data/homeserver.yaml
This server is configured to use 'matrix.org' as its trusted key server via the
'trusted_key_server...Le log de `matrix_synapse_1` renvoie :
```shell
Starting synapse with args -m synapse.app.homeserver --config-path /data/homeserver.yaml
This server is configured to use 'matrix.org' as its trusted key server via the
'trusted_key_servers' config option. 'matrix.org' is a good choice for a key
server since it is long-lived, stable and trusted. However, some admins may
wish to use another server for this purpose.
To suppress this warning and continue using 'matrix.org', admins should set
'suppress_key_server_warning' to 'true' in homeserver.yaml.
```kaiyoupierre@jaury.eukaiyoupierre@jaury.euhttps://git.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://git.tedomum.net/tedomum/www/-/issues/33Ajouter une synthèse des commandes de garage dans kubectl2023-11-11T08:19:55ZMickGeAjouter une synthèse des commandes de garage dans kubectl# Synthèse des commandes de `garage` dans `kubectl`
```shell
alias garage='kubectl -n storage-object exec svc/garage -- ./garage'
```
## Actions sur les buckets
### Obtenir de l'aide
```shell
garage bucket --help
```
### Créer un bu...# Synthèse des commandes de `garage` dans `kubectl`
```shell
alias garage='kubectl -n storage-object exec svc/garage -- ./garage'
```
## Actions sur les buckets
### Obtenir de l'aide
```shell
garage bucket --help
```
### Créer un bucket
```shell
garage bucket create <bucket_name>
```
### Lister les buckets
```shell
garage bucket list
```
### Infos d'un bucket
```shell
garage bucket info <bucket_name>
```
### Supprimer un bucket
```shell
garage bucket delete <bucket_name> --yes
```
## Actions sur les clés
### Obtenir de l'aide
```shell
garage key --help
```
### Créer une clé
```shell
garage key new --name <key_name>
```
### Donner les droits de lecture et écriture à la clé
```shell
garage bucket allow <bucket_name> --read --write --key <key_name>
```
### Lister les clés
```shell
garage key list
```
### Supprimer une clé
```shell
garage key delete <key_name> --yes
```https://git.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.euhttps://git.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://git.tedomum.net/tedomum/element/-/issues/58[SSO][Element] Redirection en 404 sur matrix.tedomum.net2023-07-15T10:12:26Zreminec[SSO][Element] Redirection en 404 sur matrix.tedomum.net### Problème :
Lorsqu'on se connecte via le SSO hiboo sur element.tedomum.net, on est redirigé vers une page en 404 sur le domaine matrix.tedomum.net.
### Quickfix :
Retourner sur element.tedomum.net et me voilà authentifié.
_De mém...### Problème :
Lorsqu'on se connecte via le SSO hiboo sur element.tedomum.net, on est redirigé vers une page en 404 sur le domaine matrix.tedomum.net.
### Quickfix :
Retourner sur element.tedomum.net et me voilà authentifié.
_De mémoire on en a causé, c'est un coup je duplique une issue déjà existante :/_https://git.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://git.tedomum.net/tedomum/mastodon/-/issues/46Problème de création de compte2023-04-04T19:51:14ZMickGeProblème de création de compteLe lien <https://mastodon.tedomum.net/auth/sign_up> renvoie une redirection (code 302).Le lien <https://mastodon.tedomum.net/auth/sign_up> renvoie une redirection (code 302).https://git.tedomum.net/tedomum/documentation/-/issues/171Uniformiser le local et le dépôt2023-02-07T21:58:07ZMickGeUniformiser le local et le dépôt```shell
git status
```
```txt
On branch master
Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
(use "git pull" to update your local branch)
Changes not staged for commit:
(use "git add <file>..." to u...```shell
git status
```
```txt
On branch master
Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
(use "git pull" to update your local branch)
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: bridges/docker-compose.yml
modified: dns1/docker-compose.yml
modified: feeds/docker-compose.yml
modified: lemmy/docker-compose.yml
modified: mastodon/docker-compose.yml
modified: ../core/front/traefik.toml
modified: ../users/pandore/docker-compose.yml
Untracked files:
(use "git add <file>..." to include in what will be committed)
matrix/maubot/
matrix/missing_prev_events.txt
matrix/missing_prev_events2.txt
matrix/synatainer.conf
no changes added to commit (use "git add" and/or "git commit -a")
```kaiyoupierre@jaury.eukaiyoupierre@jaury.eu