Les 50 derniers événements¶

2025-11-20¶

10:00 - Problème d'accès à Portainer sur yunohost-cywise - again

Concerns

Resource - server - yunohost-cywise

Cyrille n'accède plus à Portainer à nouveau.

Je me rends compte que Docker est revenu à la version 29.0.0 (j'avais oublié de le bloquer sur la version 28.5.2).

Je remets Docker 28.5.2 et ça résout le problème.

Et, cette fois, je bloque Docker sur la version 28.5.2 :

sudo apt-mark hold docker-ce docker-ce-cli

10:45 - Erreur à la publication de Cywise PROD sur yunohost-cywise - Docker version

Concerns

Resource - server - yunohost-cywise

Cyrille n'arrive pas à déployer Cywise PROD.

L'erreur, visible dans Jenkins, est liée à une tentative de mettre à jour Docker alors que j'ai bloqué la version.

C'est le process usuel de YunoHost : définition des apt nécessaires à l'app YunoHost -> en cas de mise à jour de l'app, installation des apt nécessaires. Dans notre cas, docker-ce fait partie des apt nécessaires (puisque nous déployons une stack) d'où la mise à jour...

Je ne vois pas ce que je peux faire contre ça (sauf à faire une usine à gaz) donc je viens de débloquer la version de Docker qui va repasser en 29.0 durant la MEP que je viens de lancer.

Déblocage de la version de Docker avec :

sudo apt-mark unhold docker-ce docker-ce-cli

La MEP provoque le passage à Docker 29.0.0 comme prévu et je remets Portainer en version 2.20.2 pour qu'il fonctionne.

14:00 - Plantage apt-get update sur yunohost-cywise dû à Yarn - Résolu

Concerns

Resource - server - yunohost-cywise

J'ai enlevé le commentaire que j'avais mis dans le fichier /etc/apt/sources.list.d/yarn.list sur le serveur yunohost-cywise.

deb [signed-by=/etc/apt/trusted.gpg.d/yarn.gpg] https://dl.yarnpkg.com/debian/ stable main

sudo apt-get update passe sans problème maintenant. Problème résolu.

2025-11-19¶

09:30 - Cywise PROD - Plus d'envoi des mails avec les rapports d'audit - suite

Concerns

Resource - server - yunohost-cywise

Les mails "Rapport d'audit" sont partis ce matin.

2025-11-18¶

08:40 - Superset - Plus d'exécution des requêtes dans SQL Lab

Concerns

Resource - server - yunohost-cywise

Cyrille n'arrive plus à exécuter des requêtes SQL dans SQL Lab de Superset.

Je vois des erreurs dans les logs du Worker (les requêtes sont sous-traitées au worker). Je redémarre le worker mais ça ne résout pas le problème. Le problème a l'air lié à la table où superset stocke les requêtes a exécuter. Le worker doit les retrouver dans cette table mais il fait une erreur (du genre, l'enregistrement a changé...). J'ai vidé cette table pour voir (10 requêtes dedans) mais le problème persiste.

La version de Superset n'a pas changé. La version de MariaDB non plus. Donc le plus probable est que ce soit un bug de Docker 29.0.0. mais je n'en suis pas sûr.

J'ai contourné le problème en modifiant une option dans Superset pour que les requêtes s'exécutent dans le container de Superset et non plus dans le worker.

Et ça résout le problème.

09:30 - Cywise PROD - Plus d'envoi des mails avec les rapports d'audit.

Concerns

Resource - server - yunohost-cywise

Nous nous rendons compte que les mails "Rapport d'audit" ne sont plus envoyés par Cywise.

Peut-être Docker 29.0.0, peut-être pas...

Le container queue-critical a bien traité des Jobs d'envoi de rapport le 10/11 mais aucun le 11/11. J'en trouve le 10/11 7h, le 12/11 16h, le 16/11 0h.

Je mets de côté pour l'instant.

14:00 - Plantage apt-get update sur yunohost-cywise dû à Yarn

Concerns

Resource - server - yunohost-cywise

En réactivant MariaDB Tools, une autre repo fait planter la commande :

twr_admin@apps:~$ sudo apt-get update
Hit:1 http://mirrors.online.net/debian bookworm InRelease
Hit:3 http://security.debian.org/debian-security bookworm-security InRelease                                                                                                                 
Ign:5 https://dl.yarnpkg.com/debian stable InRelease                                                                                                                                         
Hit:6 https://packages.sury.org/php bookworm InRelease                                                                                                                                       
Hit:2 https://forge.yunohost.org/debian bookworm InRelease                                                                             
Hit:4 https://downloads.mariadb.com/Tools/debian bookworm InRelease
Hit:7 https://dlm.mariadb.com/repo/mariadb-server/11.8/repo/debian bookworm InRelease
Get:8 https://dlm.mariadb.com/repo/maxscale/latest/apt bookworm InRelease [11.6 kB]
Ign:5 https://dl.yarnpkg.com/debian stable InRelease
Ign:5 https://dl.yarnpkg.com/debian stable InRelease
Err:5 https://dl.yarnpkg.com/debian stable InRelease                                                                                                                                         
  500  Internal Server Error [IP: 2606:4700::6810:a978 443]
Fetched 11.6 kB in 7s (1,631 B/s)                                                                                                                                                            
Reading package lists... Done
W: Failed to fetch https://dl.yarnpkg.com/debian/dists/stable/InRelease  500  Internal Server Error [IP: 2606:4700::6810:a978 443]
W: Some index files failed to download. They have been ignored, or old ones used instead.

J'ai vérifié que l'erreur 500 se produisait aussi avec l'IP v4 et c'était le cas.

Pour contourner le problème, j'ai commenté la ligne suivante dans le fichier /etc/apt/sources.list.d/yarn.list sur le serveur yunohost-cywise :

### Patrick 2025-11-18 - Commented to avoid this error with apt-get update:
### Ign:5 https://dl.yarnpkg.com/debian stable InRelease
### Ign:5 https://dl.yarnpkg.com/debian stable InRelease
### Err:5 https://dl.yarnpkg.com/debian stable InRelease                                                                                                                                     >
###   500  Internal Server Error [IP: 2606:4700::6810:a978 443]
### Fetched 11.6 kB in 7s (1,631 B/s)                                                                                                                                                        >
### Reading package lists... Done
### W: Failed to fetch https://dl.yarnpkg.com/debian/dists/stable/InRelease  500  Internal Server Error [IP: 2606:4700::6810:a978 443]
### W: Some index files failed to download. They have been ignored, or old ones used instead.
#deb [signed-by=/etc/apt/trusted.gpg.d/yarn.gpg] https://dl.yarnpkg.com/debian/ stable main

14:00 - Plantage apt-get update sur yunohost-cywise dû à MariaDB Tools - Résolu

Concerns

Resource - server - yunohost-cywise

J'ai décommenté la ligne de la repo "Tools" de MariaDB dans

14:15 - Retour à Docker 29.0.0 sur yunohost-cywise

Concerns

Resource - server - yunohost-cywise

Le problème de Portainer est dû à Docker 29.0.0 (contourné) le problème des mails d'audit l'est peut-être aussi.

Je décide de revenir à Docker 28.5.2.

Ce n'était pas aussi simple que prévu car Docker 28.5.2 n'est pas disponible dans les dépôts officiels de Debian. J'ai donc mis en place le dépôt officiel de Docker pour Debian et j'ai installé Docker 28.5.2 depuis ce dépôt.

Voir https://docs.docker.com/engine/install/debian/#install-using-the-repository.

# Add Docker's official GPG key:
sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update

Puis j'ai installé Docker 28.5.2 :

sudo systemctl stop docker

sudo apt install docker-ce=5:28.5.2-1~debian.12~bookworm \
                docker-ce-cli=5:28.5.2-1~debian.12~bookworm \
                containerd.io

sudo systemctl start docker
sudo systemctl enable docker

Et j'ai remis la version de Portainer comme avant (2.21.5) en modifiant le fichier /home/yunohost.app/portainer/docker-compose.yaml.

2025-11-17¶

09:45 - Problème d'accès à Portainer sur yunohost-cywise

Concerns

Resource - server - yunohost-cywise

Cyrille n'accède plus à Portainer et moi non plus. L'environnement Docker local est noté "Up" mais passe à "Down" dès qu'on clique dessus.

C'est un problème Portainer connu avec Docker 29.0.0. 2 solutions : revenir à Docker 28.5.2 ou revenir à Portainer 2.20.2.

Je ne suis pas très chaud pour revenir à la version précédente de Docker donc je choisis de revenir à Portainer 2.20.2 en modifiant le fichier /home/yunohost.app/portainer/docker-compose.yaml ce qui résout le problème (Portainer est à nouveau opérationnel).

13:00 - Problème de certificat SSL pour www.cywise.io

Concerns

Resource - server - yunohost-cywise

Pierre nous a prévenu le 16/11 vers 21h45 que le certificat SSL de www.cywise.io avait expiré.

Mon navigateur m'avertit aussi quand je vais sur www.cywise.io mais pas quand je vais sur app.cywise.io. app.cywise.io pointe vers notre application Cywise de PROD. www.cywise.io pointe vers l'application de redirection vers app.cywise.io.

YunoHost dit que le certificat est valide pendant encore 73 jours :

twr_admin@apps:~$ sudo yunohost domain cert status www.cywise.io 
certificates: 
  www.cywise.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 73

J'ai redémarré nginx pour que le certificat soit bien pris en compte :

sudo systemctl restart nginx

Problem solved.

2025-11-14¶

09:30 - Plantage apt-get update sur yunohost-cywise dû à MariaDB Tools

Concerns

Resource - server - yunohost-cywise

Quand Cyrille a voulu déployer Cywise ngdev ce matin, il a eu une erreur lors de l'exécution de apt-get update sur le serveur yunohost-cywise.

47935 WARNING Here's an extract of the logs before the crash. It might help debugging the error:
47935 INFO DEBUG - + tee /etc/apt/trusted.gpg.d/cywise-ui_ngdev.gpg
47935 INFO DEBUG - + ynh_package_update
47935 INFO DEBUG - + ynh_apt update
47936 INFO DEBUG - + ynh_wait_dpkg_free
47936 INFO DEBUG - + return 0
47936 INFO DEBUG - + apt-get --assume-yes --quiet -o=Acquire::Retries=3 -o=Dpkg::Use-Pty=0 update
47936 INFO DEBUG - Hit:1 http://mirrors.online.net/debian bookworm InRelease
47936 INFO DEBUG - Hit:3 http://security.debian.org/debian-security bookworm-security InRelease
47936 INFO DEBUG - Hit:4 https://download.docker.com/linux/debian bullseye InRelease
47936 INFO DEBUG - Hit:5 https://dl.yarnpkg.com/debian stable InRelease
47936 INFO DEBUG - Hit:2 https://forge.yunohost.org/debian bookworm InRelease
47936 INFO DEBUG - Hit:8 https://packages.sury.org/php bookworm InRelease
47936 INFO DEBUG - Hit:6 https://dlm.mariadb.com/repo/mariadb-server/11.8/repo/debian bookworm InRelease
47937 INFO DEBUG - Get:7 https://dlm.mariadb.com/repo/maxscale/latest/apt bookworm InRelease [11.6 kB]
47937 INFO DEBUG - Err:9 http://downloads.mariadb.com/Tools/debian bookworm InRelease
47937 INFO DEBUG -   522  <none> [IP: 2606:4700::6811:bf0e 80]
47937 INFO DEBUG - Reading package lists...
47937 INFO WARNING - E: Failed to fetch http://downloads.mariadb.com/Tools/debian/dists/bookworm/InRelease  522  <none> [IP: 2606:4700::6811:bf0e 80]
47937 INFO WARNING - E: The repository 'http://downloads.mariadb.com/Tools/debian bookworm InRelease' is no longer signed.
47937 INFO DEBUG - + ynh_exit_properly
47937 WARNING Failed to update apt : The operation 'Upgrade the 'cywise-ui_ngdev' app' could not be completed. Please share the full log of this operation using the command 'yunohost log share 20251114-083009-app_upgrade-cywise-ui_ngdev' to get help

C'est la repo http://downloads.mariadb.com/Tools/debian qui pose problème.

Je l'avais mise en place lors de mon installation de MariaDB 11.8 (voir ma note du 2025-07-11). J'ai téléchargé la clé GPG et c'est la même que celle déjà en place. J'ai téléchargé le script d'installation de MariaDB et, en mode "dry-run", il met en place la repo "Tools" de la même façon.

twr_admin@apps:~$ sudo ./mariadb_repo_setup --mariadb-server-version="mariadb-11.8" --include-tools --write-to-stdout
# ... (some lines omitted)
# MariaDB Tools
deb [arch=amd64] http://downloads.mariadb.com/Tools/debian bookworm main

Comme c'est la repo pour les outils, je décide de la mettre en commentaire dans le fichier /etc/apt/sources.list.d/mariadb.list et ça résout le problème (plus de plantage de la commande sudo apt-get update).

2025-10-30¶

Le client Performa plante sur yunohost-sentinel-api

Je reçois des mails de yunohost-sentinel-api quasiment toutes les minutes avec un plantage du client Performa.

Copie du message d'erreur :

node:internal/child_process:413
    throw errnoException(err, 'spawn');
    ^

Error: spawn E2BIG
    at ChildProcess.spawn (node:internal/child_process:413:11)
    at spawn (node:child_process:692:9)
    at Object.execFile (node:child_process:318:17)
    at Object.execFile (pkg/prelude/bootstrap.js:2090:30)
    at Object.exec (node:child_process:223:25)
    at exec (pkg/prelude/bootstrap.js:2104:26)
    at /snapshot/node_modules/performa-satellite/node_modules/systeminformation/lib/processes.js:682:17
    at ChildProcess.exithandler (node:child_process:381:7)
    at ChildProcess.emit (node:events:537:28)
    at maybeClose (node:internal/child_process:1091:16) {
  errno: -7,
  code: 'E2BIG',
  syscall: 'spawn'
}

Node.js v18.5.0

La commande à faire pour reproduire le problème est :

twr_admin@sentinel-api:~$ sudo su
root@sentinel-api:/home/twr_admin# /opt/performa/satellite.bin

Après recherche, il s'agit d'une limitation du système d'exploitation sur la taille maximale des arguments passés à un programme.

Hypothèse au hazard : le client Performa essaie de lister tous les processus en cours et il y en a trop.

Je vais d'abord regarder si j'ai ce problème sur d'autres serveurs YunoHost.

angardia-ai : pas de problème
yunohost-cywise : pas de problème
yunohost-dev02 : pas de problème
yunohost-ista-dev : pas de problème
yunohost-ista-prod : pas de problème
yunohost-josiane : pas de problème

htop indique qu'il y a 297 tasks (processus) en cours sur yunohost-ista-prod et 6650 tasks sur yunohost-sentinel-api.

Quand je compte les processus avec ps aux | wc -l, j'ai 6904 tasks sur yunohost-sentinel-api dont 6297 processus chrome (avec sudo ps aux | grep chrome | wc -l).

Je pense que ce sont des chromes lancés par l'outil de capture qui n'ont pas dû s'arrêter correctement. Ils doivent appartenir au service splash de nos 2 stacks Sentinel API RQ de DEV et de PROD.

Je redémarre le service sentinel-api-rq_dev_splash. Toujours 6297 processus chrome. Je redémarre le service sentinel-api-rq_prod_splash. Toujours 6297 processus chrome.

Remonter aux processus parent avec sudo ps -p 1520 -f (1520 est le PID d'un des processus chrome) ne m'aide pas car je trouve node app.js mais ça ne me dit pas quel est le service ou le container qui a lancé ce node app.js.

Je redémarre alors l'ancienne version de Sentinel API, le service worker_dev_splash. Toujours 6297 processus chrome. Puis l'ancienne version pour la PROD, le service worker_prod_splash. Toujours 6297 processus chrome.

Je décide d'arrêter les 2 anciennces stacks de Sentinel API DEV et PROD (je dois les supprimer de toute façon).

Mais cela n'a pas changé le nombre de processus chrome :

twr_admin@sentinel-api:~$ sudo systemctl stop worker_prod.service 
twr_admin@sentinel-api:~$ sudo ps aux | grep chrome | wc -l
6297
twr_admin@sentinel-api:~$ sudo systemctl stop worker_dev.service 
twr_admin@sentinel-api:~$ sudo ps aux | grep chrome | wc -l
6297
twr_admin@sentinel-api:~$ sudo systemctl stop sentinel-api_prod.service 
twr_admin@sentinel-api:~$ sudo ps aux | grep chrome | wc -l
6297
twr_admin@sentinel-api:~$ sudo systemctl stop sentinel-api_dev.service 
twr_admin@sentinel-api:~$ sudo ps aux | grep chrome | wc -l
6297
twr_admin@sentinel-api:~$ sudo systemctl stop nifi_prod.service 
twr_admin@sentinel-api:~$ sudo ps aux | grep chrome | wc -l
6297
twr_admin@sentinel-api:~$ sudo systemctl stop nifi_dev.service 
twr_admin@sentinel-api:~$ sudo ps aux | grep chrome | wc -l
6297

Je me suis donc décidé à redémarrer les stacks RQ de DEV et de PROD :

twr_admin@sentinel-api:~$ sudo systemctl stop sentinel-api-rq_dev.service 
twr_admin@sentinel-api:~$ sudo ps aux | grep chrome | wc -l
6268
twr_admin@sentinel-api:~$ sudo systemctl stop sentinel-api-rq_prod.service 
twr_admin@sentinel-api:~$ sudo ps aux | grep chrome | wc -l
1
twr_admin@sentinel-api:~$ sudo systemctl start sentinel-api-rq_prod.service 
twr_admin@sentinel-api:~$ sudo ps aux | grep chrome | wc -l
1
twr_admin@sentinel-api:~$ sudo systemctl start sentinel-api-rq_dev.service 
twr_admin@sentinel-api:~$ sudo ps aux | grep chrome | wc -l
1

Arrêter celle de DEV a supprimé 30 chrome et arrêter celle de PROD a supprimé tous les autres.

Problem solved.

Analyse¶

Contrairement àce que je pensais, ce n'est pas Splash qui laisse trainer des processus chrome mais Wappalyzer. Nous utilisons la version 3.5. J'ai changé (sur la stack de DEV) pour la version 3.6 et elle a le même problème. Puis j'ai changé pour la dernière version 4.3 et le problème a disparu. Par contre, le JSON renvoyé par Wappalyzer a changé de format et il faut adapter notre code pour le parser. Je laisse Pierre décider s'il veut faire cette mise à jour. Si j'ai bien compris, il envisage de changer d'outil de détection des technologies web (httpx).

Je suis revenu à la version 3.5 sur la stack DEV.

2025-09-25¶

AddApps - Arrêt de yunohost-addapps

Concerns

Resource - server - yunohost-addapps

Maintenant que j'ai déplacé toutes les applications déployées sur yunohost-addapps vers yunohost-cywise, je peux arrêter l'instance yunohost-addapps ce que j'ai fait aujourd'hui.

AddApps - Déplacement des redirections

Concerns

Je continue le déplacement des applications déployées sur yunohost-addapps vers yunohost-cywise.

Il reste 2 redirections sur addapps :

J'ai supprimé les applications YunoHost qui faisaient ces redirections et je vais les faire directement dans Gandi.

AddApps - Déplacement de site pour installer Towerify CLI

Concerns

Je continue le déplacement des applications déployées sur yunohost-addapps vers yunohost-cywise.

Nous avons 2 déploiements :

en DEV : https://acme.towerify.io/cli
en PROD : https://cli.towerify.io/

Je change les DNS pour que *.acme et acme pointent vers l'instance yunohost-cywise :

*.acme 1800 IN CNAME apps.cywise.io.
acme 1800 IN CNAME apps.cywise.io.

Et je change également pour cli :

cli 1800 IN CNAME apps.cywise.io.

Après avoir publié sur yunohost-cywise l'application Towerify CLI en DEV et en PROD, les deux fonctionnent à nouveau.

Faire une build de install.sh en mode production

Je me suis rendu compte depuis 1 mois environ que le oneliner utilisé pour installer Towerify CLI ne fonctionnait plus :

curl -sL https://cli.towerify.io/install.sh | bash

La commande s'exécute sans erreur mais n'affiche rien et n'installe pas Towerify CLI.

En creusant, je me suis rendu compte que c'est le cas si je génère install.sh en mode development avec Bashly au lieu du mode production.

Il faut absolument faire une build en mode production avec la commande :

cd ./install || exit
bashly generate --env production

AddApps - Déplacement de la doc de l'infra

Concerns

Je continue le déplacement des applications déployées sur yunohost-addapps vers yunohost-cywise.

La doc de l'infra se trouve dans la repo cf-infra et le sous-dossier infra-docs : https://gitlab.com/MNCC-LAB/cf-infra/-/tree/master/infra-docs?ref_type=heads

Nous déployons une seule version avec l'environnement de DEV sur le domaine : docs.infra.computablefacts.com.

Le déploiement est automatisé avec GitLab CI qui utilise Towerify CLI.

Je change les DNS pour que docs.infra.computablefacts.com pointe vers l'instance yunohost-cywise. Je supprime :

*.docs.infra 1800 IN CNAME myapps.addapps.io.
docs.infra 1800 IN A 51.15.140.162
docs.infra 300 IN AAAA 2001:bc8:710:1644:dc00:ff:fe81:67db

Puis j'ajoute :

docs.infra 1800 IN A 51.159.100.198
docs.infra 1800 IN AAAA 2001:bc8:1201:38:46a8:42ff:fe18:d621

NOTA : je n'ai pas pu mettre le CNAME vers apps.cywise.io. car il y a d'autres entrées DNS pour docs.infra (MX et TXT).

Je change les variables sur GitLab pour déployer avec Towerify CLI sur l'instance yunohost-cywise.

Après déroulement du pipeline GitLab CI, le site est bien accessible : https://docs.infra.computablefacts.com/.

AddApps - Déplacement de la doc de Towerify

Concerns

Je continue le déplacement des applications déployées sur yunohost-addapps vers yunohost-cywise.

La doc se trouve dans la repo : https://github.com/computablefacts/towerify-docs

Nous déployons en DEV sur le domaine : dev.docs.towerify.io et en PROD sur le domaine docs.towerify.io.

Je change les DNS pour que dev.docs.towerify.io et docs.towerify.io pointent vers l'instance yunohost-cywise :

*.docs 1800 IN CNAME apps.cywise.io.
docs 1800 IN CNAME apps.cywise.io.

Je déploie en DEV :

towerify deploy --env dev --profile cywise

Je déploie en PROD :

towerify deploy --env prod --profile cywise

Les deux sites s'affichent correctement.

2025-09-19¶

Cywise - Intégration Entra ID pour Hermès

Concerns

Resource - deployment - cywise-ui_prod

Hermès migre de ADFS vers Entra ID. Je vais créé un nouveau tenant, donc de nouvelles metadata, puis régler l'intégration pour tester avec le suffixe .test.

Voici le plan décidé après le point de ce jour, vendredi 19 à 14h30:

Echange de nos metadata dès maintenant
Je mets en place la nouvelle intégration Entra ID dans l'après-midi (en phase de test)
Hermès (Amine et Nicolas) teste le bon fonctionnement
Si tout va bien, basculement en PROD mardi 23 prochain 10h
Si ça coince, séance de debug lundi 22

Je crée un nouveau tenant SAML pour Hermès avec les informations contenues dans les metadata de leur Entra ID : https://login.microsoftonline.com/e4a52391-cb73-4feb-b3f5-aec2ef5593bb/federationmetadata/2007-06/federationmetadata.xml?appid=120712e9-02b4-405d-a794-558423b56e47

Sur le serveur, dans le container de Cywise PROD app, je fais la commande :

php artisan saml2:create-tenant \
  --key=hermesentra \
  --entityId=https://sts.windows.net/e4a52391-cb73-4feb-b3f5-aec2ef5593bb/ \
  --loginUrl=https://login.microsoftonline.com/e4a52391-cb73-4feb-b3f5-aec2ef5593bb/saml2 \
  --logoutUrl=https://login.microsoftonline.com/e4a52391-cb73-4feb-b3f5-aec2ef5593bb/saml2 \
  --x509cert="MIIC8DCCAdigAwIBAgIQYDQE1k6C8pNAqop25/BtQDANBgkqhkiG9w0BAQsFADA0MTIwMAYDVQQDEylNaWNyb3NvZnQgQXp1cmUgRmVkZXJhdGVkIFNTTyBDZXJ0aWZpY2F0ZTAeFw0yNTA5MTkxMjE4NDVaFw0yNzA5MTkxMjE4NDJaMDQxMjAwBgNVBAMTKU1pY3Jvc29mdCBBenVyZSBGZWRlcmF0ZWQgU1NPIENlcnRpZmljYXRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy3JrWBKF+cjIyOGK3ckP9G4kCNaRVei1Km6R3F1pXJjD1Hkh8OzIjpuXbj2scy6B38B3QVUBoJQNr24s7egFhyxCn//KuQXah+Y39ZrcUIp3laA4y2rClj9EQZ+VUSt0AGFAP01YugNMfb7iTezIbtRZKJXz2roEBpoziF1Z+7CCL+G5gbeiPQXVP47OeXwax+syJvu9gG4nodG2PtfwqxGqJDD5ro2Qq04lDaYYda911qHuj7PPunimIVgflC0HudS7RLRXZ9E2KPlBDYG61aYXe63QS+XZ9IGxQxYUScNXZzvGCPS5hw1kTdtDpt+TW3aJimZFoQxJTErdcOKYXQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQC8FsyfRmd4kcC3JNW2t/8E9DLDRtBolkuICE0Y5uZnDycur99VMj2yfI99GUG2vsXLjYNN3tBHbh9llFAO48q24F80+3Yo/9atz7GsqCHW7MkIGq6WuQLoxRfuY25vMa3aegzakU9pfMemuPOdOcX9JVhdgvLkxE0wvSNNI0AH/Y9g9TkS2G3maWYg2mbYSm7cheBoWZ9yHeMGsMsvEt84ex35gp9XKXnaJsCKQmpzLwO4pH+0j1PF05FaIHtv9dn8ZfRlfIUR5FMz9tsx8tUGxF8ySNfB7KWIh40t7Ma8ULH9z5NsaJKuM+FTl01nd6Zu56mZx8eYToLdsvjJlzQV"

Réponse :

The tenant #3 (b204f7c1-b52a-4f6d-8812-26469f8a6ca8) was successfully created.

Credentials for the tenant
--------------------------

Identifier (Entity ID): https://www.cywise.io/saml/b204f7c1-b52a-4f6d-8812-26469f8a6ca8/metadata
Reply URL (Assertion Consumer Service URL): https://www.cywise.io/saml/b204f7c1-b52a-4f6d-8812-26469f8a6ca8/acs
Sign on URL: https://www.cywise.io/saml/b204f7c1-b52a-4f6d-8812-26469f8a6ca8/login
Logout URL: https://www.cywise.io/saml/b204f7c1-b52a-4f6d-8812-26469f8a6ca8/logout
Relay State:  (optional)

Je préfère remplacer le www par app pour être cohérent avec l'URL des metadata de l'ADFS. D'autant que les 2 domaines www.cywise.io et app.cywise.io fonctionnent tous les deux.

Donc, nouveau metadata pour Cywise : https://app.cywise.io/saml/b204f7c1-b52a-4f6d-8812-26469f8a6ca8/metadata

Avec phpMyAdmin, je modifie l'entrée dans la table saml2_tenants pour :

changer tenant_id = 18
changer customer_id = 9
changer domain = hermes.com.test
changer alt_domain1 = ~hermes\.com\.test~

Reste la colonne metadata à modifier. Elle contient les réglages des claims et le comportement pour les rôles. Celle de l'ADFS est la suivante :

{
  "claims": {
    "email": {
      "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
    }, 
    "name": {
      "name": "lastname"
    }, 
    "role": {
      "friendlyName": "group", 
      "name": "http://schemas.xmlsoap.org/claims/Group"
    }
  }, 
  "roles": {
    "default": ["App\\Models\\Role::CYBERBUDDY_ONLY"], 
    "idp_roles": ["SG-WORLD-APP-CU-CYBERBUDDY-ADMIN-SSO"], 
    "SG-WORLD-APP-CU-CYBERBUDDY-ADMIN-SSO_to_cywise": ["App\\Models\\Role::CYBERBUDDY_ADMIN"]
  }
}

Le nom du groupe des Administrateurs de CyberBuddy est différent dans Entra ID : SGC-WORLD-BUD-PRD-RBAC-Admins Pour Entra ID, ce sera :

{
  "claims": {
    "email": {
      "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
    }, 
    "name": {
      "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
    }, 
    "role": {
      "name": "http://schemas.microsoft.com/ws/2008/06/identity/claims/groups"
    }
  }, 
  "roles": {
    "default": ["App\\Models\\Role::CYBERBUDDY_ONLY"], 
    "idp_roles": ["SGC-WORLD-BUD-PRD-RBAC-Admins"], 
    "SGC-WORLD-BUD-PRD-RBAC-Admins_to_cywise": ["App\\Models\\Role::CYBERBUDDY_ADMIN"]
  }
}

En faisant mon premier test, je me rends compte que patrick@hermes.com.test matche avec ~hermes\.com~ donc je suis renvoyé vers l'ADFS.

Je fais donc le changement suivant dans la colonne alt_domain1 :

ADFS : changer alt_domain1 = ~hermes\.com$~
Entra ID : changer alt_domain1 = ~hermes\.com\.test$~

Quand je mets l'email patrick@hermes.com.test, je suis bien redirigé vers Entra ID. Quand je mets l'email patrick@hermes.com, je suis bien redirigé vers ADFS.

Je communique les metadata à Amine et Nicolas.

Après des échanges pendant 1 jour ou 2, l'intégration Entra ID est validée.

2025-09-17¶

Tunnel SSH pour accès à la base MySQL

Concerns

Resource - server - angardia-ai

Cédric a besoin d'accès à la base MySQL de l'application Angardia. Après discussion, le plus simple est de créer un tunnel SSH depuis son poste.

Je crée un utilisateur YunoHost cedric avec les droits SSH :

sudo yunohost user create cedric.db --fullname "Cedric DB access" --password "KtVGnbYCMwE9WFKMQiL74wWc" --domain apps.angardia.ai
sudo yunohost user permission add ssh.main cedric.db

Je peux donc maintenant me connecter en SSH à l'instance angardia-ai depuis ma machine avec cet utilisateur (et son mot de passe) :

ssh cedric.db@51.159.101.88

Pour éviter d'utiliser le mot de passe, j'ajoute ma clé publique dans les clés autorisées de l'utilisateur cedric.db :

sudo mkdir -p /home/cedric.db/.ssh
echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDah7RARA035UA5H4lsaLBb4tqIkFZBv318ZVZmuFHvzAnO3nX4Ze81xucMirxBo6udrtVcH28IPOurYSqHXSaPjxGkptRo2cVA1I1qjJMWjlgmNcjHfrfjRK4+zr+EY9VUIYqbSoRmRowWb6N2WrulOWJct0adQ47ZFEY9XpxZG2raAk2dkSjBioNBuc+3U9SSfLvFmkhU/Jek7+G8S/CGXWUG42R2XcmovgeW136LB9FASnITYXkJOt0jgPmhPpYlteHWP1Su3pOP1lpbyF4nqPpgdHYDqIYJkzHYV4XDWLj9GWlHJtpIug076cZ32+WE4GYOD4kvbIOJbYr4I+y/ patrick@SpectreMate' \
    | sudo tee /home/cedric.db/.ssh/authorized_keys
sudo chown -R cedric.db:cedric.db /home/cedric.db/.ssh
sudo chmod 700 /home/cedric.db/.ssh
sudo chmod 600 /home/cedric.db/.ssh/authorized_keys

Je peux maintenant me connecter en SSH à l'instance angardia-ai depuis ma machine avec la commande suivante :

ssh -i ~/.ssh/id_rsa cedric.db@51.159.101.88

J'ajoute aussi la cél que Cédric m'a fournie :

echo 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIG7DSwckYVpk67fz75zjZPcFhQcuYCSVGq0C0K8N5ZR6 cedri@DESKTOP-FNHL58O' \
    | sudo tee -a /home/cedric.db/.ssh/authorized_keys

Avec phpMyAdmin, je crée un utilisateur cedric_ro avec le mot de passe vc3uhzQXXCuKUw3yc69RFFHt et je ne lui donne que le droit SELECT.

Je vérifie que je peux bien accéder à la base de données MySQL en créant un tunnel SSH avec :

ssh -i ~/.ssh/id_rsa -N -T -o StrictHostKeyChecking=no -o ExitOnForwardFailure=yes -L 33306:127.0.0.1:3306 cedric.db@51.159.101.88
mysql -h 127.0.0.1 -P 33306 -u cedric_ro -p

Et, c'est bien le cas, je peux voir les bases de données MySQL.

2025-09-12¶

MariaDB de yunohost-cywise ne répond plus

Concerns

Resource - server - yunohost-cywise

Interruption Cywise PROD du vendredi 12/09 16h52 au vendredi 12/09 17h30 soit 38 minutes

Horaire d'après la surveillance Freshping. Coupure aussi de toutes les applications qui utilisent MariaDB.

Le statut de MariaDB au moment de l'incident

twr_admin@apps:~$ sudo systemctl status mariadb.service 
● mariadb.service - MariaDB 11.8.2 database server
    Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/mariadb.service.d
            └─migrated-from-my.cnf-settings.conf
    Active: deactivating (stop-sigterm) since Fri 2025-09-12 16:48:53 CEST; 22min ago
      Docs: man:mariadbd(8)
            https://mariadb.com/kb/en/library/systemd/
  Main PID: 3373435 (mariadbd)
    Status: "Waiting for page cleaner thread to exit"
      Tasks: 20 (limit: 1530727)
    Memory: 46.3G
        CPU: 21min 36.498s
    CGroup: /system.slice/mariadb.service
            └─3373435 /usr/sbin/mariadbd

Sep 12 17:11:28 apps.cywise.io mariadbd[3373435]: Pending Read : 0
Sep 12 17:11:28 apps.cywise.io mariadbd[3373435]: Pending Write: 896
Sep 12 17:11:28 apps.cywise.io mariadbd[3373435]: -------------------
Sep 12 17:11:28 apps.cywise.io mariadbd[3373435]: 2025-09-12 17:11:28 0 [Note] InnoDB: Double Write State
Sep 12 17:11:28 apps.cywise.io mariadbd[3373435]: -------------------
Sep 12 17:11:28 apps.cywise.io mariadbd[3373435]: Batch running : true
Sep 12 17:11:28 apps.cywise.io mariadbd[3373435]: Active Slot - first_free: 97 reserved:  97
Sep 12 17:11:28 apps.cywise.io mariadbd[3373435]: Flush Slot  - first_free: 128 reserved:  26
Sep 12 17:11:28 apps.cywise.io mariadbd[3373435]: -------------------
Sep 12 17:11:31 apps.cywise.io mariadbd[3373435]: 2025-09-12 17:11:30 0 [Note] InnoDB: Waiting for page cleaner thread to exit

On voit qu'il est en cours d'arrêt : Active: deactivating (stop-sigterm). Et qu'il attend le "page cleaner" : Status: "Waiting for page cleaner thread to exit".

J'ai essayé de démarrer le service, d'arrêter le service mais rien n'y fait. J'ai fini par tuer le processus de MariaDB avec sudo kill -9 3373435 et il a redémarré correctement.

J'ai lancé sudo mysqlcheck --all-databases pour vérifier les bases de données. Tout est OK.

Recherche de la cause¶

Les logs MariaDB au moment de l'incident

Dans les logs (avec la commande sudo journalctl -u mariadb --since "60 minutes ago"), je trouve ça :

Sep 12 16:48:51 apps.cywise.io mariadbd[3373435]: Active Slot - first_free: 128 reserved:  128
Sep 12 16:48:51 apps.cywise.io mariadbd[3373435]: Flush Slot  - first_free: 128 reserved:  0
Sep 12 16:48:51 apps.cywise.io mariadbd[3373435]: -------------------
Sep 12 16:48:53 apps.cywise.io systemd[1]: Stopping mariadb.service - MariaDB 11.8.2 database server...
Sep 12 16:48:53 apps.cywise.io mariadbd[3373435]: 2025-09-12 16:48:53 0 [Note] /usr/sbin/mariadbd (initiated by: unknown): Normal shutdown
Sep 12 16:49:06 apps.cywise.io mariadbd[3373435]: 2025-09-12 16:49:05 0 [Note] InnoDB: Long wait (5 seconds) for double-write buffer flush.
Sep 12 16:49:06 apps.cywise.io mariadbd[3373435]: 2025-09-12 16:49:05 0 [Note] InnoDB: Buffer Pool pages

Une commande d'arrêt initiée par "unknown" a été reçue (!?!). Après recherche le unknown est normal car c'est un utilisateur MariaDB qui est loggué et unknown signifie donc que ce n'est pas un utilisateur MariaDB qui a demandé l'arrêt (donc plutôt un utilisateur linux si je comprends bien).

Les logs MariaDB au moment de mon kill -9

Sep 12 17:25:35 apps.cywise.io systemd[1]: mariadb.service: Main process exited, code=killed, status=9/KILL
Sep 12 17:25:35 apps.cywise.io systemd[1]: mariadb.service: Failed with result 'signal'.
Sep 12 17:25:35 apps.cywise.io systemd[1]: Stopped mariadb.service - MariaDB 11.8.2 database server.
Sep 12 17:25:35 apps.cywise.io systemd[1]: mariadb.service: Consumed 21min 41.266s CPU time.
Sep 12 17:25:35 apps.cywise.io systemd[1]: Starting mariadb.service - MariaDB 11.8.2 database server...
Sep 12 17:25:35 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:35 0 [Warning] Could not increase number of max_open_files to more than 32768 (request: 128355)
Sep 12 17:25:36 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:36 0 [Note] Starting MariaDB 11.8.2-MariaDB-deb12 source revision 8d36cafe4fc700e6e577d5a36650c58707e76b92 server_uid 8p+7>
Sep 12 17:25:36 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:36 0 [Note] mariadbd: Aria engine: starting recovery
Sep 12 17:25:39 apps.cywise.io mariadbd[3723944]: recovered pages: 0% 17% 28% 39% 57% 74% 86% 100% (0.0 seconds); tables to flush: 2 1 0 (2.3 seconds);
Sep 12 17:25:39 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:39 0 [Note] mariadbd: Aria engine: recovery done
Sep 12 17:25:39 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:39 0 [Note] InnoDB: Compressed tables use zlib 1.2.13
Sep 12 17:25:39 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:39 0 [Note] InnoDB: Number of transaction pools: 1
Sep 12 17:25:39 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:39 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
Sep 12 17:25:39 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:39 0 [Note] InnoDB: Using liburing
Sep 12 17:25:39 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:39 0 [Note] InnoDB: innodb_buffer_pool_size_max=98304m, innodb_buffer_pool_size=98304m
Sep 12 17:25:47 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:47 0 [Note] InnoDB: Completed initialization of buffer pool
Sep 12 17:25:49 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:49 0 [Note] InnoDB: Buffered log writes (block size=512 bytes)
Sep 12 17:25:50 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:50 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=1647406159033
Sep 12 17:25:54 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:54 0 [Note] InnoDB: End of log at LSN=1648045913633
Sep 12 17:25:54 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:54 0 [Note] InnoDB: To recover: 90239 pages
Sep 12 17:25:59 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:59 0 [Note] InnoDB: Last binlog file './mariadb.007700', position 19654922
Sep 12 17:25:59 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:59 0 [Note] InnoDB: Opened 3 undo tablespaces
Sep 12 17:25:59 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:59 0 [Note] InnoDB: 128 rollback segments in 3 undo tablespaces are active.
Sep 12 17:25:59 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:59 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
Sep 12 17:25:59 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:59 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
Sep 12 17:25:59 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:59 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB.
Sep 12 17:25:59 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:59 0 [Note] InnoDB: log sequence number 1648045913633; transaction id 93256550
Sep 12 17:25:59 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:59 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
Sep 12 17:25:59 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:59 0 [Note] Plugin 'FEEDBACK' is disabled.
Sep 12 17:25:59 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:59 0 [Note] Plugin 'wsrep-provider' is disabled.
Sep 12 17:25:59 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:59 0 [Note] Recovering after a crash using tc.log
Sep 12 17:25:59 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:59 0 [Note] Starting table crash recovery...
Sep 12 17:25:59 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:25:59 0 [Note] Crash table recovery finished.
Sep 12 17:26:02 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:26:02 0 [Note] Server socket created on IP: '0.0.0.0'.
Sep 12 17:26:02 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:26:02 0 [Note] mariadbd: Event Scheduler: Loaded 0 events
Sep 12 17:26:02 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:26:02 0 [Note] /usr/sbin/mariadbd: ready for connections.
Sep 12 17:26:02 apps.cywise.io mariadbd[3723944]: Version: '11.8.2-MariaDB-deb12'  socket: '/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
Sep 12 17:26:02 apps.cywise.io systemd[1]: Started mariadb.service - MariaDB 11.8.2 database server.
Sep 12 17:26:04 apps.cywise.io debian-start[3724632]: --------------
Sep 12 17:26:04 apps.cywise.io debian-start[3724632]: SELECT count(*) FROM mysql.user WHERE user='root' and password='' and password_expired='N' and plugin in ('', 'mysql_native_password', >
Sep 12 17:26:04 apps.cywise.io debian-start[3724632]: --------------
Sep 12 17:26:04 apps.cywise.io debian-start[3724632]: ERROR 1267 (HY000) at line 1: Illegal mix of collations (utf8mb4_general_ci,COERCIBLE) and (utf8mb4_uca1400_ai_ci,COERCIBLE) for operat>
Sep 12 17:26:07 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:26:07 8 [Warning] IP address '172.19.0.28' could not be resolved: Name or service not known
Sep 12 17:26:08 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:26:08 9 [Warning] IP address '172.19.0.12' could not be resolved: Name or service not known
Sep 12 17:26:19 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:26:19 18 [Warning] IP address '172.19.0.6' could not be resolved: Name or service not known
Sep 12 17:26:44 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:26:44 29 [Warning] IP address '172.19.0.7' could not be resolved: Name or service not known
Sep 12 17:26:44 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:26:44 31 [Warning] IP address '172.19.0.5' could not be resolved: Name or service not known
Sep 12 17:26:44 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:26:44 33 [Warning] IP address '172.19.0.22' could not be resolved: Name or service not known
Sep 12 17:26:48 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:26:48 38 [Warning] IP address '172.19.0.8' could not be resolved: Name or service not known
Sep 12 17:27:06 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:27:06 0 [Note] InnoDB: Buffer pool(s) load completed at 250912 17:27:06
Sep 12 17:27:17 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:27:17 48 [Warning] IP address '172.19.0.9' could not be resolved: Name or service not known
Sep 12 17:27:20 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:27:20 54 [Warning] IP address '172.19.0.10' could not be resolved: Name or service not known
Sep 12 17:27:30 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:27:30 66 [Warning] IP address '172.19.0.11' could not be resolved: Name or service not known
Sep 12 17:27:38 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:27:38 78 [Warning] IP address '172.19.0.13' could not be resolved: Name or service not known
Sep 12 17:27:38 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:27:38 79 [Warning] IP address '172.19.0.14' could not be resolved: Name or service not known
Sep 12 17:27:40 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:27:38 82 [Warning] IP address '172.19.0.15' could not be resolved: Name or service not known
Sep 12 17:27:45 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:27:45 93 [Warning] IP address '172.19.0.16' could not be resolved: Name or service not known
Sep 12 17:27:55 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:27:55 101 [Warning] IP address '172.19.0.17' could not be resolved: Name or service not known
Sep 12 17:27:56 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:27:56 102 [Warning] IP address '172.19.0.18' could not be resolved: Name or service not known
Sep 12 17:27:56 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:27:56 103 [Warning] IP address '172.19.0.19' could not be resolved: Name or service not known
Sep 12 17:27:56 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:27:56 104 [Warning] IP address '172.19.0.20' could not be resolved: Name or service not known
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:31:11 0 [Note] InnoDB: Long wait (5 seconds) for double-write buffer flush.
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:31:11 0 [Note] InnoDB: Buffer Pool pages
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: -------------------
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: LRU Pages  : 1674273
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: Free Pages : 4555743
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: Dirty Pages: 99902 : 1%
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: -------------------
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:31:11 0 [Note] InnoDB: LSN flush parameters
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: -------------------
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: System LSN     : 1648337138565
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: Checkpoint  LSN: 1647468123092
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: Flush ASync LSN: 1648337135600
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: Flush Sync  LSN: 1648337138565
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: -------------------
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:31:11 0 [Note] InnoDB: LSN age parameters
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: -------------------
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: Current Age   : 869015473 : 100%
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: Max Age(Async): 760386494
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: Max Age(Sync) : 869013136
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: Capacity      : 966356583
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: -------------------
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:31:11 0 [Note] InnoDB: Pending IO count
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: -------------------
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: Pending Read : 0
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: Pending Write: 0
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: -------------------
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:31:11 0 [Note] InnoDB: Double Write State
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: -------------------
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: Batch running : false
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: Active Slot - first_free: 128 reserved:  128
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: Flush Slot  - first_free: 0 reserved:  0
Sep 12 17:31:11 apps.cywise.io mariadbd[3723944]: -------------------
Sep 12 17:38:11 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:38:11 0 [Note] InnoDB: Long wait (5 seconds) for double-write buffer flush.
Sep 12 17:38:11 apps.cywise.io mariadbd[3723944]: 2025-09-12 17:38:11 0 [Note] InnoDB: Buffer Pool pages

Ca pourrait être mon déploiement de Performa DEV, qui a commencé 16h38, qui a provoqué le problème. Il a fait des erreurs liées à MariaDB durant le pipeline Jenkins.

Les logs du pipeline Jenkins lors du déploiement de Performa DEV

INFO Provisioning database...
mysqlshow: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb-show' instead
WARNING mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
INFO [++++................] > Adding system configurations related to performa_dev...
INFO [####++++............] > Adding the Docker Swarm file...
INFO [########++++........] > Allow Docker containers to access MariaDB database...
WARNING Job for mariadb.service canceled.
ERROR Unable to install performa_dev: An error occurred inside the app installation script
INFO The operation 'Install the 'performa_dev' app' could not be completed. Please share the full log of this operation using the command 'yunohost log share 20250912-144734-app_install-performa_dev' to get help
WARNING Here's an extract of the logs before the crash. It might help debugging the error:
INFO DEBUG - + ynh_replace_string --match_string=__NAMETOCHANGE__ --replace_string=performa_dev --target_file=/etc/mysql/mariadb.conf.d/90-performa_dev.cnf
INFO DEBUG - + ynh_replace_string --match_string=__USER__ --replace_string=performa_dev --target_file=/etc/mysql/mariadb.conf.d/90-performa_dev.cnf
INFO DEBUG - + test -n ''
INFO DEBUG - + dpkg --compare-versions 2.0 lt 2
INFO DEBUG - + test -n ''
INFO DEBUG - ++ grep -oP '__[A-Z0-9]+?[A-Z0-9_]*?[A-Z0-9]*?__' /etc/mysql/mariadb.conf.d/90-performa_dev.cnf
INFO DEBUG - ++ sort --unique
INFO DEBUG - ++ sed 's@__\([^.]*\)__@\L\1@g'
INFO DEBUG - + uniques_vars=()
INFO DEBUG - + ynh_store_file_checksum --file=/etc/mysql/mariadb.conf.d/90-performa_dev.cnf
INFO DEBUG - + update_only=0
INFO DEBUG - ++ md5sum /etc/mysql/mariadb.conf.d/90-performa_dev.cnf
INFO DEBUG - ++ cut '--delimiter= ' --fields=1
INFO DEBUG - + ynh_app_setting_set --app=performa_dev --key=checksum__etc_mysql_mariadb.conf.d_90-performa_dev.cnf --value=d0d2c1dd61c1a9aa25b3a66363a62df0
INFO DEBUG - + '[' -n '' ']'
INFO DEBUG - + chown root:root /etc/mysql/mariadb.conf.d/90-performa_dev.cnf
INFO DEBUG - + chmod 644 /etc/mysql/mariadb.conf.d/90-performa_dev.cnf
INFO DEBUG - + systemctl restart mariadb.service
INFO WARNING - Job for mariadb.service canceled.
INFO DEBUG - + ynh_exit_properly
WARNING Removing the app after installation failure…
INFO [++++++..............] > Removing system configurations related to performa_dev...
INFO [######+++++++.......] > Removing performa_dev service integration...
WARNING Nothing found in stack: performa_dev
WARNING nothing found in stack: performa_dev
WARNING mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
WARNING --------------
WARNING RENAME USER 'performa_dev'@'%' TO 'performa_dev'@'localhost'
WARNING --------------
WARNING ERROR 1396 (HY000) at line 1: Operation RENAME USER failed for 'performa_dev'@'%'
INFO [####################] > Removal of performa_dev completed
INFO Deprovisioning database...
WARNING mysqlshow: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb-show' instead
WARNING mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
WARNING mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
WARNING mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead

On voit dans ces lignes :

INFO [########++++........] > Allow Docker containers to access MariaDB database...
WARNING Job for mariadb.service canceled.
ERROR Unable to install performa_dev: An error occurred inside the app installation script

que l'erreur lors du déploiement est lié à MariaDB.

J'ai retenté un déploiement de Performa DEV et j'ai reproduit le problème : MariaDB a commencé à s'arrêter. J'ai fait le kill -9 rapidement et il a redémarré.

Et, cette fois, le pipeline de Performa DEV n'a pas fait d'erreur et il est installé et visible à l'URL : https://dev.performa.apps.cywise.io/.

J'ai lancé à nouveau sudo mysqlcheck --all-databases pour vérifier les bases de données. Tout est OK.

Script pour nettoyer les interfaces VXLAN orphelines

Concerns

J'ai fait un script pour nettoyer les interfaces VXLAN orphelines et je l'ai déployé avec Ansible sur toutes nos machines YunoHost où Docker est installé.

computablefacts/cf-infra/yunohosts> ansible-playbook -i ./inventory.yaml deploy-cleanup-vxlan.yaml

2025-09-11¶

Déplacement de Superset de yunohost-addapps vers yunohost-cywise

Concerns

Resource - server - yunohost-cywise

Je pense faire ce déplacement en plusieurs étapes : - Faire en sorte d'accèder aux deux Superset - Installation de Superset sur yunohost-cywise - Configuration de l'accès à la base de données MariaDB de yunohost-cywise - Export des dashboards de yunohost-addapps - Import des dashboards sur yunohost-cywise

URL du Superset : https://reports.cywise.io/

Faire en sorte d'accèder aux deux Superset¶

Je voudrais installer le Superset sur yunohost-cywise avec le même nom de domaine reports.cywise.io. Je peux modifier la configuration DNS pour que ce nom de domaine pointe versyunohost-cywise mais, alors, je ne pourrais plus accèder à l'ancien Superset et faire mes exports.

Je définis une entrée DNS temporaire reports-addapps.cywise.io qui pointe vers yunohost-addapps : reports-addapps 1800 IN CNAME myapps.addapps.io..

J'ajoute ce domaine sur la machine yunohost-addapps et j'installe l'application de redirection pour afficher Superset avec ce domaine :

sudo yunohost domain add reports-addapps.cywise.io
sudo yunohost diagnosis run web dnsrecords --force
sudo yunohost domain cert install reports-addapps.cywise.io --force --no-checks
sudo cat /home/yunohost.app/superset/stack.yaml | grep published
    published: 59614
sudo yunohost app install https://github.com/computablefacts/redirect_ynh --args "domain=reports-addapps.cywise.io&path=/&redirect_path=http://127.0.0.1:59614&redirect_type=public_proxy"

Je peux maintenant accèder à l'ancien Superset avec l'URL https://reports-addapps.cywise.io.

Je modifie l'entrée DNS reports.cywise.io pour qu'elle pointe vers yunohost-cywise : reports 1800 IN CNAME apps.cywise.io..

J'ajoute le domaine reports.cywise.io sur la machine yunohost-cywise :

sudo yunohost domain add reports.cywise.io
sudo yunohost diagnosis run web dnsrecords --force
sudo yunohost domain cert install reports.cywise.io --force --no-checks

Installation de Superset sur `yunohost-cywise`¶

Je le fais en utilisant l'interface d'adminitration de YunoHost et notre version de l'application : https://github.com/computablefacts/superset_ynh

L'installation a fonctionné mais je n'ai pas pu connecter Superset au LDAP malgré un changement dans iptables et d'autres modifications. Je n'ai pas compris pourquoi et j'ai décidé de ne pas utiliser le LDAP pour l'instant (je me connecte avec le compte Administrateur créé à l'installation).

Déplacement des Performa de yunohost-addapps vers yunohost-cywise

Concerns

Je veux déplacer les Performa de yunohost-addapps vers yunohost-cywise car nous voulons arrêter yunohost-addapps.

Avant de les déplacer, je dois corriger l'authentification qui ne fonctionne plus probablement depuis le déplacement de Cywise PROD de yunohost-addapps vers yunohost-cywise.

Correction de l'authentification¶

L'authentification de Performa est expliquée ici : https://github.com/jhuckaby/pixl-server-user?tab=readme-ov-file#external-user-login-systems Le performa, depuis yunohost-addapps, appelle une URL de Cywise PROD (https://app.cywise.io/performa/user/login/) pour authentifier l'utilisateur. Je pense que le domaine app.cywise.io n'est pas résolu vers yunohost-cywise mais vers des IPs internes de yunohost-addapps à cause de dnsmasq d'où l'erreur "Bad HTTP Response: Bad Gateway".

Je vais donc déplacer notre Performa performa_v29m-tcdr-kqx2 pour voir si cela fonctionne mieux. Je change le DNS pour : v29m-tcdr-kqx2 1800 IN CNAME apps.cywise.io. Puis, je déploie sur yunohost-cywise avec towerify deploy --env v29m-tcdr-kqx2 --profile cywise.

Après avoir résolu les problèmes de certificats SSL - LE était redirigé vers la mire de login de YunoHost - en redémarrant nginx (sudo systemctl restart nginx), j'ai pu me connecter au Performa.

Copie des données¶

Je veux copier les données de yunohost-addapps vers yunohost-cywise. Les données sont dans /home/yunohost.app/performa_v29m-tcdr-kqx2/data sur les 2 machines.

Sur yunohost-addapps, je donne les droits à l'utilisateur twr_admin pour lire les données :

sudo usermod -aG performa_v29m-tcdr-kqx2 cfadmin

Sur yunohost-cywise, je donne les droits à l'utilisateur twr_admin pour écrire les données :

sudo chmod g+w -R /home/yunohost.app/performa_v29m-tcdr-kqx2/data
sudo chown performa_v29m-tcdr-kqx2:performa_v29m-tcdr-kqx2 -R /home/yunohost.app/performa_v29m-tcdr-kqx2/data
sudo usermod -aG performa_v29m-tcdr-kqx2 twr_admin

Sur mon poste j'enchaîne les commandes rsync pour copier les données :

rsync -a --no-owner --no-group --info=progress2 --delete -e ssh yunohost-addapps:/home/yunohost.app/performa_v29m-tcdr-kqx2/data/ /tmp/data_temp/
rsync -a --no-owner --no-group --info=progress2 --delete -e ssh /tmp/data_temp/ yunohost-cywise:/home/yunohost.app/performa_v29m-tcdr-kqx2/data/
rm -rf /tmp/data_temp/

Déplacement des autres Performa¶

Pour les 4 autres performa de PROD, je fais les mêmes étapes :

Changement du DNS pour qu'il pointe vers yunohost-cywise
Déploiement avec Towerify
Copie des données avec rsync

Datalake ISTA PROD - error creating vxlan interface file exists

Concerns

Resource - server - yunohost-ista-prod

Un ticket de Matthieu vers 18h15 nous alerte que Datalake ISTA PROD ne fonctionne plus. Cyrille a résolu le problème. Voir https://computablefacts.freshdesk.com/a/tickets/8979

2025-09-09¶

Generic RAG STAGING - error creating vxlan interface file exists

Concerns

Resource - server - yunohost-dev02

En explorant les logs de yunohost-dev02 depuis Grafana Cloud, je vois une erreur vxlan pour Generic RAG STAGING :

network sandbox join failed: subnet sandbox join failed for "10.0.5.0/24": error creating vxlan interface: file exists

J'applique ma procédure pour résoudre ce problème. Voir cette réponse sur StackOverflow.

Et les containers démarrent.

2025-09-08¶

Sentinel RQ DEV - error creating vxlan interface file exists

En debuggant des envois trop nombreux d'erreurs 500 de Sentinel RQ vers Slack, nous avons un erreur vxlan pour Sentinel RQ DEV :

network sandbox join failed: subnet sandbox join failed for "10.0.13.0/24": error creating vxlan interface: file exists

J'applique ma procédure pour résoudre ce problème. Voir cette réponse sur StackOverflow.

Et les containers démarrent.

2025-09-04¶

Cywise PROD - error creating vxlan interface file exists

Concerns

Resource - server - yunohost-cywise

Après que Cyrille ait poussé une mise à jour pour Cywise ngprod, en regardant les logs du container dans Portainer, j'ai l'erreur suivante :

network sandbox join failed: subnet sandbox join failed for "10.0.9.0/24": error creating vxlan interface: file exists

J'applique ma procédure pour résoudre ce problème. Voir cette réponse sur StackOverflow.

Et les containers démarrent.

NOTA: le problème concernait ngprod ET ngdev.

2025-08-28¶

ISTA DEV - Certificats SSL expirés

Cyrille se rend compte que les certificats SSL de plusieurs apps sur yunohost-ista-dev sont expirés.

2025-08-20¶

ISTA DEV - Certificats SSL expirés

Concerns

Resource - server - yunohost-ista-dev

Cyrille se rend compte que les certificats SSL de plusieurs apps sur yunohost-ista-dev sont expirés.

Je confirme que j'ai bien l'erreur aussi dans mon navigateur.

Pourtant YunoHost me dit que ce domaine est encore valable pendant 71 jours :

portainer.apps.dev-ista.computablefacts.com: 
  CA_type: letsencrypt
  style: success
  summary: letsencrypt
  validity: 71

J'ai fait sudo systemctl restart nginx sur la machine yunohost-ista-dev ce qui a résolu le problème.

ISTA PROD - Certificats SSL expirés

Concerns

Resource - server - yunohost-ista-prod

Suite au problème détecté sur yunohost-ista-dev, je vérifie une app de yunohost-ista-prod et j'ai également le certificat SSL qui a expiré.

Pourtant YunoHost me dit que le domaine est encore valable, comme pour le DEV.

J'ai fait sudo systemctl restart nginx sur la machine yunohost-ista-prod ce qui a résolu le problème.

2025-07-31¶

Angardia DEV - error creating vxlan interface file exists

Concerns

Resource - server - angardia-ai

Après avoir poussé mes modifs dans la repo angardia, en regardant les logs du container dans Portainer, j'ai l'erreur suivante :

network sandbox join failed: subnet sandbox join failed for "10.0.9.0/24": error creating vxlan interface: file exists

J'applique ma procédure pour résoudre ce problème. Voir cette réponse sur StackOverflow.

Et les containers démarrent.

2025-07-30¶

Cywise PROD ng - error creating vxlan interface file exists

Concerns

Resource - server - yunohost-cywise

J'ai une erreur 502 (Bad gateway) sur la page d'accueil de Cywise PROD ng.

En regardant les logs du container dans Portainer, j'ai l'erreur suivante :

network sandbox join failed: subnet sandbox join failed for "10.0.9.0/24": error creating vxlan interface: file exists

J'applique ma procédure pour résoudre ce problème. Voir cette réponse sur StackOverflow.

J'ai repéré les interfaces vxlan qui posaient problème et je les ai supprimées :

twr_admin@apps:~$ hostname
apps.angardia.ai
twr_admin@apps:~$ ls -l /sys/class/net/ | grep vx
lrwxrwxrwx 1 root root 0 Jul 31 09:38 vx-001001-pw3uj -> ../../devices/virtual/net/vx-001001-pw3uj
twr_admin@apps:~$ sudo ip -d link show vx-001001-pw3uj
35125: vx-001001-pw3uj: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN mode DEFAULT group default 
    link/ether 46:04:ce:ff:84:55 brd ff:ff:ff:ff:ff:ff promiscuity 0  allmulti 0 minmtu 68 maxmtu 65535 
    vxlan id 4097 srcport 0 0 dstport 4789 proxy l2miss l3miss ttl auto ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 
twr_admin@apps:~$ sudo ip link delete vx-001001-pw3uj
twr_admin@apps:~$ ls -l /sys/class/net/ | grep vx

Les containers des services de Cywise PROD ng ont démarré.

2025-07-24¶

Sentinel API RQ - error creating vxlan interface file exists

Pierre me préviens que Sentinel API RQ ne fonctionne plus. Impossible de déployer de nouvelles versions.

Les containers des services ne démarrent pas et j'ai l'erreur : network sandbox join failed: subnet sandbox join failed for "10.0.13.0/24": error creating vxlan interface: file exists

Pour résoudre le problème, voir cette réponse sur StackOverflow.

J'ai repéré les interfaces vxlan qui posaient problème et je les ai supprimées :

cfadmin@yunohost-addapps-xxl:~$ ls -l /sys/class/net/ | grep vx
lrwxrwxrwx 1 root root 0 May 19 15:24 vx-001006-k026c -> ../../devices/virtual/net/vx-001006-k026c
lrwxrwxrwx 1 root root 0 May 19 15:20 vx-00100c-thnh9 -> ../../devices/virtual/net/vx-00100c-thnh9
lrwxrwxrwx 1 root root 0 May 19 15:24 vx-00100e-6jvp4 -> ../../devices/virtual/net/vx-00100e-6jvp4
lrwxrwxrwx 1 root root 0 May 19 15:24 vx-001017-vw722 -> ../../devices/virtual/net/vx-001017-vw722
cfadmin@yunohost-addapps-xxl:~$ sudo ip -d link show vx-001006-k026c
1285: vx-001006-k026c: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN mode DEFAULT group default 
    link/ether 82:8b:8b:50:1f:e2 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535 
    vxlan id 4102 srcport 0 0 dstport 4789 proxy l2miss l3miss ttl auto ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
cfadmin@yunohost-addapps-xxl:~$ sudo ip link delete vx-001006-k026c
cfadmin@yunohost-addapps-xxl:~$ sudo ip -d link show vx-00100c-thnh9
99: vx-00100c-thnh9: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN mode DEFAULT group default 
    link/ether 72:6b:43:90:03:ee brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535 
    vxlan id 4108 srcport 0 0 dstport 4789 proxy l2miss l3miss ttl auto ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
cfadmin@yunohost-addapps-xxl:~$ sudo ip link delete vx-00100c-thnh9
cfadmin@yunohost-addapps-xxl:~$ sudo ip -d link show vx-00100e-6jvp4
1302: vx-00100e-6jvp4: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN mode DEFAULT group default 
    link/ether 12:23:30:18:3e:12 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535 
    vxlan id 4110 srcport 0 0 dstport 4789 proxy l2miss l3miss ttl auto ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
cfadmin@yunohost-addapps-xxl:~$ sudo ip link delete vx-00100e-6jvp4
cfadmin@yunohost-addapps-xxl:~$ sudo ip -d link show vx-001017-vw722
1218: vx-001017-vw722: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN mode DEFAULT group default 
    link/ether 8e:db:d1:90:2a:45 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535 
    vxlan id 4119 srcport 0 0 dstport 4789 proxy l2miss l3miss ttl auto ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
cfadmin@yunohost-addapps-xxl:~$ sudo ip link delete vx-001017-vw722
cfadmin@yunohost-addapps-xxl:~$ ls -l /sys/class/net/ | grep vx

Les containers des services de Sentinel API RQ DEV ont démarré.

Je constate que Sentinel API RQ PROD avait le problème également (même erreur) et les containers ont démarrés à nouveau comme le DEV.

2025-07-17¶

Backups des bases de données MariaDB du YunoHost de Postface

Concerns

Resource - server - postface01

Comme mes backups sur yunohost-addapps et yunohost-cywise fonctionnent bien, je les mets en place également sur la machine postface01.

2025-07-16¶

Backups des bases de données MariaDB du YunoHost de Angardia AI

Concerns

Comme mes backups sur yunohost-addapps et yunohost-cywise fonctionnent bien, je les mets en place également sur la machine angardia-ai.

Plus de mémoire pour MariaDB

Concerns

Resource - server - yunohost-cywise

J'ai modifié la configuration de MariaDB pour lui donner plus de mémoire. J'ai mis à jour le fichier /etc/mysql/mariadb.conf.d/50-server.cnf pour y ajouter les lignes suivantes :

############# Ajout Patrick - 2025-07-16
# Mémoire
innodb_buffer_pool_size = 96G   # ~75% de la RAM si MariaDB est le principal service
innodb_log_file_size = 1G   # Taille du journal pour accélérer les transactions
innodb_log_buffer_size = 256M   # Buffer pour le journal, réduit les écritures disque

# Optimisation CPU et threads
innodb_read_io_threads = 16
innodb_write_io_threads = 16
innodb_flush_log_at_trx_commit = 2   # Bon compromis entre performance et sécurité

# Cache et requêtes
query_cache_type = 0   # Désactiver le Query Cache (obsolète et ralentit les performances)
query_cache_size = 0
table_open_cache = 8000
table_definition_cache = 4000
max_connections = 300   # À ajuster selon l'usage réel
tmp_table_size = 256M
max_heap_table_size = 256M

# Logs et monitoring
log_bin = mariadb   # Désactiver le log binaire si pas de réplication (commenter cette ligne)
expire_logs_days       = 5
max_binlog_size        = 100M
#slow_query_log = 1
#slow_query_log_file = /var/log/mysql/slow.log
#long_query_time = 2   # Loguer les requêtes de plus de 2 secondes

# Buffers supplémentaires
join_buffer_size = 16M
sort_buffer_size = 16M
read_buffer_size = 8M
read_rnd_buffer_size = 8M
############# FIN Ajout Patrick - 2025-07-16

Par rapport à mes réglages précédents, maintenant que MariaDB est en version 11.8, j'ai :

supprimé innodb_flush_method ([Warning] --innodb-flush-method is deprecated and will be removed in a future release)
supprimé innodb_buffer_pool_instances ([Warning] 'innodb-buffer-pool-instances' was removed. It does nothing now and exists only for compatibility with old my.cnf files)
supprimé innodb_thread_concurrency ([Warning] 'innodb-thread-concurrency' was removed. It does nothing now and exists only for compatibility with old my.cnf files)
activé le log binaire (j'ai la place sur la nouvelle machine)

Puis j'ai redémarré MariaDB avec la commande :

sudo systemctl restart mariadb

J'ai vérifié que le paramètre innodb_buffer_pool_size était bien pris en compte en regardant avec phpMyAdmin (https://phpmyadmin.apps.cywise.io/index.php?route=/server/variables).

2025-07-15¶

Désinstallation de Restic sur yunohost-ista-prod

Concerns

Resource - server - yunohost-ista-prod

Maintenant que je backupe yunohost-ista-prod avec mon nouveau système, j'ai désinstallé Restic.

Backups des bases de données MariaDB des YunoHost d'ISTA

Concerns

Comme mes backups sur yunohost-addapps et yunohost-cywise fonctionnent bien, je les mets en place également sur l'instance yunohost-ista-dev et l'instance yunohost-ista-prod.

Les backups sont bien faits et envoyés sur le bucket S3 towerify-backups-mysql.

Résiliation de l'infrastructure CoreAPI

Concerns

Deprecated: Resource - server - coreapi-1
Deprecated: Resource - server - coreapi-2
Deprecated: Resource - server - ac-master-1
Deprecated: Resource - server - ac-slave-0
Deprecated: Resource - server - ac-slave-1
Deprecated: Resource - server - ac-slave-2
Deprecated: Resource - server - zookeeper-1
Deprecated: Resource - server - zookeeper-2

J'ai résilié les 8 machines suivantes :

coreapi-1 - Start-2-M-SATA sd-150972
coreapi-2 - Start-2-M-SATA sd-150973
ac-slave-2 - Start-2-M-SATA sd-150994
ac-slave-1 - Start-2-M-SATA sd-150990
ac-slave-0 - Start-2-M-SATA sd-150995
ac-master-1 - Start-2-M-SATA sd-150975
zookeeper-1 - Start-2-M-SSD sd-150815
zookeeper-2 - Start-2-M-SSD sd-150816

2025-07-11¶

Upgrade MariaDB from 10.11 to 11.8

Concerns

Resource - server - yunohost-cywise

Les dernières version de MariaDB (depuis 11.7) possède une nouvelle fonctionnalité de Vector qui permet des recherches utiles pour l'IA, les LLM.

Nous aimerions les avoir pour améliorer Cywise. Je vais donc upgrader le MariaDB de l'instance yunohost-cywise de la version 10.11 vers la version 11.8.

D'après la documentation, je vais le faire en deux étapes :

Mise à jour de MariaDB de 10.11 vers 11.4¶

Je commence par mettre à jour la repo des packages Debian pour MariaDB avec le script décrit dans cette doc.

Je lance le script avec une option pour utiliser MariaDB 11.4 :

sudo ./mariadb_repo_setup --mariadb-server-version="mariadb-11.4"

Le script met en place le fichier /etc/apt/sources.list.d/mariadb.list dans lequel on trouve bien la version 11.4 :

deb [arch=amd64,arm64] https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/debian bookworm main

J'arrête Maria DB avec sudo systemctl stop mariadb.

Je supprime l'ancienne version avec sudo apt-get remove mariadb-server.

Résultat de la commande

twr_admin@apps:~$ sudo apt-get remove mariadb-server
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  galera-4 libcgi-fast-perl libcgi-pm-perl libconfig-inifiles-perl libdbd-mariadb-perl libfcgi-bin libfcgi-perl libfcgi0ldbl libhtml-template-perl liblzo2-2 libsnappy1v5
  libterm-readkey-perl liburing2 libzip4 mariadb-client mariadb-client-core mariadb-server-core php-common php8.3 php8.3-cli php8.3-common php8.3-curl php8.3-fpm php8.3-mbstring
  php8.3-mysql php8.3-opcache php8.3-readline php8.3-xml php8.3-zip pv rsync socat
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  mariadb-plugin-provider-bzip2 mariadb-plugin-provider-lz4 mariadb-plugin-provider-lzma mariadb-plugin-provider-lzo mariadb-plugin-provider-snappy mariadb-server phpmyadmin-ynh-deps
0 upgraded, 0 newly installed, 7 to remove and 18 not upgraded.
After this operation, 56.8 MB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 68404 files and directories currently installed.)
Removing mariadb-plugin-provider-bzip2 (1:10.11.11-0+deb12u1) ...
Removing mariadb-plugin-provider-lz4 (1:10.11.11-0+deb12u1) ...
Removing mariadb-plugin-provider-lzma (1:10.11.11-0+deb12u1) ...
Removing mariadb-plugin-provider-lzo (1:10.11.11-0+deb12u1) ...
Removing mariadb-plugin-provider-snappy (1:10.11.11-0+deb12u1) ...
Removing phpmyadmin-ynh-deps (5.2.2~ynh1) ...
Removing mariadb-server (1:10.11.11-0+deb12u1) ...
Processing triggers for man-db (2.11.2-2) ...

NOTA: cette commande supprime aussi 5 packages de plugins (mariadb-plugin-provider-bzip2, lz4, lzma, lzo, snappy) et le package phpmyadmin-ynh-deps. Ils sont peut-être utiles...

J'installe la nouvelle version avec sudo apt-get install mariadb-server galera-4 mariadb-client libmariadb3 mariadb-backup mariadb-common.

Résultat de la commande

twr_admin@apps:~$ sudo apt-get install mariadb-server galera-4 mariadb-client libmariadb3 mariadb-backup mariadb-common
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  liblzo2-2 libsnappy1v5 libzip4 php-common php8.3 php8.3-cli php8.3-common php8.3-curl php8.3-fpm php8.3-mbstring php8.3-mysql php8.3-opcache php8.3-readline php8.3-xml php8.3-zip
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  mariadb-client-compat mariadb-client-core mariadb-server-compat mariadb-server-core mysql-common
Suggested packages:
  mariadb-test
The following NEW packages will be installed:
  mariadb-backup mariadb-client-compat mariadb-server mariadb-server-compat
The following packages will be upgraded:
  galera-4 libmariadb3 mariadb-client mariadb-client-core mariadb-common mariadb-server-core mysql-common
7 upgraded, 4 newly installed, 0 to remove and 11 not upgraded.
Need to get 34.5 MB of archives.
After this operation, 134 MB of additional disk space will be used.
N: Ignoring file 'mariadb.list.old_1' in directory '/etc/apt/sources.list.d/' as it has an invalid filename extension
Do you want to continue? [Y/n] 
Get:1 https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/debian bookworm/main amd64 mysql-common all 1:11.4.7+maria~deb12 [3,056 B]
Get:2 https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/debian bookworm/main amd64 mariadb-common all 1:11.4.7+maria~deb12 [4,188 B]
Get:3 https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/debian bookworm/main amd64 mariadb-server-core amd64 1:11.4.7+maria~deb12 [7,695 kB]
Get:4 https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/debian bookworm/main amd64 mariadb-client amd64 1:11.4.7+maria~deb12 [3,034 kB]
Get:5 https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/debian bookworm/main amd64 mariadb-client-core amd64 1:11.4.7+maria~deb12 [877 kB]
Get:6 https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/debian bookworm/main amd64 libmariadb3 amd64 1:11.4.7+maria~deb12 [159 kB]
Get:7 https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/debian bookworm/main amd64 galera-4 amd64 26.4.22-deb12 [11.9 MB]
Get:8 https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/debian bookworm/main amd64 mariadb-server amd64 1:11.4.7+maria~deb12 [3,786 kB]
Get:9 https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/debian bookworm/main amd64 mariadb-backup amd64 1:11.4.7+maria~deb12 [7,057 kB]
Get:10 https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/debian bookworm/main amd64 mariadb-client-compat all 1:11.4.7+maria~deb12 [4,532 B]
Get:11 https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/debian bookworm/main amd64 mariadb-server-compat all 1:11.4.7+maria~deb12 [3,424 B]                                             
Fetched 34.5 MB in 6s (5,624 kB/s)                                                                                                                                                           
Reading changelogs... Done
N: Ignoring file 'mariadb.list.old_1' in directory '/etc/apt/sources.list.d/' as it has an invalid filename extension
Preconfiguring packages ...
(Reading database ... 68276 files and directories currently installed.)
Preparing to unpack .../mysql-common_1%3a11.4.7+maria~deb12_all.deb ...
Unpacking mysql-common (1:11.4.7+maria~deb12) over (5.8+1.1.0) ...
Setting up mysql-common (1:11.4.7+maria~deb12) ...
(Reading database ... 68272 files and directories currently installed.)
Preparing to unpack .../mariadb-common_1%3a11.4.7+maria~deb12_all.deb ...
Unpacking mariadb-common (1:11.4.7+maria~deb12) over (1:10.11.11-0+deb12u1) ...
Setting up mariadb-common (1:11.4.7+maria~deb12) ...
dpkg: considering deconfiguration of mariadb-client, which would be broken by installation of mariadb-client-core ...
dpkg: yes, will deconfigure mariadb-client (broken by mariadb-client-core)
dpkg: considering deconfiguration of mariadb-server-core, which would be broken by installation of mariadb-client-core ...
dpkg: yes, will deconfigure mariadb-server-core (broken by mariadb-client-core)
(Reading database ... 68273 files and directories currently installed.)
Preparing to unpack .../mariadb-client-core_1%3a11.4.7+maria~deb12_amd64.deb ...
De-configuring mariadb-server-core (1:10.11.11-0+deb12u1), to allow installation of mariadb-client-core (1:11.4.7+maria~deb12) ...
De-configuring mariadb-client (1:10.11.11-0+deb12u1), to allow installation of mariadb-client-core (1:11.4.7+maria~deb12) ...
Unpacking mariadb-client-core (1:11.4.7+maria~deb12) over (1:10.11.11-0+deb12u1) ...
Preparing to unpack .../mariadb-client_1%3a11.4.7+maria~deb12_amd64.deb ...
Unpacking mariadb-client (1:11.4.7+maria~deb12) over (1:10.11.11-0+deb12u1) ...
Preparing to unpack .../mariadb-server-core_1%3a11.4.7+maria~deb12_amd64.deb ...
Unpacking mariadb-server-core (1:11.4.7+maria~deb12) over (1:10.11.11-0+deb12u1) ...
Preparing to unpack .../libmariadb3_1%3a11.4.7+maria~deb12_amd64.deb ...
Unpacking libmariadb3:amd64 (1:11.4.7+maria~deb12) over (1:10.11.11-0+deb12u1) ...
Setting up libmariadb3:amd64 (1:11.4.7+maria~deb12) ...
(Reading database ... 68232 files and directories currently installed.)
Preparing to unpack .../galera-4_26.4.22-deb12_amd64.deb ...
Unpacking galera-4 (26.4.22-deb12) over (26.4.20-0+deb12u1) ...
Selecting previously unselected package mariadb-server.
Preparing to unpack .../mariadb-server_1%3a11.4.7+maria~deb12_amd64.deb ...
/var/lib/mysql: found previous version 10.11
Unpacking mariadb-server (1:11.4.7+maria~deb12) ...
Selecting previously unselected package mariadb-backup.
Preparing to unpack .../mariadb-backup_1%3a11.4.7+maria~deb12_amd64.deb ...
Unpacking mariadb-backup (1:11.4.7+maria~deb12) ...
Selecting previously unselected package mariadb-client-compat.
Preparing to unpack .../mariadb-client-compat_1%3a11.4.7+maria~deb12_all.deb ...
Unpacking mariadb-client-compat (1:11.4.7+maria~deb12) ...
Selecting previously unselected package mariadb-server-compat.
Preparing to unpack .../mariadb-server-compat_1%3a11.4.7+maria~deb12_all.deb ...
Unpacking mariadb-server-compat (1:11.4.7+maria~deb12) ...
Setting up galera-4 (26.4.22-deb12) ...
Setting up mariadb-client-core (1:11.4.7+maria~deb12) ...
Setting up mariadb-backup (1:11.4.7+maria~deb12) ...
Setting up mariadb-server-core (1:11.4.7+maria~deb12) ...
Setting up mariadb-client (1:11.4.7+maria~deb12) ...
Installing new version of config file /etc/mysql/mariadb.conf.d/60-galera.cnf ...
Setting up mariadb-client-compat (1:11.4.7+maria~deb12) ...
Setting up mariadb-server (1:11.4.7+maria~deb12) ...
Installing new version of config file /etc/init.d/mariadb ...
Installing new version of config file /etc/mysql/debian-start ...

Configuration file '/etc/mysql/mariadb.conf.d/50-server.cnf'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
  What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
The default action is to keep your current version.
*** 50-server.cnf (Y/I/N/O/D/Z) [default=N] ? Y
Installing new version of config file /etc/mysql/mariadb.conf.d/50-server.cnf ...
Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xeu mariadb.service" for details.
invoke-rc.d: initscript mariadb, action "restart" failed.
× mariadb.service - MariaDB 11.4.7 database server
    Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/mariadb.service.d
            └─migrated-from-my.cnf-settings.conf
    Active: failed (Result: exit-code) since Fri 2025-07-11 15:38:12 CEST; 11ms ago
  Duration: 23h 58min 52.342s
      Docs: man:mariadbd(8)
            https://mariadb.com/kb/en/library/systemd/
    Process: 4038222 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
    Process: 4038223 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
    Process: 4038227 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
    Process: 4038314 ExecStart=/usr/sbin/mariadbd $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=7)
  Main PID: 4038314 (code=exited, status=7)
    Status: "MariaDB server is down"
        CPU: 417ms

Jul 11 15:38:11 apps.cywise.io mariadbd[4038314]: 2025-07-11 15:38:11 0 [Note] Plugin 'wsrep-provider' is disabled.
Jul 11 15:38:11 apps.cywise.io mariadbd[4038314]: 2025-07-11 15:38:11 0 [ERROR] /usr/sbin/mariadbd: unknown variable 'provider_bzip2=force_plus_permanent'
Jul 11 15:38:11 apps.cywise.io mariadbd[4038314]: 2025-07-11 15:38:11 0 [ERROR] /usr/sbin/mariadbd: unknown variable 'provider_lz4=force_plus_permanent'
Jul 11 15:38:11 apps.cywise.io mariadbd[4038314]: 2025-07-11 15:38:11 0 [ERROR] /usr/sbin/mariadbd: unknown variable 'provider_lzma=force_plus_permanent'
Jul 11 15:38:11 apps.cywise.io mariadbd[4038314]: 2025-07-11 15:38:11 0 [ERROR] /usr/sbin/mariadbd: unknown variable 'provider_lzo=force_plus_permanent'
Jul 11 15:38:11 apps.cywise.io mariadbd[4038314]: 2025-07-11 15:38:11 0 [ERROR] /usr/sbin/mariadbd: unknown variable 'provider_snappy=force_plus_permanent'
Jul 11 15:38:11 apps.cywise.io mariadbd[4038314]: 2025-07-11 15:38:11 0 [ERROR] Aborting

NOTA: j'ai fait une copie du fichier de configuration 50-server.cnf (avec cp /etc/mysql/mariadb.conf.d/50-server.cnf ./50-server.cnf.save) avant que la commande ne le remplace car je voudrais y retrouver mes réglages pour que MariaDB profite de la mémoire du serveur.

La commande échoue à démarrer MariaDB car il manque les 5 plugins qui ont été désinstallé ci-dessus. Je vais donc les réinstaller avec la commande sudo apt-get install mariadb-plugin-provider-bzip2 mariadb-plugin-provider-lz4 mariadb-plugin-provider-lzma mariadb-plugin-provider-lzo mariadb-plugin-provider-snappy

Résultat de la commande

twr_admin@apps:~$ sudo apt-get install mariadb-plugin-provider-bzip2 mariadb-plugin-provider-lz4 mariadb-plugin-provider-lzma mariadb-plugin-provider-lzo mariadb-plugin-provider-snappy
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libzip4 php-common php8.3 php8.3-cli php8.3-common php8.3-curl php8.3-fpm php8.3-mbstring php8.3-mysql php8.3-opcache php8.3-readline php8.3-xml php8.3-zip
Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed:
  mariadb-plugin-provider-bzip2 mariadb-plugin-provider-lz4 mariadb-plugin-provider-lzma mariadb-plugin-provider-lzo mariadb-plugin-provider-snappy
0 upgraded, 5 newly installed, 0 to remove and 11 not upgraded.
2 not fully installed or removed.
Need to get 23.4 kB of archives.
After this operation, 180 kB of additional disk space will be used.
Get:1 https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/debian bookworm/main amd64 mariadb-plugin-provider-bzip2 amd64 1:11.4.7+maria~deb12 [4,732 B]
Get:2 https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/debian bookworm/main amd64 mariadb-plugin-provider-lz4 amd64 1:11.4.7+maria~deb12 [4,648 B]
Get:3 https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/debian bookworm/main amd64 mariadb-plugin-provider-lzma amd64 1:11.4.7+maria~deb12 [4,692 B]
Get:4 https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/debian bookworm/main amd64 mariadb-plugin-provider-lzo amd64 1:11.4.7+maria~deb12 [4,620 B]
Get:5 https://dlm.mariadb.com/repo/mariadb-server/11.4/repo/debian bookworm/main amd64 mariadb-plugin-provider-snappy amd64 1:11.4.7+maria~deb12 [4,672 B]
Fetched 23.4 kB in 2s (11.7 kB/s)                          
Selecting previously unselected package mariadb-plugin-provider-bzip2.
(Reading database ... 68395 files and directories currently installed.)
Preparing to unpack .../mariadb-plugin-provider-bzip2_1%3a11.4.7+maria~deb12_amd64.deb ...
Unpacking mariadb-plugin-provider-bzip2 (1:11.4.7+maria~deb12) ...
Selecting previously unselected package mariadb-plugin-provider-lz4.
Preparing to unpack .../mariadb-plugin-provider-lz4_1%3a11.4.7+maria~deb12_amd64.deb ...
Unpacking mariadb-plugin-provider-lz4 (1:11.4.7+maria~deb12) ...
Selecting previously unselected package mariadb-plugin-provider-lzma.
Preparing to unpack .../mariadb-plugin-provider-lzma_1%3a11.4.7+maria~deb12_amd64.deb ...
Unpacking mariadb-plugin-provider-lzma (1:11.4.7+maria~deb12) ...
Selecting previously unselected package mariadb-plugin-provider-lzo.
Preparing to unpack .../mariadb-plugin-provider-lzo_1%3a11.4.7+maria~deb12_amd64.deb ...
Unpacking mariadb-plugin-provider-lzo (1:11.4.7+maria~deb12) ...
Selecting previously unselected package mariadb-plugin-provider-snappy.
Preparing to unpack .../mariadb-plugin-provider-snappy_1%3a11.4.7+maria~deb12_amd64.deb ...
Unpacking mariadb-plugin-provider-snappy (1:11.4.7+maria~deb12) ...
Setting up mariadb-server (1:11.4.7+maria~deb12) ...
Setting up mariadb-plugin-provider-bzip2 (1:11.4.7+maria~deb12) ...
Setting up mariadb-plugin-provider-lzma (1:11.4.7+maria~deb12) ...
Setting up mariadb-plugin-provider-lzo (1:11.4.7+maria~deb12) ...
Setting up mariadb-plugin-provider-lz4 (1:11.4.7+maria~deb12) ...
Setting up mariadb-server-compat (1:11.4.7+maria~deb12) ...
Setting up mariadb-plugin-provider-snappy (1:11.4.7+maria~deb12) ...

Le temps de prendre mes notes, je constate que MariaDB est démarré.

phpMyAdmin fonctionne et me confirme que je suis bien en version 11.4.7 :

Server version: 11.4.7-MariaDB-deb12 - mariadb.org binary distribution

Comme la doc le demande, je lance la commande sudo mariadb-upgrade mais c'est déjà fait :

twr_admin@apps:~$ sudo mariadb-upgrade
This installation of MariaDB is already upgraded to 11.4.7-MariaDB.
There is no need to run mariadb-upgrade again.
You can use --force if you still want to run mariadb-upgrade

Mise à jour de MariaDB de 11.4 vers 11.8¶

Je refais la même opération pour mettre à jour MariaDB de la version 11.4 vers la version 11.8.

Je lance le script avec une option pour utiliser MariaDB 11.8 :

sudo ./mariadb_repo_setup --mariadb-server-version="mariadb-11.8"

Le script met en place le fichier /etc/apt/sources.list.d/mariadb.list dans lequel on trouve bien la version 11.8 :

deb [arch=amd64,arm64] https://dlm.mariadb.com/repo/mariadb-server/11.8/repo/debian bookworm main

J'arrête Maria DB avec sudo systemctl stop mariadb.

Je supprime l'ancienne version avec sudo apt-get remove mariadb-server.

Résultat de la commande

twr_admin@apps:~$ sudo apt-get remove mariadb-server
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libcgi-fast-perl libcgi-pm-perl libfcgi-bin libfcgi-perl libfcgi0ldbl libhtml-template-perl liblzo2-2 libsnappy1v5 libzip4 mariadb-server-core php-common php8.3 php8.3-cli php8.3-common
  php8.3-curl php8.3-fpm php8.3-mbstring php8.3-mysql php8.3-opcache php8.3-readline php8.3-xml php8.3-zip pv rsync socat
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  mariadb-plugin-provider-bzip2 mariadb-plugin-provider-lz4 mariadb-plugin-provider-lzma mariadb-plugin-provider-lzo mariadb-plugin-provider-snappy mariadb-server mariadb-server-compat
0 upgraded, 0 newly installed, 7 to remove and 19 not upgraded.
After this operation, 55.9 MB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 68419 files and directories currently installed.)
Removing mariadb-plugin-provider-bzip2 (1:11.4.7+maria~deb12) ...
Removing mariadb-plugin-provider-lz4 (1:11.4.7+maria~deb12) ...
Removing mariadb-plugin-provider-lzma (1:11.4.7+maria~deb12) ...
Removing mariadb-plugin-provider-lzo (1:11.4.7+maria~deb12) ...
Removing mariadb-plugin-provider-snappy (1:11.4.7+maria~deb12) ...
Removing mariadb-server-compat (1:11.4.7+maria~deb12) ...
Removing mariadb-server (1:11.4.7+maria~deb12) ...
Processing triggers for man-db (2.11.2-2) ...

NOTA: cette commande supprime à nouveau les 5 packages de plugins (mariadb-plugin-provider-bzip2, lz4, lzma, lzo, snappy).

J'installe la nouvelle version avec sudo apt-get install mariadb-server galera-4 mariadb-client libmariadb3 mariadb-backup mariadb-common.

J'obtiens les mêmes erreurs que ci-dessus à cause des 5 packages manquants donc je les ré-installe avec sudo apt-get install mariadb-plugin-provider-bzip2 mariadb-plugin-provider-lz4 mariadb-plugin-provider-lzma mariadb-plugin-provider-lzo mariadb-plugin-provider-snappy.

Après cette installation, je constate à nouveau que le service MariaDB est démarré, que phpMyAdmin fonctionne et que je suis bien en version 11.8 :

Server version: 11.8.2-MariaDB-deb12 - mariadb.org binary distribution

2025-07-10¶

Backups des bases de données MariaDB

Concerns

Je n'ai pas de système de backups des bases de données MariaDB sur les instances YunoHost. A part les backup de ISTA avec restic. J'ai repris ma stack swarm01 et je l'ai adaptée pour pouvoir la publier avec Towerify CLI : https://github.com/computablefacts/towerify-mysql-backup.

Je l'ai déployée sur l'instance yunohost-cywise et sur l'instance yunohost-addapps.

Les backups sont bien faits et envoyés sur le bucket S3 towerify-backups-mysql.

2025-07-09¶

Copie v0.x databases

Concerns

Resource - server - yunohost-cywise

Objectifs¶

Cywise v1.x (nextgen) a besoin d'accéder aux données de Cywise v0.x afin de les importer. Comme la v1.x et la v0.x ne sont pas déployées sur la même instance YunoHost, il faut copier les bases de données 0.x vers la machine yunohost-cywise.

Réflexions¶

La base de DEV pèse 20Go et la base de PROD pèse 32Go. Utilise mysqldump pour transférer les bases de données ne me semble pas une bonne idée vues leur taille. J'envisage plutôt de faire une copie des fichiers binaires de MySQL avec rsync.

Mise en place¶

Connexion SSH entre les 2 machines¶

Je crée un utilisateur YunoHost cywise_db_sync avec les droits SSH :

sudo yunohost user create cywise_db_sync --fullname "Cywise DB Sync" --password "EyUE2GW6EoZynembK56a2Cof" --domain dev.cywise-ui.myapps.addapps.io
sudo yunohost user permission add ssh.main cywise_db_sync

Je peux donc maintenant me connecter en SSH à l'instance yunohost-addapps depuis la machine yunohost-cywise cet utilisateur :

ssh cywise_db_sync@51.15.140.162

Pour éviter d'utiliser le mot de passe, je crée une paire de clés SSH sur la machine yunohost-cywise pour l'utilisateur twr_admin avec lequel j'y suis connecté :

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_cywise_db_sync

NOTA : avant, j'ai dû mettre les bons droits sur le dossier .ssh avec sudo chown -R twr_admin:twr_admin ~/.ssh/

Puis, j'ajoute la clé publique dans les clés autorisées de l'utilisateur cywise_db_sync.

sudo mkdir -p /home/cywise_db_sync/.ssh
echo 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMS0TInSDSwgfRSNOg1cDBepGwAelQnlgn+fYe1mAydR twr_admin@apps.cywise.io' \
    | sudo tee /home/cywise_db_sync/.ssh/authorized_keys
sudo chown -R cywise_db_sync:cywise_db_sync /home/cywise_db_sync/.ssh
sudo chmod 700 /home/cywise_db_sync/.ssh
sudo chmod 600 /home/cywise_db_sync/.ssh/authorized_keys

Je peux maintenant me connecter en SSH à l'instance yunohost-addapps depuis la machine yunohost-cywise avec la commande suivante :

ssh -i ~/.ssh/id_ed25519_cywise_db_sync cywise_db_sync@51.15.140.162

Copie de la base de données Cywise v0.x DEV¶

Je crée le répertoire de destination sur l'instance yunohost-cywise :

sudo mkdir -p /var/lib/mysql/cywise_ui_dev/
sudo chown mysql:mysql /var/lib/mysql/cywise_ui_dev/
sudo chmod 700 /var/lib/mysql/cywise_ui_dev/

Afin que mon utilisateur cywise_db_sync puisse avoir le droit de lire dans le répertoire /var/lib/mysql/cywise_ui_dev/, je dois ajouter l'utilisateur cywise_db_sync dans le groupe mysql :

sudo usermod -aG mysql cywise_db_sync

J'ai dû modifier les droits du répertoire /var/lib/mysql/cywise_ui_dev/ car le groupe mysql n'avait pas le droit de lire dans ce répertoire :

sudo chmod g+rx /var/lib/mysql/cywise_ui_dev/

J'ai pu lancer une première synchronisation de la base de données Cywise v0.x DEV avec la commande suivante :

sudo rsync -avz -e "ssh -i /home/twr_admin/.ssh/id_ed25519_cywise_db_sync" cywise_db_sync@51.15.140.162:/var/lib/mysql/cywise_ui_dev/ /var/lib/mysql/cywise_ui_dev/

En rafraîchissant la page de phpMyAdmin, je vois la base de données cywise_ui_dev apparaître. Je vois aussi les tables et les vues. Mais, en cliquant sur une table, j'ai l'erreur suivante :

#1932 - Table 'cywise_ui_dev.addresses' doesn't exist in engine

Je redémarrage mysql avec la commande sudo systemctl restart mysql.service mais cela ne change rien.

Je n'ai pas la même version de MySQL (MariaDB) sur les 2 machines : - yunohost-addapps : MariaDB 10.5.29 - yunohost-cywise : MariaDB 10.11.11

Je lis que je devrais faire sudo mariadb-upgrade --force sur la machine yunohost-cywise. Mais cela génère une erreur pour chaque table :

Repairing tables
cywise_ui_dev.addresses
Error    : Table 'cywise_ui_dev.addresses' doesn't exist in engine
status   : Operation failed
cywise_ui_dev.adjustments
Error    : Table 'cywise_ui_dev.adjustments' doesn't exist in engine
status   : Operation failed
...

Cela pourrait être dû à la copie des fichiers que je fais sans arrêter le service MySQL. J'arrête donc le service MySQL sur la machine yunohost-addapps, je relance la commande rsync puis je redémarre le service MySQL sur la machine yunohost-addapps.

J'ai toujours la même erreur.

Je redémarre le service MySQL sur la machine yunohost-cywise : même erreur.

Je relance la commande mariadb-upgrade --force : même erreur.

Je vais donc abandonner cette méthode de copie des fichiers binaires de MySQL.

Je supprime donc les fichiers copiés dans le répertoire /var/lib/mysql/cywise_ui_dev/ sur la machine yunohost-cywise :

sudo rm -rf /var/lib/mysql/cywise_ui_dev/

Tunnel SSH¶

Comme j'ai déjà créé un utilisateur YunoHost cywise_db_sync avec les droits SSH, je peux créer un tunnel SSH entre la machine yunohost-cywise et la machine yunohost-addapps pour accéder à la base de données Cywise v0.x DEV (cywise_ui_dev) avec cette commande :

nohup ssh -i ~/.ssh/id_ed25519_cywise_db_sync -N -T -o StrictHostKeyChecking=no -o ExitOnForwardFailure=yes -L 33306:127.0.0.1:3306 cywise_db_sync@51.15.140.162 &

NOTA : j'utilise le port 33306 pour éviter les conflits avec le port 3306 de la machine yunohost-cywise.

NOTA 2 : j'utilise nohup pour que le tunnel SSH reste actif même si je ferme ma session.

NOTA 3 : je peux utiliser pkill -f id_ed25519_cywise_db_sync pour arrêter le tunnel SSH.

Je peux accèder aux MySQL avec la commande mysql -h 127.0.0.1 -P 33306 -u cywise_ui_dev -p mais impossible d'établir une connexion depuis un container Docker. Pour ça, démarrer le tunnel sur les autres IPs de la machine (pas que localhost).

nohup ssh -i ~/.ssh/id_ed25519_cywise_db_sync -N -T -o StrictHostKeyChecking=no -o ExitOnForwardFailure=yes -L 0.0.0.0:33306:127.0.0.1:3306 cywise_db_sync@51.15.140.162 &

Il faut également ajouter GatewayPorts yes dans le fichier /etc/ssh/sshd_config et redémarrer le service SSH avec sudo systemctl restart sshd.

Enfin, j'ai dû autoriser les IPs des containers Docker à accéder au port 33306 avec les commandes suivantes :

sudo iptables -A INPUT -p tcp --dport 33306 -s 172.17.0.0/12 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 33306 -s 192.168.0.0/16 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 33306 -s 10.0.0.0/8 -j ACCEPT

Conversion des données DEV¶

Pour faire propre, je vais supprimer le contenu de la nouvelle base (cywise_ui_ngdev) puis relancer le scheduler (la stack) pour que les données soient importées depuis la base de données cywise_ui_dev.

Arrêt de la stack : sudo systemctl stop cywise-ui_ngdev.service.

Je supprime toutes les tables de la base de données cywise_ui_ngdev depuis phpMyAdmin.

Démarrage de la stack : sudo systemctl start cywise-ui_ngdev.service.

Le scheduler a bien convertit les données depuis la base de données cywise_ui_dev vers la base de données cywise_ui_ngdev sans erreur. Durée = environ 9 minutes.

2025-07-08¶

Accès tunnel SSH pour Angardia

Concerns

Resource - server - angardia-ai

Les commandes fournies par Cédric de Angardia.

Celles permettant de créer un utilisateur et de lui donner les droits pour faire un tunnel SSH :

adduser --disabled-password --gecos "" --shell /usr/sbin/nologin natsworker
echo 'command="echo Tunnel only",permitopen="localhost:4223",no-agent-forwarding,no-X11-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEoUevl/DE2vnlRE0NkTt1OMGMQ+E1dQctdEcNnrc4CQ' \
    > /home/natsworker/.ssh/authorized_keys
chown -R natsworker:natsworker /home/natsworker/.ssh \
    && chmod 700 /home/natsworker/.ssh \
    && chmod 600 /home/natsworker/.ssh/authorized_keys

Celle permettant de créer le tunnel SSH :

ssh -i /private_key -N -T -o StrictHostKeyChecking=no -o ExitOnForwardFailure=yes -L 4222:localhost:4223 natsworker@test_host

Principe¶

Cédric va ajouter un container à la stack Angardia qui doit communiquer avec l'application qu'il fait tourner sur RunPod. Pour cela il va établir un tunnel SSH entre le container et l'application RunPod.

Il faut que le container expose un port "en dehors" de la stack donc visible depuis localhost sur le serveur YunoHost. Il faut un utilisateur sur le serveur YunoHost qui puisse faire un tunnel SSH.

Réflexions¶

Comme les containers de la stack Angardia sont déployés avec Towerify CLI, je voudrais que le port pour le tunnel SSH soit créer durant le déploiement. J'aimerai que ce soit la même chose pour l'utilisateur SSH.

Après quelques recherches, il est facile d'ajouter un port avec le package YunoHost. Il suffit de modifier le fichier manifest.toml pour ajouter 1 ligne dans la section resources.ports :

[resources.ports]
# This will pick a random port for reverse-proxying and store it as the $port setting
# Add an extra port found in $port_extra
extra.exposed=false

J'ai testé et ce port supplémentaire est bien créé durant l'installation du package YunoHost mais aussi durant la mise à jour du package YunoHost. Donc un port supplémentaire sera créé lors du prochain déploiement de la stack Angardia.

Pour l'utilisateur SSH, c'est plus compliqué. Ce n'est pas prévu dans la définition d'un package YunoHost de pouvoir ajouter un utilisateur. J'ai pensé utiliser les hooks ou ajouter un script qui crée l'utilisateur mais c'est complexe. J'ai pensé utiliser l'utilisateur créé qui a le même nom que l'application installée mais il n'a pas de droits SSH par défaut et ce n'est pas simple de les lui donner.

J'ai finalement décidé de créer un utilisateur YunoHost, de lui donner les droits SSH en le mettant dans le groupe ssh.main de YunoHost puis d'ajouter la clé publique dans le fichier authorized_keys de cet utilisateur.

Mise en place (DEV)¶

Le port supplémentaire pour le DEV est 55746. J'y ai associé un service de test avec :

services:
  nats:
    image: mendhak/http-https-echo:33
    ports:
      - target: 8080
        published: __PORT_EXTRA__
    extra_hosts:
      host.docker.internal: host-gateway
    env_file:
      - .env
    environment:
      - PORT_EXTRA=__PORT_EXTRA__

J'ai créé un utilisateur YunoHost et je lui ai donné les droits SSH avec les commandes suivantes :

sudo yunohost user create angardia_ai_dev_ssh --fullname "Angardia AI DEV SSH" --password MTb6mQEduGHwo3AW5z4tGv5w --domain dev.app.angardia.ai
sudo yunohost user permission add ssh.main angardia_ai_dev_ssh

J'ai ajouté la clé publique dans le fichier authorized_keys de l'utilisateur avec les commandes suivantes :

sudo mkdir -p /home/angardia_ai_dev_ssh/.ssh
echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDah7RARA035UA5H4lsaLBb4tqIkFZBv318ZVZmuFHvzAnO3nX4Ze81xucMirxBo6udrtVcH28IPOurYSqHXSaPjxGkptRo2cVA1I1qjJMWjlgmNcjHfrfjRK4+zr+EY9VUIYqbSoRmRowWb6N2WrulOWJct0adQ47ZFEY9XpxZG2raAk2dkSjBioNBuc+3U9SSfLvFmkhU/Jek7+G8S/CGXWUG42R2XcmovgeW136LB9FASnITYXkJOt0jgPmhPpYlteHWP1Su3pOP1lpbyF4nqPpgdHYDqIYJkzHYV4XDWLj9GWlHJtpIug076cZ32+WE4GYOD4kvbIOJbYr4I+y/ patrick@SpectreMate' \
    | sudo tee /home/angardia_ai_dev_ssh/.ssh/authorized_keys
echo 'command="echo Tunnel only",permitopen="localhost:4223",no-agent-forwarding,no-X11-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEoUevl/DE2vnlRE0NkTt1OMGMQ+E1dQctdEcNnrc4CQ' \
    | sudo tee -a /home/angardia_ai_dev_ssh/.ssh/authorized_keys
sudo chown -R angardia_ai_dev_ssh:angardia_ai_dev_ssh /home/angardia_ai_dev_ssh/.ssh
sudo chmod 700 /home/angardia_ai_dev_ssh/.ssh
sudo chmod 600 /home/angardia_ai_dev_ssh/.ssh/authorized_keys

J'ai ensuite testé la connexion SSH avec la commande suivante :

ssh -i ~/.ssh/id_rsa -N -T -o StrictHostKeyChecking=no -o ExitOnForwardFailure=yes -L 4567:127.0.0.1:55746 angardia_ai_dev_ssh@51.159.101.88

Et cela fonctionne bien. J'ai pu accéder au service de test avec l'URL http://localhost:4567/.

2025-07-02¶

Déploiement du serveur yunohost-cywise depuis Cywise (suite)

Concerns

Resource - server - yunohost-cywise

Installation de Jenkins¶

J'ai mis à jour notre package jenkins_ynh en récupérant la dernière version de la version d'origine https://github.com/YunoHost-Apps/jenkins_ynh qui est en version 2.517~ynh1.

J'ai relancé l'installation de Jenkins depuis le SSH en rejouant la commande de Cywise :

sudo yunohost app install https://github.com/computablefacts/jenkins_ynh/tree/cf-prod -a "domain=jenkins.apps.cywise.io&path=/" --force

Et, cette fois, Jenkins s'est bien installé.

Comme j'avais fait l'installation puis des upgrade

Installation de phpMyAdmin¶

Installation depuis Cywise. RAS.

Surveillance de l'instance¶

Je fais la commande donnée par Cywise :

curl -s https://app.cywise.io/update/YrOMNqbUIprWYOekLfe4RtlpuImhHS | bash

Droits d'accès à Patrick et Cyrille¶

Depuis Cywise PROD avec engineering, j'ai ajouté les droits d'accès à Patrick Brisacier (pbrisacier@mncc.fr).

TODO : je n'ai pas trouvé le compte de Cyrille i.e. "Cyrille Savelief" qui est utilisé sur AddApps.

Premier test Towerify CLI¶

Comme je l'avais noté lors de l'installation de la machine pour Angardia, il faut modifier un paramètre YunoHost pour jenkins afin que Towerify CLI puisse s'authentifier à Jenkins (pour que l'entête Authorization soit transmise à Jenkins).

Il faut mettre l'option à false avec la commande :

sudo yunohost app setting jenkins protect_against_basic_auth_spoofing -v false

Regénérer la conf de SSOwat avec :

sudo yunohost app ssowatconf

Puis redémarrer nginx avec :

sudo systemctl reload nginx.service

Après cela, j'ai pu créer un nouveau profil pour Towerify CLI avec la commande :

towerify configure --profile cywise --domain apps.cywise.io --login pbrisacier

Puis, j'ai pu déployer un projet de test avec la commande :

[17:40:59]$ towerify deploy --profile cywise
Tentative de connexion à Towerify ..................................................... [OK]
Vérification du pipeline de déploiement ..................................... [confirmation]
C'est la première fois que vous déployez cette application pour :
- le profil cywise (apps.cywise.io)
- l'environnement dev

? Voulez-vous continuer ?
1) Oui
2) Non
Votre choix : 1
Vérification du pipeline de déploiement ............................................... [OK]
Envoi des secrets ..................................................................... [OK]
Compression des fichiers de votre application ......................................... [OK]
Lancement du déploiement .............................................................. [OK]
Le job est terminé avec le statut : SUCCESS ........................................... [OK]
==> Le job a réussi.
Application compressée dans ./towerify/dev/app.20250703-174600.tar.gz

Vous pouvez accéder à votre application avec :
https://dev.debug-towerify-cli.apps.cywise.io/

Déploiement du serveur yunohost-cywise depuis Cywise

Concerns

Resource - server - yunohost-cywise

Préparation des DNS¶

YunoHost sera installé sur le domaine apps.cywise.io. J'ai donc mis en place les enregistrements DNS suivants dans Gandi :

apps.cywise.io A 51.159.100.198
apps.cywise.io AAAA 2001:bc8:1201:38:46a8:42ff:fe18:d621
*.apps.cywise.io CNAME apps.cywise.io

Installation de YunoHost¶

J'ai tenté d'installer YunoHost depuis Cywise mais cela ne fonctionne plus. Dès le départ, quand je veux ajouter un serveur YunoHost, j'ai une erreur 500 dû à la mise en place des Procedure pour notre API.

Je préfère ne pas corriger le problème car cela va me prendre du temps, je devrais publier en PROD et c'est la branche 0.x que nous allons bientôt abandonner.

Je vais donc déployer "à la main" mais en utilisant les scripts de Cywise.

??? Script d'installation de YunoHost

```bash
#!/bin/bash
apt-get install ca-certificates curl jq -y
apt-get remove bind9 --purge --autoremove -y
export SUDO_FORCE_REMOVE=yes

cp /root/.ssh/authorized_keys /root/.ssh/authorized_keys.bak

#### curl https://install.yunohost.org | bash -s -- -a
curl https://install.yunohost.org -o yunohost_install_script
chmod +x yunohost_install_script
./yunohost_install_script -a
rm yunohost_install_script

yunohost tools postinstall --force-diskspace --domain apps.cywise.io --username twr_admin --fullname "Towerify Admin" --password "Vnsi4ezXHm69M3Y7tQVXSyPa"
yunohost settings set security.password.passwordless_sudo -v yes
yunohost settings set ssowat.panel_overlay.enabled -v False
yunohost diagnosis run --force
yunohost domain cert install apps.cywise.io
yunohost user permission add ssh.main twr_admin
yunohost user permission add sftp.main twr_admin

mkdir -p /home/twr_admin/.ssh
cp /root/.ssh/authorized_keys.bak /home/twr_admin/.ssh/authorized_keys
rm /root/.ssh/authorized_keys.bak
chown twr_admin:twr_admin /home/twr_admin/.ssh/authorized_keys
```

Où j'ai remplacé les variables suivantes :

- `{$domain}` par `apps.cywise.io`
- `{$username}` par `twr_admin`
- `{$password}` par `Vnsi4ezXHm69M3Y7tQVXSyPa`

Enfin, j'ai copié le script dans /root/install-yunohost.sh et je l'ai lancé.

La commande `yunohost settings set ssowat.panel_overlay.enabled -v False` affiche une 
erreur : `Error: The filter key 'ssowat.panel_overlay.enabled' is incorrect.`. 
Certainement dû à la version de YunoHost qui est maintenant la version 12.

YunoHost est installé et fonctionnel.

Je veux créer un serveur YunoHost dans la base de Cywise PROD. J'ai pris une entrée existante (créée avant l'erreur 500) et j'ai modifié les champs suivants :

name : yunohost-cywise
ip_address : 51.159.100.198
ssh_username : twr_admin
user_id : 17
is_ready : 1

Grâce au user_id, je peux voir ce serveur avec mon compte pbrisacier@mncc.fr

Il y avait déjà la paire de clés SSH dans ssh_public_key et ssh_private_key. J'ai utilisé php artisan tinker pour récupérer la commande permettant d'ajouter la clé publique dans les clés autorisées de l'utilisateur twr_admin :

> $cywiseKeyPair = new SshKeyPair()
> $cywiseKeyPair->init2("`ssh_public_key`", "`ssh_private_key`")
> $cywiseKeyPair->echoAuthorizedKey()
= "echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQD75yw/Eif+QrhhzqRemLUeaaofKm0IS6imREUR+J/K56cdqfTRAflWMJLrGGpSvjQTKGjK0JQO+BvlGPHlIzM1QxYRRkgttw/F6/9DQNBhgSiLphEzz9ZXfin5Z7FIMgsu/eYnZgTqsF+5WS3B3orkzVKwacwLErpbg1dL7XJnK6OJ1J2OaIHIIjxkGHHqofTT56SMPP02+tOi1dYYxqmyWLzy/PUXLhKOWZVmnSZB5JUyKOiPOJAyX5/safxHvomeMhqFh25mvfeUQOHZWAnl/oqJ8VJ1fP6Ay0nGwTfh/+OBbPf0U0JxNn+9a3gYUSAadkxklrmP1LrHwCdGS8ZiYqmnhfIZVH0FEByMq1chyc8DXwaAhVPdk5Hl8AtEAEsx8yJGuuXhLK2Ux8voaHeZBHMi17gllsJr3lIG2cpNAZKaSM+dDzeDiuPsJhBr8HmISTGpBE7JEqaC+X7e1m0O/02783/GGAiHRrLt8iX/+v59QH3wcb+u3m0xsRlzA3UeEin3kZ/P044yqN25uIHc0zFs58fRlHOFjf+uFRGbxM9hdkwy1Zw9gx5p9/M+zkjIvIqFCAoo1pFTDNZSALKT0BEgfdrBvFsnHV+2gJfc/WuzS0dDsJpQmgZoROyJtKQRCv7F6qHlxdm6EcwzJdBKVQWheU74OZnzo/5xc969Jw== phpseclib-generated-key" >>~/.ssh/authorized_keys"

Puis, j'ai joué cette commande pour ajouter la clé à l'utilisateur twr_admin :

echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQD75yw/Eif+QrhhzqRemLUeaaofKm0IS6imREUR+J/K56cdqfTRAflWMJLrGGpSvjQTKGjK0JQO+BvlGPHlIzM1QxYRRkgttw/F6/9DQNBhgSiLphEzz9ZXfin5Z7FIMgsu/eYnZgTqsF+5WS3B3orkzVKwacwLErpbg1dL7XJnK6OJ1J2OaIHIIjxkGHHqofTT56SMPP02+tOi1dYYxqmyWLzy/PUXLhKOWZVmnSZB5JUyKOiPOJAyX5/safxHvomeMhqFh25mvfeUQOHZWAnl/oqJ8VJ1fP6Ay0nGwTfh/+OBbPf0U0JxNn+9a3gYUSAadkxklrmP1LrHwCdGS8ZiYqmnhfIZVH0FEByMq1chyc8DXwaAhVPdk5Hl8AtEAEsx8yJGuuXhLK2Ux8voaHeZBHMi17gllsJr3lIG2cpNAZKaSM+dDzeDiuPsJhBr8HmISTGpBE7JEqaC+X7e1m0O/02783/GGAiHRrLt8iX/+v59QH3wcb+u3m0xsRlzA3UeEin3kZ/P044yqN25uIHc0zFs58fRlHOFjf+uFRGbxM9hdkwy1Zw9gx5p9/M+zkjIvIqFCAoo1pFTDNZSALKT0BEgfdrBvFsnHV+2gJfc/WuzS0dDsJpQmgZoROyJtKQRCv7F6qHlxdm6EcwzJdBKVQWheU74OZnzo/5xc969Jw== phpseclib-generated-key" >> /home/twr_admin/.ssh/authorized_keys

Enfin, j'ai utilisé la commande "refresh" de l'UI de Cywise PROD pour vérifier que la connexion SSH fonctionne bien.

Installation de Portainer¶

J'ai lancé l'installation de Portainer depuis l'UI de YunoHost.

L'installation s'est bien passée mais la configuration LDAP n'était pas en place. Je l'ai donc faite à la main. Et tout fonctionne bien.

Installation de Jenkins¶

J'ai lancé l'installation de Jenkins depuis l'UI de YunoHost. Pas d'erreur pendant l'installation mais Jenkins ne semble pas être installé.

J'ai donc lancé l'installation de Jenkins depuis le SSH en rejouant la commande de Cywise :

sudo yunohost app install https://github.com/computablefacts/jenkins_ynh/tree/cf-prod -a "domain=jenkins.apps.cywise.io&path=/" --force

Et, effectivement, il y a une erreur durant l'installation :

Info: DEBUG - Plugin prerequisite not met:
Info: DEBUG - mailer (488.v0c9639c1a_eb_3) requires a greater version of Jenkins (2.440.3) than 2.426.1

Mon package YunoHost pour Jenkins installe la version 2.426.1 alors que la dernière version en date est 2.517.

Je vais donc mettre à jour mon package YunoHost pour Jenkins avant de retenter l'installation.

2025-07-01¶

Arrêt de l'infrastructure CoreAPI

Concerns

Deprecated: Resource - server - coreapi-1
Deprecated: Resource - server - coreapi-2
Deprecated: Resource - server - ac-master-1
Deprecated: Resource - server - ac-slave-0
Deprecated: Resource - server - ac-slave-1
Deprecated: Resource - server - ac-slave-2
Deprecated: Resource - server - zookeeper-1
Deprecated: Resource - server - zookeeper-2

Lur Berri a résilié son contrat avec nous. Lur Berri était le dernier client à utiliser CoreAPI et l'infra qui va avec (Accumulo, ZooKeeper).

Je vais donc arrêter les 8 machines suivantes :

coreapi-1 - Start-2-M-SATA sd-150972
coreapi-2 - Start-2-M-SATA sd-150973
ac-slave-2 - Start-2-M-SATA sd-150994
ac-slave-1 - Start-2-M-SATA sd-150990
ac-slave-0 - Start-2-M-SATA sd-150995
ac-master-1 - Start-2-M-SATA sd-150975
zookeeper-1 - Start-2-M-SSD sd-150815
zookeeper-2 - Start-2-M-SSD sd-150816

Je n'ai pas la possibilité d'arrêter les machines. J'ai donc ouvert un ticket et c'est le technicien Scaleway qui les a arrêtées le 2025-07-01 vers 8h30

TODO: attendons 2 semaines avant de résilier les 8 machines.

J'ai noté les machines comme deprecated dans cette doc.

J'ai supprimé les 8 surveillances Freshping associées.

2025-06-30¶

Suppression du Superset pour Lur Berri déployé sur swarm01

Concerns

Deprecated: Resource - deployment - lurberri-superset
Deprecated: Resource - storage - prodlurberri_superset

Lur Berri a résilié son contrat avec nous. Je vais donc supprimer le Superset pour Lur Berri déployé sur swarm01.

??? la stack depuis s001 : sudo docker stack rm lurberri-superset

```
ansible@s001:~$ sudo docker stack rm lurberri-superset
Removing service lurberri-superset_redis
Removing service lurberri-superset_superset
Removing service lurberri-superset_superset-init
Removing service lurberri-superset_superset-worker
Removing service lurberri-superset_superset-worker-beat
Removing network lurberri-superset_redis-net
Removing network lurberri-superset_selenium-net
```

Je note ce déploiement comme `deprecated` dans cette doc.

??? le déploiement ansible dans ansible/client-lurberri.yaml

Ce qui revient à supprimer ce fichier car plus rien n'est déployé 
pour Lur Berri.

??? la base MySQL prodlurberri_superset sur swarm01

Je supprime la base de données `prodlurberri_superset` depuis phpMyAdmin.
J'en profite pour supprimer l'utilisateur correspondant : `prolurbersuper`.

Je note cette base comme `deprecated` dans cette doc.

Je supprime la création de la base et de l'utilisateur du playbook ansible `ansible/mysql-stacks.yaml`.

??? Suppression des backups de la base MySQL prodlurberri_superset

Ce sont des backups de la base MySQL. Ils se trouvent dans le bucket S3 swarm01-backups-mysql
dans le dossier `prod-mysql/prodlurberri_superset/`.

J'ai supprimé ce dossier et son contenu.

Suppression de l'environnement de PROD de Lur Berri

Concerns

Deprecated: Resource - deployment - prod-lurberri-cf-ui
Deprecated: Resource - storage - prodlurberri_cfui

Lur Berri a résilié son contrat avec nous. Je vais donc supprimer tout ce qui concerne leur environnement de PROD.

Lur Berri Datalake UI PROD¶

Je supprime la stack qui se trouve sur swarm01 depuis s001.

sudo docker stack rm prod-lurberri-cf-ui

ansible@s001:~$ sudo docker stack rm prod-lurberri-cf-ui
Removing service prod-lurberri-cf-ui_app
Removing service prod-lurberri-cf-ui_queue
Removing service prod-lurberri-cf-ui_scheduler

Je supprime le déploiement dans le playbook ansible de Lur Berri (ansible/client-lurberri.yaml).

Je note ce deploiement comme deprecated dans cette doc.

MySQL database for Lur Berri cf-ui PROD¶

Je supprime la base de données prodlurberri_cfui depuis phpMyAdmin. J'en profite pour supprimer les 3 utilisateurs correspondant : prolurbercfui, prolurbercfuiro et prolurbercfuimater.

Je note cette base comme deprecated dans cette doc.

Je supprime la création de la base et des utilisateurs du playbook ansible ansible/mysql-stacks.yaml.

Suppression des données sur le SFTP¶

Je désactive le compte SFTP de PROD. Voici la taille des données présentes pour Lur Berri sur le SFTP :

sudo du -h -d 1 /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri

ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri
735G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/prod_out
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/dev
7.8G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/prod
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/dev_out
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/staging_out
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/staging
743G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri

J'ai supprimé les données de prod et de prod_out sans supprimer les dossiers eux-mêmes.

sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/prod -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;

ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/prod
total 136K
drwxr-xr-x 34 ansible ansible 4.0K Sep 19  2022 .
drwxr-xr-x  8 ansible ansible 4.0K Mar  7  2022 ..
drwxr-xr-x  4 ansible ansible 4.0K Mar 31  2023 compta-archive-ecritures-analytiques-zhgea
drwxr-xr-x  4 ansible ansible 4.0K Mar 31  2023 compta-archive-ecritures-tiers-zhget
drwxr-xr-x  4 ansible ansible 4.0K Mar 31  2023 compta-archive-ecritures-zhgec
drwxr-xr-x  4 ansible ansible 4.0K Jan  1  2023 compta-ecritures-analytiques-zzgea
drwxr-xr-x  4 ansible ansible 4.0K Jan  1  2023 compta-ecritures-tiers-zzget
drwxr-xr-x  4 ansible ansible 4.0K Jan  1  2023 compta-ecritures-zzgec
drwxr-xr-x  4 ansible ansible 4.0K Jan  1  2023 compta-origines-zzpor
drwxr-xr-x  4 ansible ansible 4.0K Jan  1  2023 compta-plan-comptable-zzgpc
drwxr-xr-x  4 ansible ansible 4.0K Jan  1  2023 compta-tiers-zztie
drwxr-xr-x  4 ansible ansible 4.0K Jan  1  2023 compta-tiers-zztpc
drwxr--r--  4 ansible ansible 4.0K Jul  1  2022 conf
drwxr-xr-x  4 ansible ansible 4.0K Jan  1  2023 eloficash
drwxr-xr-x 28 ansible ansible 4.0K Jun 18 03:38 factures
drwxr-xr-x  6 ansible ansible 4.0K Jan  1 02:53 feedit-parcelles
drwxr-xr-x  4 ansible ansible 4.0K Jan  2  2023 gicab-bovins-stats
drwxr-xr-x  4 ansible ansible 4.0K Apr 19  2023 grc-atc-activite
drwxr-xr-x  3 ansible ansible 4.0K Mar 22  2022 kerhis-table-activite
drwxr-xr-x  4 ansible ansible 4.0K Jan  2  2023 kerhis-table-batiment
drwxr-xr-x  4 ansible ansible 4.0K Jan  2  2023 kerhis-table-ecritures-lignes
drwxr-xr-x  4 ansible ansible 4.0K Jan  2  2023 kerhis-table-entete-ecritures
drwxr-xr-x  4 ansible ansible 4.0K Jan  2  2023 kerhis-table-facture-entete
drwxr-xr-x  4 ansible ansible 4.0K Jan  2  2023 kerhis-table-facture-ligne
drwxr-xr-x  4 ansible ansible 4.0K Jan  2  2023 kerhis-table-paramanalytique
drwxr-xr-x  4 ansible ansible 4.0K Jan  2  2023 kerhis-table-plancomptable
drwxr-xr-x  4 ansible ansible 4.0K Jan  2  2023 kerhis-table-sites
drwxr-xr-x  4 ansible ansible 4.0K Jan  2  2023 kerhis-table-tiers
drwxr-xr-x  4 ansible ansible 4.0K Jan  1  2023 oc-base
drwxr-xr-x  4 ansible ansible 4.0K Jan  1  2023 persone-base
drwxr-xr-x  4 ansible ansible 4.0K Jan  2  2023 persone-pays
drwxr-xr-x  4 ansible ansible 4.0K Jan  2  2023 persone-titre
drwxr-xr-x  3 ansible ansible 4.0K Mar 22  2022 tiers-ca-recapitulatif
drwxr-xr-x  4 ansible ansible 4.0K Jan  2  2023 tms-base
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/prod -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;
ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/prod
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Jul  1 16:08 .
drwxr-xr-x 8 ansible ansible 4.0K Mar  7  2022 ..

sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/prod_out -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;

ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/prod_out
total 140K
drwxr-xr-x 35 ansible ansible 4.0K Sep 19  2022 .
drwxr-xr-x  8 ansible ansible 4.0K Mar  7  2022 ..
drwxr-xr-x  5 ansible ansible 4.0K Mar 31  2023 compta-archive-ecritures-analytiques-zhgea
drwxr-xr-x  5 ansible ansible 4.0K Mar 31  2023 compta-archive-ecritures-tiers-zhget
drwxr-xr-x  5 ansible ansible 4.0K Mar 31  2023 compta-archive-ecritures-zhgec
drwxr-xr-x  5 ansible ansible 4.0K Jan  1  2023 compta-ecritures-analytiques-zzgea
drwxr-xr-x  5 ansible ansible 4.0K Jan  1  2023 compta-ecritures-tiers-zzget
drwxr-xr-x  5 ansible ansible 4.0K Jan  1  2023 compta-ecritures-zzgec
drwxr-xr-x  5 ansible ansible 4.0K Jan  1  2023 compta-origines-zzpor
drwxr-xr-x  5 ansible ansible 4.0K Jan  1  2023 compta-plan-comptable-zzgpc
drwxr-xr-x  5 ansible ansible 4.0K Jan  1  2023 compta-tiers-zztie
drwxr-xr-x  5 ansible ansible 4.0K Jan  1  2023 compta-tiers-zztpc
drwxr-xr-x  4 ansible ansible 4.0K Mar  4  2022 conf
drwxr-xr-x  4 ansible ansible 4.0K Jan  1  2023 eloficash
drwxr-xr-x 18 ansible ansible 4.0K Aug  4  2022 factures
drwxr-xr-x  5 ansible ansible 4.0K Jan  1  2024 feedit-parcelles
drwxr-xr-x  4 ansible ansible 4.0K Jan  2  2023 gicab-bovins-stats
drwxr-xr-x  4 ansible ansible 4.0K Apr 19  2023 grc-atc-activite
drwxr-xr-x  4 ansible ansible 4.0K Mar  4  2022 kerhis-table-activite
drwxr-xr-x  5 ansible ansible 4.0K Jan  2  2023 kerhis-table-batiment
drwxr-xr-x  5 ansible ansible 4.0K Jan  2  2023 kerhis-table-ecritures-lignes
drwxr-xr-x  5 ansible ansible 4.0K Jan  2  2023 kerhis-table-entete-ecritures
drwxr-xr-x  4 ansible ansible 4.0K Jan  2  2023 kerhis-table-facture-entete
drwxr-xr-x  3 ansible ansible 4.0K Mar 22  2022 kerhis-table-Facture-Entete
drwxr-xr-x  5 ansible ansible 4.0K Jan  2  2023 kerhis-table-facture-ligne
drwxr-xr-x  5 ansible ansible 4.0K Jan  2  2023 kerhis-table-paramanalytique
drwxr-xr-x  5 ansible ansible 4.0K Jan  2  2023 kerhis-table-plancomptable
drwxr-xr-x  5 ansible ansible 4.0K Jan  2  2023 kerhis-table-sites
drwxr-xr-x  5 ansible ansible 4.0K Jan  2  2023 kerhis-table-tiers
drwxr-xr-x  4 ansible ansible 4.0K Jan  1  2023 oc-base
drwxr-xr-x  5 ansible ansible 4.0K Jan  1  2023 persone-base
drwxr-xr-x  5 ansible ansible 4.0K Jan  2  2023 persone-pays
drwxr-xr-x  5 ansible ansible 4.0K Jan  2  2023 persone-titre
drwxr-xr-x  3 ansible ansible 4.0K Mar  4  2022 tiers-ca-recapitulatif
drwxr-xr-x  4 ansible ansible 4.0K Jan  2  2023 tms-base
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/prod_out -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;
ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/prod_out
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Jul  1 16:14 .
drwxr-xr-x 8 ansible ansible 4.0K Mar  7  2022 ..

Suppression des données du cache de NiFi¶

NiFi, qui traite les données déposées sur le SFTP et qui est sur la même machine s004, stocke les fichiers qu'il récupère du SFTP dans son dossier tmp.

Je supprime donc les fichiers de lurberri/prod etlurberri/prod_out.

sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/prod sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/prod_out

ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri
277G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/prod_out
169M    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/prod
277G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri
ansible@s004:~$ sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/prod
ansible@s004:~$ sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/prod_out
ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri
4.0K    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri

Suppression des données sur S3¶

NiFi backupe les données déposées sur le SFTP dans le bucket S3 cf-sftp-achives. J'ai donc supprimé le dossier /tmp/sftp/lurberri/prod/ de ce bucket (prod_out n'est pas backupé sur S3).

Notre NiFi précédent backupait les données dans /var/sftp/lurberri/prod/ donc je supprime aussi ce dossier.

Suppression des backups¶

Ce sont des backups de la base MySQL. Ils se trouvent dans le bucket S3 swarm01-backups-mysql dans le dossier prod-mysql/prodlurberri_cfui/.

J'ai supprimé ce dossier et son contenu.

Freshping¶

J'ai supprimé les 2 checks Freshping de Lur Berri PROD (https://www.lurberri.computablefacts.com/healthz et https://www.lurberri.computablefacts.com/login).

Suppression de l'environnement de STAGING de Lur Berri

Concerns

Deprecated: Resource - deployment - staging-lurberri-cf-ui
Deprecated: Resource - storage - staginglurberri_cfui

Lur Berri a résilié son contrat avec nous. Je vais donc supprimer tout ce qui concerne leur environnement de STAGING.

Lur Berri Datalake UI STAGING¶

Je supprime la stack qui se trouve sur swarm01 depuis s001.

sudo docker stack rm staging-lurberri-cf-ui

ansible@s001:~$ sudo docker stack rm staging-lurberri-cf-ui
Removing service staging-lurberri-cf-ui_app
Removing service staging-lurberri-cf-ui_queue
Removing service staging-lurberri-cf-ui_scheduler

Je supprime le déploiement dans le playbook ansible de Lur Berri (ansible/client-lurberri.yaml).

Je note ce deploiement comme deprecated dans cette doc.

MySQL database for Lur Berri cf-ui STAGING¶

Je supprime la base de données staginglurberri_cfui depuis phpMyAdmin. J'en profite pour supprimer les 2 utilisateurs correspondant : stalurbercfui et stalurbercfuimater.

Je note cette base comme deprecated dans cette doc.

Je supprime la création de la base et des utilisateurs du playbook ansible ansible/mysql-stacks.yaml.

Suppression des données sur le SFTP¶

Je désactive le compte SFTP de STAGING. Voici la taille des données présentes pour Lur Berri sur le SFTP :

sudo du -h -d 1 /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri

ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri
735G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/prod_out
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/dev
7.8G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/prod
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/dev_out
12K /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/staging_out
8.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/staging
743G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri

J'ai supprimé les données de staging et de staging_out sans supprimer les dossiers eux-mêmes.

sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/staging -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;

ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/staging
total 12K
drwxr-xr-x 3 ansible ansible 4.0K Mar 21  2022 .
drwxr-xr-x 8 ansible ansible 4.0K Mar  7  2022 ..
drwxr-xr-x 2 ansible ansible 4.0K Mar 21  2022 conf
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/staging -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;
ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/staging
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Jul  1 08:54 .
drwxr-xr-x 8 ansible ansible 4.0K Mar  7  2022 ..

sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/staging_out -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;

ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/staging_out
total 12K
drwxr-xr-x 3 ansible ansible 4.0K Mar 21  2022 .
drwxr-xr-x 8 ansible ansible 4.0K Mar  7  2022 ..
drwxr-xr-x 2 ansible ansible 4.0K Mar 21  2022 conf
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/staging_out -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;
ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/staging_out
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Jul  1 08:55 .
drwxr-xr-x 8 ansible ansible 4.0K Mar  7  2022 ..

Suppression des données du cache de NiFi¶

NiFi, qui traite les données déposées sur le SFTP et qui est sur la même machine s004, stocke les fichiers qu'il récupère du SFTP dans son dossier tmp.

Je supprime donc les fichiers de lurberri/staging etlurberri/staging_out.

sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/staging sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/staging_out

ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri
277G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/prod_out
169M    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/prod
277G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri
ansible@s004:~$ sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/staging
ansible@s004:~$ sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/staging_out
ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri
277G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/prod_out
169M    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/prod
277G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri

NOTA : aucune donnée supprimée car Lur Berri n'utilisait pas l'environnement de STAGING.

Suppression des données sur S3¶

NiFi backupe les données déposées sur le SFTP dans le bucket S3 cf-sftp-achives. Pas de donnée dans le dossier /tmp/sftp/lurberri/staging/ ni dans /var/sftp/lurberri/staging/ puisque Lur Berri n'utilisait pas l'environnement de STAGING.

Rien à supprimer donc.

Suppression des backups¶

Ce sont des backups de la base MySQL. Ils se trouvent dans le bucket S3 swarm01-backups-mysql dans le dossier staging-mysql/staginglurberri_cfui/.

J'ai supprimé ce dossier et son contenu.

Freshping¶

Pas de surveillance Freshping pour Lur Berri STAGING.

Les 50 derniers événements¶

2025-11-20¶

2025-11-19¶

2025-11-18¶

2025-11-17¶

2025-11-14¶

2025-10-30¶

Analyse¶

2025-09-25¶

2025-09-19¶

2025-09-17¶

2025-09-12¶

Recherche de la cause¶

2025-09-11¶

Faire en sorte d'accèder aux deux Superset¶

Installation de Superset sur yunohost-cywise¶

Correction de l'authentification¶

Copie des données¶

Déplacement des autres Performa¶

2025-09-09¶

2025-09-08¶

2025-09-04¶

2025-08-28¶

2025-08-20¶

2025-07-31¶

2025-07-30¶

2025-07-24¶

2025-07-17¶

2025-07-16¶

2025-07-15¶

2025-07-11¶

Mise à jour de MariaDB de 10.11 vers 11.4¶

Mise à jour de MariaDB de 11.4 vers 11.8¶

2025-07-10¶

2025-07-09¶

Objectifs¶

Réflexions¶

Mise en place¶

Connexion SSH entre les 2 machines¶

Copie de la base de données Cywise v0.x DEV¶

Tunnel SSH¶

Conversion des données DEV¶

2025-07-08¶

Principe¶

Réflexions¶

Mise en place (DEV)¶

2025-07-02¶

Installation de Jenkins¶

Installation de phpMyAdmin¶

Surveillance de l'instance¶

Droits d'accès à Patrick et Cyrille¶

Premier test Towerify CLI¶

Préparation des DNS¶

Installation de YunoHost¶

Installation de Portainer¶

Installation de Jenkins¶

2025-07-01¶

2025-06-30¶

Lur Berri Datalake UI PROD¶

MySQL database for Lur Berri cf-ui PROD¶

Suppression des données sur le SFTP¶

Suppression des données du cache de NiFi¶

Suppression des données sur S3¶

Suppression des backups¶

Freshping¶

Lur Berri Datalake UI STAGING¶

MySQL database for Lur Berri cf-ui STAGING¶

Suppression des données sur le SFTP¶

Suppression des données du cache de NiFi¶

Suppression des données sur S3¶

Suppression des backups¶

Freshping¶

Installation de Superset sur `yunohost-cywise`¶