Tous les é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.

Suppression de l'environnement de DEV de Lur Berri

Concerns

Deprecated: Resource - deployment - dev-lurberri-cf-ui
Deprecated: Resource - storage - devlurberri_cfui

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

Lur Berri Datalake UI DEV¶

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

sudo docker stack rm dev-lurberri-cf-ui

ansible@s001:~$ sudo docker stack rm dev-lurberri-cf-ui
Removing service dev-lurberri-cf-ui_app
Removing service dev-lurberri-cf-ui_queue
Removing service dev-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 DEV¶

Je supprime la base de données devlurberri_cfui depuis phpMyAdmin. J'en profite pour supprimer les 2 utilisateurs correspondant : devlurbercfui et devlurbercfuimater.

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 DEV. Voici la taille des données présentes pour la 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
80K /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/dev
7.8G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/prod
11G /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
753G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri

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

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

ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/dev
total 56K
drwxr-xr-x 6 ansible ansible 4.0K Mar 23  2023 .
drwxr-xr-x 8 ansible ansible 4.0K Mar  7  2022 ..
drwxr-xr-x 4 ansible ansible 4.0K Dec  3  2022 conf
drwxr-xr-x 2 ansible ansible  36K Mar 30  2022 factures
drwxr-xr-x 3 ansible ansible 4.0K Mar 23  2023 feedit
drwxr-xr-x 3 ansible ansible 4.0K Apr 21  2022 persone-titre
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/dev -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;
ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/dev
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Jun 30 17:28 .
drwxr-xr-x 8 ansible ansible 4.0K Mar  7  2022 ..

sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/dev_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/dev_out
total 160K
drwxr-xr-x 15 ansible ansible 4.0K Mar 23  2023 .
drwxr-xr-x  8 ansible ansible 4.0K Mar  7  2022 ..
drwxr-xr-x  3 ansible ansible 4.0K Mar  4  2022 compta-ecritures-analytiques-zzgea
drwxr-xr-x  4 ansible ansible 4.0K Mar  4  2022 compta-ecritures-zzgec
drwxr-xr-x  4 ansible ansible 4.0K Mar  4  2022 compta-plan-comptable-zzgpc
drwxr-xr-x  4 ansible ansible 4.0K Mar  4  2022 conf
drwxr-xr-x  2 ansible ansible 104K Mar 30  2022 factures
drwxr-xr-x  3 ansible ansible 4.0K Mar 23  2023 feedit
drwxr-xr-x  4 ansible ansible 4.0K Mar  4  2022 kerhis-table-batiment
drwxr-xr-x  4 ansible ansible 4.0K Mar  4  2022 kerhis-table-paramanalytique
drwxr-xr-x  4 ansible ansible 4.0K Mar  4  2022 kerhis-table-plancomptable
drwxr-xr-x  3 ansible ansible 4.0K Mar  4  2022 kerhis-table-tiers
drwxr-xr-x  4 ansible ansible 4.0K Mar  4  2022 persone-base
drwxr-xr-x  4 ansible ansible 4.0K Mar  4  2022 persone-pays
drwxr-xr-x  3 ansible ansible 4.0K Apr 21  2022 persone-titre
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri/dev_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/dev_out
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Jun 30 17:30 .
drwxr-xr-x 8 ansible ansible 4.0K Mar  7  2022 ..

Il y avait aussi 1 fichier /var/lib/docker/volumes/sftp_sftp-data/_data/data/lurberri-factures-archive.tar.gz de 15G que j'ai supprimé.

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/dev etlurberri/dev_out.

sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/dev sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/dev_out

ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri
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
256K    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/dev
169M    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/prod
260K    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/dev_out
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/dev
ansible@s004:~$ sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri/dev_out
ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/lurberri
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

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/dev/ de ce bucket (dev_out n'est pas backupé sur S3).

Notre NiFi précédent backupait les données dans /var/sftp/lurberri/dev/ 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 dev-mysql/devlurberri_cfui/.

J'ai supprimé ce dossier et son contenu.

Freshping¶

Pas de surveillance Freshping pour Lur Berri DEV.

Suppression du Jenkins de Lur Berri

Concerns

Deprecated: Resource - deployment - lurberri-jenkins

Lur Berri a résilié son contrat avec nous. Je vais donc supprimer son Jenkins.

Je supprime la stack qui se trouve sur swarm01.

sudo docker stack rm lurberri-jenkins

ansible@s001:~$ sudo docker stack rm lurberri-jenkins
Removing service lurberri-jenkins_jenkins

Puis je supprime le container DinD (Docker in Docker) qui se trouve sur s005.

sudo docker stop lurberri-jenkins_dind sudo docker rm lurberri-jenkins_dind

ansible@s005:~$ sudo docker stop lurberri-jenkins_dind
lurberri-jenkins_dind
ansible@s005:~$ sudo docker rm lurberri-jenkins_dind
lurberri-jenkins_dind

Je supprime les 2 volumes associés.

sudo docker volume rm lurberri-jenkins_jenkins-data sudo docker volume rm lurberri-jenkins_jenkins-docker-certs

ansible@s005:~$ sudo docker volume rm lurberri-jenkins_jenkins-data
lurberri-jenkins_jenkins-data
ansible@s005:~$ sudo docker volume rm lurberri-jenkins_jenkins-docker-certs
lurberri-jenkins_jenkins-docker-certs

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.

Je supprime le tag lurberri-jenkins.jenkins_home du noeud s005 en modifiant le fichier ansible/03-swarm01-labels.yaml puis en appliquant avec la commande : ansible-playbook -i ansible/inventory.yml ansible/03-swarm01-labels.yaml.

2025-06-20¶

08:30 - Sentinel API PROD ne trouve plus les sous-domaines (hypothèse)

J'ai retrouvé une capture de la commande sudo systemctl status dnsmasq.service sur yunohost-sentinel-api datant du 2025-05-19 qui montre ces messages :

Apr 25 16:13:07 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
Apr 25 16:13:13 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
Apr 28 17:37:46 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
Apr 28 17:37:52 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
May 08 20:29:35 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
May 09 02:42:31 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
May 14 10:15:28 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
May 15 15:53:50 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
May 19 15:34:51 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)

Je n'ai pas pensé à regarder dnsmasq il y a 3 jours lors des problèmes de résolution DNS mais c'est possible que le problème vienne de là.

Malheureusement, j'ai n'ai plus les journaux pour dnsmasq car ils sont écrasés :

twr_admin@sentinel-api:~$ sudo journalctl -u dnsmask
-- Journal begins at Fri 2025-06-20 00:54:04 CEST, ends at Fri 2025-06-20 07:41:46 CEST. --
-- No entries --

Je vais donc augmenter la taille des journaux de dnsmasq pour conserver plus longtemps les logs.

Les journaux utilisent 4G maximum pour l'instant :

twr_admin@sentinel-api:~$ sudo journalctl --disk-usage
Archived and active journals take up 4.0G in the file system.

Et ça ne correspond qu'à 8h d'historique. Je voudrais avoir 7 jours d'historique donc je vais multipler par 20 et mettre un maximum à 80G. Pour être prudent, je vais mettre une place libre minimum de 50G pour ne pas saturer le disque.

J'ai modifié /etc/systemd/journald.conf pour ajouter les lignes suivantes :

[Journal]
SystemMaxUse=80G
SystemKeepFree=50G

Puis j'ai redémarré le service systemd-journald :

twr_admin@sentinel-api:~$ sudo systemctl restart systemd-journald

Maintenant, je veux augmenter le nombre maximum de requêtes DNS concurrentes dans dnsmasq. Pour cela, je vais modifier le fichier /etc/dnsmasq.conf pour ajouter la ligne suivante :

dns-forward-max=1000

Puis je vais redémarrer le service dnsmasq :

twr_admin@sentinel-api:~$ sudo systemctl restart dnsmasq

Pour mémoire, la doc de dnsmasq indique :

-0, --dns-forward-max=<queries>
Set the maximum number of concurrent DNS queries. The default value is 150, which should be fine for most setups. 
The only known situation where this needs to be increased is when using web-server log file resolvers, 
which can generate large numbers of concurrent queries. This parameter actually controls the number of concurrent 
queries per server group, where a server group is the set of server(s) associated with a single domain. 
So if a domain has it's own server via --server=/example.com/1.2.3.4 and 1.2.3.4 is not responding, but queries 
for *.example.com cannot go elsewhere, then other queries will not be affected. On configurations with many such 
server groups and tight resources, this value may need to be reduced.

2025-06-17¶

10:30 - Sentinel API PROD ne trouve plus les sous-domaines

Alerte de Cyrille qui a reçu 2 messages de prospects : notre application ne trouve aucun sous-domaine pour leurs 2 domaines : a51.fr et olalabordeaux.com.

Le dernier health check de Cywise PROD qui demande à Sentinel les sous-domaines de cywise.io a pourtant réussi vers 10h (environ 30 minutes plus tôt).

Une fois connecté au container Docker de Sentinel API PROD, je vois que subfinder ne trouve aucun domaine pour nos 2 prospects mais, pas de sous-domaines pour cywise.io non plus.

En affichant le verbose, je vois que subfinder n'arrive pas à résoudre les noms de domaine des sources :

root@api:/app# /app/bin/subfinder -v -all -d a51.fr
[ERR] subfinder version check failed: [updater:RUNTIME] http Get https://api.pdtm.sh/api/v1/tools/subfinder?arch=amd64&go_version=go1.21.13&machine_id=bb033a16193f61dc3ab0d0a63793f3cb59dfc76db051ca69202e9da9bfeb5771&os=debian&utm_source=docker&v=v2.7.0 failed <- Get "https://api.pdtm.sh/api/v1/tools/subfinder?arch=amd64&go_version=go1.21.13&machine_id=bb033a16193f61dc3ab0d0a63793f3cb59dfc76db051ca69202e9da9bfeb5771&os=debian&utm_source=docker&v=v2.7.0": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
[WRN] Encountered an error with source digitorus: Get "https://certificatedetails.com/a51.fr": dial tcp: lookup certificatedetails.com on 127.0.0.11:53: server misbehaving
[WRN] Encountered an error with source censys: Get "https://search.censys.io/api/v2/certificates/search?q=a51.fr&per_page=100": dial tcp: lookup search.censys.io on 127.0.0.11:53: server misbehaving
[WRN] Encountered an error with source netlas: Get "https://app.netlas.io/api/domains_count/?q=domain%3A%2A.a51.fr+AND+NOT+domain%3Aa51.fr": dial tcp: lookup app.netlas.io on 127.0.0.11:53: server misbehaving
[WRN] Encountered an error with source sitedossier: Get "http://www.sitedossier.com/parentdomain/a51.fr": dial tcp: lookup www.sitedossier.com on 127.0.0.11:53: server misbehaving
[WRN] Encountered an error with source alienvault: Get "https://otx.alienvault.com/api/v1/indicators/domain/a51.fr/passive_dns": dial tcp: lookup otx.alienvault.com on 127.0.0.11:53: server misbehaving
[WRN] Encountered an error with source rapiddns: Get "https://rapiddns.io/subdomain/a51.fr?page=1&full=1": dial tcp: lookup rapiddns.io on 127.0.0.11:53: server misbehaving
[WRN] Encountered an error with source securitytrails: Post "https://api.securitytrails.com/v1/domains/list?include_ips=false&scroll=true": dial tcp: lookup api.securitytrails.com on 127.0.0.11:53: server misbehaving
[WRN] Encountered an error with source hudsonrock: Get "https://cavalier.hudsonrock.com/api/json/v2/osint-tools/urls-by-domain?domain=a51.fr": dial tcp: lookup cavalier.hudsonrock.com on 127.0.0.11:53: server misbehaving
[WRN] Encountered an error with source commoncrawl: Get "https://index.commoncrawl.org/collinfo.json": dial tcp: lookup index.commoncrawl.org on 127.0.0.11:53: server misbehaving
[WRN] Encountered an error with source leakix: Get "https://leakix.net/api/subdomains/a51.fr": dial tcp: lookup leakix.net on 127.0.0.11:53: server misbehaving
[WRN] Encountered an error with source threatcrowd: Get "http://ci-www.threatcrowd.org/searchApi/v2/domain/report/?domain=a51.fr": dial tcp: lookup ci-www.threatcrowd.org on 127.0.0.11:53: server misbehaving
[WRN] Encountered an error with source anubis: Get "https://jonlu.ca/anubis/subdomains/a51.fr": dial tcp: lookup jonlu.ca on 127.0.0.11:53: server misbehaving
[WRN] Encountered an error with source waybackarchive: Get "http://web.archive.org/cdx/search/cdx?url=*.a51.fr/*&output=txt&fl=original&collapse=urlkey": dial tcp: lookup web.archive.org on 127.0.0.11:53: server misbehaving
[WRN] Encountered an error with source hackertarget: Get "https://api.hackertarget.com/hostsearch/?q=a51.fr": dial tcp: lookup api.hackertarget.com on 127.0.0.11:53: server misbehaving
[WRN] Encountered an error with source crtsh: dial tcp: lookup crt.sh on 127.0.0.11:53: server misbehaving
[WRN] Encountered an error with source crtsh: Get "https://crt.sh/?q=%25.a51.fr&output=json": dial tcp: lookup crt.sh on 127.0.0.11:53: server misbehaving
[WRN] Encountered an error with source binaryedge: Get "https://api.binaryedge.io/v1/query/domains/subdomain/a51.fr?page=1&pagesize=10000": dial tcp: lookup api.binaryedge.io on 127.0.0.11:53: server misbehaving
[INF] Found 0 subdomains for a51.fr in 16 seconds 14 milliseconds

Je redémarre le service donc le container mais le problème persiste.

Je redémarre Docker. J'ai un problème avec error creating vxlan interface que je résouds. Les containers démarrent mais le problème de résolution DNS persiste.

Je regarde iptables mais je ne vois pas de blocage de ce côté.

Même un nslookup app.cywise.io depuis la connexion SSH sur la machine yunohost-sentinel-api ne fonctionne pas.

Je regarde le fichier /etc/resolv.conf mais je ne vois rien de particulier.

twr_admin@sentinel-api:~$ cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.

nameserver 127.0.0.1
twr_admin@sentinel-api:~$ resolvectl status
Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.
twr_admin@sentinel-api:~$ sudo resolvectl status
Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.


twr_admin@sentinel-api:~$ sudo systemctl status resolvconf.service 
● resolvconf.service - Nameserver information manager
    Loaded: loaded (/lib/systemd/system/resolvconf.service; enabled; vendor preset: enabled)
    Active: active (exited) since Tue 2025-05-27 15:40:18 CEST; 2 weeks 6 days ago
      Docs: man:resolvconf(8)
  Main PID: 493 (code=exited, status=0/SUCCESS)
      Tasks: 0 (limit: 232000)
    Memory: 0B
        CPU: 0
    CGroup: /system.slice/resolvconf.service

Warning: journal has been rotated since unit was started, output may be incomplete.
twr_admin@sentinel-api:~$ sudo journalctl -u resolvconf.service 
-- Journal begins at Sun 2025-06-15 19:01:48 CEST, ends at Tue 2025-06-17 11:23:02 CEST. --
-- No entries --
twr_admin@sentinel-api:~$

11:25 - Je redémarre la machine

Les services et les containers Docker mettent un peu de temps à redémarrer mais tout refonctionne.

2025-06-06¶

14:00 - Alertes Freshping pour les applications de AddApps (suite et fin)

Concerns

Les alertes Freshping pour les applications de AddApps reprennent vers 14h avec la même erreur "Connection Refused".

C'est une règle que Cyrille a mis en place dans Fail2Ban pour bloquer les requêtes qui retournent des erreurs 4xx (404, 403, 400, etc.) dans les logs Nginx.

/etc/fail2ban/filter.d/nginx-4xx.conf

[Definition]
failregex = ^<HOST> - .* "(GET|POST|PUT|DELETE|HEAD|OPTIONS|PATCH|CONNECT|TRACE).*" (403|404|500|502|503|504) .*$
ignoreregex =

Pour tester le fichier de conf:

fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/nginx-4xx.conf

/etc/fail2ban/jail.conf

[nginx-4xx]
enabled = true
port = http,https
filter = nginx-4xx
logpath = %(nginx_access_log)s
          %(apache_access_log)s
bantime = 3600
findtime = 300
maxretry = 10

Redémarage du service:
```
service fail2ban restart
```
Pour voir le statut:
```
fail2ban-client status nginx-4xx
```

J'ai modifié le fichier /etc/fail2ban/filter.d/nginx-4xx.conf pour supprimer 503. Puis j'ai retiré les 2 IPs des sondes Freshping de la liste des IPs bannies :

cfadmin@yunohost-addapps-xxl:~$ sudo fail2ban-client set nginx-4xx unbanip --report-absent 35.173.69.86
1
cfadmin@yunohost-addapps-xxl:~$ sudo fail2ban-client set nginx-4xx unbanip --report-absent 52.42.49.200
1

15:00 : Les alertes Freshping ont cessé d'arriver.

Je veux remettre 503 dans la liste et ajouter les IPs Freshping dans la liste des IPs autorisées dans Fail2Ban.

La liste des IPs des sondes Freshping se trouve ici : https://support.freshping.io/support/solutions/articles/237620-what-are-the-monitoring-locations-and-their-ips-

D'où la liste suivante : 35.173.69.86 50.17.185.102 18.179.133.14 34.246.131.0 13.251.205.206 52.60.140.174 13.55.57.184 52.42.49.200 13.232.175.73 18.228.60.182 18.130.156.195.

Je les ajoute dans le fichier /etc/fail2ban/jail.conf :

[nginx-4xx]
enabled = true
port = http,https
filter = nginx-4xx
logpath = %(nginx_access_log)s
          %(apache_access_log)s
bantime = 3600
findtime = 300
maxretry = 10
ignoreip = 35.173.69.86 50.17.185.102 18.179.133.14 34.246.131.0 13.251.205.206 52.60.140.174 13.55.57.184 52.42.49.200 13.232.175.73 18.228.60.182 18.130.156.195

Puis je remets 503 dans le fichier /etc/fail2ban/filter.d/nginx-4xx.conf :

[Definition]
failregex = ^<HOST> - .* "(GET|POST|PUT|DELETE|HEAD|OPTIONS|PATCH|CONNECT|TRACE).*" (403|404|500|502|503|504) .*$
ignoreregex =

Enfin, je redémarage le service:

service fail2ban restart

09:00 - Alertes Freshping pour les applications de AddApps

Concerns

Ce matin, je trouve plus de 200 alertes Freshping pour les applications de AddApps.

Certaines alertes coresspondent à mes Health Check de Cywise DEV et Cywise PROD et semblent être justifiées par des réponses trop lentes de Assets Discover.

Mais la pluspart des alertes correspondent dans Freshping à l'erreur "Connection Refused". Cette erreur n'est pas systématique ce qui fait qu'on reçoit un DOWN, puis un UP, puis un DOWN, etc. D'ailleurs, quand je reçois une alerte DOWN, je peux accéder à l'application tout de même.

Vu le message d'erreur dans Freshping mon hypothèse est que nous avons atteint la limite de connexions TCP.

Performa affiche environ 180 "Open TCP connections". La commande netstat -ntap | grep ESTABLISHED | wc -l en compte 80. De même que la commande ss -s (pour TCP/estab).

Le temps de rédiger cette note, j'ai déjà moins de connexions TCP dans Performa, environ 140. Mais les alertes DOWN et UP continuent d'arriver dans Freshping. Je décide de redémarrer nginx pour voir si cela résout le problème.

10:00 : Je redémarre nginx sur yunohost-addapps avec sudo systemctl restart nginx.

Cela n'a pas résolut le problème car les alertes Freshping ont continué d'arriver jusqu'à 10h30. Il est maintenant 11h15 et les alertes Freshping n'arrivent plus alors que je n'ai rien fait pour résoudre le problème.

Je ne sais pas ce qui s'est passé mais je m'arrête là pour le moment.

2025-06-04¶

09:15 - Interruption de service pour les applications de AddApps

Concerns

Interruption 15 minutes

Du mercredi 04/06 9h15 au mercredi 04/06 9h30 soit 15 minutes. Pour toutes les applications de AddApps.

Première alerte Freshping reçue à 9h17. Cyrille n'arrive pas à afficher app.cywise.io. Moi non plus.

Je résouds le problème en redémarrant nginx avec sudo systemctl restart nginx.

Plus de détails : - htop montre une forte occupation CPU - htop montre le process nginx en premier - un sudo systemctl status nginx montre un reload récent de nginx avec des warnings sur les certificats SSL - un sudo yunohost domain cert status montre que les certificats SSL Let's Encrypt sont à jour

sudo systemctl status nginx avant le redémarrage

cfadmin@yunohost-addapps-xxl:~$ sudo systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
    Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
    Active: active (running) since Mon 2025-05-26 20:02:47 UTC; 1 weeks 1 days ago
      Docs: man:nginx(8)
  Main PID: 3615443 (nginx)
      Tasks: 8 (limit: 38502)
    Memory: 483.9M
        CPU: 2h 33min 195ms
    CGroup: /system.slice/nginx.service
            ├─2251829 [nginx]
            ├─2251830 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
            ├─2251831 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
            ├─2251834 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
            ├─2251835 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
            ├─2251836 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
            ├─2251837 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
            └─3615443 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;

Jun 04 07:12:49 yunohost-addapps-xxl systemd[1]: Reloading A high performance web server and a reverse proxy server.
Jun 04 07:12:49 yunohost-addapps-xxl nginx[2153486]: nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/yunohost/certs/dev.infra-docs.myapps.addapps.io/crt.pem"
Jun 04 07:12:49 yunohost-addapps-xxl nginx[2153486]: nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/yunohost/certs/dev.static-root.myapps.addapps.io/crt.pem"
Jun 04 07:12:49 yunohost-addapps-xxl nginx[2153486]: nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/yunohost/certs/docs.infra.computablefacts.com/crt.pem"
Jun 04 07:12:49 yunohost-addapps-xxl nginx[2153486]: nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/yunohost/certs/hf5y-rhal-8tr4.cywise.io/crt.pem"
Jun 04 07:12:49 yunohost-addapps-xxl nginx[2153486]: nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/yunohost/certs/js5f-4t7e-5er8.cywise.io/crt.pem"
Jun 04 07:12:49 yunohost-addapps-xxl nginx[2153486]: nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/yunohost/certs/ka8u-e1fs-3qmh.cywise.io/crt.pem"
Jun 04 07:12:49 yunohost-addapps-xxl nginx[2153486]: nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/yunohost/certs/reports.cywise.io/crt.pem"
Jun 04 07:12:49 yunohost-addapps-xxl nginx[2153486]: nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/yunohost/certs/sentinel.computablefacts.com/crt.pem"
Jun 04 07:12:50 yunohost-addapps-xxl systemd[1]: Reloaded A high performance web server and a reverse proxy server.

sudo yunohost domain cert status

cfadmin@yunohost-addapps-xxl:~$ sudo yunohost domain cert status
certificates: 
  acme.towerify.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 54
  app.cywise.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 59
  app.towerify.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 54
  cli.towerify.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 48
  dev.adversarymeter.myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 42
  dev.api1.myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 22
  dev.ciblage-commercial.myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 22
  dev.cywise-ui.myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 28
  dev.docs.towerify.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 34
  dev.infra-docs.myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 71
  dev.performa.myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 57
  dev.poc-llm.myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 30
  dev.secrets-envvars.myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 26
  dev.static-root.myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 66
  dev.test-wsl.myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 50
  dev.towerify-ui.myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 46
  docs.infra.computablefacts.com: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 70
  docs.towerify.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 54
  hf5y-rhal-8tr4.cywise.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 69
  jenkins.myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 27
  js5f-4t7e-5er8.cywise.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 69
  ka8u-e1fs-3qmh.cywise.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 69
  myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 45
  patrick.towerify-cli-install.myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 48
  patrick.towerify-docs.myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 42
  patrick2.towerify-docs.myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 51
  portainer.myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 27
  prod.towerify-docs.myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 22
  reports.cywise.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 72
  sentinel.computablefacts.com: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 71
  superset.myapps.addapps.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 48
  v29m-tcdr-kqx2.cywise.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 58
  zdhi-8skn-fu6v.cywise.io: 
    CA_type: letsencrypt
    style: success
    summary: letsencrypt
    validity: 58
cfadmin@yunohost-addapps-xxl:~$

sudo systemctl status nginx après le redémarrage

cfadmin@yunohost-addapps-xxl:~$ sudo systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
    Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
    Active: active (running) since Wed 2025-06-04 07:29:08 UTC; 5s ago
      Docs: man:nginx(8)
    Process: 2285211 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 2285245 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
  Main PID: 2285294 (nginx)
      Tasks: 9 (limit: 38502)
    Memory: 117.1M
        CPU: 1.593s
    CGroup: /system.slice/nginx.service
            ├─2285294 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
            ├─2285295 nginx: worker process
            ├─2285296 nginx: worker process
            ├─2285297 nginx: worker process
            ├─2285298 nginx: worker process
            ├─2285299 nginx: worker process
            ├─2285300 nginx: worker process
            ├─2285301 nginx: worker process
            └─2285302 nginx: worker process

Jun 04 07:29:06 yunohost-addapps-xxl nginx[2285211]: nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/yunohost/certs/sentinel.computablefacts.com/crt.pem"
Jun 04 07:29:07 yunohost-addapps-xxl nginx[2285245]: nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/yunohost/certs/dev.infra-docs.myapps.addapps.io/crt.pem"
Jun 04 07:29:07 yunohost-addapps-xxl nginx[2285245]: nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/yunohost/certs/dev.static-root.myapps.addapps.io/crt.pem"
Jun 04 07:29:07 yunohost-addapps-xxl nginx[2285245]: nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/yunohost/certs/docs.infra.computablefacts.com/crt.pem"
Jun 04 07:29:07 yunohost-addapps-xxl nginx[2285245]: nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/yunohost/certs/hf5y-rhal-8tr4.cywise.io/crt.pem"
Jun 04 07:29:07 yunohost-addapps-xxl nginx[2285245]: nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/yunohost/certs/js5f-4t7e-5er8.cywise.io/crt.pem"
Jun 04 07:29:07 yunohost-addapps-xxl nginx[2285245]: nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/yunohost/certs/ka8u-e1fs-3qmh.cywise.io/crt.pem"
Jun 04 07:29:07 yunohost-addapps-xxl nginx[2285245]: nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/yunohost/certs/reports.cywise.io/crt.pem"
Jun 04 07:29:07 yunohost-addapps-xxl nginx[2285245]: nginx: [warn] "ssl_stapling" ignored, no OCSP responder URL in the certificate "/etc/yunohost/certs/sentinel.computablefacts.com/crt.pem"
Jun 04 07:29:08 yunohost-addapps-xxl systemd[1]: Started A high performance web server and a reverse proxy server.

2025-06-02¶

16:00 - Interruption de service Sentinel API (vxlan issue)

Cyrille a été prévenu d'un problème par quelqu'un qui testait https://app.cywise.io/cyber-check/.

Plusieurs services ont aucun container de démarré, les démarrages échouent avec l'erreur suivante :

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

De mémoire, je dirais que les services qui avaient le problème étaient ceux de la stack sentinel-api_prod et ceux de la stack worker_prod.

J'ai appliqué la même résolution qu'il y a quelques semaines avec AddApps :

twr_admin@sentinel-api:~$ ls -l /sys/class/net/ | grep vx
lrwxrwxrwx 1 root root 0 May 30 17:41 vx-001008-mo6e9 -> ../../devices/virtual/net/vx-001008-mo6e9
twr_admin@sentinel-api:~$ sudo ip -d link show  vx-001008-mo6e9
604: vx-001008-mo6e9: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN mode DEFAULT group default 
    link/ether c2:5d:f8:9a:2e:1f brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535 
    vxlan id 4104 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 
twr_admin@sentinel-api:~$ sudo ip link delete  vx-001008-mo6e9

16:10 : Les containers ont pu être redémarrés et les services sont de nouveau opérationnels.

NOTA: je n'ai pas de surveillance Freshping sur Sentinel API car il y a une protection Basic Auth et la version gratuite de Freshping ne permet pas de surveiller des URLs protégées par un mot de passe. Il faudrait la version payante à 132$ / an.

2025-05-27¶

11:30 - Déploiement des honeypots de Matmut

Cela correspond à 3 tickets : - HTTP : #8873 - HTTPS : #8874 - SSH : #8875

09:05 - Augmentation de la place disque de 80Go

Concerns

Resource - server - yunohost-addapps

Pour éviter les problèmes de place disque sur yunohost-addapps, j'ai décidé d'augmenter la place disque de 80Go. En effet, j'ai déjà augmenté de 50Go le 19/05 et le disque était full hier soir. Ce matin il y a 11G de libre.

Voir cette procédure.

Détail des commandes

cfadmin@yunohost-addapps-xxl:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G  4.7M  3.2G   1% /run
/dev/sda1       285G  264G   11G  97% /
tmpfs            16G   80K   16G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/sda15      124M   11M  114M   9% /boot/efi
tmpfs           3.2G     0  3.2G   0% /run/user/1249
cfadmin@yunohost-addapps-xxl:~$ sudo growpart /dev/sda 1
CHANGED: partition=1 start=262144 old: size=605206573 end=605468717 new: size=761456573 end=761718717
cfadmin@yunohost-addapps-xxl:~$ sudo resize2fs -p /dev/sda1
resize2fs 1.46.2 (28-Feb-2021)
Filesystem at /dev/sda1 is mounted on /; on-line resizing required
old_desc_blocks = 37, new_desc_blocks = 46
The filesystem on /dev/sda1 is now 95182071 (4k) blocks long.

cfadmin@yunohost-addapps-xxl:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G  4.7M  3.2G   1% /run
/dev/sda1       358G  264G   82G  77% /
tmpfs            16G   80K   16G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/sda15      124M   11M  114M   9% /boot/efi
tmpfs           3.2G     0  3.2G   0% /run/user/1249

2025-05-22¶

15:20 - Mise à jour du Jenkins de yunohost-sentinel-api

Je mets à jour les plugins du Jenkins de Sentinel API : 95 mises à jour disponibles dans l'UI.

J'en ai mis à jour 25 seulement car les 70 autres nécessitent une version plus récente de Jenkins.

Puis, je mets à jour Jenkins lui-même en utilisant l'UI Admin de YunoHost.

Je vais dans "Mise à jour du système". YunoHost détecte une nouvelle version de Jenkins : 2.510~ynh1. Je lance la mise à jour depuis l'UI Admin.

Je ce message d'erreur :

This app requires YunoHost >= 11.2.30 but current installed version is 11.2.9.1

Je vais donc mettre à jour YunoHost en premier. Pour ça, je vais faire les mises à jour "Système" depuis l'UI de YunoHost. Ca met à jour tous les packages y compris : - yunohost (from 11.2.9.1 to 11.3.0.2) - yunohost-admin (from 11.2.4 to 11.3.0) - moulinette (from 11.2 to 11.3.0) - ssowat (from 11.2 to 11.3.0)

Après la mise à jour de YunoHost, je relance la mise à jour de Jenkins.

Passage de la version 2.426.1~ynh4 à la version 2.510~ynh1.

J'ai dû remettre client_max_body_size 100m; (à la place de 10m) dans la conf nginx de Jenkins (fichier /etc/nginx/conf.d/jenkins.apps.sentinel-api.towerify.io.d/jenkins.conf).

08:20 - Problème Basic Auth et certificat Let's Encrypt

Hier soir, j'ai ajouté la variable d'environnement TOWERIFY_BASIC_AUTH aux secrets de sentinel-api-rq. Mais mon navigateur ne m'a pas demandé de mot de passe.

J'ai fait une autre application (statique) pour tester le Basic Auth et, cette fois, impossible d'obtenir le certificat Let's Encrypt pour le domaine de cette application de test. Quand Let's Encrypt essaie de valider le domaine, il est redirigé vers /yunohost/admin/.

Ce matin, j'ai retrouvé ma note et redémarré nginx avec la commande :

sudo systemctl restart nginx

J'ai pu obtenir le certificat Let's Encrypt pour l'application de test et le Basic Auth de sentinel-api-rq fonctionne aussi.

07:45 - Mise à jour du Jenkins de AddApps

Concerns

Resource - deployment - yunohost-addapps-jenkins

Je mets à jour les plugins du Jenkins de AddApps : 88 mises à jour disponibles dans l'UI.

Puis, je mets à jour Jenkins lui-même en utilisant l'UI Admin de YunoHost, activée pour l'occasion.

Dans cf_custom, je bascule sur le catalogue par défaut. Puis je vais dans "Mise à jour du système". YunoHost détecte une nouvelle version de Jenkins : 2.510~ynh1. Je lance la mise à jour depuis l'UI Admin. Dans cf_custom, je remets notre catalogue spécifique.

Passage de la version 2.479.2~ynh1 à la version 2.510~ynh1.

J'ai dû remettre client_max_body_size 100m; (à la place de 10m) dans la conf nginx de Jenkins (fichier /etc/nginx/conf.d/jenkins.myapps.addapps.io.d/jenkins.conf)

2025-05-20¶

09:25 - ISTA PROD - Redémarrage régulier de Clickhouse pour prise en compte du certificat LE

Concerns

Resource - server - yunohost-ista-prod

Je mets en place un redémarrage régulier de Clickhouse sur yunohost-ista-prod pour qu'il prenne en compte le certificat Let's Encrypt. J'avais modifié l'installation de notre package Clickhouse pour ajouter ce redémarrage mais je n'avais pas réussi à faire fonctionner la mise à jour qui m'aurait permis d'appliquer la modification sur ISTA PROD. Je vais donc le faire manuellement.

Je crée le fichier /etc/systemd/system/clickhouse-certificates.timer avec le contenu suivant :

[Unit]
Description=Restart clickhouse service to load new TLS certificate if exists

[Timer]
Persistent=true
OnCalendar=Sun *-*-* 01:00:00
RandomizedDelaySec=1h
Unit=clickhouse-restart.service

[Install]
WantedBy=timers.target

Je crée le fichier /etc/systemd/system/clickhouse-restart.service avec le contenu suivant :

[Unit]
Description=Restart clickhouse service

[Service]
Type=oneshot
ExecStart=/usr/bin/systemctl restart clickhouse-server.service

Je vérifie le service de redémarrage :

sudo systemctl start clickhouse-restart.service

Je vérifie que Clickhouse a bien redémarré et c'est le cas :

sudo systemctl status clickhouse-server.service

Puis, j'active et je démarre le timer :

sudo systemctl enable clickhouse-certificates.timer
sudo systemctl start clickhouse-certificates.timer

09:00 - ISTA DEV - Redémarrage régulier de Clickhouse pour prise en compte du certificat LE

Concerns

Resource - server - yunohost-ista-dev

Je mets en place un redémarrage régulier de Clickhouse sur yunohost-ista-dev pour qu'il prenne en compte le certificat Let's Encrypt. J'avais modifié l'installation de notre package Clickhouse pour ajouter ce redémarrage mais je n'avais pas réussi à faire fonctionner la mise à jour qui m'aurait permis d'appliquer la modification sur ISTA DEV. Je vais donc le faire manuellement.

Je crée le fichier /etc/systemd/system/clickhouse-certificates.timer avec le contenu suivant :

[Unit]
Description=Restart clickhouse service to load new TLS certificate if exists

[Timer]
Persistent=true
OnCalendar=Sun *-*-* 01:00:00
RandomizedDelaySec=1h
Unit=clickhouse-restart.service

[Install]
WantedBy=timers.target

Je crée le fichier /etc/systemd/system/clickhouse-restart.service avec le contenu suivant :

[Unit]
Description=Restart clickhouse service

[Service]
Type=oneshot
ExecStart=/usr/bin/systemctl restart clickhouse-server.service

Je vérifie le service de redémarrage :

twr_admin@apps:~$ sudo systemctl start clickhouse-restart.service 
twr_admin@apps:~$ sudo systemctl status clickhouse-restart.service 
● clickhouse-restart.service - Restart clickhouse service
    Loaded: loaded (/etc/systemd/system/clickhouse-restart.service; static)
    Active: inactive (dead) since Tue 2025-05-20 09:15:46 CEST; 5s ago
TriggeredBy: ● clickhouse-certificates.timer
    Process: 418647 ExecStart=/usr/bin/systemctl restart clickhouse-server.service (code=exited, status>
  Main PID: 418647 (code=exited, status=0/SUCCESS)
        CPU: 3ms

May 20 09:15:44 apps.dev-ista.computablefacts.com systemd[1]: Starting Restart clickhouse service...
May 20 09:15:46 apps.dev-ista.computablefacts.com systemd[1]: clickhouse-restart.service: Succeeded.
May 20 09:15:46 apps.dev-ista.computablefacts.com systemd[1]: Finished Restart clickhouse service.

Je vérifie que Clickhouse a bien redémarré et c'est le cas :

twr_admin@apps:~$ sudo systemctl status clickhouse-server.service 
● clickhouse-server.service - ClickHouse Server (analytic DBMS for big data)
    Loaded: loaded (/lib/systemd/system/clickhouse-server.service; disabled; vendor preset: enabled)
    Active: active (running) since Tue 2025-05-20 09:15:46 CEST; 6min ago
  Main PID: 418653 (clickhouse-serv)
      Tasks: 310 (limit: 231951)
    Memory: 266.4M
        CPU: 6.075s
    CGroup: /system.slice/clickhouse-server.service
            ├─418649 clickhouse-watchdog        --config=/etc/clickhouse-server/config.xml --pid-file=/run/clickhouse-server/clickhouse-server.pid
            └─418653 /usr/bin/clickhouse-server --config=/etc/clickhouse-server/config.xml --pid-file=/run/clickhouse-server/clickhouse-server.pid

May 20 09:15:45 apps.dev-ista.computablefacts.com clickhouse-server[418649]: Merging configuration file '/etc/clickhouse-server/config.d/logger.xml'.
May 20 09:15:45 apps.dev-ista.computablefacts.com clickhouse-server[418649]: Merging configuration file '/etc/clickhouse-server/config.d/openSSL.xml'.
May 20 09:15:45 apps.dev-ista.computablefacts.com clickhouse-server[418649]: Merging configuration file '/etc/clickhouse-server/config.d/paths.xml'.
May 20 09:15:45 apps.dev-ista.computablefacts.com clickhouse-server[418649]: Merging configuration file '/etc/clickhouse-server/config.d/remove-log-tables.xml'.
May 20 09:15:45 apps.dev-ista.computablefacts.com clickhouse-server[418649]: Merging configuration file '/etc/clickhouse-server/config.d/tcp_port_secure.xml'.
May 20 09:15:45 apps.dev-ista.computablefacts.com clickhouse-server[418649]: Merging configuration file '/etc/clickhouse-server/config.d/user_directories.xml'.
May 20 09:15:45 apps.dev-ista.computablefacts.com clickhouse-server[418649]: Logging information to /var/log/clickhouse-server/clickhouse-server.log
May 20 09:15:45 apps.dev-ista.computablefacts.com clickhouse-server[418649]: Logging errors to /var/log/clickhouse-server/clickhouse-server.err.log
May 20 09:15:45 apps.dev-ista.computablefacts.com systemd[1]: clickhouse-server.service: Supervising process 418653 which is not our child. We'll most likely not notice when it exits.
May 20 09:15:46 apps.dev-ista.computablefacts.com systemd[1]: Started ClickHouse Server (analytic DBMS for big data).

Puis, j'active et je démarre le timer :

twr_admin@apps:~$ sudo systemctl enable clickhouse-certificates.timer 
Created symlink /etc/systemd/system/timers.target.wants/clickhouse-certificates.timer → /etc/systemd/system/clickhouse-certificates.timer.
twr_admin@apps:~$ sudo systemctl start clickhouse-certificates.timer 
twr_admin@apps:~$ sudo systemctl status clickhouse-certificates.timer 
● clickhouse-certificates.timer - Restart clickhouse service to load new TLS certificate if exists
    Loaded: loaded (/etc/systemd/system/clickhouse-certificates.timer; enabled; vendor preset: enabled)
    Active: active (waiting) since Tue 2025-05-20 09:16:13 CEST; 5s ago
    Trigger: Sun 2025-05-25 01:05:57 CEST; 4 days left
  Triggers: ● clickhouse-restart.service

May 20 09:16:13 apps.dev-ista.computablefacts.com systemd[1]: Started Restart clickhouse service to loa>

2025-05-19¶

16:55 - ISTA - Erreur Jobs to Dataset - Problème répertoire durable-xxx

Concerns

Ticket #8866 ouvert par Marlène pour une erreur Jenkins dans Jobs to Dataset.

En regardant le log du job #193, je vois que c'est le problème récurrent de suppression des répertoires temporaires durable-xxx.

Je me connecte en SSH sur yunohost-ista-dev. Il y a 3 répertoires durable-xxx dans le dossier tmp du job :

twr_admin@apps:~$ sudo ls -alh /var/lib/jenkins/jobs/jobs_to_dataset/workspace/jobs@tmp
total 20K
drwxr-xr-x 5 jenkins jenkins 4.0K May 11 02:21 .
drwxr-xr-x 3 jenkins jenkins 4.0K May 11 02:21 ..
drwxr-xr-x 2 root    root    4.0K Apr 17 13:45 durable-20b62aca
drwxr-xr-x 2 root    root    4.0K Apr 17 13:37 durable-469723fa
drwxr-xr-x 2 root    root    4.0K Apr 10 10:01 durable-f0f43766

Je supprime tout avec la commande sudo rm -R /var/lib/jenkins/jobs/jobs_to_dataset/workspace/jobs@tmp/. Je relance le job (pour syndics-clients-2 comme précisé par Marlène) et il réussi.

2025-05-20 8h55 - Problème résolu

22:20 - Augmentation de la place disque de 50Go

Concerns

Resource - server - yunohost-addapps

Pour éviter les problèmes de place disque sur yunohost-addapps, j'ai décidé d'augmenter la place disque de 50Go. En effet, nous avons eu un disque plein la semaine dernière et, malgré notre ménage, il ne reste que 15Go de libre.

Voir cette procédure.

Détail des commandes

cfadmin@yunohost-addapps-xxl:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G  4.5M  3.2G   1% /run
/dev/sda1       239G  217G   13G  95% /
tmpfs            16G   60K   16G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/sda15      124M   11M  114M   9% /boot/efi
tmpfs           3.2G     0  3.2G   0% /run/user/1249
cfadmin@yunohost-addapps-xxl:~$ sudo growpart /dev/sda 1
CHANGED: partition=1 start=262144 old: size=507550323 end=507812467 new: size=605206573 end=605468717
cfadmin@yunohost-addapps-xxl:~$ sudo resize2fs -p /dev/sda1
resize2fs 1.46.2 (28-Feb-2021)
Filesystem at /dev/sda1 is mounted on /; on-line resizing required
old_desc_blocks = 31, new_desc_blocks = 37
The filesystem on /dev/sda1 is now 75650821 (4k) blocks long.

cfadmin@yunohost-addapps-xxl:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G  4.5M  3.2G   1% /run
/dev/sda1       285G  218G   56G  80% /
tmpfs            16G   60K   16G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/sda15      124M   11M  114M   9% /boot/efi
tmpfs           3.2G     0  3.2G   0% /run/user/1249

16:35 - Interruption de service pour les applications de AddApps

Concerns

Interruption 1 heure et 25 minutes

Du lundi 19/05 16h35 au lundi 19/05 18h00 soit 85 minutes. Pour toutes les applications de AddApps.

J'ai reçu une alerte Freshping pour Cywise PROD à 16h39. app.cywise.io ne répondait pas. Le performa de CF ne répondait pas non plus. Impossible de me connecter en SSH à yunohost-addapps.

Je décide de redémarrer l'instance yunohost-addapps depuis l'UI de Scaleway.

app.cywise.io me répond à nouveau à 16h49.

D'après les logs de Freshping pour Cywise PROD : - coupure de 16h35 à 16h43 (8m) - Timeout - coupure de 16h44 à 16h45 (1m) - HTTP 502 - coupure de 16h46 à 16h47 (1m) - HTTP 502 - coupure de 16h48 à 17h20 (32m) - HTTP 502 - coupure de 17h22 à 17h48 (26m) - HTTP 502

A 16h49, Cyrille parle d'une requête de suppression des événements de la table ynh_osquery liés à CF et lance la requête SQL de DELETE probablement vers 16h50.

A 17h03, je me rends compte que j'ai une erreur HTTP 502 sur app.cywise.io. Puis, à 17h05, je vois dans Portainer que les containers de Cywise PROD (et ceux de Cywise DEV) ne démarrent pas. Je trouve une erreur réseau : network sandbox join failed: subnet sandbox join failed for "10.0.6.0/24": error creating vxlan interface: file exists.

J'ai tenté de redémarrer le service Docker mais le message était toujours présent. J'ai tenté de redémarrer l'instance yunohost-addapps à nouveau mais le message était toujours présent.

Après plusieurs tatonnements, j'ai fini par trouver une moyen de résoudre ce problème grâce à cette réponse sur StackOverflow.

J'ai commencé par arrêter le service Docker à 17h36 :

cfadmin@yunohost-addapps-xxl:~$ sudo systemctl stop docker.service 
Warning: Stopping docker.service, but it can still be activated by:
  docker.socket
cfadmin@yunohost-addapps-xxl:~$ sudo systemctl stop docker.socket 
cfadmin@yunohost-addapps-xxl:~$ sudo systemctl stop docker.service 
cfadmin@yunohost-addapps-xxl:~$ sudo systemctl status docker.service 
● docker.service - Docker Application Container Engine
    Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
    Active: inactive (dead) since Mon 2025-05-19 15:36:04 UTC; 14s ago
TriggeredBy: ● docker.socket
      Docs: https://docs.docker.com
    Process: 90952 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (code=exited, status=0/SUCCESS)
  Main PID: 90952 (code=exited, status=0/SUCCESS)
        CPU: 46.692s

May 19 15:36:04 yunohost-addapps-xxl dockerd[90952]: time="2025-05-19T15:36:04.584873760Z" level=warning msg="Error (Unable to complete atomic operation, key modified) deleting object [endpoint gk9rj7vs3v0qkne0>
May 19 15:36:04 yunohost-addapps-xxl dockerd[90952]: time="2025-05-19T15:36:04.661980482Z" level=warning msg="Error (Unable to complete atomic operation, key modified) deleting object [endpoint_count gk9rj7vs3v>
May 19 15:36:04 yunohost-addapps-xxl dockerd[90952]: time="2025-05-19T15:36:04.662147447Z" level=error msg="network ingress remove failed: error while removing network: unknown network ingress id gk9rj7vs3v0qkn>
May 19 15:36:04 yunohost-addapps-xxl dockerd[90952]: time="2025-05-19T15:36:04.662305126Z" level=error msg="network ingress remove failed: error while removing network: unknown network ingress id gk9rj7vs3v0qkn>
May 19 15:36:04 yunohost-addapps-xxl dockerd[90952]: time="2025-05-19T15:36:04.662977739Z" level=info msg="stopping event stream following graceful shutdown" error="<nil>" module=libcontainerd namespace=moby
May 19 15:36:04 yunohost-addapps-xxl dockerd[90952]: time="2025-05-19T15:36:04.664077690Z" level=info msg="Daemon shutdown complete"
May 19 15:36:04 yunohost-addapps-xxl dockerd[90952]: time="2025-05-19T15:36:04.664181256Z" level=info msg="stopping event stream following graceful shutdown" error="context canceled" module=libcontainerd namesp>
May 19 15:36:04 yunohost-addapps-xxl systemd[1]: docker.service: Succeeded.
May 19 15:36:04 yunohost-addapps-xxl systemd[1]: Stopped Docker Application Container Engine.
May 19 15:36:04 yunohost-addapps-xxl systemd[1]: docker.service: Consumed 46.692s CPU time.
cfadmin@yunohost-addapps-xxl:~$ sudo docker ps
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Puis 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

Enfin, j'ai redémarré le service Docker et tout est rentré dans l'ordre.

Scénario le plus probable : - Oppscience (Sylvain Moreau) tente de se connecter à Cywise et a un timeout (504) - La requête SQL déclenchée par cette connexion continue à tourner et consomme du CPU sur yunohost-addapps - Cette consommation de CPU finit par empêcher le renouvellement de l'IP (v4 et/ou v6) de yunohost-addapps et provoque l'interruption de service et la coupure pour le SSH aussi. - Je redémarre la machine - La tentative de ménage de Cyrille (suppression des événements CF de la table ynh_osquery) avec une requête SQL bloque à nouveau la machine. - Je découvre le problème réseau de Docker. Il est probablement dû au premier redémarrage de la machine qui est brutal et n'a pas dû laisser le temps à Docker de s'arrêter proprement. - Un nouveau redémarrage de la machine ne change rien. - La suppression des interfaces vxlan puis le démarrage de Docker permet de résoudre le problème.

16:00 - Plus de ping, nslookup ou curl sur yunohost-sentinel-api (problème DNS)

Par exemple, quand je fais :

twr_admin@sentinel-api:~$ ping app.cywise.io
ping: app.cywise.io: Temporary failure in name resolution

Le DNS, avec YunoHost, passe par dnsmask. J'ai arrêté puis redémarré le service sur la machine Sentinel API.

J'ai arrêté puis démarré le service dnsmasq ce qui a résolu le problème.

Détails

twr_admin@sentinel-api:~$ sudo systemctl status dnsmasq.service 
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
    Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
    Active: active (running) since Thu 2025-02-06 06:26:27 CET; 3 months 11 days ago
  Main PID: 1837854 (dnsmasq)
      Tasks: 1 (limit: 232000)
    Memory: 1.9M
        CPU: 21min 838ms
    CGroup: /system.slice/dnsmasq.service
            └─1837854 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service --trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c0b0d7c65d08458e880>

Apr 25 16:13:07 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
Apr 25 16:13:13 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
Apr 28 17:37:46 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
Apr 28 17:37:52 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
May 08 20:29:35 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
May 09 02:42:31 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
May 14 10:15:28 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
May 15 15:53:50 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
May 19 15:34:51 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
Warning: journal has been rotated since unit was started, output may be incomplete.
twr_admin@sentinel-api:~$ sudo systemctl stop dnsmasq.service 
twr_admin@sentinel-api:~$ sudo systemctl status dnsmasq.service 
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
    Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
    Active: failed (Result: timeout) since Mon 2025-05-19 16:25:12 CEST; 11s ago
    Process: 1298447 ExecStop=/etc/init.d/dnsmasq systemd-stop-resolvconf (code=exited, status=0/SUCCESS)
  Main PID: 1837854 (code=killed, signal=KILL)
        CPU: 21min 958ms

May 14 10:15:28 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
May 15 15:53:50 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
May 19 15:34:51 sentinel-api.towerify.io dnsmasq[1837854]: Maximum number of concurrent DNS queries reached (max: 150)
May 19 16:23:42 sentinel-api.towerify.io systemd[1]: Stopping dnsmasq - A lightweight DHCP and caching DNS server...
May 19 16:25:12 sentinel-api.towerify.io systemd[1]: dnsmasq.service: State 'stop-sigterm' timed out. Killing.
May 19 16:25:12 sentinel-api.towerify.io systemd[1]: dnsmasq.service: Killing process 1837854 (dnsmasq) with signal SIGKILL.
May 19 16:25:12 sentinel-api.towerify.io systemd[1]: dnsmasq.service: Main process exited, code=killed, status=9/KILL
May 19 16:25:12 sentinel-api.towerify.io systemd[1]: dnsmasq.service: Failed with result 'timeout'.
May 19 16:25:12 sentinel-api.towerify.io systemd[1]: Stopped dnsmasq - A lightweight DHCP and caching DNS server.
May 19 16:25:12 sentinel-api.towerify.io systemd[1]: dnsmasq.service: Consumed 21min 958ms CPU time.
twr_admin@sentinel-api:~$ sudo systemctl start dnsmasq.service 
twr_admin@sentinel-api:~$ sudo systemctl status dnsmasq.service 
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
    Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
    Active: active (running) since Mon 2025-05-19 16:25:31 CEST; 10s ago
    Process: 1310688 ExecStartPre=/etc/init.d/dnsmasq checkconfig (code=exited, status=0/SUCCESS)
    Process: 1310695 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS)
    Process: 1310705 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=exited, status=0/SUCCESS)
  Main PID: 1310704 (dnsmasq)
      Tasks: 1 (limit: 232000)
    Memory: 836.0K
        CPU: 346ms
    CGroup: /system.slice/dnsmasq.service
            └─1310704 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service --trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c0b0d7c65d08458e880>

May 19 16:25:30 sentinel-api.towerify.io dnsmasq[1310704]: using nameserver 194.150.168.168#53
May 19 16:25:30 sentinel-api.towerify.io dnsmasq[1310704]: using nameserver 2001:1608:10:25::1c04:b12f#53
May 19 16:25:30 sentinel-api.towerify.io dnsmasq[1310704]: using nameserver 2a0c:e300::101#53
May 19 16:25:30 sentinel-api.towerify.io dnsmasq[1310704]: using nameserver 2a00:5881:8100:1000::3#53
May 19 16:25:30 sentinel-api.towerify.io dnsmasq[1310704]: using nameserver 2001:910:800::12#53
May 19 16:25:30 sentinel-api.towerify.io dnsmasq[1310704]: using nameserver 89.233.43.71#53
May 19 16:25:30 sentinel-api.towerify.io dnsmasq[1310704]: using nameserver 91.239.100.100#53
May 19 16:25:30 sentinel-api.towerify.io dnsmasq[1310704]: using nameserver 80.67.169.40#53
May 19 16:25:30 sentinel-api.towerify.io dnsmasq[1310704]: read /etc/hosts - 6 addresses
May 19 16:25:31 sentinel-api.towerify.io systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.
twr_admin@sentinel-api:~$

2025-05-15¶

12:45 - Problème de mise à jour de Cywise PROD

Concerns

Resource - deployment - cywise-ui_prod

Interruption 15 minutes

Du jeudi 15/05 12h50 au jeudi 15/05 13h05 soit 15 minutes

J'ai fait une MEP et j'ai constaté que l'image Docker des services de la stack Cywise PROD n'était pas à jour. J'ai arrêté le service cywise-ui_prod puis je l'ai redémarré mais il ne redémarrait pas.

J'ai fini par comprendre que la stack cywise-ui_prod ne démarrait pas à cause d'une erreur dans le fichier .env (les secrets) : une ligne qui n'était pas du type KEY=VALUE.

J'ai corrigé le fichier .env et le service cywise-ui_prod a pu redémarrer avec la bonne image Docker.

J'ai également mis à jour le fichier des secrets sur mon poste pour supprimer la ligne qui posait problème.

2025-05-13¶

17:00 - Bug à l'embarquement - Problème de token

Concerns

Resource - deployment - cywise-ui_prod

Un propect de Cywise a eu un problème d'embarquement :

De : Christophe GRENIER cgrenier@globalsp.com Date : mardi 13 mai 2025 à 15:50 À : Eric Esmerian eesmerian@computablefacts.com Objet : RE: Offre de Pentest

Il y a eu un bug lors de la finalisation de l’inscription. « Ce jeton de réinitialisation du mot de passe n'est pas valide. » J’ai contourné le problème avec « Perte de mot de passe ».

Je vois, dans les logs de app qu'il a fait plusieurs appels aux URL de reset de mot de passe :

10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:34:09 +0000] "GET /password/reset/f82523df8b7afbbbd4e7f47cba4646778395254437804f59b689442b2cbdefe8?email=grenier%40cgsecurity.org&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe HTTP/1.0" 200 3877 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:34:29 +0000] "POST /password/reset HTTP/1.0" 302 2703 "https://app.cywise.io/password/reset/f82523df8b7afbbbd4e7f47cba4646778395254437804f59b689442b2cbdefe8?email=grenier%40cgsecurity.org&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:34:29 +0000] "GET /password/reset/f82523df8b7afbbbd4e7f47cba4646778395254437804f59b689442b2cbdefe8?email=grenier%40cgsecurity.org&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe HTTP/1.0" 200 3947 "https://app.cywise.io/password/reset/f82523df8b7afbbbd4e7f47cba4646778395254437804f59b689442b2cbdefe8?email=grenier%40cgsecurity.org&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:34:45 +0000] "GET /password/reset/f82523df8b7afbbbd4e7f47cba4646778395254437804f59b689442b2cbdefe8?email=grenier%40cgsecurity.org&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe HTTP/1.0" 200 3877 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:34:58 +0000] "POST /password/reset HTTP/1.0" 302 2703 "https://app.cywise.io/password/reset/f82523df8b7afbbbd4e7f47cba4646778395254437804f59b689442b2cbdefe8?email=grenier%40cgsecurity.org&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:34:58 +0000] "GET /password/reset/f82523df8b7afbbbd4e7f47cba4646778395254437804f59b689442b2cbdefe8?email=grenier%40cgsecurity.org&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe HTTP/1.0" 200 3947 "https://app.cywise.io/password/reset/f82523df8b7afbbbd4e7f47cba4646778395254437804f59b689442b2cbdefe8?email=grenier%40cgsecurity.org&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:35:12 +0000] "GET /login HTTP/1.0" 200 3231 "https://app.cywise.io/password/reset/f82523df8b7afbbbd4e7f47cba4646778395254437804f59b689442b2cbdefe8?email=grenier%40cgsecurity.org&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:36:27 +0000] "GET /password/reset/ea6ebb95aecbbb34e2545323b9f666fbe39365673963cdb6fa963bc2d5dee263?email=grenier%40cgsecurity.org HTTP/1.0" 200 3856 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:36:38 +0000] "POST /password/reset HTTP/1.0" 302 1516 "https://app.cywise.io/password/reset/ea6ebb95aecbbb34e2545323b9f666fbe39365673963cdb6fa963bc2d5dee263?email=grenier%40cgsecurity.org" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:36:38 +0000] "GET /home HTTP/1.0" 200 14338 "https://app.cywise.io/password/reset/ea6ebb95aecbbb34e2545323b9f666fbe39365673963cdb6fa963bc2d5dee263?email=grenier%40cgsecurity.org" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"

Lien reçu avec Mandat@Archers-Guyancourt.fr : https://app.cywise.io/password/reset/8c2dec94d5a5f77483dcf3caf8667e25e51be8bb64356980644ff447b122409e?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe

10.0.6.130:80 10.0.0.2 - - [13/May/2025:15:47:55 +0000] "GET /password/reset/8c2dec94d5a5f77483dcf3caf8667e25e51be8bb64356980644ff447b122409e?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe HTTP/1.0" 200 3883 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.130:80 10.0.0.2 - - [13/May/2025:15:49:06 +0000] "POST /password/reset HTTP/1.0" 302 1516 "https://app.cywise.io/password/reset/8c2dec94d5a5f77483dcf3caf8667e25e51be8bb64356980644ff447b122409e?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.130:80 10.0.0.2 - - [13/May/2025:15:49:06 +0000] "GET /home HTTP/1.0" 200 10472 "https://app.cywise.io/password/reset/8c2dec94d5a5f77483dcf3caf8667e25e51be8bb64356980644ff447b122409e?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"

=> Je n'ai pas reproduit le problème avec ce lien

Je refais un test avec Mandat@Archers-Guyancourt.fr (après avoir supprimer ce compte dans la base). Nouveau lien reçu : https://dev.cywise-ui.myapps.addapps.io/password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe

Oups, il pointe vers le site de DEV !

Je retrouve bien une ligne dans la table password_resets avec le mail Mandat@Archers-Guyancourt.fr dans la base de DEV.

10.0.10.47:80 10.0.0.2 - - [13/May/2025:16:17:56 +0000] "GET /password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe HTTP/1.0" 200 3914 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.10.47:80 10.0.0.2 - - [13/May/2025:16:24:08 +0000] "POST /password/reset HTTP/1.0" 302 2839 "https://dev.cywise-ui.myapps.addapps.io/password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.10.47:80 10.0.0.2 - - [13/May/2025:16:24:08 +0000] "GET /password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe HTTP/1.0" 200 3960 "https://dev.cywise-ui.myapps.addapps.io/password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.10.47:80 10.0.0.2 - - [13/May/2025:16:24:22 +0000] "POST /password/reset HTTP/1.0" 302 2839 "https://dev.cywise-ui.myapps.addapps.io/password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.10.47:80 10.0.0.2 - - [13/May/2025:16:24:22 +0000] "GET /password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe HTTP/1.0" 200 3960 "https://dev.cywise-ui.myapps.addapps.io/password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.10.47:80 10.0.0.2 - - [13/May/2025:16:24:37 +0000] "POST /password/reset HTTP/1.0" 302 1622 "https://dev.cywise-ui.myapps.addapps.io/password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.10.47:80 10.0.0.2 - - [13/May/2025:16:24:37 +0000] "GET /home HTTP/1.0" 200 10327 "https://dev.cywise-ui.myapps.addapps.io/password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"

J'ai mis 2 fois un mot de passe erroné donc le formulaire s'est réaffiché avec l'erreur. Malgré cela, j'ai pu valider une troisième fois avec un password valide et le compte a été créé.

https://app.cywise.io/password/reset/5cbd2e0db1150f88b90d99191829eb6d0f5b9f1146967df6f113f304a9c72a72?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe

J'ai testé la modification de l'email avant validation du formulaire. J'obtiens le message : "Aucun utilisateur n'a été trouvé avec cette adresse email.". Donc pas le même problème.

Finalement, pour reproduire le problème, il faut attendre plus de 60 minutes avant d'utiliser le lien de réinitialisation du mot de passe. En effet, par défaut, il expire au bout de 60 minutes. Il faut donc que le prospect attende plus de 60 minutes avant de valider le formulaire de réinitialisation du mot de passe. Il reçoit alors le message "Ce jeton de réinitialisation du mot de passe n'est pas valide.".

Actions : - j'ai mis en lecture seule l'email pour éviter la tentation de le changer - j'ai passé l'expiration à 90 minutes pour tester que j'ai trouvé le bon réglage - je mettrais 15j (durée de la période d'essai) après validation

2025-05-07¶

09:00 - Réglage MariaDB pour place disque

Concerns

Resource - server - yunohost-addapps

La place disque manque sur yunohost-addapps : 10G à 20G de libre. Je me rends compte que j'ai plus de 30G de fichiers avec des noms du type 0.000345, 0.000346, 0.000347, etc.

Finalement, ce sont des binary logs de MariaDB que je pensais avoir désactivé avec l'option log_bin = 0. Mais cette option indique le nom des fichiers d'où mes fichiers avec des noms en 0.

Je commente la ligne log_bin = 0 dans le fichier de configuration /etc/mysql/mariadb.conf.d/50-server.cnf et je redémarre le service.

Je vérifie avec la requête SHOW GLOBAL VARIABLES LIKE 'log_bin'; qui affiche bien OFF.

Puis je supprime les fichiers de logs avec la commande :

sudo rm -f /var/lib/mysql/0.*

30G de place disque de libérée.

2025-04-30¶

11:30 - Plantage de yunohost-addapps donc de toutes les apps hébergées dessus.

Concerns

Interruption du mercredi 30/04 9h15 au mercredi 30/04 11h45 soit 2 heures 30 minutes

Toutes les applications hébergées sur yunohost-addapps n'étaient plus accessibles.

J'ai eu une alerte à 9h13 venant de mes surveillances Freshping pour Cywise PROD puis toute une série pour les autres applications :

9h13 : DOWN - Cywise PROD
9h25 : DOWN - Ping yunohsot-addapps
9h27 : DOWN - Performa CF
9h27 : DOWN - Cywise Superset
9h27 : DOWN - Performa DEV
9h27 : DOWN - Performa pour Oppscience
9h27 : DOWN - Performa pour Elephantastic
9h32 : DOWN - Performa pour Postface
9h32 : DOWN - Performa ISTA

Puis Cyrille a redémarré l'instance yunohost-addapps-xxl vers 11h15.

Et Cywise PROD est repassé up à 11h27 puis tous les autres aussi :

11h20 : UP - Ping yunohsot-addapps
11h21 : DOWN - Cywise PROD
11h27 : UP - Cywise PROD
11h37 : UP - Performa pour Postface
11h37 : DOWN - Performa pour Elephantastic
11h37 : DOWN - Performa CF
11h37 : DOWN - Performa DEV
11h37 : DOWN - Performa pour Oppscience
11h37 : DOWN - Cywise Superset
11h42 : UP - Performa pour Oppscience
11h42 : UP - Performa CF
11h42 : UP - Performa pour Elephantastic
11h42 : UP - Performa ISTA
11h42 : UP - Cywise Superset
11h46 : UP - Performa DEV

10:30 - Timeout à la connexion

La page /home de cywise-prod fait un timeout (504). Ce qui correspond à un timeout à la connexion d'un utilisateur puisqu'il est redirigé vers cette page après sa connexion.

Sylvain Moreau de Oppscience a appelé Cyrille ce matin qui a ouvert le ticket #8879.

C'est la vue pour les login/logout qui est lente (plus de 80s d'après les tests de Cyrille). Cette vue utilise la table ynh_osquery (24M+ de lignes) au lieu d'utiliser la table ynh_osquery_latest_events (180k+ de lignes).

J'ai donc fait un patch directement dans la base de données de Cywise PROD pour modifier la vue v_logins_and_logouts.

La vue avant

CREATE OR REPLACE VIEW v_logins_and_logouts AS
SELECT DISTINCT
  ynh_servers.user_id,
  users.customer_id,
  users.tenant_id,
  ynh_osquery.id AS event_id,
  ynh_osquery.ynh_server_id AS server_id,
  ynh_servers.name AS server_name,
  ynh_servers.ip_address AS server_ip_address,
  ynh_osquery.calendar_time AS timestamp,
  json_unquote(json_extract(ynh_osquery.columns, '$.pid')) AS pid,    
  CASE
    WHEN json_unquote(json_extract(ynh_osquery.columns, '$.host')) = 'null' THEN NULL
    ELSE json_unquote(json_extract(ynh_osquery.columns, '$.host'))
  END AS entry_host,
  json_unquote(json_extract(ynh_osquery.columns, '$.time')) AS entry_timestamp,
  json_unquote(json_extract(ynh_osquery.columns, '$.tty')) AS entry_terminal,
  json_unquote(json_extract(ynh_osquery.columns, '$.type_name')) AS entry_type,
  CASE
      WHEN json_unquote(json_extract(ynh_osquery.columns, '$.username')) = 'null' THEN NULL
      ELSE json_unquote(json_extract(ynh_osquery.columns, '$.username'))
  END AS entry_username,
  ynh_osquery.action,
  ynh_osquery.name,
  ynh_osquery.columns_uid
FROM ynh_osquery
INNER JOIN ynh_servers ON ynh_servers.id = ynh_osquery.ynh_server_id
INNER JOIN users ON users.id = ynh_servers.user_id
WHERE ynh_osquery.name = 'last'

La vue après

CREATE OR REPLACE VIEW v_logins_and_logouts AS
SELECT DISTINCT
  ynh_servers.user_id,
  users.customer_id,
  users.tenant_id,
  ynh_osquery.id AS event_id,
  ynh_osquery.ynh_server_id AS server_id,
  ynh_servers.name AS server_name,
  ynh_servers.ip_address AS server_ip_address,
  ynh_osquery.calendar_time AS timestamp,
  json_unquote(json_extract(ynh_osquery.columns, '$.pid')) AS pid,    
  CASE
    WHEN json_unquote(json_extract(ynh_osquery.columns, '$.host')) = 'null' THEN NULL
    ELSE json_unquote(json_extract(ynh_osquery.columns, '$.host'))
  END AS entry_host,
  json_unquote(json_extract(ynh_osquery.columns, '$.time')) AS entry_timestamp,
  json_unquote(json_extract(ynh_osquery.columns, '$.tty')) AS entry_terminal,
  json_unquote(json_extract(ynh_osquery.columns, '$.type_name')) AS entry_type,
  CASE
      WHEN json_unquote(json_extract(ynh_osquery.columns, '$.username')) = 'null' THEN NULL
      ELSE json_unquote(json_extract(ynh_osquery.columns, '$.username'))
  END AS entry_username,
  ynh_osquery.action,
  ynh_osquery.name,
  ynh_osquery.columns_uid
FROM (
  SELECT
    ynh_osquery_id AS _oid,
    ynh_server_id AS _sid
  FROM ynh_osquery_latest_events
  WHERE event_name = 'last'
) AS t
INNER JOIN ynh_osquery ON ynh_osquery.id = t._oid
INNER JOIN ynh_servers ON ynh_servers.id = t._sid
INNER JOIN users ON users.id = ynh_servers.user_id

2025-04-25¶

Plus de mémoire pour MariaDB

Concerns

Resource - server - angardia-ai

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-04-25
# Mémoire
innodb_buffer_pool_size = 32G   # ~75% de la RAM si MariaDB est le principal service
innodb_buffer_pool_instances = 8  # Diviser le buffer en plusieurs instances (nombre conseillé = RAM/2G, max 8)
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
innodb_flush_method = O_DIRECT   # Évite la mise en cache du système de fichiers

# Optimisation CPU et threads
innodb_thread_concurrency = 24   # Généralement 2x le nombre de CPU
innodb_read_io_threads = 8
innodb_write_io_threads = 8
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 = 0   # Désactiver le log binaire si pas de réplication
#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-04-25

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.angardia.ai/index.php?route=/server/variables).

2025-04-24¶

Installation de Clickhouse sur angardia-ai

Concerns

Resource - server - angardia-ai

J'ai mis à jour clickhouse_ynh et ma branche restart_for_certificate pour faire un redémarrage automatique de Clickhouse chaque dimanche matin.

J'ai installé la nouvelle version sur angardia-ai :

sudo yunohost app install --force https://github.com/computablefacts/clickhouse_ynh/tree/restart_for_certificate --args "domain=clickhouse.apps.angardia.ai&path=/&init_main_permission=visitors&admin=twr_admin&password=***"

J'ai l'erreur Code: 210. DB::NetException: SSL Exception: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED (localhost:9440). (NETWORK_ERROR) au moment où l'installation essaie de se connecter à Clickhouse avec clickhouse-client pour créer le rôle ldap_user_role...

Je pense que c'est dû au fait que le domaine n'a pas de certificat SSL Let's Encrypt.

Mais j'ai également une erreur quand j'essaie de créer le certificat LE avec la commande :

sudo yunohost domain cert install clickhouse.apps.angardia.ai --no-checks

Let's Encrypt essaie de valider le domaine avec un challenge HTTP sur l'URL, par exemple, http://clickhouse.apps.angardia.ai/.well-known/acme-challenge/SidGfKTJ_M_nTtZDIB96rGR29wxLXJJ7V_WsSNPTQfE mais cette URL est redirigée vers https://clickhouse.apps.angardia.ai/yunohost/admin/ (page d'administration de YunoHost). Je le constate quand je l'appelle avec curl depuis mon poste :

patrick@SpectreMate:~
[14:59:01]$ curl -v http://clickhouse.apps.angardia.ai/.well-known/acme-challenge/SidGfKTJ_M_nTtZDIB96rGR29wxLXJJ7V_WsSNPTQfE
*   Trying 51.159.101.88:80...
* Connected to clickhouse.apps.angardia.ai (51.159.101.88) port 80 (#0)
> GET /.well-known/acme-challenge/SidGfKTJ_M_nTtZDIB96rGR29wxLXJJ7V_WsSNPTQfE HTTP/1.1
> Host: clickhouse.apps.angardia.ai
> User-Agent: curl/7.81.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Moved Temporarily
< Server: nginx
< Date: Thu, 24 Apr 2025 12:59:14 GMT
< Content-Type: text/html
< Content-Length: 138
< Connection: keep-alive
< Location: https://clickhouse.apps.angardia.ai/yunohost/admin
< 
<html>
<head><title>302 Found</title></head>
<body>
<center><h1>302 Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host clickhouse.apps.angardia.ai left intact

Je pense que c'est dû au fait que le YunoHost d'angardia-ai est en version 12.

J'ai fini par trouver. La conf nginx du domaine clickhouse.apps.angardia.ai me semblait correcte donc j'ai redémarré nginx avec sudo systemctl restart nginx et j'ai relancé la commande d'installation du certificat Let's Encrypt.

sudo yunohost domain cert install clickhouse.apps.angardia.ai --no-checks

Cette fois-ci, ça a fonctionné.

NOTA : j'avais déjà fait sudo systemctl reload nginx mais ça n'avait pas résolu le problème.

Je relance l'installation de Clickhouse. Elle réussit sans erreur cette fois.

J'ai créé un compte MySQL clickhouse_ro avec le droit SELECT sur la base angardia_ai_dev.

Puis j'ai créé une base clickhouse qui "pointe" vers la base MySQL angardia_ai_dev :

CREATE DATABASE angardia_ai_dev
ENGINE = MySQL('127.0.0.1:3306', 'angardia_ai_dev', 'clickhouse_ro', '<password>')

J'ai créé un utilisateur datascience_ro dans clickhouse et je lui ai donné accès uniquement à la base clickhouse angardia_ai_dev. Voilà le fichier de configuration que j'ai ajouté pour ça :

<?xml version="1.0"?>
<yandex>
    <users>
        <datascience_ro>
            <password_sha256_hex>d8b5b5025740f087f6fccab0b1ad88f338df544154decc3ae53195b40ea20ec7</password_sha256_hex>
            <access_management>0</access_management>
            <named_collection_control>0</named_collection_control>
            <show_named_collections>0</show_named_collections>
            <show_named_collections_secrets>0</show_named_collections_secrets>
            <profile>readonly</profile>
            <quota>unlimited</quota>
            <networks>
                <ip>::/0</ip>
            </networks>
            <default_database>angardia_ai_dev</default_database>
            <allow_databases>
                <database>angardia_ai_dev</database>
            </allow_databases>
        </datascience_ro>
    </users>
</yandex>

J'ai mis ce fichier dans /etc/clickhouse-server/users.d/datascience_ro.xml. Il n'est pas nécessaire de redémarrer Clickhouse pour que ce fichier soit pris en compte.

2025-04-23¶

Mot de passe de Matthieu non propagé sur yunohost-ista-dev

Concerns

Matthieu a ouvert le ticket #8775.

Ses login et mot de passe de app.cywise.io ne fonctionnent pas pour configurer Towerify CLI.

Je vais faire comme avec Marlène en février : décoder son mot de passe puis mettre ce mot de passe sur son compte sur ISTA DEV.

Décodage du mot de passe

J'ajoute le code ci-dessous dans TheCyberBriefController.php de Towerify :

$passwordChiffre = '<MotDePasseChiffré>';
$key = '<HASHER_NONCE>';
$initializationVector = strtok($passwordChiffre, '_');
$value2 = substr($passwordChiffre, strpos($passwordChiffre, '_') + 1);
$passwordDechiffre = openssl_decrypt($value2, 'AES-256-CBC', $key, 0, $initializationVector);
Log::info($passwordDechiffre);

Je remplace <MotDePasseChiffré> par le mot de passe de Matthieu dans la table users. Je remplace <HASHER_NONCE> par la clé du hasher qui se trouve dans les secrets.

J'affiche la page d'accueil local de Towerify (http://localhost:8080/) et je retrouve le mot de passe de Matthieu dans les logs affichés en bas de la page (onglet Messages).

Mise à jour du mot de passe

Je fais cette commande sur yunohost-ista-dev :

sudo yunohost user update matthieu.gosset -p <MotDePasse>

Je fais aussi cette commande sur yunohost-ista-prod :

sudo yunohost user update matthieu.gosset -p <MotDePasse>

Matthieu a confirmé dans le ticket que ça fonctionnait pour lui.

2025-04-20¶

19:30 - Nos 5 performa ne répondent plus

Concerns

Interruption du vendredi 18/04 18h15 au dimanche 20/04 20h15 soit 50 heures

Les remontées des machines de nos 5 performa ont été perdues.

J'ai eu 3 alertes à 18h12 venant de mes surveillances Freshping. Puis les 2 autres alertes à 18h17 puis 18h22.

Les images des 5 performa ne sont plus présentes.

Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.

Je décide de mettre en commentaire le cron qui fait le ménage dans les images Docker (docker builder prune -f) pour éviter de supprimer les images. En principe, cette commande ne devrait pas supprimer les images utilisées par les containers mais je ne vois pas ce qui pourrait les supprimer à part cette commande. D'où ma décision de la mettre en commentaire.

2025-04-17¶

16:50 - Nos 5 performa ne répondent plus

Concerns

Interruption du jeudi 17/04 16h45 au jeudi 17/04 17h05 soit 20 minutes

Les remontées des machines de nos 5 performa ont été perdues.

J'ai eu 4 alertes à 16h47 venant de mes surveillances Freshping. Puis la 5ème à 16h51.

Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.

Je constate que Docker a redémarré à 16h32. Certainement suite à un towerify deploy. Les images des performa ont pu être supprimées plus tôt et c'est au moment du redémarrage que Docker ne les trouve plus et que les performa ne peuvent donc pas redémarrer...

2025-04-08¶

Problème d'intégration de données par Marlène d'Ista

Concerns

Resource - server - yunohost-ista-dev

La description du problème par Marlène dans un SMS :

Je suis en pleine mise à jour des données d'istaLake, je ne suis pas sûre que l'un de mes jeux de données (qlik-appareils) se soit bien importé car j'ai un nombre de lignes=0 pour ce jeu dans DEV d'après le comparatif DEV/PROD superset. Dans le catalogue de données sur l'app de DEV, je n'ai pas l'en-tête censé m'indiquer la dernière date de màj. Dans Nifi, je vois "Queued 1" dans l'étape LoadFile mais je ne sais pas coment creuser plus pour voir s'il s'agit de ce jeu-là et comment le débloquer.

Quand je regarde superset, je vois bien le dataset qlik_appareils avec 0 ligne côté DEV contre 6.6M côté PROD. Le plus probable, c'est que NiFi a effacé les données avant d'importer le nouveau fichier.

En me connectant au SFTP sur la machine de DEV, je vois que le dossier qlik-appareils a été modifié hier (2025-04-08) vers 13h40. Certainement l'heure du dépôt du fichier par Marlène. Le dossier /ista/dev/qlik-appareils/2025/04/08 est vide donc NiFi est bien venu chercher le fichier. Et le dossier /ista/dev_out/qlik-appareils/2025/04/08 est rempli ce qui indiquerait que NiFi a bien traité le fichier. Les fichiers sont :

qlik-appareils.csv (954Mo)
qlik-appareils.docs.jsonl.gz (337Mo)
qlik-appareils.processed.jsonl.gz (128Mo)

En regardant dans NiFi, je trouve le fichier (flowfile) qui est dans une file d'attente (Queued) mais il s'agit de la file d'attente des fichiers qui n'ont pas pu être traités faute d'avoir déposé le end_of_upload.txt et que nous sortons en bout de 3h. Ce flowfile a été créé il y a 90 jours donc peu de chance qu'il soit lié au problème de Marlène.

2025-04-07¶

Création d'une repo pour le code de yunohost-josiane

Concerns

Resource - server - yunohost-josiane

Thomas, notre stagiaire, a commencé le code d'ingestion des fichiers de Josiane dans Clickhouse. A sa demande, je crée une repo pour stocker ce code.

J'ai créé la repo sur GitHub : https://github.com/computablefacts/josiane

J'ai mis le compte de Thomas (Touxooo) dans les membres du groupes contributors donc il a déjà un accès en écriture à la repo.

Par contre, il code avec Visual Studio Code depuis son PC en se connectant par SSH à yunohost-josiane avec le compte twr_admin. Donc, j'ai créé une clé SSH pour ce compte et je l'ai ajoutée à la repo GitHub.

J'ai fait un premier commit avec le code de Thomas.

2025-04-04¶

Installation de Clickhouse sur yunohost-josiane

Concerns

Resource - server - yunohost-josiane

J'ai déjà installé YunoHost sur yunohost-josiane depuis app.cywise.io.

J'ai voulu commencer par mettre en place un redémarrage automatique de Clickhouse pour qu'il prenne en compte le certificat SSL Let's Encrypt après son renouvellement. Mais je n'ai pas réussi à mettre au point la mise à jour du package YunoHost de Clickhouse (que je voulais utiliser pour mettre à jour les 2 serveurs d'ISTA).

Du coup, j'ai tout de même fait une nouvelle version du package YunoHost de Clickhouse pour y ajouter le redémarrage automatique de Clickhouse. Je l'ai installé sur yunohost-josiane.

sudo yunohost app install --force https://github.com/computablefacts/clickhouse_ynh/tree/restart_for_certificate --args "domain=clickhouse.apps.josiane.computablefacts.io&path=/&init_main_permission=visitors&admin=twr_admin&password=***"

Puis modifié pour changer le timing (redémarrage tous les dimanches matin).

2025-03-27¶

15:15 - Erreur 500 sur ISTA DEV et ISTA PROD

Concerns

Marlène a ouvert le ticket #8768 hier vers 17h30. Et Jimmy nous a relancé par mail ce jour, 27/03 vers 15h.

Nous reproduisons bien le problème sur les 2 environnements.

Après recherche, c'est le même problème que nous avons déjà eu 2 fois (au moins) : le certificat SSL de clickhouse qui se met à jour pour le HTTPS mais n'est pas pris en compte pour le port sécurisé 9440 si le service Clickhouse n'est pas redémarré.

Il y avait ensuite la problématique du cache qu'il fallait vider. La bonne procédure est :

redémarrage du service clickhouse
redémarrage de CoreAPI (Le cache de CoreAPI est supprimé)
redémarrage du redis de Federa UI (Le cache de l'UI est supprimé)

J'ai exécuté cette procédure sur les 2 environnements et tout est rentré dans l'ordre.

2025-03-24¶

Suppression de la machine scw-optimistic-brattain

Concerns

Deprecated: Resource - server - scw-optimistic-brattain

La Smacl n'étant plus un client, pas la peine de garder cette machine qui servait a entraîner ses modèles.

2025-03-21¶

20:10 - Nos 5 performa ne répondent plus

Concerns

Interruption du mardi 25/03 17h au mercredi 26/03 15h soit 22 heures

Les remontées des machines de nos 5 performa ont été perdues.

J'ai eu 5 alertes à 16h51 venant de mes surveillances Freshping que je n'ai vues que le lendemain vers 15h.

Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.

Deux déploiements de Cywise DEV ont été faits par Cyrille à 16h28 puis 16h34. Je pense qu'ils sont à l'origine de la perte des images des Performa mais je n'arrive pas à trouver le lien.

20:10 - Nos 5 performa ne répondent plus

Concerns

Interruption du vendredi 21/03 17h40 au vendredi 21/03 20h25 soit 2 heures et 45 minutes

Les remontées des machines de nos 5 performa ont été perdues.

J'ai eu 2 alertes à 17h42 venant de mes surveillances Freshping. Puis 2 alertes à 17h46. Puis une alerte pour le cinquième performa à 18h12.

En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.

Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.

Cela s'est produit à nouveau après un towerify deploy de ma doc d'infra. Je ne sais pas si c'est lié.

Suppression des hooks Portainer pour les apps qui n'existent plus sur swarm01

Concerns

Resource - deployment - deploy-redirect

Pour mettre à jour les stacks de swarm01, j'utilisais les hooks Portainer permettant de mettre à jour un service et j'avais mis ces hooks derrière des redirections avec la stack deploy-redirect.

Comme j'ai supprimé quasiment toutes les stacks sauf les 3 cf-ui de Lur Berri, je vais supprimer les redirections pour les apps qui n'existent plus.

Les redirections que j'ai supprimées (dans ansible/roles/stack-deploy-redirect/templates/deploy-redirect.stack.yaml.j2) :

cf-ui Sentinel DEV
cf-ui Ista DEV
cf-ui Smacl DEV
module Smacl DEV, STAGING, PROD
cf-ui Sentinel STAGING
cf-ui Ista STAGING
cf-ui Smacl STAGING
modules-smacl contracts DEV, STAGING, PROD
cf-ui Sentinel PROD
cf-ui appscompose DEV

Il reste donc les redirections pour les hooks de cf-ui Lur Berri DEV et STAGING (je n'avais pas fait celles pour la PROD).

Puis je mets à jour la stack avec la commande :

ansible-playbook -i ansible/inventory.yml ansible/client-common.yaml --tags deploy-redirect

Mise à jour de Jenkins pour Lur Berri en version 2.492.2

Concerns

Deprecated: Resource - deployment - lurberri-jenkins

En voulant supprimer notre Jenkins commun, j'ai vu tous les avertissements de sécurité et je l'ai mis à jour en version 2.492.2.

Comme le Jenkins de Lur Berri est aussi en version 2.387.1, je vais aussi le mettre à jour en version 2.492.2.

Le Jenkins de Lur Berri ne démarre plus... Problème de chargement de plugins... Je suis revenu à la version 2.387.1 mais Jenkins dit qu'il faut minimum la version 2.479.1 pour charger le premier plugin. Je suis passé en version 2.479.2 mais, maintenant, Jenkins demande la version 2.479.3 ou supérieure pour charger le plugin instance-identity.

Je suis repassé en version 2.492.2 donc toujours le problème de démarrage avec un plugins...

Le problème vient probablement du fait que j'ai voulu passer de la version 2.387.1 à la version 2.492.2 sans passer par la version 2.479.2 et sans avoir fait une mise à jour de plugins intermédiaire.

Comme les 2 Jenkins sont sur la même machine, s005, j'ai accès aux 2 répertoires de Jenkins (volumes Docker). Je vais donc copier le répertoire de plugins du Jenkins commun vers le Jenkins de Lur Berri pour voir si ça démarre.

Le Jenkins de Lur Berri redémarre.

Mise à jour terminée.

Suppression du Jenkins commun sur swarm01

Concerns

Deprecated: Resource - deployment - common-jenkins

Je pense que je pourrais supprimer le Jenkins commun déployé sur swarm01, le nôtre.

Il est en version 2.387.1, avec plein d'alertes de sécurité, je commence par le mettre à jour en version 2.479.2.

Jenkins common en version 2.479.2 puis 2.492.2

J'ai changé le tag de l'image Docker pour Jenkins mais ça ne fonctionne pas car cette image est générée par nous...

J'ai donc généré une image avec la version 2.479.2 puis mis à jour la stack de Jenkins common.

J'ai, ensuite, mis à jour les plugins de Jenkins.

Il y avait des avertissements pour mettre à jour dans la dernière version LTS i.e. 2.492.2. J'ai donc généré l'image Docker pour cette version et mis à jour à nouveau.

Mise à jour terminée

Job cf-ui DEV only¶

Ce job met à jour cf-ui DEV pour Lur Berri, Ista, Smacl et AppsCompose. J'ai supprimé les 3 derniers mais il reste Lur Berri.

Mais je vois que j'ai un job Jenkins sur le Jenkins de Lur Berri qui met à jour leurs cf-ui : https://jenkins.lurberri.computablefacts.com/job/cf-ui/. Je l'avais réglé pour qu'il ne mette pas à jour le DEV mais je pourrais le modifier facilement pour qu'il le fasse (supprimer l'exclusion de la branche develop).

Je vais donc supprimer le job cf-ui DEV only du Jenkins commun.

Job cf-ui ISTA¶

Je n'ai plus de stack ISTA sur swarm01 donc je supprime ce job.

Jobs DEV_Publish_cf-sentinel-api, STAGING_Publish_cf-sentinel-api et PROD_Publish_cf-sentinel-api¶

Ces jobs mettent à jour Sentinel API sur le Captain qui n'existe plus. Je les supprime.

J'ai vérifié et j'avais déjà supprimé les fichiers .jenkinsfile de ces jobs de la repo.

Job AdversaryMeter¶

Ce job met à jour les 3 stacks Sentinel DEV, STAGING et PROD qui n'existent plus. Je le supprime.

Jobs Build_xxx¶

Ce sont des builds maven de nos librairies Java. Cyrille me confirme que je peux supprimer tous ces jobs.

Suppression du Jenkins common¶

Je vais donc supprimer le Jenkins common.

Je supprime la stack qui se trouve sur swarm01.

sudo docker stack rm common-jenkins

ansible@s001:~$ sudo docker stack rm common-jenkins
Removing service common-jenkins_jenkins

Puis je supprime le container DinD (Docker in Docker) qui se trouve sur s005.

sudo docker stop common-jenkins_dind sudo docker rm common-jenkins_dind

ansible@s005:~$ sudo docker stop common-jenkins_dind
common-jenkins_dind
ansible@s005:~$ sudo docker rm common-jenkins_dind
common-jenkins_dind

Je supprime les 2 volumes associés.

sudo docker volume rm common-jenkins_jenkins-data sudo docker volume rm common-jenkins_jenkins-docker-certs

ansible@s005:~$ sudo docker volume rm common-jenkins_jenkins-data
common-jenkins_jenkins-data
ansible@s005:~$ sudo docker volume rm common-jenkins_jenkins-docker-certs
common-jenkins_jenkins-docker-certs

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

Je note ce deploiement comme deprecated dans cette doc.

Je supprime le tag common-jenkins.jenkins_home du noeud s005 en modifiant le fichier ansible/03-swarm01-labels.yaml puis en appliquant avec la commande : ansible-playbook -i ansible/inventory.yml ansible/03-swarm01-labels.yaml.

Suppression du Superset commun sur swarm01

Concerns

Deprecated: Resource - deployment - common-superset
Deprecated: Resource - storage - prod_superset

Je pense que je pourrais supprimer le Superset commun déployé sur swarm01, le nôtre.

Il y a 2 dashboards pour la Smacl que je supprime. Un dashboard pour AdversaryMeter qui ne fonctionne plus (nous avons déplacé AM vers Cywise) donc je le supprime aussi. Un dashboard pour Sentinel qui ne fonctionne plus (nous avons déplacé Sentinel vers Cywise) donc je le supprime aussi. Un dashboard AM pour Hermès qui n'est plus client chez nous pour AM. Je supprime également. Un dashboard pour les droits de nos cf-ui que j'ai désinstallés depuis longtemps. Je supprime aussi.

Un dashboard pour Ista qui liste les droits des utilisateurs dans cf-ui pour savoir si ces droits ont été attribués directement à l'utilisateur ou en passant par un rôle. Je vais le transférer dans le Superset de Ista.

Transfert du dashboard ISTA - User Rights

J'ai exporté le dashboard ISTA - User Rights depuis le Superset commun. J'ai modifié le fichier JSON pour changer le nom de la base de données de MySQL PROD RO vers ista_prod_mysql_ro. L'import du JSON c'est fait sans erreur dans le Superset de Ista.

Le nom de la base MySQL a changé de prodista_cfui à federa_ui_prod donc je fais le changement dans le dataset. Je supprime, dans le dataset, les parties concernant la Smacl et Lur Berri.

Puis, dans le dashboard, j'ai un warning concernant le filtre. J'ai changé les paramètres du dashboard pour mettre "show_native_filters": false, mais le warning persiste.

J'ai ouvert les 4 "charts", échangé leur dataset par le même puis enregistré. Le warning a disparu.

Je n'ai plus aucun dashboard dans le Superset commun. Je vais donc le supprimer :

la stack depuis s001 : sudo docker stack rm common-superset
le déploiement ansible dans ansible/client-common.yaml
la base MySQL prod_superset sur swarm01
l'utilisateur MySQL prosuper
le déploiement ansible de la base et de l'utilisateur dans ansible/mysql-stacks.yaml

2025-03-20¶

Suppression du Superset pour Ista déployé sur swarm01

Concerns

Deprecated: Resource - deployment - ista-superset
Deprecated: Resource - storage - prodista_superset

J'ai d'abord vérifié que j'avais bien transféré les dashboards de Ista vers le Superset de leur serveur ISTA PROD. Pour cela, j'ai modifié mon fichier /etc/hosts en ajoutant ces lignes :

# Superset ISTA on swarm01
51.159.100.42   dataviz.ista.computablefacts.com
# Superset ISTA on yunohost-ista-prod
51.159.221.199  dataviz.ista.fr

Puis j'ai comparé les dashboards de dataviz.ista.computablefacts.com et dataviz.ista.fr et tout était déjà transféré.

J'ai donc supprimé le Superset de Ista déployé sur swarm01 :

la stack depuis s001 : sudo docker stack rm ista-superset
le déploiement ansible dans ansible/client-ista.yaml
la base MySQL prodista_superset sur swarm01
l'utilisateur MySQL proistasuper

2025-03-19¶

Suppression base de données stagingappscompose_cfui

Concerns

Deprecated: Resource - storage - stagingappscompose_cfui

Je supprime la base MySQL stagingappscompose_cfui sur swarm01. J'avais créé cette base par anticipation mais je n'ai jamais déployé Apps Compose staging. Je supprime également les deux utilisateurs associés : staappscocfui et staappscocfuimater.

Suppression base de données staging_keycloak

Concerns

Resource - storage - staging-mysql

Je supprime la base MySQL staging_keycloak sur swarm01. J'ai supprimé le Keycloak de staging depuis longtemps mais j'avais oublié de supprimer la base de données. Je supprime également l'utilisateur associé : stakeyc.

J'en profite pour supprimer 2 utilisateurs Ista que j'ai dû laisser après avoir supprimé leur base de staging : staistacfui et staistacfuimater.

Suppression d'utilisateurs MySQL DEV non utilisés

Concerns

Resource - storage - dev-mysql

Je supprime les utilisateurs MySQL que j'ai laissés après suppression de leur base de données :

devappscocfui
devistacfui
devistacfuimater
devistacfuiro

Suppression d'utilisateurs MySQL PROD non utilisés

Concerns

Resource - storage - prod-mysql

Je supprime les utilisateurs MySQL que j'ai laissés après suppression de leur base de données :

proistacfui
proistacfuimater
proistacfuiro
prosentincfui
prosentincfuimater

2025-03-12¶

Mise à jour de Clickhouse sur swarm01

Concerns

Resource - deployment - swarm01-clickhouse

Nous avons besoin de manipuler des fichiers stockés dans Azure avec Clickhouse mais la version actuelle de Clickhouse, v21.10, ne supporte pas les fichiers Azure car il n'y a pas le moteur AzureBlobStorage. Ce moteur n'a été ajouté que à partir de la version v22.1.

Backup

La stack clickhouse utilise 3 volumes :

clickhouse_clickhouse-data -> /var/lib/clickhouse
clickhouse_clickhouse-conf -> /etc/clickhouse-server
clickhouse_clickhouse-materializations -> /opt/materializations

Pour sauvegarder les données, je vais recopier ces 3 répertoires. Le container de clickhouse est stické sur la machine s005.

En regardant la place disque occupée, je vois que le volume data occupe 430Go. Je vais donc d'abord faire du ménage en supprimant les bases de données de la Smacl et d'Ista.

Pour ça, je me connecte depuis mon PC au Clickhouse avec le compte nifi :

clickhouse-client --secure --host clickhouse.swarm01.computablefacts.io --user nifi --password ***

Et je supprime les plus grosses base de la smacl et d'ista. Les bases de Lur Berri font 180Go au total. Je supprime aussi sentinel_prod qui fait 110Go. Je termine avec un peu moins de 200Go à backuper.

Pour le backup, je préfère synchroniser les volumes dans un autre dossier avec rsync :

sudo rsync -avzP --delete /var/lib/docker/volumes/clickhouse_clickhouse-data ./clickhouse-backups/ 
sudo rsync -avzP --delete /var/lib/docker/volumes/clickhouse_clickhouse-conf ./clickhouse-backups/
sudo rsync -avzP --delete /var/lib/docker/volumes/clickhouse_clickhouse-materializations ./clickhouse-backups/

185G de backup :

ansible@s005:~$ sudo du -h -d 1 ./clickhouse-backups/
8.0K    ./clickhouse-backups/clickhouse_clickhouse-materializations
120K    ./clickhouse-backups/clickhouse_clickhouse-conf
185G    ./clickhouse-backups/clickhouse_clickhouse-data
185G    ./clickhouse-backups/

J'ai fait une montée de version progressive :

v22.1 (première version avec AzureBlobStorage) : pas de moteur AzureBlobStorage
v22.12 : pas de moteur AzureBlobStorage
v23.12 : le moteur AzureBlobStorage est bien présent
v24.12 : mes imports depuis Azure et depuis AWS fonctionnent
v25.2 : les imports depuis Azure et depuis AWS fonctionnent

NOTA : j'ai fait les 3 premières montées de versions mercredi 12 mars 2025 et les 2 dernières vendredi 14 mars 2025.

Je suis donc avec la dernière version de Clickhouse, v25.2.

2025-03-07¶

Installation de YunoHost sur yunohost-josiane

Concerns

Resource - server - yunohost-josiane

J'ai installé YunoHost sur yunohost-josiane depuis app.cywise.io.

2025-03-03¶

Redirection de sentinel.computablefacts.com vers app.cywise.io

Concerns

Resource - server - yunohost-addapps
Deprecated: Resource - deployment - cf-ui-sentinel-prod

Dans Gandi, j'ai modifié l'entrée DNS de sentinel.computablefacts.com pour qu'elle pointe vers yunohost-addapps. Dans le YunoHost de AddApps, j'ai ajouté le domaine sentinel.computablefacts.com puis le certificat SSL Let's Encrypt. Dans le YunoHost de AddApps, j'ai installé l'application redirect pour rediriger https://sentinel.computablefacts.com vers https://app.cywise.io.

2025-02-28¶

09:40 - Nos 5 performa ne répondent plus

Concerns

Interruption du vendredi 28/02 9h30 au vendredi 28/02 9h55 soit 25 minutes

Les remontées des machines de nos 5 performa ont été perdues.

J'ai eu 3 alertes vers 9h40 venant de mes surveillances Freshping. Puis 2 autres alertes vers 9h50.

En regardant en SSH, le symptôme est le même : les images performa ne sont plus là.

Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.

L'hypothèse se confirme : j'ai fait un towerify deploy de Cywise DEV peu avant les alertes. Comme si un déploiement d'une autre appli supprimait les images des performa.

Je constate que Docker a redémarré à 9h31. Certainement suite à mon towerify deploy. Les images des performa ont pu être supprimées plus tôt et c'est au moment du redémarrage que Docker ne les trouve plus et que les performa ne peuvent donc pas redémarrer...

2025-02-25¶

Mot de passe de Marlène non propagé sur yunohost-ista-prod

Concerns

Marlène nous préviens qu'elle n'a pas le même mot de passe entre ISTA DEV et ISTA PROD pour l'accès à Portainer. Je n'ai pas répondu complètement à sa première demande donc elle a créé une deuxième demande.

Premier ticket #8750 de Marlène. Nouveau ticket #8764 de Marlène.

Cette fois, je vais forcer le mot de passe de Marlène sur yunohost-ista-prod avec la procédure suivante :

décoder le mot de passe avec la technique envoyée par Cyrille
mettre à jour le mot de passe sur yunohost-ista-prod avec une commande yunohost user update

Décodage du mot de passe

J'ajoute le code ci-dessous dans TheCyberBriefController.php de Towerify :

$passwordChiffre = '<MotDePasseChiffré>';
$key = '<HASHER_NONCE>';
$initializationVector = strtok($passwordChiffre, '_');
$value2 = substr($passwordChiffre, strpos($passwordChiffre, '_') + 1);
$passwordDechiffre = openssl_decrypt($value2, 'AES-256-CBC', $key, 0, $initializationVector);
Log::info($passwordDechiffre);

Je remplace <MotDePasseChiffré> par le mot de passe de Marlène dans la table users. Je remplace <HASHER_NONCE> par la clé du hasher qui se trouve dans les secrets.

J'affiche la page d'accueil local de Towerify (http://localhost:8080/) et je retrouve le mot de passe de Marlène dans les logs affichés en bas de la page (onglet Messages).

Mise à jour du mot de passe

Je fais cette commande sur yunohost-ista-prod :

sudo yunohost user update marlene.denis -p <MotDePasse>

Je teste le mot de passe avec l'URL de Portainer ISTA PROD et ça fonctionne.

2025-02-21¶

12:40 - Nos 5 performa ne répondent plus

Concerns

Interruption du vendredi 21/02 12h10 au vendredi 21/02 12h55 soit 45 minutes

Les remontées des machines de nos 5 performa ont été perdues.

J'ai eu 3 alertes vers 12h10 venant de mes surveillances Freshping. Puis une alerte vers 12h15. Puis une alerte pour le cinquième performa vers 12h20.

En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.

Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.

Je n'ai pas d'hypothèse mais j'ai fait un towerify deploy de ma doc d'infra peu avant les alertes. Je ne sais pas si c'est lié.

Problème de place disque sur postface01

Concerns

Resource - server - postface01

Christian a eu une erreur lors d'un job Jenkins indiquant qu'il n'y avait plus de place sur le disque.

J'ai fait du ménage dans Docker (sudo docker system prune --all) et je suis passé de 90% d'occupation disque à 10%.

2025-02-20¶

Debug python, stanza, container

Concerns

Resource - server - postface01

Le script wiki_factoids.py de Christian s'arrête au moment de la commande :

nlp = stanza.Pipeline('fr', processors='tokenize,mwt,pos,lemma,ner', download_method="reuse_resources", verbose=False)

La commande affiche un Warning (mais c'est le cas sur le poste de Christian aussi) puis le script s'arrête. C'est peut-être dû à l'environnement Docker. Je vais essayer de le reproduire sur une VM Scaleway.

J'utilise l'image php:8.3-apache basée sur Debian 12 (bookworm) donc je mets cet OS sur ma VM.

J'ai reproduit la même erreur (warning + arrêt du script) sur la VM Scaleway. Les erreurs changent en fonction des versions des packages python. Après plusieurs essais, je fige ces versions dans requirements.txt :

# pip install -r requirements.txt
nltk~=3.5.0
numpy~=1.0
stanza~=1.0
torch~=2.3.0
wikipedia~=1.4.0

Le script fonctionne maintenant.

2025-02-18¶

11:00 - Beaucoup de place disque consommée

Concerns

Resource - server - yunohost-addapps

Depuis le 9/2, je perds beaucoup de place disque sur yunohost-addapps.

Je constate que c'est dans le dossier /var/lib/mysql que je la perds. J'ai 70 fichiers de 1Go chacun nommés OFF.000001, OFF.000002, etc.

Les premiers fichiers datent de mon changement de paramètres MySQL dans /etc/mysql/mariadb.conf.d/50-server.cnf. Je repère l'option coupable :

log_bin = OFF   # Désactiver le log binaire si pas de réplication

que je change par :

log_bin = 0   # Désactiver le log binaire si pas de réplication

Je redémarre le service mariadb vers 11h30 (sudo systemctl restart mariadb.service).

Enfin, je récupère mes 70Go de place disque en supprimant les fichiers de log binaire avec sudo rm /var/lib/mysql/OFF.*.

2025-02-17¶

09:30 - Erreur 504 Gateway Time-out sur Cywise et non réception du rapport d'audit par mail (suite et fin)

Concerns

Resource - deployment - cywise-ui_prod

Cyrille se rend compte que nous avons à nouveau 55k jobs en attente dans queue-critical.

Les rapports d'audit ont été envoyés samedi matin mais pas envoyé dimanche ni ce matin.

La file ne se vide pas malgré les 3 containers qui traitent queue-critical maintenant.

Cyrille et moi faisons une conf de 16h30 à 19h30 : - nous avons déplacé les jobs des événements de DC2 vers la queue-medium (18.1k) - nous avons donc laissé environ 40k de jobs dans la queue-critical - après un peu plus d'une heure, il nous reste 5k jobs dans queue-critical et 18k jobs dans queue medium - certains jobs mettaient 50s à ingérer 63 events contre quelques centaines de ms pour les autres jobs - après analyse, il s'agit d'événements firefox venant d'un serveur de Elephantastic - Nous déplaçons les événements de DC2 vers queue-critical (qui est vide) et nous ne gardons que ceux du serveur Elephantastic dans queue-medium - Les événements de DC2 sont ingérés rapidement (200ms/job) alors que dans queue-medium tous les jobs prennent 50s - Nous ajoutons du chronométrage et nous repérons la requête qui est lente (0.7s par event à la place de 0.007 habituellement) - C'est dû à un hash qui est présent en grande quantité pour d'autres événements (même événement firefox) et qui ralentit la recherche d'un événement déjà existant pour éviter de créer un doublon - Finalement, en ajoutant calendar_time en plus de unix_time dans la comparaison le temps revient dans la norme des 0.007s (calendar_time est indexée alors que unix_time ne l'est pas et les deux représentent le même instant)

Problem solved.

2025-02-14¶

07:30 - Erreur 504 Gateway Time-out sur Cywise et non réception du rapport d'audit par mail (suite)

Concerns

Resource - deployment - cywise-ui_prod

Je me rends compte que le scheduler n'a pas démarré depuis ma mise en PROD d'hier soir. Le seeder plante car l'URL où nous allons chercher les règles OSSEC n'existe plus. La branche principale de la repo est passée de master à main, il faut donc modifier toutes les URLs. Par exemple, https://raw.githubusercontent.com/wazuh/wazuh-agent/refs/heads/master/etc/ruleset/sca/nginx/cis_nginx_1.yml devient https://raw.githubusercontent.com/wazuh/wazuh-agent/refs/heads/main/etc/ruleset/sca/nginx/cis_nginx_1.yml.

Je fais les changements et j'en profite pour décaler l'heure d'envoi des rapports d'audit à 8h40.

Je fais la requête SQL qui était très lentes (70s) lors du rapport d'audit Oppscience d'hier ce qui permet de l'obtenir en quelques secondes les fois suivantes (MySQL a mis les données en mémoire).

Les rapports d'audit se génèrent sans erreur.

Je remets l'heure des rapports à 7h45.

2025-02-13¶

11:45 - Erreur 504 Gateway Time-out sur Cywise et non réception du rapport d'audit par mail

Concerns

Resource - deployment - cywise-ui_prod

Sylvain Moreau prévient Cyrille par mail qu'il a des problèmes avec Cywise PROD.

Uniquement 6 jobs dans queue-critical, ce n'est pas l'origine des problèmes.

Je l'appelle et il a 2 problèmes : - il a une erreur 504 Gateway Time-out quand il se connecte à Cywise - il n'a pas reçu le rapport d'audit par mail ce matin

J'ouvre le ticket #8758 dans Freshdesk.

Après analyse, nous arrivons à la conclusion que les lenteurs viennent de la classe Messages. Elle est utilisée pour les rapports d'audits et aussi pour afficher les derniers événements sur la page d'accueil de Cywise (donc juste après le login).

En essayant l'URL Cywise qui permet d'afficher le rapport d'audit dans mon navigateur, j'ai une erreur la première fois (504 Gateway Timoeout) et un rapport qui s'affiche en quelques secondes la fois suivante.

J'identifie la requête SQL qui prend la majeure partie du temps :

select * from `ynh_osquery`
where `calendar_time` >= '2025-02-12 15:45:14'
  and `ynh_server_id` in (...)
  and `name` = 'ld_preload'

Cette requête renvoie 30k enregistrements.

Finalement, nous trouvons que la classe Messages utilise des vues sur la table ynh_osquery_latest_events dans plusieurs méthodes mais elle utilise aussi des requêtes, comme celle ci-dessus qui est lente, qui attaque directement la table ynh_osquery.

ynh_osquery contient plusieurs millions de lignes alors que ynh_osquery_latest_events n'en contient que quelques milliers puisqu'elle a été conçue pour ça (ne garder que les 1000 derniers événements pour chaque type de chaque serveurs).

La solution doit être de faire des vues sur ynh_osquery_latest_events là où ce n'est pas encore le cas. Cyrille le fera lundi.

Mais je n'ai pas compris non plus pourquoi le rapport d'audit de Oppscience n'est pas parti ce matin : je n'ai pas trouvé d'erreur, juste des containers qui ont redémarré car la tâche (queue:work) a renvoyé un code non nul.

Je décide d'ajouter l'option --memory 1024 à la commande queue:work. La valeur par défaut est 128 et mon hypothèse est que le rapport a besoin de plus de 128Mo pour se générer donc il est peut-être interrompu et il fait sortir la commande avec un code non nul. Modif poussé en PROD vers 22h.

2025-02-12¶

10:00 - Docker arrêté sur DEV02

Concerns

Resource - server - yunohost-dev02

Pierre, qui a une démo à 11h, a des erreurs 502 sur Portainer et generic rag qui sont déployés sur DEV02.

Je constate que le service Docker est arrêté. Je le redémarre et les 2 applications fonctionnent à nouveau.

09:50 - Non traitement des événements de Cywise (suite)

Concerns

Resource - deployment - cywise-ui_prod

Restait 14k jobs à 22h hier soir et la file était vide vers 1h30 ce matin.

Je fait un commit pour qu'il y ait toujours 3 containers qui traitent la file des jobs critiques.

2025-02-11¶

15:30 - Non traitement des événements de Cywise (suite)

Concerns

Resource - deployment - cywise-ui_prod

Reste 27.9k jobs. Ca va plus vite que mon calcul de ce matin : 3200 jobs par heure.

08:10 - Non traitement des événements de Cywise (suite)

Concerns

Resource - deployment - cywise-ui_prod

Il y a encore 52k jobs en attente de traitement dans queue-critical.

Environ 1650 jobs par heure traités depuis hier soir. Reste 30h de traitement d'après mes calculs.

2025-02-10¶

08:30 - Non traitement des événements de Cywise (suite)

Concerns

Resource - deployment - cywise-ui_prod

Il y a encore 69k jobs en attente de traitement dans queue-critical.

J'augmente le nombre de containers de 1 à 3 pour traiter queue-critical. Je passe même de 3 à 5 containers entre 10h30 et 12h mais je reviens à 3 containers car je trouve la machine yunohost-addapps trop chargée.

Je m'aperçois que MySQL n'utilise que 128Mo de mémoire alors que la VM a maintenant 32Go de mémoire au total. Je décide de modifier les réglages de MySQL pour lui donner plus de mémoire (12Go).

Paramètres ajoutés dans /etc/mysql/mariadb.conf.d/50-server.cnf

############# Ajout Patrick - 2025-02-10
# Mémoire
innodb_buffer_pool_size = 12G   # ~75% de la RAM si MariaDB est le principal service
innodb_buffer_pool_instances = 6  # Diviser le buffer en plusieurs instances (nombre conseillé = RAM/2G>
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
innodb_flush_method = O_DIRECT   # Évite la mise en cache du système de fichiers

# Optimisation CPU et threads
innodb_thread_concurrency = 8   # Généralement 2x le nombre de CPU
innodb_read_io_threads = 8
innodb_write_io_threads = 8
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 = OFF   # Désactiver le log binaire si pas de réplication
#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-02-10

Encore 50h de traitement d'après mes calculs et le rythme actuel.

2025-02-09¶

17:55 - Non traitement des événements de Cywise

Concerns

Resource - deployment - cywise-ui_prod

Cyrille par slack :

Bon, second pb : on ne reçoit plus d'events depuis la MEP de jeudi.

19h05 : Cyrille s'aperçoit qu'il y a 79.1k jobs en attente de traitement dans queue-critical. Ce sont des jobs d'ingestion d'événements.

11:10 - Problème de déploiement de Cywise avec Jenkins

Concerns

Resource - deployment - yunohost-addapps-jenkins

Cyrille par slack :

je ne peux pas déployer mon fix, j'ai la même erreur Jenkins que Marlène

Ce n'était pas la même erreur, pas les dossiers durable-xxx, mais un problème de récupération de la repo Git https://github.com/computablefacts/towerify.git.

Après plusieurs essais de résolution infructeux, j'ai décidé de supprimer le job cywise-ui_dev. Le towerify deploy suivant de Cyrille l'a recréé et le déploiement a fonctionné.

J'ai supprimé également le job cywise-ui_prod qui avait le même problème.

10:50 - Non réception du rapport d'audit par mail

Concerns

Resource - deployment - cywise-ui_prod

Cyrille par slack :

Apparemment Cywise est down... C'est oppscience qui vient de me prévenir car ils ne reçoivent plus les emails du matin.

Cyrille pense que c'est dû à une modification des droits d'accès aux menus de Cywise qu'il a mis en PROD jeudi 06/02. Il a fait un correctif et l'a poussé vers 13h30.

2025-02-05¶

Déploiement du serveur Angardia AI avec Cywise (suite)

Concerns

Resource - server - angardia-ai

Je reprends où je m'étais arrêté vendredi dernier.

Installation de Jenkins¶

J'ai toujours le problème de connexion de Towerify CLI à Jenkins quand je fais towerify configure.

Je vois en ajoutant --debug que la requête renvoie un 403 (Authentication required).

Requête vers angardia-ai

[14:15:01]$ curl -X GET -s -L --user pbrisacier:****  https://jenkins.apps.angardia.ai/user/pbrisacier/api/json
<html><head><meta http-equiv='refresh' content='1;url=/login?from=%2Fuser%2Fpbrisacier%2Fapi%2Fjson'/><script id='redirect' data-redirect-url='/login?from=%2Fuser%2Fpbrisacier%2Fapi%2Fjson' src='/static/f9857f24/scripts/redirect.js'></script></head><body style='background-color:white; color:white;'>
Authentication required
<!--
-->

</body></html>

Même requête vers yunohost-dev02

[14:15:30]$ curl -X GET -s -L --user pbrisacier:****  https://jenkins.dev02.towerify.io/user/pbrisacier/api/json
{"_class":"hudson.model.User","absoluteUrl":"https://jenkins.dev02.towerify.io/user/pbrisacier","description":null,"fullName":"Patrick Brisacier","id":"pbrisacier","property":[{"_class":"jenkins.security.ApiTokenProperty"},{"_class":"com.cloudbees.plugins.credentials.UserCredentialsProvider$UserCredentialsProperty"},{"_class":"hudson.plugins.emailext.watching.EmailExtWatchAction$UserProperty","triggers":[]},{"_class":"hudson.plugins.favorite.user.FavoriteUserProperty"},{"_class":"hudson.model.MyViewsProperty"},{"_class":"org.jenkinsci.plugins.displayurlapi.user.PreferredProviderUserProperty"},{"_class":"hudson.model.PaneStatusProperties"},{"_class":"jenkins.security.seed.UserSeedProperty"},{"_class":"hudson.search.UserSearchProperty","insensitiveSearch":true},{"_class":"hudson.model.TimeZoneProperty"},{"_class":"jenkins.model.experimentalflags.UserExperimentalFlagsProperty"},{"_class":"hudson.tasks.Mailer$UserProperty","address":"pbrisacier@dev02.towerify.io"},{"_class":"jenkins.security.LastGrantedAuthoritiesProperty"},{"_class":"jenkins.console.ConsoleUrlProviderUserProperty"}]}

Je constate que j'ai Jenkins 2.426.1 pour angardia-ai et Jenkins 2.479.2 pour yunohost-dev02. Je décide de mettre à jour le Jenkins de angardia en passant par l'UI admin de YunoHost et en utilisant le catalogue standard de YunoHost.

J'ai maintenant Jenkins 2.479.3 sur angardia-ai mais j'ai toujours la même réponse avec ma requête curl.

Quand je tape l'URL de l'API directement dans mon navigateur, je suis redirigé vers la page de login de Jenkins. Aussi bien avec angardia-ai qu'avec yunohost-dev02.

J'ai tenté de mettre un API Token à la place du password comme indiqué dans la doc Jenkins mais ça ne fonctionne pas. NOTA: plus étonnant, quand je mets un token pour dev02 j'ai une erreur 401 alors que ça fonctionne avec le password.

Je lis dans la doc de YunoHost 12 sur le SSO :

Application wich provide an API¶

Some app, like Nextcloud or SOGo provide an service like Caldav, Cardav or Webdav, the client will need to send the basic authentication and the nginx must transmit this authentication header to the serivice which will validate the authentication. Currently to make it working correctly you need to set a following app settings this way:

ynh_app_setting_set --key=protect_against_basic_auth_spoofing --value=false

This will say to YunoHost that for this app we can safely transmit auth basic header from the client to the application.

Cette variable n'est définie ni sur yunohost-dev02 ni sur angardia-ai. Je la définis sur angardia-ai avec la commande :

sudo yunohost app setting jenkins protect_against_basic_auth_spoofing -v false

Je redémarre Jenkins et je recharge nginx avec :

sudo systemctl reload nginx.service 
sudo systemctl restart jenkins.service

Mais j'ai toujours la même réponse avec ma requête curl.

J'avais également comparé les conf nginx des 2 jenkins qui sont identiques. Seul différence sans importance, la ligne include conf.d/yunohost_panel.conf.inc : YunoHost 11 modifie le HTML renvoyé pour inclure un bouton qui affiche la liste des applications alors que YunoHost 12 ne fait rien.

Sur angardia-ai, j'ai modifié le fichier /lib/systemd/system/jenkins.service pour ajouter la ligne :

# Patrick 2025-02-06 - More HTTP logs
Environment="JENKINS_OPTS=-Dorg.eclipse.jetty.LEVEL=DEBUG"

Mais, après reload de systemd et redémarrage de Jenkins, je n'ai pas plus d'informations dans les logs.

J'ai démarré un serveur avec sudo php -S 0.0.0.0:2301 -t /var/www/html/ et créé un fichier test.php avec :

<?php
echo "<h1>Entêtes HTTP reçues</h1>";
echo "<pre>";
foreach (getallheaders() as $name => $value) {
    echo "$name: $value\n";
}
echo "</pre>";
?>

Et, quand je fais un curl vers ce serveur, je vois bien les entêtes HTTP mais pas l'entête Authorization.

18:35 $ curl -X GET -s -L -H "X-Patrick: test" --user pbrisacier:Qtc1XVWVhiTvuikE43Q0  https://jenkins.apps.angardia.ai/test.php
<h1>Entêtes HTTP reçues</h1><pre>Host: jenkins.apps.angardia.ai:443
X-Real-IP: 82.67.138.141
X-Forwarded-For: 82.67.138.141
X-Forwarded-Proto: https
X-NginX-Proxy: true
Connection: close
user-agent: curl/7.81.0
accept: */*
x-patrick: test

Je finis par comprendre que l'option protect_against_basic_auth_spoofing est bien présente dans /etc/ssowat/conf.json et que c'est bien cette option qu'il faut mettre à false pour que l'entête Authorization soit transmise à Jenkins.

Mais, pour que l'option soit prise en compte, il faut mettre l'option à false avec la commande :

sudo yunohost app setting <my_app> 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 ce changement, ma requête curl réussi et je peux configurer le profil angardia-ai dans Towerify CLI avec towerify configure --profile angardia-ai.

J'ai ensuite déployé l'application :

j'ai modifié la conf nginx de Jenkins pour autoriser des tar.gz jusqu'à 100Mo
j'ai définie APP_KEY dans les secrets de la repo GitHub
j'ai récupéré APP_KEY dans mon action GitHub pour mettre en place le secret avec Towerify CLI.

L'application se déploie sans erreur maintenant.

J'ai supprimé le job angardia-ai_dev dans le Jenkins de yunohost-dev02. J'ai supprimé l'application angardia-ai_dev du YunoHost de yunohost-dev02.

Installation de cf_custom¶

Déploiement de l'application sur cette machine¶

2025-02-04¶

14:20 - ISTA - Erreur Jobs to Dataset - Problème répertoire durable-xxx

Concerns

Ticket de Marlène sur un problème avec Job to Dataset.

En regardant le log du job #159, je vois que c'est le problème récurrent de suppression des répertoires temporaires durable-xxx.

Je me connecte en SSH sur yunohost-ista-dev. Il y a 2 répertoires durable-xxx dans le dossier tmp du job :

twr_admin@apps:~$ sudo ls -alh /var/lib/jenkins/jobs/jobs_to_dataset/workspace/jobs@tmp
total 16K
drwxr-xr-x 4 jenkins jenkins 4.0K Dec  6 01:21 .
drwxr-xr-x 3 jenkins jenkins 4.0K Dec  6 01:21 ..
drwxr-xr-x 2 root    root    4.0K Nov  6 13:22 durable-52345e57
drwxr-xr-x 2 root    root    4.0K Nov  6 12:09 durable-e510f36b

Je supprime tout avec la commande sudo rm -R /var/lib/jenkins/jobs/jobs_to_dataset/workspace/jobs@tmp/. Je relance le job (pour contrats comme le montre les paramètres du job #159) et il réussi.

16:30 - Problème résolu

2025-01-31¶

Déploiement du serveur Angardia AI avec Cywise

Concerns

Resource - server - angardia-ai

Installation de YunoHost¶

Depuis Cywise, j'ajoute un serveur YunoHost pour Angardia AI :

Nom : angardia-ai
IP : 51.159.101.88
Domaine : apps.angardia.ai
Port : 22
Utilisateur : root

J'ai exécuté la commande pour autoriser la clé SSH de Cywise. Un click sur "Tester la connexion SSH" confirme que tout est OK.

Je clique donc sur "Configurer l'hôte".

J'ai une erreur que je peux voir en détail en lançant le script d'installation sur la machine :

root@sd-167494:~# ./install-yunohost-DrfUj22oty 
...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                Dload  Upload   Total   Spent    Left  Speed
100 25949  100 25949    0     0  1206k      0 --:--:-- --:--:-- --:--:-- 1206k
[FAIL] YunoHost is only available for the version 12 (Bookworm) of Debian, you are using '11.11'.

Je dois donc avoir Debian 12 pour installer la dernière version de YunoHost.

Comme je n'ai pas accès au compte Scaleway pour cette machine, je ne peux pas changer la version de Debian. Je vais donc faire la mise à jour depuis mon accès SSH.

Mise à jour vers Debian 12

Mise à jour du Debian 11 :

root@sd-167494:~# apt-get update
root@sd-167494:~# apt-get full-upgrade
root@sd-167494:~# apt-get --purge autoremove

Changement de version Debian dans les sources de apt :

root@sd-167494:~# cp /etc/apt/sources.list /etc/apt/sources.list.bak
root@sd-167494:~# sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list

Mise à jour vers Debian 12 :

root@sd-167494:~# apt-get update
root@sd-167494:~# apt-get full-upgrade

Je redémarre la machine :

root@sd-167494:~# reboot

Puis je vérifie la version de Debian et je fais le ménage :

root@sd-167494:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 12 (bookworm)
Release:    12
Codename:   bookworm
root@sd-167494:~# cat /etc/debian_version 
12.9
root@sd-167494:~# apt-get --purge autoremove

Je relance le script d'installation de YunoHost :

root@sd-167494:~# ./install-yunohost-DrfUj22oty

Petite frayeur : je n'arrivais pas à me connecter en SSH directement (avec ma clé) et l'utilisateur twr_admin. J'ai dû saisir le mot de passe.

Les droits n'étaient pas bons sur le répertoire Home de twr_admin. Le dossier /home/twr_admin appartenait à root. J'ai donc fait un chown pour que twr_admin puisse se connecter :

twr_admin@apps:~$ sudo chown twr_admin:twr_admin -R /home/twr_admin/

J'ai pu me connecter en SSH avec ma clé et l'utilisateur twr_admin. J'ai pu me connecter à l'interface web de YunoHost.

Surveillance de l'instance¶

Je fais la commande donnée par Cywise :

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

Installation de Portainer¶

Installation depuis Cywise. Ma première tentative a échoué. Probablement à cause du mot de passe de l'utilisateur engineering qui contient &. J'ai basculé sur mon compte pbrisacier et l'installation a fonctionné.

Installation de phpMyAdmin¶

Installation depuis Cywise. RAS.

Installation de Jenkins¶

Installation depuis Cywise. RAS.

Impossible de connecter Towerify CLI au Jenkins. J'ai vérifié les plugins installés et leur configuration et tout semble correct. Je soupçonne YunoHost 12 que j'utilise pour la première fois et qui a fait des changements dans le SSO. Je regarderai à nouveau plus tard.

2025-01-30¶

Autorisation d'accès à AWS S3 pour Clickhouse

Concerns

Resource - deployment - swarm01-clickhouse

Pour Cywise, nous avons besoin d'accéder aux données de nos clients sur leurs buckets S3. Nous le faisons avec Clickhouse, celui qui est sur swarm01.

Cela revient à créer une table Clickhouse avec le moteur S3 comme dans l'exemple suivant :

clickhouse-client --host=clickhouse.swarm01.computablefacts.io --secure --user=cyrille --password=**** --query="CREATE TABLE IF NOT EXISTS weekly_100k_patrick (REGION_ID Nullable(Int64), REGION_NAME Nullable(String), REGION_TYPE Nullable(String), REGION_TYPE_ID Nullable(Int64)) ENGINE = S3('https://s3.eu-west-3.amazonaws.com/towerify-public/dev/datasets/out/weekly_100k.parquet', 'AKIAS7C7WWRZCYEA7EL3', '****', 'Parquet')"

J'ai dû autoriser les URL de AWS S3 pour ne plus avoir l'erreur UNACCEPTABLE_URL. Je l'ai fait dans le fichier ansible/files/clickhouse-conf/config.d/remote_url_allow_hosts.xml. J'ai dû mettre toutes les régions AWS car le wildcard s3.*.amazonaws.com ne fonctionne pas.

remote_url_allow_hosts.xml

<?xml version="1.0"?>
<yandex>
    <remote_url_allow_hosts>
        <host>s3.af-south-1.amazonaws.com</host>
        <host>s3.ap-east-1.amazonaws.com</host>
        <host>s3.ap-northeast-1.amazonaws.com</host>
        <host>s3.ap-northeast-2.amazonaws.com</host>
        <host>s3.ap-northeast-3.amazonaws.com</host>
        <host>s3.ap-south-1.amazonaws.com</host>
        <host>s3.ap-southeast-1.amazonaws.com</host>
        <host>s3.ap-southeast-2.amazonaws.com</host>
        <host>s3.ca-central-1.amazonaws.com</host>
        <host>s3.eu-central-1.amazonaws.com</host>
        <host>s3.eu-north-1.amazonaws.com</host>
        <host>s3.eu-south-1.amazonaws.com</host>
        <host>s3.eu-west-1.amazonaws.com</host>
        <host>s3.eu-west-2.amazonaws.com</host>
        <host>s3.eu-west-3.amazonaws.com</host>
        <host>s3.me-central-1.amazonaws.com</host>
        <host>s3.me-south-1.amazonaws.com</host>
        <host>s3.sa-east-1.amazonaws.com</host>
        <host>s3.us-east-1.amazonaws.com</host>
        <host>s3.us-east-2.amazonaws.com</host>
        <host>s3.us-west-1.amazonaws.com</host>
        <host>s3.us-west-2.amazonaws.com</host>
    </remote_url_allow_hosts>
</yandex>

2025-01-28¶

09:00 - Ajout d'une base de tests Clickhouse pour Cyrille

Concerns

Resource - deployment - swarm01-clickhouse

Cyrille a besoin d'une base de tests Clickhouse pour ses développements. J'ai ajouté un compte cyrille sur le Clickhouse de swarm01. Et j'ai déployé avec ansible :

ansible-playbook -i ansible/inventory.yml ansible/clickhouse-stack.yaml --tags configure

Puis, j'ai créé une base de tests cyrille_dev en utilisant le compte nifi.

Enfin, j'ai vérifié que je pouvais bien y accéder avec clickhouse-client :

patrick@SpectreMate:~
[09:32:13]$ clickhouse-client --host=clickhouse.swarm01.computablefacts.io --secure --user=cyrille --password=**** --query="SHOW DATABASES;"
cyrille_dev

2025-01-23¶

09:35 - Nos 5 performa ne répondent plus

Concerns

Interruption du jeudi 23/01 9h20 au jeudi 23/01 9h50 soit 30 minutes

Les remontées des machines de nos 5 performa ont été perdues.

J'ai eu 4 alertes vers 9h35 venant de mes surveillances Freshping. Puis une alerte pour le cinquième performa vers 9h40.

En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.

Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.

2025-01-17¶

14:30 - Suppression de l'environnement de PROD de Sentinel

Concerns

Deprecated: Resource - deployment - cf-ui-sentinel-prod
Deprecated: Resource - storage - prodsentinel_cfui

Nous avons déplacé les fonctionnalités de Sentinel dans Towerify / Cywise. Les environnements Sentinel cf-ui ne sont donc plus utilisés. Je vais supprimer l'environnement de PROD.

Warning

Je ne vais pas supprimer les backups de la base de données MySQL car nous pourrions en avoir besoin.

Sentinel Datalake UI PROD¶

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

sudo docker stack rm prod-sentinel-cf-ui

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

Je supprime le déploiement dans le playbook ansible de Sentinel (ansible/client-sentinel.yaml). Ce qui revient à supprimer le ficher car Jenkins était le dernier déploiement restant.

Je note ce deploiement comme deprecated dans cette doc.

Je supprime mes surveillances :

Statping-ng sur DEV02 - Sentinel Socle
Statping-ng sur DEV02 - Sentinel Login
Freshping - Sentinel Socle
Freshping - Sentinel Login

MySQL database for Sentinel cf-ui PROD¶

Je supprime la base de données prodsentinel_cfui depuis phpMyAdmin. J'en profite pour supprimer les 2 utilisateurs correspondant : prosentincfui et prosentincfuimater.

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 Sentinel sur le SFTP :

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

ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel
75G /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/prod_out
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/dev
1.0M    /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/prod
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/dev_out
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/staging_out
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/staging
75G /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel

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/sentinel/prod -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;

ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/prod
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--r-- 3 ansible ansible 4.0K Mar 21  2022 conf
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/prod -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;
ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/prod
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Jan 17 15:04 .
drwxr-xr-x 8 ansible ansible 4.0K Mar  7  2022 ..

sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/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/sentinel/prod_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 3 ansible ansible 4.0K Mar 21  2022 conf
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/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/sentinel/prod_out
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Jan 17 15:06 .
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 sentinel/prod etsentinel/prod_out.

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

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

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/sentinel/prod/ de ce bucket (prod_out n'est pas backupé sur S3).

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

Conservation 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/prodsentinel_cfui/.

Le bucket S3 swarm01-backups-mysql supprime tous les fichiers de plus de 30 jours. Donc, dans 1 mois, les backups auront disparu...

J'ai donc décidé de les copier dans un autre bucket que j'ai créé (swarm01-backups-sentinel). Je vais les faire transiter par mon PC pour les copier d'un bucket à l'autre donc je les aurais en local aussi.

Commandes pour faire la copie

patrick@SpectreMate:~$ mkdir sentinel-mysql-backups
patrick@SpectreMate:~$ aws --profile computablefacts s3 sync s3://swarm01-backups-mysql/prod-mysql/prodsentinel_cfui/ ./sentinel-mysql-backups
patrick@SpectreMate:~$ aws --profile computablefacts s3 sync ./sentinel-mysql-backups/ s3://swarm01-backups-sentinel/

J'ai finalement décidé de n'en garder que 6 sur les 30 (1 tous les 6 jours).

14:10 - Suppression de l'environnement de STAGING de Sentinel

Concerns

Deprecated: Resource - deployment - staging-sentinel-cf-ui
Deprecated: Resource - storage - stagingsentinel_cfui

Nous avons déplacé les fonctionnalités de Sentinel dans Towerify / Cywise. Les environnements Sentinel cf-ui ne sont donc plus utilisés. Je vais supprimer l'environnement de STAGING.

Sentinel Datalake UI STAGING¶

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

sudo docker stack rm staging-sentinel-cf-ui

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

Je supprime le déploiement dans le playbook ansible de Sentinel (ansible/client-sentinel.yaml).

Je note ce deploiement comme deprecated dans cette doc.

MySQL database for Sentinel cf-ui STAGING¶

Je supprime la base de données stagingsentinel_cfui depuis phpMyAdmin. J'en profite pour supprimer les 2 utilisateurs correspondant : stasentincfui et stasentincfuimater.

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 Sentinel sur le SFTP :

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

ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel
75G /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/prod_out
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/dev
1.0M    /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/prod
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/dev_out
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/staging_out
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/staging
75G /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel

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/sentinel/staging -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;

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

sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/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/sentinel/staging_out
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Mar  7  2022 .
drwxr-xr-x 8 ansible ansible 4.0K Mar  7  2022 ..
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/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/sentinel/staging_out
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Mar  7  2022 .
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 sentinel/staging etsentinel/staging_out.

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

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

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/sentinel/staging/ de ce bucket (staging_out n'est pas backupé sur S3). NOTA: ce dossier n'existait pas...

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/stagingsentinel_cfui/.

J'ai supprimé ce dossier et son contenu.

12:30 - Suppression de l'environnement de DEV de Sentinel

Concerns

Deprecated: Resource - deployment - dev-sentinel-cf-ui
Deprecated: Resource - storage - devsentinel_cfui

Nous avons déplacé les fonctionnalités de Sentinel dans Towerify / Cywise. Les environnements Sentinel cf-ui ne sont donc plus utilisés. Je vais supprimer l'environnement de DEV.

Sentinel Datalake UI DEV¶

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

sudo docker stack rm dev-sentinel-cf-ui

ansible@s001:~$ sudo docker stack rm dev-sentinel-cf-ui
Removing service dev-sentinel-cf-ui_app
Removing service dev-sentinel-cf-ui_queue
Removing service dev-sentinel-cf-ui_queue-heavy
Removing service dev-sentinel-cf-ui_scheduler

Je supprime le déploiement dans le playbook ansible de Sentinel (ansible/client-sentinel.yaml).

Je note ce deploiement comme deprecated dans cette doc.

MySQL database for Sentinel cf-ui DEV¶

Je supprime la base de données devsentinel_cfui depuis phpMyAdmin. J'en profite pour supprimer les 2 utilisateurs correspondant : devsentincfui et devsentincfuimater.

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 DEV. Voici la taille des données présentes pour Sentinel sur le SFTP :

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

ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel
75G /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/prod_out
104K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/dev
1.0M    /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/prod
3.9G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/dev_out
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/staging_out
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/staging
79G /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel

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

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

ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/dev
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--r-- 4 ansible ansible 4.0K Feb 16  2023 conf
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/dev -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;
ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/dev
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Jan 17 12:40 .
drwxr-xr-x 8 ansible ansible 4.0K Mar  7  2022 ..

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

ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/dev_out
total 12K
drwxr-xr-x 3 ansible ansible 4.0K Mar 28  2022 .
drwxr-xr-x 8 ansible ansible 4.0K Mar  7  2022 ..
drwxr-xr-x 3 ansible ansible 4.0K Nov 22  2022 conf
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/dev_out -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;
ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/sentinel/dev_out
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Jan 17 12:41 .
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 sentinel/dev etsentinel/dev_out.

sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/sentinel/dev sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/sentinel/dev_out

ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/sentinel
7.2G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/sentinel/prod_out
177M    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/sentinel/dev
7.2G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/sentinel/prod
177M    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/sentinel/dev_out
15G /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/sentinel
ansible@s004:~$ sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/sentinel/dev
ansible@s004:~$ sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/sentinel/dev_out
ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/sentinel
7.2G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/sentinel/prod_out
7.2G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/sentinel/prod
15G /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/sentinel

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/sentinel/dev/ de ce bucket (dev_out n'est pas backupé sur S3).

Notre NiFi précédent backupait les données dans /var/sftp/sentinel/dev/ 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 dev-mysql/devsentinel_cfui/.

J'ai supprimé ce dossier et son contenu.

12:00 - Suppression de l'environnement de DEV de Apps Compose

Concerns

Deprecated: Resource - deployment - dev-appscompose-cf-ui
Deprecated: Resource - storage - devappscompose_cfui

Nous n'avons jamais vraiment utilisé Apps Compose. Je vais donc supprimer son environnement de DEV.

Apps Compose Datalake UI DEV¶

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

sudo docker stack rm dev-appscompose-cf-ui

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

Je supprime le déploiement dans le playbook ansible de Apps Compose (ansible/client-appscompose.yaml). Ce qui revient à supprimer le ficher car Jenkins était le dernier déploiement restant.

Je note ce deploiement comme deprecated dans cette doc.

MySQL database for Apps Compose cf-ui DEV¶

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

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 DEV. Voici la taille des données présentes pour Apps Compose sur le SFTP :

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

ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/sftp_sftp-data/_data/data/appscompose
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/appscompose/prod_out
24K /var/lib/docker/volumes/sftp_sftp-data/_data/data/appscompose/dev
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/appscompose/prod
40K /var/lib/docker/volumes/sftp_sftp-data/_data/data/appscompose/dev_out
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/appscompose/staging_out
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/appscompose/staging
84K /var/lib/docker/volumes/sftp_sftp-data/_data/data/appscompose

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

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

ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/appscompose/dev
total 16K
drwxr-xr-x 4 ansible ansible 4.0K Jun 13  2023 .
drwxr-xr-x 8 ansible ansible 4.0K Jun 13  2023 ..
drwxr-xr-x 2 ansible ansible 4.0K Jun 13  2023 conf
drwxr-xr-x 3 ansible ansible 4.0K Jun 13  2023 repotests
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/appscompose/dev -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;
ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/appscompose/dev
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Jan 17 12:18 .
drwxr-xr-x 8 ansible ansible 4.0K Jun 13  2023 ..

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

ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/appscompose/dev_out
total 16K
drwxr-xr-x 4 ansible ansible 4.0K Jun 13  2023 .
drwxr-xr-x 8 ansible ansible 4.0K Jun 13  2023 ..
drwxr-xr-x 2 ansible ansible 4.0K Jun 13  2023 conf
drwxr-xr-x 3 ansible ansible 4.0K Jun 13  2023 repotests
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/appscompose/dev_out -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;
ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/appscompose/dev_out
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Jan 17 12:19 .
drwxr-xr-x 8 ansible ansible 4.0K Jun 13  2023 ..

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 appscompose/dev etappscompose/dev_out.

sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/appscompose/dev sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/appscompose/dev_out

ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/appscompose
24K /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/appscompose/dev
28K /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/appscompose/dev_out
56K /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/appscompose
ansible@s004:~$ sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/appscompose/dev
ansible@s004:~$ sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/appscompose/dev_out
ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/appscompose
4.0K    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/appscompose

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/appscompose/dev/ de ce bucket (dev_out n'est pas backupé sur S3).

Suppression des backups¶

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

J'ai supprimé ce dossier et son contenu.

10:30 - Suppression du Jenkins de Apps Compose

Concerns

Deprecated: Resource - deployment - appscompose-jenkins

Nous n'avons jamais vraiment utilisé Apps Compose. Je vais donc supprimer son Jenkins.

Je supprime la stack qui se trouve sur swarm01.

sudo docker stack rm appscompose-jenkins

ansible@s001:~$ sudo docker stack rm appscompose-jenkins
Removing service appscompose-jenkins_jenkins

Puis je supprime le container DinD (Docker in Docker) qui se trouve sur s008.

sudo docker stop appscompose-jenkins_dind sudo docker rm appscompose-jenkins_dind

ansible@s008:~$ sudo docker stop appscompose-jenkins_dind
appscompose-jenkins_dind
ansible@s008:~$ sudo docker rm appscompose-jenkins_dind
appscompose-jenkins_dind

Je supprime les 2 volumes associés.

sudo docker volume rm appscompose-jenkins_jenkins-data sudo docker volume rm appscompose-jenkins_jenkins-docker-certs

ansible@s008:~$ sudo docker volume rm appscompose-jenkins_jenkins-data
appscompose-jenkins_jenkins-data
ansible@s008:~$ sudo docker volume rm appscompose-jenkins_jenkins-docker-certs
appscompose-jenkins_jenkins-docker-certs

Je supprime le déploiement dans le playbook ansible de la Apps Compose (ansible/client-appscompose.yaml).

Je note ce deploiement comme deprecated dans cette doc.

Je supprime le tag appscompose-jenkins.jenkins_home du noeud s008 en modifiant le fichier ansible/03-swarm01-labels.yaml puis en appliquant avec la commande : ansible-playbook -i ansible/inventory.yml ansible/03-swarm01-labels.yaml.

09:30 - Suppression du Jenkins de la Smacl

Concerns

Deprecated: Resource - deployment - smacl-jenkins

La Smacl a résilié son contrat avec nous. Je vais donc supprimer son Jenkins.

Je supprime la stack qui se trouve sur swarm01.

sudo docker stack rm smacl-jenkins

ansible@s001:~$ sudo docker stack rm smacl-jenkins
Removing service smacl-jenkins_jenkins

Puis je supprime le container DinD (Docker in Docker) qui se trouve sur s005.

sudo docker stop smacl-jenkins_dind sudo docker rm smacl-jenkins_dind

ansible@s005:~$ sudo docker stop smacl-jenkins_dind
smacl-jenkins_dind
ansible@s005:~$ sudo docker rm smacl-jenkins_dind
smacl-jenkins_dind

Je supprime les 2 volumes associés.

sudo docker volume rm smacl-jenkins_jenkins-data sudo docker volume rm smacl-jenkins_jenkins-docker-certs

ansible@s005:~$ sudo docker volume rm smacl-jenkins_jenkins-data
smacl-jenkins_jenkins-data
ansible@s005:~$ sudo docker volume rm smacl-jenkins_jenkins-docker-certs
smacl-jenkins_jenkins-docker-certs

Je supprime le déploiement dans le playbook ansible de la Smacl (ansible/client-smacl.yaml). Ce qui revient à supprimer le ficher car Jenkins était le dernier déploiement restant.

Je note ce deploiement comme deprecated dans cette doc.

Je supprime le tag smacl-jenkins.jenkins_home du noeud s005 en modifiant le fichier ansible/03-swarm01-labels.yaml puis en appliquant avec la commande : ansible-playbook -i ansible/inventory.yml ansible/03-swarm01-labels.yaml.

2025-01-16¶

Suppression de l'environnement de PROD de la Smacl

Concerns

Deprecated: Resource - deployment - prod-smacl-cf-ui
Deprecated: Resource - deployment - prod-smacl-module
Deprecated: Resource - deployment - prod-modules-smacl-contracts
Deprecated: Resource - storage - prodsmacl_cfui
Deprecated: Resource - storage - prodsmacl_cfmodulesmacl

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

Warning

Je ne vais pas supprimer les backups des bases de données MySQL car nous devrons fournir les données à la Smacl.

Quand la Smacl le demandera, nous pourrons restaurer les bases pour le faire.

Smacl Datalake UI PROD¶

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

sudo docker stack rm prod-smacl-cf-ui

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

Je supprime le déploiement dans le playbook ansible de la Smacl (ansible/client-smacl.yaml).

Je note ce deploiement comme deprecated dans cette doc.

MySQL database for Smacl cf-ui PROD¶

Je supprime la base de données prodsmacl_cfui depuis phpMyAdmin. J'en profite pour supprimer les 2 utilisateurs correspondant : prosmaclcfui et prosmaclcfuimater.

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.

Module VAM de la Smacl de PROD¶

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

sudo docker stack rm prod-smacl-module

ansible@s001:~$ sudo docker stack rm prod-smacl-module
Removing service prod-smacl-module_app

Je supprime le déploiement dans le playbook ansible de la Smacl (ansible/client-smacl.yaml).

Je note ce deploiement comme deprecated dans cette doc.

MySQL database for Smacl VAM module PROD¶

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

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.

Smacl nouveau module contrats ??? PROD¶

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

sudo docker stack rm prod-modules-smacl-contracts

ansible@s001:~$ sudo docker stack rm prod-modules-smacl-contracts
Removing service prod-modules-smacl-contracts_web

Je supprime le déploiement dans le playbook ansible de la Smacl (ansible/client-smacl.yaml).

Je note ce deploiement comme deprecated dans cette doc.

Suppression des données sur le SFTP¶

J'ai déjà désactivé le compte SFTP de PROD. Voici la taille des données présentes pour la smacl sur le SFTP :

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

ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl
923G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/prod_out
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/dev
9.8G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/prod
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/dev_out
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/staging_out
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/staging
933G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl

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/smacl/prod -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;

ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/prod
total 104K
drwxr-xr-x    6 ansible ansible 4.0K Jun 29  2022 .
drwxr-xr-x    8 ansible ansible 4.0K Feb 18  2022 ..
drwxr-xr-x    4 ansible ansible 4.0K Apr  2  2022 conf
drwxr-xr-x 1330 ansible ansible  36K Jan  7 23:12 dab
drwxr-xr-x    6 ansible ansible  12K Dec 30 12:03 dce
drwxr-xr-x 1421 ansible ansible  36K Jan  7 23:15 vam
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/prod -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;
ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/prod
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Jan 16 15:19 .
drwxr-xr-x 8 ansible ansible 4.0K Feb 18  2022 ..

sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/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/smacl/prod_out
total 488K
drwxr-xr-x    6 ansible ansible 4.0K Jun 29  2022 .
drwxr-xr-x    8 ansible ansible 4.0K Feb 18  2022 ..
drwxr-xr-x    7 ansible ansible 4.0K Mar  4  2022 conf
drwxr-xr-x 9544 ansible ansible 248K Dec 16 23:18 dab
drwxr-xr-x    6 ansible ansible 4.0K Jan 15  2024 dce
drwxr-xr-x 8705 ansible ansible 216K Jan  1 02:04 vam
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/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/smacl/prod_out
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Jan 16 15:24 .
drwxr-xr-x 8 ansible ansible 4.0K Feb 18  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 smacl/prod etsmacl/prod_out.

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

ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl
107G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/prod_out
17G /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/prod
123G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl
ansible@s004:~$ sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/prod
ansible@s004:~$ sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/prod_out
ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl
4.0K    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl

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/smacl/prod/ de ce bucket (prod_out n'est pas backupé sur S3).

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

Conservation 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/prodsmacl_cfui/ et dans le dossier prod-mysql/prodsmacl_cfmodulesmacl/.

Le bucket S3 swarm01-backups-mysql supprime tous les fichiers de plus de 30 jours. Donc, dans 1 mois, les backups auront disparu...

J'ai donc décidé de les copier dans un autre bucket que j'ai créé (swarm01-backups-smacl). Je vais les faire transiter par mon PC pour les copier d'un bucket à l'autre donc je les aurais en local aussi.

Commandes pour faire la copie

patrick@SpectreMate:~$ mkdir smacl-mysql-backups
patrick@SpectreMate:~$ aws --profile computablefacts s3 sync s3://swarm01-backups-mysql/prod-mysql/prodsmacl_cfmodulesmacl/ ./smacl-mysql-backups
patrick@SpectreMate:~$ aws --profile computablefacts s3 sync s3://swarm01-backups-mysql/prod-mysql/prodsmacl_cfui/ ./smacl-mysql-backups
patrick@SpectreMate:~$ aws --profile computablefacts s3 sync ./smacl-mysql-backups/ s3://swarm01-backups-smacl/

Suppression de l'environnement de STAGING de la Smacl

Concerns

Deprecated: Resource - deployment - staging-smacl-cf-ui
Deprecated: Resource - deployment - staging-smacl-module
Deprecated: Resource - deployment - staging-modules-smacl-contracts
Deprecated: Resource - storage - stagingsmacl_cfui
Deprecated: Resource - storage - stagingsmacl_cfmodulesmacl

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

Smacl Datalake UI STAGING¶

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

sudo docker stack rm staging-smacl-cf-ui

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

Je supprime le déploiement dans le playbook ansible de la Smacl (ansible/client-smacl.yaml).

Je note ce deploiement comme deprecated dans cette doc.

MySQL database for Smacl cf-ui STAGING¶

Je supprime la base de données stagingsmacl_cfui depuis phpMyAdmin. J'en profite pour supprimer les 2 utilisateurs correspondant : stasmaclcfui et stasmaclcfuimater.

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.

Module VAM de la Smacl de STAGING¶

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

sudo docker stack rm staging-smacl-module

ansible@s001:~$ sudo docker stack rm staging-smacl-module
Removing service staging-smacl-module_app

Je supprime le déploiement dans le playbook ansible de la Smacl (ansible/client-smacl.yaml).

Je note ce deploiement comme deprecated dans cette doc.

MySQL database for Smacl VAM module STAGING¶

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

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.

Smacl nouveau module contrats ??? STAGING¶

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

sudo docker stack rm staging-modules-smacl-contracts

ansible@s001:~$ sudo docker stack rm staging-modules-smacl-contracts
Removing service staging-modules-smacl-contracts_web

Je supprime le déploiement dans le playbook ansible de la Smacl (ansible/client-smacl.yaml).

Je note ce deploiement comme deprecated dans cette doc.

Suppression des données sur le SFTP¶

J'ai déjà désactivé le compte SFTP de STAGING. Voici la taille des données présentes pour la smacl sur le SFTP :

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

ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl
923G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/prod_out
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/dev
9.8G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/prod
4.0K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/dev_out
24G /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/staging_out
6.4M    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/staging
957G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl

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/smacl/staging -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;

ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/staging
total 40K
drwxr-xr-x  6 ansible ansible 4.0K Oct 11  2022 .
drwxr-xr-x  8 ansible ansible 4.0K Feb 18  2022 ..
drwxr--r--  3 ansible ansible 4.0K May 23  2022 conf
drwxr-xr-x 25 ansible ansible 4.0K Jan 10  2023 dab
drwxr-xr-x  4 ansible ansible  20K Jan  8  2024 dce
drwxr-xr-x 27 ansible ansible 4.0K Jan 10  2023 vam
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/staging -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;
ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/staging
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Jan 16 12:01 .
drwxr-xr-x 8 ansible ansible 4.0K Feb 18  2022 ..

sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/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/smacl/staging_out
total 44K
drwxr-xr-x  6 ansible ansible 4.0K Mar  3  2022 .
drwxr-xr-x  8 ansible ansible 4.0K Feb 18  2022 ..
drwxr-xr-x  8 ansible ansible 4.0K May 23  2022 conf
drwxr-xr-x 25 ansible ansible  12K Jan  9  2023 dab
drwxr-xr-x  6 ansible ansible 4.0K Jan  8  2024 dce
drwxr-xr-x 27 ansible ansible  16K Jan  9  2023 vam
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/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/smacl/staging_out
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Jan 16 12:02 .
drwxr-xr-x 8 ansible ansible 4.0K Feb 18  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 smacl/staging etsmacl/staging_out.

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

ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl
107G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/prod_out
17G /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/prod
9.1M    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/staging_out
7.6M    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/staging
123G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl
ansible@s004:~$ sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/staging
ansible@s004:~$ sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/staging_out
ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl
107G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/prod_out
17G /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/prod
123G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl

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/smacl/staging/ de ce bucket (staging_out n'est pas backupé sur S3).

Notre NiFi précédent backupait les données dans /var/sftp/smacl/staging/ 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 staging-mysql/stagingsmacl_cfui/ et dans le dossier staging-mysql/stagingsmacl_cfmodulesmacl/.

J'ai supprimé ces 2 dossiers et leur contenu.

11:20 - Suppression des 2 machines Scaleway s002 et s003

Concerns

Deprecated: Resource - server - s002
Deprecated: Resource - server - s003

Cela fait 6 jours que j'ai sorti ces 2 machines du cluster swarm01 et tout se passe bien. Je peux donc les "rendre" à Scaleway.

Je note ces 2 machines comme deprecated.

2025-01-15¶

15:30 - Suppression du Bucket S3 wordpress-cfn-templates-eu-west-3

Concerns

Deprecated: Resource - storage - wordpress-cfn-templates-eu-west-3

Ce bucket contient les fichiers CloudFormation pour le déploiement des Wordpress de itslearing. itslearning France a fermé en septembre 2024.

J'ai supprimé le bucket complet.

14:10 - Suppression du Bucket S3 cf-ui-mysql-backups

Concerns

Deprecated: Resource - storage - cf-ui-mysql-backups

Ce bucket contient des backups MySQL réalisés avant que nous ne migriions nos applications dans swarm01. Les plus récents datent de juillet 2022.

J'ai supprimé le bucket complet.

Suppression de l'environnement de DEV de la Smacl

Concerns

Deprecated: Resource - deployment - dev-smacl-cf-ui
Deprecated: Resource - deployment - dev-smacl-module
Deprecated: Resource - deployment - dev-modules-smacl-contracts
Deprecated: Resource - storage - devsmacl_cfui
Deprecated: Resource - storage - devsmacl_cfmodulesmacl

La Smacl a résilié son contrat avec nous. Je vais donc supprimer tout ce qui concerne leur environnement de DEV.

Smacl Datalake UI DEV¶

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

sudo docker stack rm dev-smacl-cf-ui

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

Je supprime le déploiement dans le playbook ansible de la Smacl (ansible/client-smacl.yaml).

Je note ce deploiement comme deprecated dans cette doc.

MySQL database for Smacl cf-ui DEV¶

Je supprime la base de données devsmacl_cfui depuis phpMyAdmin. J'en profite pour supprimer les 2 utilisateurs correspondant : devsmaclcfui et devsmaclcfuimater.

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.

Module VAM de la Smacl de DEV¶

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

sudo docker stack rm dev-smacl-module

ansible@s001:~$ sudo docker stack rm dev-smacl-module
Removing service dev-smacl-module_app

Je supprime le déploiement dans le playbook ansible de la Smacl (ansible/client-smacl.yaml).

Je note ce deploiement comme deprecated dans cette doc.

MySQL database for Smacl VAM module DEV¶

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

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.

Smacl nouveau module contrats ??? DEV¶

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

sudo docker stack rm dev-modules-smacl-contracts

ansible@s001:~$ sudo docker stack rm dev-modules-smacl-contracts
Removing service dev-modules-smacl-contracts_web

Je supprime le déploiement dans le playbook ansible de la Smacl (ansible/client-smacl.yaml).

Je note ce deploiement comme deprecated dans cette doc.

Suppression des données sur le SFTP¶

J'ai déjà désactivé le compte SFTP de DEV. Voici la taille des données présentes pour la smacl sur le SFTP :

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

ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl
923G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/prod_out
880K    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/dev
9.8G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/prod
6.9G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/dev_out
24G /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/staging_out
6.4M    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/staging
964G    /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl

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

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

ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/dev
total 40K
drwxr-xr-x 10 ansible ansible 4.0K Jan 15 16:44 .
drwxr-xr-x  8 ansible ansible 4.0K Feb 18  2022 ..
drwxr--r--  4 ansible ansible 4.0K Feb 16  2023 conf
drwxr-xr-x 10 ansible ansible 4.0K Jan 16  2023 dab
drwxr-xr-x  4 ansible ansible 4.0K Oct 10  2022 dce
drwxr--r--  3 ansible ansible 4.0K Jun 24  2024 smart-policies-1
drwxr--r--  3 ansible ansible 4.0K Jun 25  2024 test1-1
drwxr-xr-x  6 ansible ansible 4.0K Feb 23  2023 test-coreapi-fileindex
drwxr-xr-x  3 ansible ansible 4.0K Mar 13  2022 test-nifi-invoke-http
drwxr-xr-x  3 ansible ansible 4.0K May  2  2022 test-nifi-unpack-archive
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/dev -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;
ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/dev
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Jan 15 16:49 .
drwxr-xr-x 8 ansible ansible 4.0K Feb 18  2022 ..

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

ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/dev_out
total 64K
drwxr-xr-x 16 ansible ansible 4.0K Jun 25  2024 .
drwxr-xr-x  8 ansible ansible 4.0K Feb 18  2022 ..
drwxr-xr-x  7 ansible ansible 4.0K Mar  3  2022 conf
drwxr-xr-x 62 ansible ansible 4.0K Jan 16  2023 dab
drwxr-xr-x  4 ansible ansible 4.0K Oct 10  2022 dce
drwxr-xr-x  3 ansible ansible 4.0K Mar  3  2022 ecritures-comptables
drwxr-xr-x  4 ansible ansible 4.0K Mar  3  2022 patrick01
drwxr-xr-x  4 ansible ansible 4.0K Mar  3  2022 patrick02
drwxr-xr-x  4 ansible ansible 4.0K Mar  3  2022 patrick03
drwxr-xr-x  4 ansible ansible 4.0K Mar  3  2022 patrick04
drwxr-xr-x  3 ansible ansible 4.0K Apr 23  2024 smart_policies
drwxr-xr-x  3 ansible ansible 4.0K Jun 24  2024 smart-policies-1
drwxr-xr-x  3 ansible ansible 4.0K Jun 25  2024 test1-1
drwxr-xr-x  4 ansible ansible 4.0K Feb 23  2023 test-coreapi-fileindex
drwxr-xr-x  3 ansible ansible 4.0K May  2  2022 test-nifi-unpack-archive
drwxr-xr-x 74 ansible ansible 4.0K Dec  8  2022 vam
ansible@s004:~$ sudo find /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/dev_out -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;
ansible@s004:~$ sudo ls -alh /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl/dev_out
total 8.0K
drwxr-xr-x 2 ansible ansible 4.0K Jan 15 16:50 .
drwxr-xr-x 8 ansible ansible 4.0K Feb 18  2022 ..

Il y avait aussi 2 dossiers /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl-dab et /var/lib/docker/volumes/sftp_sftp-data/_data/data/smacl-vam qui contenaient des .tar.lz4 de 2022. J'ai supprimé complètement ces 2 dossiers.

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 smacl/dev etsmacl/dev_out.

sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/dev sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/dev_out

ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl
107G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/prod_out
9.4M    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/dev
17G /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/prod
54M /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/dev_out
9.1M    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/staging_out
7.6M    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/staging
123G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl
ansible@s004:~$ sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/dev
ansible@s004:~$ sudo rm -Rf /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/dev_out
ansible@s004:~$ sudo du -h -d 1 /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl
107G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/prod_out
17G /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/prod
9.1M    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/staging_out
7.6M    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl/staging
123G    /var/lib/docker/volumes/nifi-all_tmp/_data/sftp/smacl

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/smacl/dev/ de ce bucket (dev_out n'est pas backupé sur S3).

Notre NiFi précédent backupait les données dans /var/sftp/smacl/dev/ 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 dev-mysql/devsmacl_cfui/ et dans le dossier dev-mysql/devsmacl_cfmodulesmacl/.

J'ai supprimé ces 2 dossiers et leur contenu.

2025-01-14¶

20:30 - Compression de la table ynh_osquery de cywise_ui_prod

Concerns

J'ai d'abord compressé la table ynh_osquery de cywise_ui_dev. J'ai choisi la table, cliqué sur l'onglet "Opérations", choisi "COMPRESSED" pour ROW_FORMAT puis cliqué sur le bouton "Exécuter".

En dev, cela a duré 2 ou 3 minutes pour une table qui faisait 1.5G avant compression.

En prod, phpMyAdmin a fait une timeout (en indiquant que la connexion à la base avait été perdue) mais l'opération était toujours en cours car j'ai vu beaucoup de CPU attribué à mariadb et la place disque diminuer avec le temps. Je dirai que ça a durée 15 à 20 minutes.

La table de prod faisait 52G avant compression et 10G après. Sur le disque, je suis passé de 99G de libre à 144G.

Du coup, j'ai également fait la compression des 2 tables pour Telescope qui pesaient 5.8G et 437M. Passées à 2.6G et 213M.

17:30 - Logo Cywise pour le login YunoHost sur yunohost-ista-prod

Concerns

Resource - server - yunohost-ista-prod

J'ai déinstallé puis réinstallé cf_custom_ynh depuis l'Admin YunoHost de yunohost-ista-prod. J'ai eu le problème de la page blanche pour l'admin. J'ai donc appliqué la procédure pour le résoudre. Ca fonctionne : le logo Cywise est présent (après avoir vidé mon cache).

17:25 - Mise à jour de Portainer 2.21.5 sur yunohost-ista-dev

Concerns

Resource - server - yunohost-ista-dev

Depuis l'Admin YunoHost de yunohost-ista-dev, je vais dans "Mise à jour du système". La nouvelle version de notre package portainer_ynh est bien détectée. Je clique sur "Mettre à jour". Tout se déroule sans erreur. Je peux me connecter à Portainer qui est en version 2.21.5 maintenant. Et la connexion au LDAP fonctionne toujours.

17:15 - Logo Cywise pour le login YunoHost sur yunohost-ista-dev

Concerns

Resource - server - yunohost-ista-dev

J'ai installé cf_custom_ynh depuis l'Admin YunoHost de yunohost-ista-dev. Ca fonctionne : le logo Cywise est présent (après avoir vidé mon cache).

17:05 - Mise à jour de Portainer 2.21.5 sur postface01

Concerns

Resource - deployment - postface01-portainer

Depuis l'Admin YunoHost de postface01, je vais dans "Mise à jour du système". La nouvelle version de notre package portainer_ynh est bien détectée. Je clique sur "Mettre à jour". Tout se déroule sans erreur. Je peux me connecter à Portainer qui est en version 2.21.5 maintenant. Et la connexion au LDAP fonctionne toujours.

17:00 - Logo Cywise pour le login YunoHost sur postface01

Concerns

Resource - server - postface01

J'ai déinstallé puis réinstallé cf_custom_ynh depuis l'Admin YunoHost de postface01. Ca fonctionne : le logo Cywise est présent (après avoir vidé mon cache).

Mise à jour des pages de login de YunoHost pour avoir le logo de Cywise

Concerns

J'ai mis à jour le logo du thème ComputableFacts de cf_custom_ynh pour avoir celui de Cywise à la place de celui de Towerify.

J'ai ensuite mis à jour yunohost-dev02 et ça fonctionne.

J'ai ensuite mis à jour yunohost-addapps. La page de login utilisateurs (https://myapps.addapps.io/yunohost/sso/) est à jour mais la page de login de l'Admin est une page blanche...

J'ai déjà eu ce problème. Pour le résoudre il faut installer le package yunohost-admin à nouveau : sudo apt-get install --reinstall yunohost-admin. Et le problème est bien résolu.

Info

J'ai tenté de corriger le script d'upgrade du package mais il échoue car YunoHost voudrait absolument utiliser $install_dir (en dehors de mes scripts) alors que je n'ai pas de répertoire d'installation pour ce package.

Du coup, je mets à jour en désinstallant puis en installant de nouveau l'application cf_custom_ynh.

Mise à jour de Portainer 2.21.5 avec le package portainer_ynh de YunoHost sur yunohost-dev02 puis sur yunohost-addapps

Concerns

Comme je dois corriger le hook conf_regen du package portainer_ynh, je vais en profiter pour mettre à jour la version du container Portainer que nous utilisons.

J'ai corrigé le hook. Je suis passé de la version 2.19.1 à la version 2.21.5 de Portainer (dernière LTS).

J'ai mis à jour notre catalogue d'applications YunoHost. Sur yunohost-dev02, la nouvelle version a bien été détectée. J'ai fait la mise à jour sans erreur. Mon Portainer est à jour et fonctionne correctement sur yunohost-dev02.

J'ai fait de même avec le Portainer de yunohost-addapps.

Augmentation de la place disque de yunohost-addapps

Concerns

Resource - server - yunohost-addapps

Il restait 15G sur 150G hier. J'ai vidé les tables telescope de Cywise PROD pour gagner 15G de plus mais c'est plus prudent d'ajouter de la place disque.

J'ajoute 100G supplémentaires car nous voulons compresser la table ynh_osquery qui fait 52G et il faut le double de place disque pour pouvoir le faire. Voir cette procédure.

Détail des commandes

cfadmin@yunohost-addapps-xxl:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G  4.1M  3.2G   1% /run
/dev/sda1       147G  109G   33G  78% /
tmpfs            16G   80K   16G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/sda15      124M   11M  114M   9% /boot/efi
tmpfs           3.2G     0  3.2G   0% /run/user/1249
cfadmin@yunohost-addapps-xxl:~$ sudo growpart /dev/sda 1
CHANGED: partition=1 start=262144 old: size=312237823 end=312499967 new: size=507550323 end=507812467
cfadmin@yunohost-addapps-xxl:~$ sudo resize2fs -p /dev/sda1
resize2fs 1.46.2 (28-Feb-2021)
Filesystem at /dev/sda1 is mounted on /; on-line resizing required
old_desc_blocks = 19, new_desc_blocks = 31
The filesystem on /dev/sda1 is now 63443790 (4k) blocks long.

cfadmin@yunohost-addapps-xxl:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             16G     0   16G   0% /dev
tmpfs           3.2G  4.1M  3.2G   1% /run
/dev/sda1       239G  109G  121G  48% /
tmpfs            16G   80K   16G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/sda15      124M   11M  114M   9% /boot/efi
tmpfs           3.2G     0  3.2G   0% /run/user/1249

Problème d'accès au Portainer de yunohost-addapps et de yunohost-dev02

Concerns

Il y a le même problème que pour Postface : l'accès au LDAP depuis le container de Portainer ne fonctionne plus.

Détails de ma manip sur yunohost-dev02

J'ai bien SLAPD_SERVICES="ldap://localhost:389/ ldaps:/// ldapi:///" dans la conf /etc/default/slapd.

Quand je fais la commande qui met à jour la conf et qui doit appliquer le hook de portainer_ynh, je n'ai pas de différence :

twr_admin@dev02:~$ sudo yunohost tools regen-conf slapd --dry-run --with-diff
twr_admin@dev02:~$

Je modifie le hook /etc/yunohost/hooks.d/conf_regen/50-portainer pour ajouter cette ligne :

ynh_replace_string --match_string="^SLAPD_SERVICES=\"ldap://localhost:389/ ldaps:/// ldapi:///\"" --replace_string="SLAPD_SERVICES=\"ldap:/// ldaps:/// ldapi:///\"" --target_file="${slapd_conf}"

Mais la commande ne trouve aucune différence à nouveau :

twr_admin@dev02:~$ sudo yunohost tools regen-conf slapd --dry-run --with-diff
twr_admin@dev02:~$

Par contre, quand je demande les différences pour tous les fichiers (pas que slapd), YunoHost m'affiche des différences pour slapd :

twr_admin@dev02:~$ sudo yunohost tools regen-conf --dry-run --with-diff
Success! The configuration would have been updated for category 'slapd'
Success! The configuration would have been updated for category 'dnsmasq'
Warning: The configuration file '/etc/fail2ban/jail.conf' has been manually modified and will not be updated
...
slapd: 
  applied: 
    /etc/default/slapd: 
      diff: @@ -21,7 +21,7 @@
# sockets.
# Example usage:
# SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///"
-SLAPD_SERVICES="ldap://localhost:389/ ldaps:/// ldapi:///"
+SLAPD_SERVICES="ldap:/// ldaps:/// ldapi:///"

# If SLAPD_NO_START is set, the init script will not start or restart
# slapd (but stop will still work).  Uncomment this if you are
      status: updated
  pending:

Donc mon hook corrigé fonctionne. Mais je ne veux pas mettre à jour les autres fichiers de conf donc je modifie à la main /etc/default/slapd.

Puis je redémarre slapd avec la commande sudo systemctl restart slapd.service.

Le problème est résolu.

J'applique la même méthode pour résoudre le problème sur yunohost-addapps.

2025-01-13¶

21:15 - Nos 5 performa ne répondent plus

Concerns

Interruption du lundi 13/01 19h45 au lundi 13/01 21h30 soit 1 heure 45 minutes

Les remontées des machines de nos 5 performa ont été perdues.

J'ai eu 2 alertes vers 20h05 venant de mes 2 surveillances Freshping (CF et Ista). Les 3 autres performa n'ont pas de surveillance Freshping.

En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.

Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.

Problème d'accès au Portainer de postface

Concerns

Resource - deployment - postface01-portainer

Cyrille reproduit l'erreur LDAP de Christian :

failed creating LDAP connection: LDAP Result Code 200 "Network Error": dial tcp 172.17.0.1:389: connect: connection refused

Mon compte ne fait pas partie du LDAP ce qui explique que j'arrivais à me connecter. J'ai créé un compte de test, dans le LDAP donc, et je reproduis également l'erreur LDAP avec.

J'ai redémarré le container de portainer mais le problème persiste. J'ai redémarré le service Docker mais le problème persiste. J'ai redémarré la machine Scaleway mais le problème persiste.

J'ai fini par trouver l'origine du problème : la configuration du LDAP (slapd) n'autorise que des connexions venant de localhost (donc celles venant des containers comme Portainer sont rejetées).

J'ai pourtant, dans mon installation portainer_ynh un hook qui change la conf de slapd afin qu'il accepte les connexions de tous les IPs : je remplace ldap://127.0.0.1:389/ par ldap:/// dans son fichier de conf. Je me rends compte que ce n'est plus ldap://127.0.0.1:389/ mais ldap://localhost:389/ qu'il y a dans le fichier de conf.

J'ai tenté de faire le remplacement en modifiant mon hook mais sans succès...

J'ai fini par modifier à la main la conf, par redémarrer slapd et j'ai corrigé le problème.

Ne pas arrêter le service LDAP (slapd)

J'ai redémarré le service slapd plusieurs fois. J'ai pensé que arrêter puis démarrer serait mieux.

Grave erreur : une fois le service arrêté, sudo demande le mot de passe de twr_admin... Donc, impossible de redémarrer le service si on ne connait pas le mot de passe.

Cela veut dire que le sudo utilise le LDAP ?!?

2025-01-10¶

18:20 - Suppression de 2 managers du cluster swarm01 (s002 et s003)

Concerns

Resource - cluster - swarm01
Resource - deployment - swarm01-portainer
Deprecated: Resource - server - s002
Deprecated: Resource - server - s003

Comme nous avons réduit le nombre de clients utilisant swarm01, nous voulons réduire le nombre de machines. Je veux commencer par retirer les 2 managers.

Je choisi de garder s001 comme manager et de supprimer s002 et s003.

Je sauvegarde le répertoire /var/lib/docker/swarm sur s001.

Commande

ansible@s001:~$ sudo tar -czvf var_lib_docker_swarm.20250110.tar.gz /var/lib/docker/swarm
tar: Removing leading `/' from member names
/var/lib/docker/swarm/
/var/lib/docker/swarm/worker/
/var/lib/docker/swarm/worker/tasks.db
/var/lib/docker/swarm/state.json
/var/lib/docker/swarm/docker-state.json
/var/lib/docker/swarm/raft/
/var/lib/docker/swarm/raft/wal-v3-encrypted/
/var/lib/docker/swarm/raft/wal-v3-encrypted/0000000000000282-0000000000fb5e32.wal
/var/lib/docker/swarm/raft/wal-v3-encrypted/0.tmp
/var/lib/docker/swarm/raft/snap-v3-encrypted/
/var/lib/docker/swarm/raft/snap-v3-encrypted/0000000000000184-0000000000fb7703.snap
/var/lib/docker/swarm/certificates/
/var/lib/docker/swarm/certificates/swarm-node.key
/var/lib/docker/swarm/certificates/swarm-root-ca.crt
/var/lib/docker/swarm/certificates/swarm-node.crt

Pour restaurer, faire (non testé) :

sudo systemctl stop docker
sudo tar -xzvf swarm-backup.tar.gz -C /
sudo systemctl start docker

Le status des noeuds de mon swarm :

ansible@s001:~$ sudo docker node ls
ID                            HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
k232lszqgaa76qas459m9v9c1 *   s001       Ready     Active         Reachable        24.0.4
0u3khzcl9z51ht6mkm4faejxw     s002       Ready     Active         Leader           24.0.4
ljt3zkvuzii9f90k7o0g5jx6d     s003       Ready     Active         Reachable        24.0.4
wvjk3zj5trf7shi8sk4lwaiau     s004       Ready     Active                          24.0.4
julb8p7h0lakc89ivtmhmtmhd     s005       Ready     Active                          24.0.4
yt8tm5wpiigklqt3zi7n1x2q8     s008       Ready     Active                          24.0.4

Je vais d'abord enlever le rôle de manager à s003. s002 devrait rester Leader. Puis je vais enlever le rôle de manager à s002 donc s001 sera le seul manager restant et devrait devenir Leader.

Commandes

ansible@s001:~$ sudo docker node demote ljt3zkvuzii9f90k7o0g5jx6d
Manager ljt3zkvuzii9f90k7o0g5jx6d demoted in the swarm.
ansible@s001:~$ sudo docker node ls
ID                            HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
k232lszqgaa76qas459m9v9c1 *   s001       Ready     Active         Reachable        24.0.4
0u3khzcl9z51ht6mkm4faejxw     s002       Ready     Active         Leader           24.0.4
ljt3zkvuzii9f90k7o0g5jx6d     s003       Ready     Active                          24.0.4
wvjk3zj5trf7shi8sk4lwaiau     s004       Ready     Active                          24.0.4
julb8p7h0lakc89ivtmhmtmhd     s005       Ready     Active                          24.0.4
yt8tm5wpiigklqt3zi7n1x2q8     s008       Ready     Active                          24.0.4
ansible@s001:~$ sudo docker node demote 0u3khzcl9z51ht6mkm4faejxw
Manager 0u3khzcl9z51ht6mkm4faejxw demoted in the swarm.
ansible@s001:~$ sudo docker node ls
ID                            HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
k232lszqgaa76qas459m9v9c1 *   s001       Ready     Active         Leader           24.0.4
0u3khzcl9z51ht6mkm4faejxw     s002       Ready     Active                          24.0.4
ljt3zkvuzii9f90k7o0g5jx6d     s003       Ready     Active                          24.0.4
wvjk3zj5trf7shi8sk4lwaiau     s004       Ready     Active                          24.0.4
julb8p7h0lakc89ivtmhmtmhd     s005       Ready     Active                          24.0.4
yt8tm5wpiigklqt3zi7n1x2q8     s008       Ready     Active                          24.0.4

Je teste :

l'accès à l'admin de Keycloak fonctionne
l'accès au datalake de DEV puis de PROD ISTA, en passant par Keycloak fonctionne

Je dois maintenant retirer s002 et s003 du swarm. Je veux le faire avec ansible.

Je mets à jour mon inventaire :

swarm01_nodes:
  children:
    # Must be one of the Swarm managers hosts (only the first host is used)
    swarm_initiator:
      hosts:
        s001:
    # Hosts that will be Swarm manager (at least one)
    swarm01_managers:
      hosts:
        s001:
    # Hosts that will be Swarm worker. Must not be in Swarm managers list.
    swarm01_workers:
      hosts:
        s004:
        s005:
        s008:
    # Hosts that will be remove from Swarm
    swarm01_leave:
      hosts:
        s002:
        s003:

Puis je fais la commande : ansible-playbook -i ansible/inventory.yml ansible/02-swarm.yaml --tags swarm-leave -e "infra=swarm01".

Elle est restée bloquée après avoir affichée Ok [s002]. J'ai donc fait aussi la commande sudo docker swarm leave directement sur s002 qui a réussi car elle a affiché : Node left the swarm..

s002 ne fait plus partie du swarm01

ansible@s001:~$ sudo docker node ls
ID                            HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
k232lszqgaa76qas459m9v9c1 *   s001       Ready     Active         Leader           24.0.4
0u3khzcl9z51ht6mkm4faejxw     s002       Down      Active                          24.0.4
ljt3zkvuzii9f90k7o0g5jx6d     s003       Ready     Active                          24.0.4
wvjk3zj5trf7shi8sk4lwaiau     s004       Ready     Active                          24.0.4
julb8p7h0lakc89ivtmhmtmhd     s005       Ready     Active                          24.0.4
yt8tm5wpiigklqt3zi7n1x2q8     s008       Ready     Active                          24.0.4

Mais j'ai un problème car Portainer était stické sur s002.

Comment j'ai rétabli Portainer

J'ai d'abord mis le tag qui sticke Portainer sur s001 avec la commande sudo docker node update --label-add portainer.portainer-data=true k232lszqgaa76qas459m9v9c1.

Portainer a démarré mais comme si je venais de l'installer. Je dois donc transférer le contenu du volume de s002 vers s001.

J'ai commencé par arrêter le service de Portainer qui utilise le volume avec cette commande sur s001 : sudo docker service scale portainer_portainer=0.

Puis j'ai transféré depuis mon poste avec ces 3 commandes :

ssh swarm01-s002 "sudo tar czf - /var/lib/docker/volumes/portainer_portainer-data/_data" > portainer_portainer-data/portainer-data.tar.gz
scp portainer_portainer-data/portainer-data.tar.gz swarm01-s001:/home/ansible/portainer-data.tar.gz
ssh swarm01-s001 "sudo tar xzf /home/ansible/portainer-data.tar.gz -C /home/ansible/ && sudo mv /home/ansible/var/lib/docker/volumes/portainer_portainer-data/_data/* /var/lib/docker/volumes/portainer_portainer-data/_data && sudo rm -rf /var/lib/docker/volumes/portainer_portainer-data/var"

Je redémarre le service avec sudo docker service scale portainer_portainer=1. J'arrive à me connecter. Je vois le swarm et je vois qu'il a 49 stacks mais je n'arrive pas à lister les stacks ni les services. Par contre je vois la liste des containers. J'ai des messages d'erreur "Unable to retrieve stacks" ou "Unable to retreive services". Parfois les stacks se sont affichées mais les services jamais.

Je décide de publier à nouveau portainer sur s001 avec ansible et la commande : ansible-playbook -i ansible/inventory.yml ansible/04-swarm01-utility-stacks.yaml --tags portainer (j'ai changé hosts: s002 par hosts: s001 avant).

Les agents de chaque node redémarrent (comme je le pensais) et, maintenant, mon portainer fonctionne à nouveau comme avant.

Je vois toujours s002 avec la commande sudo docker node ls exécutée sur s001. Il a le statut down depuis que je l'ai retiré du swarm. Je fais la commande sudo docker node rm 0u3khzcl9z51ht6mkm4faejxw pour l'enlever définitivement de la liste.

Je passe à s003. Sur s003, je fais la commande sudo docker swarm leave qui réussie avec le retour Node left the swarm.. Comme s002, s003 reste présent avec le statut down dans la liste de sudo docker node ls. Je le supprime donc avec la commande sudo docker node rm s003. Ca fonctionne : je n'ai plus que 4 serveurs dans swarm01.

J'arrête là pour aujourd'hui. Je supprimerai les machines la semaine prochaine.

17:30 - Suppression des 3 stacks cf-ui d'ISTA sur swarm01

Concerns

Deprecated: Resource - deployment - dev-ista-cf-ui
Deprecated: Resource - storage - devista_cfui
Deprecated: Resource - deployment - staging-ista-cf-ui
Deprecated: Resource - storage - stagingista_cfui
Deprecated: Resource - deployment - prod-ista-cf-ui
Deprecated: Resource - storage - prodista_cfui

Nous avons migré l'infra d'Ista sur les serveurs yunohost-ista-dev et yunohost-ista-prod depuis plusieurs mois donc je peux supprimer ces 3 stacks conservées par prudence.

Actions :

suppression des stacks depuis le ssh (ansible@s001:~$ sudo docker stack rm dev-ista-cf-ui, ansible@s001:~$ sudo docker stack rm staging-ista-cf-ui, ansible@s001:~$ sudo docker stack rm prod-ista-cf-ui)
suppression des 3 bases MySQL correspondantes (devista_cfui, stagingista_cfui, prodista_cfui, ) avec phpMyAdmin.
suppression dans le playbook ansible (cf-infra/ansible/client-ista.yaml)

16:50 - Problème d'accès au Portainer de postface ?

Concerns

Resource - deployment - postface01-portainer

Christian de Postface qui m'a envoyé, à 16h50, ce message d'erreur qu'il a eu en accédant à son Portainer :

failed creating LDAP connection: LDAP Result Code 200 "Network Error": dial tcp 172.17.0.1:389: connect: connection refused

Quand j'ai essayé de mon côté, pas d'erreur. Peut-être un problème temporaire.

16:30 - Mise à jour des certificats SSL dans l'image du container de Traefik

Concerns

Resource - deployment - traefik-public

Comme nous avons réduit le nombre de clients utilisant swarm01, nous voulons réduire le nombre de machines. Je veux commencer par retirer les 2 managers. Mais je risque de déplacer le container de Traefik et de provoquer le regénération des certificats. Et, pire, si je sature Let's Encrypt, de ne pas réussir à les regénérer...

J'ai donc récupéré les fichiers /etc/acme.json et /etc/acme-tls.json pour les mettre à jour dans la repo cf-infra puis j'ai mis à jour Traefik (cela reconstruit l'image Docker avec la dernière version des certificats donc en cas de redémarrage, pas besoin de les mettre à jour).

Pas d'interruption perceptible.

2025-01-09¶

11:40 - Problème avec le Job to Dataset qui appelait l'ancienne URL de api1

Concerns

Resource - deployment - yunohost-ista-prod_jenkins

Matthieu remonte un problème avec le Job to Dataset du Jenkins de PROD : l'URL de api1 n'était pas la bonne (c'était l'ancienne). Voir le ticket #8740.

J'ai résolu le problème le lendemain 2025-01-10.

2025-01-08¶

19:30 - Mise à jour Performa de Oppscience pour Windows

Concerns

Resource - deployment - performa_js5f-4t7e-5er8

J'ai mis au point une façon de calculer le Load Average sous Windows. Je recopie ma commande windows_load et je modifie le monitor load_avg du Performa de DEV vers celui de Oppscience. J'ai fait le même chose pour le pourcentage de CPU.

15:00 - Suppression des surveillances Freshping de la Smacl

Concerns

Deprecated: Resource - deployment - prod-smacl-cf-ui
Deprecated: Resource - deployment - prod-smacl-module

La Smacl a résilié son contrat avec nous.

J'ai donc supprimé 3 surveillances Freshping :

https://www.smacl.computablefacts.com/healthz
https://www.smacl.computablefacts.com/login
https://cf-module-smacl-prod.smacl.computablefacts.com/healthz

J'ai également supprimé la page de statut dédiée qui affichait ces 3 surveillances :

http://status.smacl.computablefacts.com/
et supprimé les 2 entrées DNS correspondantes chez Gandi

Enfin, j'ai supprimé les 3 surveillances, les mêmes que Freshping, que j'avais mises dans statping.

14:00 - Désactivation de l'accès SFTP de la Smacl

Concerns

Resource - deployment - swarm01-sftp

La Smacl a résilié son contrat avec nous.

J'ai donc désactivé les 3 comptes qui leur permettaient de déposer des fichiers sur notre SFTP.

2025-01-07¶

Données erronées sur le Datalake de PROD Ista qui impactent le module Ciblage Commercial

Concerns

Resource - deployment - ciblage-commercial_prod

Voir le ticket #8738.

Le plus problable : quand j'ai déplacé le dataset de PROD d'Ista, j'ai déposé seulement les derniers fichiers du dataset conso-gaz. Le premier fichier ne contenait que 10 colonnes au lieu des 27 dans les autres. Le concept créé ne contenait pas les colonnes attendues donc cela provoquait l'erreur dans l'UI.

Pourquoi l'ancienne PROD fonctionnait : certainement car la création du concept avait été fait après le dépôt d'un ou plusieurs fichiers corrects (avec les 27 colonnes). Déposer le fichier erroné n'avait alors pas eu d'impact.

09:00 - Problème de publication avec Towerify CLI suite à la mise à jour de Jenkins

Concerns

Cyrille a des erreurs quand il tente de publier Cywise PROD sur yunohost-addapps.

Après analyse, il y avait 2 problèmes :

l'effacement des secrets échouait
l'archive tar.gz envoyée à Jenkins qui était trop grosse

Le problème de l'effacement des secrets venait d'un slash en double dans l'URL de Jenkins : https://jenkins.myapps.addapps.io//manage/.... Corriger Towerify CLI pour ne pas avoir ce double slash a résolu ce premier problème.

Le refus de l'archive trop grosse venait de la mise à jour de Jenkins : la taille maximale était revenue à sa valeur par défaut (10M) au lieu de la valeur que nous avions augmentée (100M). Modifier la conf de nginx pour Jenkins afin de remettre 100M a résolu le problème.

J'ai remis 100M sur les 3 Jenkins que j'avais mis à jour : yunohost-dev02, postface01 et yunohost-addapps.

2025-01-06¶

16:45 - Mise à jour Jenkins sur yunohost-addapps

Concerns

Resource - server - yunohost-addapps

Fait en utilisant l'UI Admin de YunoHost, activée pour l'occasion.

Dans cf_custom, je bascule sur le catalogue par défaut. Puis je vais dans "Mise à jour du système". YunoHost détecte une nouvelle version de Jenkins : 2.479.2~ynh1. Je lance la mise à jour depuis l'UI Admin. Dans cf_custom, je remets notre catalogue spécifique.

Passage de la version 2.426.1~ynh2 à la version 2.479.2~ynh1.

16:35 - Installation de cf_custom sur Postface

Concerns

Resource - server - postface01

Fait en utilisant l'UI Admin de YunoHost, activée pour l'occasion.

Choix du thème ComputableFacts à l'installation. Affiche le logo Towerify.

12:40 - Mise à jour Jenkins sur Postface

Concerns

Resource - server - postface01

Fait en utilisant l'UI Admin de YunoHost, activée pour l'occasion.

Passage de la version 2.426.1~ynh4 à la version 2.479.2~ynh1.

Ajout d'une surveillance Freshping pour l'application de Postface

Concerns

Resource - server - postface01

La surveillance Freshping : https://computablefacts.freshping.io/reports?check_id=1096025. L'URL de l'application surveillée : https://www.postface.towerify.io/login.

12:00 - Mise à jour YunoHost sur Postface

Concerns

Resource - server - postface01

Fait en utilisant l'UI Admin de YunoHost, activée pour l'occasion.

Passage de la version 11.2.6 à la version 11.3.0.

11:55 - Changement du mot de passe de twr_admin sur Postface

Concerns

Resource - server - postface01

J'ai changé le mot de passe de twr_admin pour pouvoir me connecter à l'UI Admin. Fait avec la commande sudo yunohost user update twr_admin -p <new_pwd>.

2025-01-03¶

Redirection de app.towerify.io vers app.cywise.io

Concerns

Deprecated: Resource - deployment - dev-towerify-ui

TODO

19:10 - Installation de cf_custom sur yunohost-dev02

Concerns

Resource - server - yunohost-dev02

Fait en utilisant l'UI Admin de YunoHost, activée pour l'occasion.

Choix du thème ComputableFacts à l'installation. Affiche le logo Towerify.

18:40 - Mise à jour Jenkins sur yunohost-dev02

Concerns

Resource - server - yunohost-dev02

Fait en utilisant l'UI Admin de YunoHost, activée pour l'occasion.

Passage de la version 2.426.3~ynh2 à la version 2.479.2~ynh1.

18:30 - Mise à jour YunoHost sur yunohost-dev02

Concerns

Resource - server - yunohost-dev02

Fait en utilisant l'UI Admin de YunoHost, activée pour l'occasion.

Passage de la version 11.2.5 à la version 11.3.0.

18:25 - Mise à jour phpMyAdmin sur yunohost-addapps

Concerns

Resource - server - yunohost-addapps

Fait en utilisant l'UI Admin de YunoHost, activée pour l'occasion.

Passage à la version 5.2.1.

17:20 - Mise à jour YunoHost sur yunohost-addapps

Concerns

Resource - server - yunohost-addapps

Fait en utilisant l'UI Admin de YunoHost, activée pour l'occasion.

Passage de la version 11.2.9 à la version 11.3.0.

2024-12-18¶

17:40 - Erreur lors du déploiement

Concerns

Resource - deployment - cywise-ui_prod

Interruption du mercredi 18/12 12h10 au vendredi 18/12 13h10 soit 1 heure

Toutes les applications hébergées sur la machine yunohost-addapps ont été indisponibles.

Je déploie Cywise PROD pour debugger la connexion de engineering sur tous les performa mais j'ai une erreur de syntaxe dans config/towerify.php qui empêche l'application de démarrer.

Le temps de comprendre le problème et de déployer le correctif.

Puis une nouvelle erreur : network sandbox join failed: subnet sandbox join failed for "10.0.0.0/24": error creating vxlan interface: file exists.

J'arrête Docker puis je démarre Docker mais j'ai toujours la même erreur (NOTA: Docker avait été redémarré 5 minutes plus tôt. le hook de règles du firewall ?).

Je redémarre la machine cette fois.

C'était un problème de place disque finalement. J'ai fait le ménage dans les tables de telescope et des événements.

2024-12-12¶

17:40 - Limiter la taille des logs de chaque container

Concerns

Resource - server - yunohost-addapps

Interruption du jeudi 12/12 17h20 au jeudi 12/12 18h20 soit 1h

Toutes les applications hébergées sur la machine yunohost-addapps ont été indisponibles.

Je me rends compte du problème car Jenkins ne répond pas quand je veux publier Cywise DEV. Pas de problème de place disque. Les IP v4 et v6 sont toujours présents. Mais sudo htop montre les 8 CPU à 80% en continu.

Je fais l'hypothèse d'un scan de Sentinel mais ce n'était pas ça car ça a duré 45 minutes environ. Quand l'occupation CPU redevient raisonnable, les applications ne répondent toujours pas. Je tente de redémarrer Docker avec sudo systemctl restart docker mais les applications sont toujours indisponibles. Beaucoup d'erreurs dans /var/log/nginx/error.log donc je tente un redémarrage de nginx avec sudo systemctl restart nginx.

C'était ça le problème...

18h20

Les applications sont à nouveau opérationnelles.

11:00 - Limiter la taille des logs de chaque container

Concerns

Resource - server - yunohost-addapps

Plus de place disque sur yunohost-addapps. Un container a un fichier de log de 40Go. C'est le container app de Cywise PROD. J'ai supprimé le fichier sans que cela ne me fasse regagner de la place. J'ai dû arrêter le container et en démarrer un nouveau pour regagner la place disque.

Je décide de faire un réglage global au niveau de Docker afin de limiter la taille et le nombre de fichiers de logs. Je crée donc le fichier /etc/docker/daemon.json avec ce contenu :

  {
    "log-driver": "json-file",
    "log-opts": {
      "max-size": "10m",
      "max-file": "20",
      "cache-disabled": "false",
      "cache-max-file": "5",
      "cache-max-size": "20m",
      "cache-compress": "true"
    }
  }

Puis j'ai redémarré Docker avec sudo systemctl restart docker. Tous les containers ont été recréés.

2024-11-29¶

Perte de yunohost-addapps

Concerns

Resource - server - yunohost-addapps

Je décide de changer de type d'instance à nouveau pour yunohost-addapps

Je suis cette doc Scaleway.

Je crée une image de yunohost-addapps-xl. Je crée une nouvelle instance à partir de l'image en choissant un type 4 fois plus puissant : PRO2-S à la place de PRO2-XXS. Je n'ai mis ni IP v4 ni IP v6 à cette instance (transfert depuis la précédente à venir). J'ai basculé IP v4 et IP v6 de yunohost-addapps-xl vers yunohost-addapps-xxl...

Voilà les IP sur la nouvelle instance :

cfadmin@yunohost-addapps-xxl:~$ date && ip addr show ens2
Fri 29 Nov 2024 08:33:54 AM UTC
2: ens2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether de:00:00:81:67:db brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    inet 51.15.140.162/32 scope global dynamic ens2
      valid_lft 778sec preferred_lft 778sec
    inet6 2001:bc8:710:1644:dc00:ff:fe81:67db/64 scope global dynamic mngtmpaddr noprefixroute 
      valid_lft 86395sec preferred_lft 14395sec
    inet6 fe80::dc00:ff:fe81:67db/64 scope link 
      valid_lft forever preferred_lft forever

L'IP v6 a changé, c'était 2001:bc8:710:1644:dc00:ff:fe76:38f3/64 avant. Je change le paramétrage AAAA de myapps.addapps.io chez Gandi pour mettre ce nouvel IP v6. Les autres domaines sont des CNAME de myapps.addapps.io donc doivent basculer en même temps.

2024-11-28¶

01:25 - Perte de yunohost-addapps

Concerns

Resource - server - yunohost-addapps

Interruption du jeudi 28/11 1h25 au jeudi 28/11 8h soit

Toutes les machines qui remontent leurs infos n'ont pas pu le faire donc nous avons perdu leur historique sur cette période.

Le 28/11 vers 7h45, je vois des alertes disant que yunohost-addapps ne répond plus depuis 1h25.

Impossible de me connecter en SSH, ni avec l'IP v4, ni avec l'IP v6 :

patrick@SpectreMate:~
[07:51:30]$ ssh yunohost-addapps-ipv6 
ssh: connect to host 2001:bc8:710:1644:dc00:ff:fe76:38f3 port 22: Network is unreachable
patrick@SpectreMate:~
[07:51:10]$ ssh yunohost-addapps
ssh: connect to host 51.15.140.162 port 22: Connection timed out
patrick@SpectreMate:~
[07:54:19]$

8h00

Je redémarre l'instance.

Je me rends compte que je n'arrive pas à me connecter en IP v6 sur AddApps à cause de mon contexte : je suis connecté au WiFi d'un hotel. Sur une connexion partagée avec mon téléphone, je n'ai pas non plus accès à l'IP v6. Mais si je me connecte à une autre instance, je peux faire un ping en IP v6 vers AddApps.

Donc, contrairement à ce que je pensais hier, le problème d'hier et d'aujourd'hui et certainement le même que les 3 ou 4 précédents : perte de l'IP v4 uniquement. Je dis "certainement" car je n'ai pas pu vérifier que je pouvais me connecter en IP v6 sur AddApps avant de la redémarrer.

Je mets à jour mon ticket Scaleway.

2024-11-27¶

Traitement des événements très lent sur Cywise PROD²

Concerns

Resource - deployment - cywise-ui_prod

Le 2024-11-26, Cyrille remarque que Cywise affiche les serveurs en rouge comme si ceux-ci n'avaient pas contacté Cywise depuis longtemps. Bien sûr, nous pensons à une perte d'IP v6 ou v4 mais ce n'était pas le cas.

L'historique des métriques des serveurs n'est pas à jour et les dernières métriques affichées datent de la veille vers 23h. Pourtant, des requêtes venant des serveurs arrivent et sont traitées rapidement et sans erreur. Elles créent un événement qui doit être traité par la queue.

Le container qui traite les événements en attente fonctionne et il n'y a pas d'erreur dans les logs.

Cela me rappelle également le mail que Cywise envoie tous les matins et qui s'était décalé pour passer de 7h45 à 15h05 en 3 ou 4 jours.

Finalement, nous comprenons que le traitement est ralenti car il y a beaucoup trop d'événements à traiter. Plus de 960k événements en attente... Dont 590k d'événements ProcessPendingUpdates qui sont des événements Lavarel liés à Telescope.

Cyrille supprime ces événements ProcessPendingUpdates et plusieurs autres qui sont lancés à intervalle régulier (EmbedChunks, DeleteEmbeddedChunks, TriggerScan, PullServersInfos, TriggerDiscoveryShallow).

Cela débloque le traitement des événements pour les métriques qui se mettent à jour en rattrappant leur retard.

Pour les événements Laravel liés à Telescope, une option existe pour les désactiver. Nous ajoutons TELESCOPE_JOB_WATCHER=false dans les secrets pour ça.

Nous décidons de séparer les événements dans 3 files d'attente distinctes : low, medium, critical

Nous enverrons les événements liés à la remontée d'information des serveurs dans la file critical afin que leur prise en compte en soit pas retardée par d'autres événements plus long à traiter.

Fait en DEV vers 11h.

2024-11-26¶

23:15 - Perte de yunohost-addapps

Concerns

Resource - server - yunohost-addapps

Interruption du mardi 26/11 23h15 au mercredi 27/11 9h soit 9h45

Toutes les machines qui remontent leurs infos n'ont pas pu le faire donc nous avons perdu leur historique sur cette période.

Le 27/11 vers 8h45, je vois des alertes disant que yunohost-addapps ne répond plus depuis la veille vers 23h15.

Impossible de me connecter en SSH, ni avec l'IP v4, ni avec l'IP v6 :

[08:51:46]$ ssh yunohost-addapps-ipv6 
ssh: connect to host 2001:bc8:710:1644:dc00:ff:fe76:38f3 port 22: Network is unreachable
patrick@SpectreMate:~
[08:51:52]$ ssh yunohost-addapps
ssh: connect to host 51.15.140.162 port 22: Connection timed out
patrick@SpectreMate:~
[08:54:11]$

9h00

Je redémarre l'instance.

Je mets à jour mon ticket Scaleway.

2024-11-22¶

16:05 - Intervention Scaleway sur yunohost-addapps

Concerns

Resource - server - yunohost-addapps

J'ai un échange sur Slack avec un ingénieur de Scaleway à propos des pertes IP v4 (et IP v6). Je lui fais l'historique des mes problèmes en résumant le contenu du ticket. Je lui donne accès à l'instance en accrochant sa clé SSH au compte cfadmin.

Il trouve 2 fichiers de configuration réseau. Le premier qui serait lié à l'ancienne version du package cloud-init et le deuxième lié à la nouvelle version. Les 2 packages entreraient en conflit ce qui provoquerait les pertes d'IP v4.

Le fichier lié à l'ancien cloud-init est /etc/network/interfaces.d/50-cloud-init. Le fichier lié à nouveau cloud-init est /etc/network/interfaces.d/50-cloud-init.

Il me conseille de supprimer l'ancien fichier et de redémarrer l'instance ce que je fais.

16:05

Redémarrage de l'instance. Interruption de 2 minutes environ.

Impossible d'être sûr à 100% que le problème est résolu. Je laisse donc le ticket ouvert pendant au moins une semaine (j'ai eu une perte d'IP v4 tous les 2 ou 3 jours depuis la mise à jour de cloud-init donc pas de perte pendant 7 à 10 jours laisserait penser que le problème est résolu).

2024-11-21¶

01:30 - Perte de l'IPv4 de yunohost-addapps

Concerns

Resource - server - yunohost-addapps

Interruption IPv4 du jeudi 21/11 1h30 au jeudi 21/11 9h30 soit 8h

Toutes les machines qui remontent leurs infos avec l'IP v4 n'ont pas pu le faire donc nous avons perdu leur historique sur cette période.

Je me connecte à l'instance en utilisant son IP v6 (qu'elle ne perd plus) et l'IP v4 a bien disparu :

2: ens2:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether de:00:00:76:38:f3 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    inet6 2001:bc8:710:1644:dc00:ff:fe76:38f3/64 scope global deprecated dynamic mngtmpaddr noprefixroute
      valid_lft 57339sec preferred_lft 0sec
    inet6 fe80::dc00:ff:fe76:38f3/64 scope link
      valid_lft forever preferred_lft forever

9h30

Je redémarre l'instance. Et elle retrouve son IP v4.

J'ai mis à jour mon ticket Scaleway.

A nouveau, la bail de l'IP v6 est bien inférieur au 86400s habituel. Calcul fait, il a arrêté d'être renouvelé vers 1h15 comme pour l'IP v4. Même remarque que pour les 2 précédentes pertes d'IP v4. J'ai ajouté cette remarque dans mon ticket Scaleway.

2024-11-19¶

21:54 - Décommissionnement de s007

Concerns

Resource - cluster - swarm01
Deprecated: Resource - server - s007

Maintenant qu'aucune application n'est stickée sur s007 et que je l'ai sorti de swarm01, je peux le rendre à Scaleway.

Serveur Elastic Metal s007 supprimé depuis l'UI de Scaleway.

Déplacement de notre Jenkins et de celui de Lur Berri vers s005

Concerns

Resource - server - s005
Deprecated: Resource - server - s007

Nous avons fait cela afin de ne plus avoir d'applications avec des volumes stickés sur s007. Cela nous a permis de rendre la machine s007 à Scaleway.

Voir ma note détaillée.

2024-11-18¶

11:30 - Perte de l'IPv4 de yunohost-addapps - remarque intéressante

Concerns

Resource - server - yunohost-addapps

En regardant les 2 pertes d'IP v4 de ce jour et de samedi, je me rends compte que l'IP v6 n'est plus renouvelé non plus car le temps restant pour le bail est bien inférieur à 24h (86400s) :

Samedi vers 22h10, j'ai valid_lft 11650sec. 86400 - 11650 = 74750 secondes soit 20h45. Et 22h10 - 20h45 = 1h25.
Lundi vers 9h30, j'ai valid_lft 57030sec. 86400 - 57030 = 29370 secondes soit 8h10. Et 9h30 - 8h10 = 1h20.

On dirait bien que l'IP v6 arrête d'être renouvelée au même moment que l'IP v4. L'IP v4 expire au bout de 15 minutes donc cela provoque le problème et je redémarre l'instance mais l'IP v6 expirerait probablement au bout de 24h aussi.

01:35 - Perte de l'IPv4 de yunohost-addapps

Concerns

Resource - server - yunohost-addapps

Interruption IPv4 du lundi 18/11 1h35 au lundi 18/11 9h35 soit 8h

Toutes les machines qui remontent leurs infos avec l'IP v4 n'ont pas pu le faire donc nous avons perdu leur historique sur cette période.

Cyrille me prévient, et je vois son message vers 9h30, que AddApps ne réponds plus. Un ping app.cywise.io depuis sa machine va vers l'IP v4 et ne répond pas (Destination Host Unreachable).

Je me connecte à l'instance en utilisant son IP v6 (qu'elle ne perd plus) et l'IP v4 a bien disparu :

2: ens2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether de:00:00:76:38:f3 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    inet6 2001:bc8:710:1644:dc00:ff:fe76:38f3/64 scope global deprecated dynamic mngtmpaddr noprefixroute 
      valid_lft 57030sec preferred_lft 0sec
    inet6 fe80::dc00:ff:fe76:38f3/64 scope link 
      valid_lft forever preferred_lft forever

9h30

Je redémarre l'instance. Et elle retrouve son IP v4.

J'ai mis à jour mon ticket Scaleway.

Comme demandé par Scaleway en réponse à mon message de samedi, j'ai fait la commande sudo grep -i dhcp /var/log/syslog et j'ai mis le résultat dans le ticket. Rien de particulier de mon point de vue : on voit que l'instance récupère son IP v4 par DHCP après le redémarrage que je viens de faire.

Autre demande de Scaleway : j'ai refait un "sos report" que j'ai transmis en utilisant leur "pastebin".

2024-11-16¶

01:35 - Perte de l'IPv4 de yunohost-addapps

Concerns

Resource - server - yunohost-addapps

Interruption IPv4 du samedi 16/11 1h35 au samedi 16/11 22h10 soit 20h35

Toutes les machines qui remontent leurs infos avec l'IP v4 n'ont pas pu le faire donc nous avons perdu leur historique sur cette période.

Vers 22h, je me rends compte que yunohost-addapps ne répond plus sur son IP v4. Cela se confirme car j'ai eu une alerte de Freshping vers 1h35 ce matin.

Je me connecte à l'instance en utilisant son IP v6 (qu'elle ne perd plus) et l'IP v4 a bien disparu :

2: ens2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether de:00:00:76:38:f3 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    inet6 2001:bc8:710:1644:dc00:ff:fe76:38f3/64 scope global deprecated dynamic mngtmpaddr noprefixroute 
      valid_lft 11650sec preferred_lft 0sec
    inet6 fe80::dc00:ff:fe76:38f3/64 scope link 
      valid_lft forever preferred_lft forever

22h10

Je redémarre l'instance. Et elle retrouve son IP v4.

J'ai mis à jour mon ticket Scaleway en demandant si on peut mettre des IPs fixes.

2024-11-15¶

12:45 - L'IPv6 de yunohost-addapps est toujours là

Concerns

Resource - server - yunohost-addapps

24h après mon précédent redémarrage, j'ai toujours l'IP v6 et son bail est toujours proche de 86400 secondes (24h).

Le problème semble résolu.

2024-11-14¶

13:50 - Perte de l'IPv6 pour poc-ynh99

Concerns

Resource - server - poc-ynh99

Comme l'IP v6 de yunohost-addapps est renouvelée régulièrement, je tente de faire la même chose sur poc-ynh99 car j'avais constaté que cette instance perdait aussi son IP v6 quand j'avais fait mon inventaire.

Je mets à jour les packages :

cfadmin@poc-ynh99:~$ date --rfc-3339=second && ip -6 addr show ens2
2024-11-14 12:50:54+00:00
2: ens2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    altname enp0s2
    inet6 fe80::dc00:ff:fe33:9817/64 scope link 
      valid_lft forever preferred_lft forever
cfadmin@poc-ynh99:~$ dpkg -l | grep cloud-init
ii  cloud-init                            23.2.1-1                                           all          initialization system for infrastructure cloud instances
cfadmin@poc-ynh99:~$ dpkg -l | grep scaleway
ii  scaleway-ecosystem                    0.0.6-14~ubuntu20.04                               all          Collection of files, scripts and systemd units used to
cfadmin@poc-ynh99:~$ sudo apt-get update
...
cfadmin@poc-ynh99:~$ sudo apt-get upgrade scaleway-ecosystem cloud-init
...
cfadmin@poc-ynh99:~$ dpkg -l | grep scaleway
ii  cloud-init                            24.3.1-0ubuntu0~20.04.1+scaleway                   all          initialization and customization tool for cloud instances
ii  scaleway-ecosystem                    0.0.9-1~ubuntu20.04                                all          Collection of files, scripts and systemd units used to

14:05

Je redémarre l'instance.

Et, effectivement, elle récupère son IP v6 dont le bail se renouvelle très régulièrement (toutes les 10 secondes environ).

12:45 - Perte de l'IPv6 de yunohost-addapps à nouveau malgré la mise à jour du package scaleway-ecosystem

Concerns

Resource - server - yunohost-addapps

L'instance yunohost-addapps a perdu à nouveau son IPv6 :

cfadmin@yunohost-addapps-xl:~$ date && ip -6 addr show ens2
Thu 14 Nov 2024 11:39:40 AM UTC
2: ens2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    altname enp0s2
    inet6 2001:bc8:710:1644:dc00:ff:fe76:38f3/64 scope global deprecated dynamic mngtmpaddr 
      valid_lft 406sec preferred_lft 0sec
    inet6 fe80::dc00:ff:fe76:38f3/64 scope link 
      valid_lft forever preferred_lft forever
cfadmin@yunohost-addapps-xl:~$ date && ip -6 addr show ens2
Thu 14 Nov 2024 11:46:28 AM UTC
2: ens2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    altname enp0s2
    inet6 fe80::dc00:ff:fe76:38f3/64 scope link 
      valid_lft forever preferred_lft forever

Donc j'ai redémarré l'instance vers 12h45.

13:30

Je mets à jour le package cloud-init car Scaleway m'a demandé de mettre à jour régulièrement ce package en plus de scaleway-ecosystem.

cfadmin@yunohost-addapps-xl:~$ dpkg -l | grep cloud-init
ii  cloud-init                            23.2.1-1                                           all          initialization system for infrastructure cloud instances
cfadmin@yunohost-addapps-xl:~$ sudo apt-get update
...
cfadmin@yunohost-addapps-xl:~$ sudo apt-get upgrade cloud-init
...
cfadmin@yunohost-addapps-xl:~$ dpkg -l | grep cloud-init
ii  cloud-init                            24.3.1-0ubuntu0~20.04.1+scaleway                   all          initialization and customization tool for cloud instances

J'ai bien une version plus récente maintenant et, en plus, dans son numéro de version, il y a scaleway...

13:40

Je redémarre l'instance à nouveau.

Je me rends compte que le valid_lft de l'IP v6 remonte à 86400s (24h) régulièrement. La machine ne devrait plus perdre son IP v6 :

cfadmin@yunohost-addapps-xl:~$ date && ip -6 addr show ens2
Thu 14 Nov 2024 12:44:52 PM UTC
2: ens2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    altname enp0s2
    inet6 2001:bc8:710:1644:dc00:ff:fe76:38f3/64 scope global dynamic mngtmpaddr noprefixroute 
      valid_lft 86396sec preferred_lft 14396sec
    inet6 fe80::dc00:ff:fe76:38f3/64 scope link 
      valid_lft forever preferred_lft forever
cfadmin@yunohost-addapps-xl:~$ date && ip -6 addr show ens2
Thu 14 Nov 2024 12:45:08 PM UTC
2: ens2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    altname enp0s2
    inet6 2001:bc8:710:1644:dc00:ff:fe76:38f3/64 scope global dynamic mngtmpaddr noprefixroute 
      valid_lft 86400sec preferred_lft 14400sec
    inet6 fe80::dc00:ff:fe76:38f3/64 scope link 
      valid_lft forever preferred_lft forever
cfadmin@yunohost-addapps-xl:~$ date && ip -6 addr show ens2
Thu 14 Nov 2024 12:47:55 PM UTC
2: ens2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    altname enp0s2
    inet6 2001:bc8:710:1644:dc00:ff:fe76:38f3/64 scope global dynamic mngtmpaddr noprefixroute 
      valid_lft 86399sec preferred_lft 14399sec
    inet6 fe80::dc00:ff:fe76:38f3/64 scope link 
      valid_lft forever preferred_lft forever

Problem solved?

2024-11-13¶

12:30 - Info Scaleway pour résolution du problème de perte d'IP v6

Concerns

Resource - server - yunohost-addapps

J'ai reçu un retour de Scaleway vers 9:45 dans le ticket sur ce problème.

Je vérifie la version du package scaleway-ecosystem avec la commande dpkg -l | grep scaleway-ecosystem :

cfadmin@yunohost-addapps-xl:~$ dpkg -l | grep scaleway-ecosystem
ii  scaleway-ecosystem                    0.0.6-9~ubuntu20.04                                all          Collection of files, scripts and systemd units used to

Et, effectivement, la version installée est inférieure à 0.0.7-1~debian11 (version minimum demandée dans le ticket).

Je mets à jour le package avec ces commandes :

sudo apt-get update
sudo apt-get upgrade scaleway-ecosystem

Et je confirme que le package a maintenant une version supérieure à 0.0.7-1~debian11 avec dpkg -l | grep scaleway-ecosystem :

cfadmin@yunohost-addapps-xl:~$ dpkg -l | grep scaleway-ecosystem
ii  scaleway-ecosystem                    0.0.9-1~ubuntu20.04                                all          Collection of files, scripts and systemd units used to

12:45

Je redémarre yunohost-addapps, comme demandé dans le ticket, pour prendre en compte le nouveau package.

2024-11-12¶

20:20 - Redémarrage préventif de yunohost-addapps pour IPv6

Concerns

Resource - server - yunohost-addapps

Je redémarre yunohost-addapps de façon préventive avant qu'elle ne perde son IP v6.

Interruption de 2 minutes environ.

09:30 - Les honeypots de DEV ne fonctionnent pas

Vendredi, 2024-11-08, j'ai modifié le code python des honeypots pour changer les ACL passées à S3 quand ils envoient les logs avec put_object. Mais, après publication de mes modifications, j'ai deux problèmes :

Le honeypot SSH ne permet pas de se connecter avec un login/pwd
Le honeypot Web ne répond pas

Je commence par le honeypot web. J'utilise nuclei pour solliciter le honeypot web avec la commande ./nuclei -u http://dev1.computablefacts.io/ ou ./nuclei -u https://dev2.computablefacts.io/

Quelques remarques :

il faut attendre entre 10 et 15 minutes après la mise à jour du container Docker sur AWS pour que apache soit démarré (j'attends que le Load Balancer AWS trouve le container healthy et je génère les certificats SSL avec Let's Encrypt)
il faut attendre environ 10 minutes après la commande nuclei avant que les logs soient envoyés vers S3 (un cron tourne toutes les 5 minutes et il attend que le fichier de log apache date de plus de 5 minutes avant de le traiter)

J'ai démarré un honeypot web en local pour debugger. Depuis le local le fichier est bien envoyé vers les 2 buckets S3 alors que depuis le honeypot web de DEV, il n'est envoyé que dans le premier. Tous les paramètres / réglages des 2 S3 sont identiques vus de l'UI de AWS.

08:30 - Peu de place disque libre sur la machine de Postface

Concerns

Resource - server - postface01

Cywise m'avertit qu'il ne reste que 4G de place disque libre sur la machine postface01.

Je me connecte en SSH et je confirme que c'est bien le cas. La commande sudo docker system prune ne récupère que 2G. La commande sudo docker image prune --all en récupère 2 de plus.

Pourtant la commande sudo du -h -d 1 /var/lib/docker montre que 222G sur 234G sont utilisés par Docker. La majorité dans /var/lib/docker/overlay2 (221G).

Je vois que j'ai 25 "overlay2" qui dépasse le Go avec la commande sudo du -h -d 1 /var/lib/docker/overlay2 | grep G.

Résultat de la commande

twr_admin@postface:~$ sudo du -h -d 1 /var/lib/docker/overlay2 | grep G
8.0G    /var/lib/docker/overlay2/aea341fk5zi9rnzwq5n096jwh
7.6G    /var/lib/docker/overlay2/d1tvq1o82p0fg0p7hfka7su0h
7.6G    /var/lib/docker/overlay2/yf3e5k1b9qpgnkpp6nbqwpzjx
7.6G    /var/lib/docker/overlay2/6ifp1xq594x4t6cvhvrr4n98k
8.0G    /var/lib/docker/overlay2/jjnge6vkj2bew5u86gnlxh9vd
8.0G    /var/lib/docker/overlay2/b6xgwvock7wku2m0vpwd82mda
7.6G    /var/lib/docker/overlay2/iatijaa8j25fu1tsbxg7q2pah
8.0G    /var/lib/docker/overlay2/yaxblhqyrzl6tt88800nsyz8b
7.6G    /var/lib/docker/overlay2/ikd71442ieyu39kxx1yg07euh
7.6G    /var/lib/docker/overlay2/tsg1h1e1tc6iszkdp4lfnh2pm
7.7G    /var/lib/docker/overlay2/slzq531fx34pjgw84wakpzw8j
7.6G    /var/lib/docker/overlay2/4gedkgv8y9urw4odno2xn1ly0
7.6G    /var/lib/docker/overlay2/rrrx2dfrjm0e92mpc47p4ll59
7.6G    /var/lib/docker/overlay2/6dc9lpkwl3b970epdwr8brgf4
8.7G    /var/lib/docker/overlay2/1f26c1ef9303c35e9b685706fb4cfea2e5cf6f8ddc4be7278f7e19501bb9f2ba
7.6G    /var/lib/docker/overlay2/racjox7fgxl0dcyrnt4ryxe7s
9.7G    /var/lib/docker/overlay2/871aecca354699b35962fd6272958c45484b6f54527b28ed19eb0f4d9c932902
7.6G    /var/lib/docker/overlay2/m4zl76tysudpuqjluo5s2dyjh
1.3G    /var/lib/docker/overlay2/5da914678e9754ae870ffd6f52b21dc00f398b0c52babe2cbae5bdc0b347fb72
1.1G    /var/lib/docker/overlay2/530ce09ce6afbf425bbf9743e15768681fa04c06353b8768ed65d695b73e23da
7.6G    /var/lib/docker/overlay2/rtyipdfgmbvptemjm76c79zc8
7.6G    /var/lib/docker/overlay2/xdcj2vk9pw2zy9jzq23ih2356
7.6G    /var/lib/docker/overlay2/sp3ineibw6jpvpzgqi7ad0p73
7.6G    /var/lib/docker/overlay2/442n74wc4k6yj4qdyiqdsth8x
8.0G    /var/lib/docker/overlay2/kv723pww0gsvueif3wctk448y
221G    /var/lib/docker/overlay2

Je me suis décidé à faire un sudo docker system prune --all (j'ai toujours peur que cela supprime trop de chose) et je viens de gagner 200G environ. Dans le log de la commande, je lis Deleted build cache objects: donc je suppose que la place était prise par des étapes de build de l'image Docker gardées en cache.

09:15

Problème résolu (199G de libre sur 234G).

2024-11-11¶

20:30 - Redémarrage préventif de yunohost-addapps pour IPv6

Concerns

Resource - server - yunohost-addapps

Je redémarre yunohost-addapps de façon préventive avant qu'elle ne perde son IP v6.

Interruption de 2 minutes environ.

2024-11-10¶

20:30 - Redémarrage préventif de yunohost-addapps pour IPv6

Concerns

Resource - server - yunohost-addapps

Je redémarre yunohost-addapps de façon préventive avant qu'elle ne perde son IP v6.

Interruption de 2 minutes environ.

2024-11-09¶

20:30 - Redémarrage préventif de yunohost-addapps pour IPv6

Concerns

Resource - server - yunohost-addapps

Je redémarre yunohost-addapps de façon préventive avant qu'elle ne perde son IP v6.

Interruption de 2 minutes environ.

2024-11-08¶

20:30 - Redémarrage préventif de yunohost-addapps pour IPv6

Concerns

Resource - server - yunohost-addapps

Je redémarre yunohost-addapps de façon préventive avant qu'elle ne perde son IP v6.

Interruption de 2 minutes environ.

01:15 - La machine yunohost-addapps est indisponible

Concerns

Resource - server - yunohost-addapps

Interruption de 1h15 à 7h40 soit 6h25 de durée

Toutes les apps dont app.cywise.io indisponibles.

Cyrille et moi avons détecté le blocage de la machine vers 1h15. C'était au moment du démarrage des tâches planifiées de app.cywise.io "Daily" (démarrage à 00:00 UTC donc 01:00). Elle répondait très très lentement à mes commandes sur mon SSH donc nous avons pensé qu'elle était saturée et que, comme la veille, elle reviendrait à elle au bout d'une heure ou deux.

Mais elle était toujours indisponible ce matin vers 7h40.

07:40 Redémarrage de yunohost-addapps depuis la console Scaleway

La machine a bien redémarré et les applications sont à nouveau disponibles.

00:30 - Inventaire des instances Scaleway qui perdent leur IP v6

Suite à la perte de l'IPv6 de yunohost-addapps 24h après son redémarrage, je fais l'hypothèse que cela pourrait être dû au Security Group qui bloquerait le protocole SLAAC (basé sur ICMPv6) qui renouvelle l'IP v6.

Je fais donc l'inventaire de mes instances pour voir lesquelles ont le problème de la perte de l'IPv6 ou pas.

instance	Zone	Security group	IPv6 ?	IPv6 perdue ?
yunohost-addapps-xl	PAR1	SMTP	oui	oui
poc-ynh02-bis	PAR2	default	non	n/a
federa-demo-hermes	PAR2	SMTP	non	n/a
poc-ynh99	PAR2	SMTP	oui	oui
poc-ynh03	PAR2	default	oui	non
ynh-package-check	PAR2	default	oui	non
poc-ynh01	PAR2	default	oui	non
tower	PAR2	default	oui	non

Une seule autre instance a perdu son IPv6 (poc-ynh99) qui est dans un Security Group que j'ai créé pour lui autoriser l'envoi de mail par SMTP. Toutes les autres instances qui ont un IPv6 et qui sont dans le Security Group par défaut, n'ont pas perdu leur IPv6.

01:00 Je mets poc-ynh99 dans le Security Group par défaut pour voir si elle récupère son IPv6.

07:20 poc-ynh99 n'a pas récupéré son IPv6. Je la redémarre.

Elle a bien son IPv6 après redémarrage :

cfadmin@poc-ynh99:~$ date --rfc-3339=second && ip -6 addr show ens2
2024-11-08 06:23:51+00:00
2: ens2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    altname enp0s2
    inet6 2001:bc8:1210:4a7:dc00:ff:fe33:9817/64 scope global dynamic mngtmpaddr 
      valid_lft 86362sec preferred_lft 14362sec
    inet6 fe80::dc00:ff:fe33:9817/64 scope link 
      valid_lft forever preferred_lft forever

preferred_lft 14362sec indique que l'IPv6 devrait être renouvellée dans 4h environ.

2024-11-07¶

16:35 - Redémarrage préventif de yunohost-addapps pour IPv6

Concerns

Resource - server - yunohost-addapps

Je redémarre yunohost-addapps de façon préventive avant qu'elle ne perde son IP v6.

Interruption de 2 minutes environ.

08:10 - Fermeture du port LDAP sur yunohost-addapps

Concerns

Resource - server - yunohost-addapps

Nous avions ouvert le port LDAP de AddApps pour faire un POC avec Keycloak. Un IdP Keycloak qui fédérait les LDAP de 2 YunoHost.

Cywise a détecté ce LDAP accessible en anonyme donc je referme le port.

Connexion en SSH sur yunohost-addapps.

La commande sudo yunohost firewall list montre que le port 389 est bien ouvert. Je ferme le port avec la commande sudo yunohost firewall disallow Both 389.

Résultat de la commande

cfadmin@yunohost-addapps-xl:~$ sudo yunohost firewall disallow Both 389
Warning: Another YunoHost command is running right now, we are waiting for it to finish before running this one
Warning: Still waiting...
Warning: The other command just completed, now starting this command
Warning: Port 389 is already closed for IPv4 connections
Warning: Port 389 is already closed for IPv6 connections
Success! Firewall reloaded
opened_ports: 
  - 22
  - 53
  - 68
  - 80
  - 443
  - 784
  - 853
  - 5222
  - 5269
  - 5353

Docker a redémarré

La fermeture du port a déclenché la mise à jour du firewall YunoHost (un reload). Les 2 apps Cywise DEV et PROD avaient la commande non commentée du redémarrage de Docker. Donc 2 redémarrages du service Docker de suite.

Les commandes étaient non commentées car une mise à jour de l'application avec towerify deploy remet en place le hook d'origine.

2024-11-06¶

16:40 - Redémarrage préventif de yunohost-addapps pour IPv6

Concerns

Resource - server - yunohost-addapps

Je redémarre yunohost-addapps de façon préventive avant qu'elle ne perde son IP v6.

Interruption de 2 minutes environ.

2024-11-05¶

17:45 - ISTA - Erreur Jobs to Dataset - Erreur pour syndics-clients-avec-codes-communes-2/select.sh

Concerns

Resource - server - yunohost-ista-dev

Appel de Marlène juste après m'avoir envoyé un mail sur le sujet.

En regardant le log du job #137, on voit une erreur concernant jq.

Je génère un token API avec le compte de Matthieu (compte utilisé par Jenkins) et je lance le script en local :

./syndics-clients-avec-codes-communes-2/select.sh https://dev.ista.computablefacts.com **** ./download/syndics-clients-avec-codes-communes-2.jsonl https://dev.twr-api1.apps.dev-ista.computablefacts.com/

Bonne nouvelle : j'obtiens la même erreur que dans Jenkins (jq: error (at <stdin>:0): Cannot iterate over string ("Received e...)).

J'affiche les commandes du script (décommenter la ligne set -o xtrace) et je repère le curl qui provoque l'erreur. Je lance ce curl en local :

curl -s --no-progress-meter -X POST -H 'Content-Type: application/json' -d 
'{"jsonrpc": "2.0", "id": 1, "method": "execute-sql-query", "params": 
{"format": "arrays", "sql_query": 
"SELECT DISTINCT ID FROM tmp_syndics_clients_2_1 ORDER BY ID ASC LIMIT 0, 100", 
"invalidate_cache": true}}' 
'https://dev.ista.computablefacts.com/api/v2/public/json-rpc?api_token=****'
{"jsonrpc":"2.0","result":{"code":-32603,"message":"Internal error",
"data":"Received exception from server (version 23.3.22):\nCode: 60. 
DB::Exception: Received from clickhouse.apps.dev-ista.computablefacts.com:9440. 
DB::Exception: Table default.tmp_syndics_clients_2_1 doesn't exist. (UNKNOWN_TABLE)\n(query: SELECT DISTINCT ID FROM tmp_syndics_clients_2_1 ORDER BY ID ASC LIMIT 0, 100)"},"id":1}

Donc la table tmp_syndics_clients_2_1 n'existe pas... syndics_clients_2_1 est un concept primaire et devrait exister puisque Marlène a lancé le job syndics-clients-2 sur lequel le concept est basé...

Finalement, nous supprimons le cache du compte de Matthieu ce qui résout le problème.

L'erreur ne se reproduit pas quand nous lançons le job à nouveau et le job se termine avec succès 11 minutes plus tard.

18:10 - Problème résolu

16:30 - yunohost-addapps - Perte de l'IP v6

Concerns

Resource - server - yunohost-addapps

Interruption IPv6 du mardi 05/11 15h15 au mardi 05/11 16h40 soit 1h25

Toutes les machines qui remontent leurs infos avec l'IP v6 n'ont pas pu le faire donc nous avons perdu leur historique sur cette période.

Je n'arrive pas à publier ma doc de l'Infra (cette doc) sur AddApps et je me rends compte que la machine a, de nouveau, perdu son IP v6. J'étais déjà connecté en SSH dessus et la commande ip a me confirme que l'IP v6 n'est plus là. Puis je perds ma connexion SSH (ou elle devient très, très lente).

Je décide d'arrêter la VM. Puis je la démarre à nouveau.

Vers 16:45, je récupère mon SSH et ip a me confirme que l'IP v6 est de nouveau présente sur l'interface ens2.

Mais je me rends compte que Docker n'a pas redémarré :

cfadmin@yunohost-addapps-xl:~$ sudo systemctl status docker
● docker.service - Docker Application Container Engine
    Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
    Active: failed (Result: start-limit-hit) since Tue 2024-11-05 15:40:30 UTC; 6min ago
TriggeredBy: ● docker.socket
      Docs: https://docs.docker.com
    Process: 5736 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (cod>
  Main PID: 5736 (code=exited, status=0/SUCCESS)
        CPU: 3.117s

Nov 05 15:40:30 yunohost-addapps-xl systemd[1]: Failed to start Docker Application Container Engine.
Nov 05 15:40:33 yunohost-addapps-xl systemd[1]: docker.service: Start request repeated too quickly.
Nov 05 15:40:33 yunohost-addapps-xl systemd[1]: docker.service: Failed with result 'start-limit-hit'.
Nov 05 15:40:33 yunohost-addapps-xl systemd[1]: Failed to start Docker Application Container Engine.
Nov 05 15:40:37 yunohost-addapps-xl systemd[1]: docker.service: Start request repeated too quickly.
Nov 05 15:40:37 yunohost-addapps-xl systemd[1]: docker.service: Failed with result 'start-limit-hit'.
Nov 05 15:40:37 yunohost-addapps-xl systemd[1]: Failed to start Docker Application Container Engine.
Nov 05 15:40:39 yunohost-addapps-xl systemd[1]: docker.service: Start request repeated too quickly.
Nov 05 15:40:39 yunohost-addapps-xl systemd[1]: docker.service: Failed with result 'start-limit-hit'.
Nov 05 15:40:39 yunohost-addapps-xl systemd[1]: Failed to start Docker Application Container Engine.

Je le démarre à la main avec sudo systemctl start docker. Il démarre sans erreur.

16:50 - Situation rétablie

J'ai mis à jour le ticket Scaleway que j'avais ouvert hier.

Je vais éditer tous les hooks YunoHost pour le firewall (iptables) afin de commenter la ligne qui redémarre Docker. 14 hooks présents :

cfadmin@yunohost-addapps-xl:~$ sudo ls -alh /etc/yunohost/hooks.d/post_iptable_rules
total 64K
drwxr-xr-x 2 root root 4.0K Nov  4 16:09 .
drwx------ 4 root root 4.0K Nov  1  2023 ..
-rw-r--r-- 1 root root  303 Nov 17  2023 50-adversarymeter_dev
-rw-r--r-- 1 root root  552 Nov  4 16:07 50-cywise-ui_prod
-rw-r--r-- 1 root root  552 Apr  9  2024 50-infra-docs_dev
-rw-r--r-- 1 root root  552 Apr 22  2024 50-nlm_ingestor_ynh
-rw-r--r-- 1 root root  303 Jan 16  2024 50-poc-llm_dev
-rw-rw-rw- 1 root root  299 Nov  1  2023 50-portainer
-rw-r--r-- 1 root root  552 Sep 25 13:33 50-secrets-envvars_dev
-rw-r--r-- 1 root root  553 Oct  7 17:43 50-superset
-rw-r--r-- 1 root root  303 Jul 11 19:56 50-towerify-cli-install_dev
-rw-r--r-- 1 root root  552 Jul 11 19:41 50-towerify-cli-install_prod
-rw-r--r-- 1 root root  303 Jul 15 16:16 50-towerify-docs_dev
-rw-r--r-- 1 root root  552 Jul  4 07:50 50-towerify-docs_patrick2
-rw-r--r-- 1 root root  303 Jul 15 16:21 50-towerify-docs_prod
-rw-r--r-- 1 root root  303 Sep 18 10:27 50-towerify-ui_prod

J'ai trouvé et commenté systemctl restart docker.service dans 7 fichiers.

19:40

Je tente d'ouvrir le port pour le client DHCP (UDP 68) dans le firewall de YunoHost avec la commande sudo yunohost firewall allow UDP 68. Opération réussie :

cfadmin@yunohost-addapps-xl:~$ sudo yunohost firewall allow UDP 68 
Success! Firewall reloaded
opened_ports: 
  - 22
  - 53
  - 68
  - 80
  - 389
  - 443
  - 784
  - 853
  - 5222
  - 5269
  - 5353

Puis je tente le renouvellement de l'IP v6 avec sudo dhclient -6 ens2. J'ai attendu 25 minutes mais la commande ne m'a pas rendu la main alors je l'ai interrompue.

Je peux voir que l'adresse IP v6 expire dans 74828s et l'IP v4 dans 840s :

cfadmin@yunohost-addapps-xl:~$ ip addr show dev ens2
2: ens2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether de:00:00:76:38:f3 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    inet 51.15.140.162/32 brd 51.15.140.162 scope global dynamic ens2
      valid_lft 840sec preferred_lft 840sec
    inet6 2001:bc8:710:1644:dc00:ff:fe76:38f3/64 scope global dynamic mngtmpaddr 
      valid_lft 74828sec preferred_lft 2828sec
    inet6 fe80::dc00:ff:fe76:38f3/64 scope link 
      valid_lft forever preferred_lft forever

Ce qui est étrange, c'est que le DHCP pour l'IP v4 fonctionne alors que le DHCP pour l'IP v6 ne fonctionne pas...

J'ai mis à jour le ticket Scaleway avec ces dernières infos.

15:45 - Suppression de toutes les apps Flarum

Concerns

Resource - server - yunohost-addapps

Ces apps Flarum sont des forums que nous avions liées à AdversaryMeter (un Flarum par client). Maintenant que AdversaryMeter est intégré à Cywise, ils ne sont plus utilisés donc nous pouvons les supprimer.

Il y a 6 Flarum installés sur la machine yunohost-addapps :

https://team-11.forum.myapps.addapps.io/
https://team-11.dev-forum.myapps.addapps.io/
https://team-78.forum.myapps.addapps.io/
https://team-82.forum.myapps.addapps.io/
https://team-83.forum.myapps.addapps.io/
https://team-89.forum.myapps.addapps.io/

Je vais les supprimer depuis l'interface Admin de YunoHost. J'active l'API de l'interface Admin avec la commande sudo systemctl start yunohost-api.service.

Je supprime les 6 applications. Puis je supprime les 6 domaines correspondants.

J'ai également vérifié, avec phpMyAdmin, que les bases de données des 6 forums avaient bien été supprimées.

Je désactive l'API de l'interface Admin avec la commande sudo systemctl stop yunohost-api.service.

16:15 - Fin de la manip

14:45 - ISTA - Erreur Jobs to Dataset - Problème répertoire durable-xxx

Concerns

Appel de Marlène qui me relance pour 2 mails qu'elle a envoyés vers 12h.

En regardant le log du job #127, je vois que c'est le problème récurrent de suppression des répertoires temporaires durable-xxx.

Je me connecte en SSH sur yunohost-ista-dev. Il y a 8 répertoires durable-xxx dans le dossier tmp du job :

twr_admin@apps:~$ sudo ls -alh /var/lib/jenkins/jobs/jobs_to_dataset/workspace/jobs@tmp
total 40K
drwxr-xr-x 10 jenkins jenkins 4.0K Oct 19 07:14 .
drwxr-xr-x  3 jenkins jenkins 4.0K Oct 19 07:14 ..
drwxr-xr-x  2 root    root    4.0K Oct 16 15:23 durable-5af2de4e
drwxr-xr-x  2 root    root    4.0K Oct 16 15:05 durable-5f0b7ddc
drwxr-xr-x  2 root    root    4.0K Oct 11 18:02 durable-780b8b99
drwxr-xr-x  2 root    root    4.0K Sep 19 13:33 durable-8e280dbe
drwxr-xr-x  2 root    root    4.0K Sep 19 15:57 durable-a514f785
drwxr-xr-x  2 root    root    4.0K Oct 11 14:54 durable-b1e5fded
drwxr-xr-x  2 root    root    4.0K Sep 30 09:37 durable-eb309dbb
drwxr-xr-x  2 root    root    4.0K Sep 30 09:44 durable-f982209f

Je supprime tout avec la commande sudo rm -R /var/lib/jenkins/jobs/jobs_to_dataset/workspace/jobs@tmp/. Je relance le job (pour syndics-clients-2 comme précisé par Marlène) et il réussi.

15:05 - Problème résolu

14:20 - generic-rag DEV ne répond plus

Concerns

L'URL https://dev.generic-rag.dev02.towerify.io/docs#/ renvoie une erreur 502.

L'app est déployée sur yunohost-dev02. En voulant aller dans Portainer, j'ai une erreur 502 aussi...

J'ai accès au SSH. Pas de problème de place disque (800G de libre).

Avec la commande sudo systemctl status docker, je me rends compte que Docker est arrêté (depuis 22h, le 04/11 à 15h38). Les erreurs sont :

Nov 04 15:38:11 dev02.towerify.io systemd[1]: docker.service: Start request repeated too quickly.
Nov 04 15:38:11 dev02.towerify.io systemd[1]: docker.service: Failed with result 'start-limit-hit'.
Nov 04 15:38:11 dev02.towerify.io systemd[1]: Failed to start Docker Application Container Engine.
Nov 04 15:38:13 dev02.towerify.io systemd[1]: docker.service: Start request repeated too quickly.
Nov 04 15:38:13 dev02.towerify.io systemd[1]: docker.service: Failed with result 'start-limit-hit'.
Nov 04 15:38:13 dev02.towerify.io systemd[1]: Failed to start Docker Application Container Engine.

Certainement une mise à jour du firewall de YunoHost (yunohost firewall reload) qui a déclenché mes hooks qui contiennent des instructions pour redémarrer Docker. Plusieurs redémarrages de suite doivent provoquer cette erreur.

Je démarre Docker avec sudo systemctl status docker.

L'URL répond maintenant. Portainer aussi.

14:35 - Problème résolu

Impacts : coupure de toutes les apps "Docker" de DEV02 du 04/11 15h30 au 05/11 14h30 (21h).

2024-11-04¶

15:15 - Perte de l'IP v6 de yunohost-addapps - Redémarrage

Concerns

Resource - server - yunohost-addapps

Interruption IPv6 du vendredi 01/11 12h au lundi 04/11 15h15 soit 4 jours et 3h15

Toutes les machines qui remontent leurs infos avec l'IP v6 n'ont pas pu le faire donc nous avons perdu leur historique sur cette période.

Depuis que j'ai augmenté la taille de l'instance de yunohost-addapps, le 16/10 vers 12h, l'instance perd son IPv6 24h après avoir démarré.

10:50 - DEV02 n'est plus accessible

Concerns

Resource - server - yunohost-dev02

La machine yunohost-dev02 n'est plus accessible en SSH. Je la redémarre depuis le site de Scaleway.

Je récupère l'accès SSH.

10:50 - Problème résolu

Statping a envoyé plein d'alerte dans Slack concernant les pings qui sont tous rouges... Je me demande d'ailleurs si ce n'est pas Statping et ses 38 surveillances chaque minute qui finit par bloquer la machine...

12:10 - app.cywise.io n'est pas accessible pour certaines machines - Perte IP v6 yunohost-addapps

Concerns

Resource - server - yunohost-addapps

Dans l'UI de Cywise, certaines machines sont au rouge ce qui signifie que ces machines n'envoie pas d'information à Cywise de manière régulière comme ça devrait être le cas.

Cyrille a fait un test avec un ping app.towerify.io :

depuis poc-ynh99, le ping est envové à l'IP v4 et réussi
depuis poc-ynh01, le ping est envoyé à l'IP v6 et échoue

En SSH sur yunohost-addapps, avec ip a, je vois que l'IP v6 n'est plus présente sur l'interface ens2 :

2: ens2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether de:00:00:76:38:f3 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    inet 51.15.140.162/32 brd 51.15.140.162 scope global dynamic ens2
      valid_lft 707sec preferred_lft 707sec
    inet6 fe80::dc00:ff:fe76:38f3/64 scope link 
      valid_lft forever preferred_lft forever

Je recherche l'IP v6 dans les logs du journal et je trouve ça :

cfadmin@yunohost-addapps-xl:~$ sudo journalctl | grep "2001:bc8:710:1644:dc00:ff:fe76:38f3"
Oct 31 15:47:31 yunohost-addapps-xl cloud-init[568]: ci-info: |  ens2  | True | 2001:bc8:710:1644:dc00:ff:fe76:38f3/64 |        .        | global | de:00:00:76:38:f3 |
Oct 31 15:47:33 yunohost-addapps-xl ntpd[804]: Listen normally on 5 ens2 [2001:bc8:710:1644:dc00:ff:fe76:38f3]:123
Oct 31 19:20:24 yunohost-addapps-xl sshd[51897]: Connection from 2001:910:1400:115::12 port 56060 on 2001:bc8:710:1644:dc00:ff:fe76:38f3 port 22 rdomain ""
Oct 31 22:53:25 yunohost-addapps-xl sshd[77728]: Connection from 2a06:4880:1000::a port 52225 on 2001:bc8:710:1644:dc00:ff:fe76:38f3 port 22 rdomain ""
Oct 31 22:53:27 yunohost-addapps-xl sshd[77731]: Connection from 2a06:4880:1000::a port 43651 on 2001:bc8:710:1644:dc00:ff:fe76:38f3 port 22 rdomain ""
Nov 01 07:16:32 yunohost-addapps-xl sshd[151590]: Connection from 2001:910:1400:115::12 port 37248 on 2001:bc8:710:1644:dc00:ff:fe76:38f3 port 22 rdomain ""
Nov 01 15:47:32 yunohost-addapps-xl ntpd[804]: Deleting interface #5 ens2, 2001:bc8:710:1644:dc00:ff:fe76:38f3#123, interface stats: received=0, sent=0, dropped=0, active_time=86399 secs
Nov 04 12:50:40 yunohost-addapps-xl audit: EXECVE argc=2 a0="grep" a1="2001:bc8:710:1644:dc00:ff:fe76:38f3"

On voit l'attribution de l'IP v6 au démarrage à 16h47 (15h47 UTC) puis la perte de l'IP 24h plus tard signalée par ntpd.

C'est certainement le DHCP qui attribue l'IP v6 pour un bail de 24h et le renouvellement de ce bail qui échoue.

J'ai ouvert un ticket chez Scaleway.

2024-10-31¶

16:00 - Perte de l'IP v6 de yunohost-addapps - Redémarrage

Concerns

Resource - server - yunohost-addapps

Interruption IPv6 du jeudi 24/10 9h15 au jeudi 31/10 16h soit 5 jours et 22 heures

Toutes les machines qui remontent leurs infos avec l'IP v6 n'ont pas pu le faire donc nous avons perdu leur historique sur cette période.

Depuis que j'ai augmenté la taille de l'instance de yunohost-addapps, le 16/10 vers 12h, l'instance perd son IPv6 24h après avoir démarré.

2024-10-23¶

10:00 - Perte de l'IP v6 de yunohost-addapps - Redémarrage

Concerns

Resource - server - yunohost-addapps

Interruption IPv6 du jeudi 17/10 12h au mercredi 23/10 10h soit 5 jours et 22 heures

Toutes les machines qui remontent leurs infos avec l'IP v6 n'ont pas pu le faire donc nous avons perdu leur historique sur cette période.

Depuis que j'ai augmenté la taille de l'instance de yunohost-addapps, le 16/10 vers 12h, l'instance perd son IPv6 24h après avoir démarré.

2024-10-16¶

12:00 - Augmentation de taille d'instance pour yunohost-addapps

Concerns

Resource - server - yunohost-addapps

J'ai augmenté la taille de l'instance de yunohost-addapps, le 16/10 vers 12h.

Interruption de quelques minutes (entre 5 et 10).

TODO : remettre ici ma manip pour le faire (ou un lien vers ma manip).

2024-09-11¶

Honeypots pour tests Cyrille

Cyrille a ré-écrit le core de Adversary Meter dans l'application Towerify. Il lui reste à tester l'interaction avec les honeypots.

Il faudrait donc que je déploie des honeypots (avec 3 domaines nouveaux) et que les logs des honeypots soient envoyés dans le Bucket S3 de l'app Towerify dans le sous-dossier honeypots.

Après discussions, nous avons décidé : - de modifier le code pour envoyer les logs vers le Bucket de Towerify en plus du Bucket actuel - donc d'utiliser les instances existantes actuelles - à terme, les logs utilisés par sentinel.computablefacts.com ne seront plus utilisés (arrêt de Adversary Meter après son transfert vers Towerify) - d'utiliser les domaines existants sur le DEV pour faire les tests de Cyrille

J'ai fait les modifications dans le code sur la branche develop et j'ai poussé. Terraform a fait le déploiement sans erreur. Mais le job sur GitLab était en erreur (ça arrive à cause d'un problème de timing : le job se déclenche avant que les machines à mettre à jour ne soient prêtes...). J'ai donc relancé le job et il a réussi.

Les domaines des honeypots de DEV pour tester : - HTTP : dev1.computablefacts.io - HTTPS : dev2.computablefacts.io - SSH : devssh.computablefacts.io

Malgré quelques accès sur ces domaines, je ne vois pas de logs arriver (ni sur le Bucket de Towerify ni sur celui de AM).

J'ai transmis les domaines à Cyrille pour qu'il utilise l'outil de Pierre pour faire des accès "pirate" dessus.

Honeypots pour tests Cyrille

Cyrille a ré-écrit le core de Adversary Meter dans l'application Towerify. Il lui reste à tester l'interaction avec les honeypots.

Il faudrait donc que je déploie des honeypots (avec 3 domaines nouveaux) et que les logs des honeypots soient envoyés dans le Bucket S3 de l'app Towerify dans le sous-dossier honeypots.

Après discussions, nous avons décidé : - de modifier le code pour envoyer les logs vers le Bucket de Towerify en plus du Bucket actuel - donc d'utiliser les instances existantes actuelles - à terme, les logs utilisés par sentinel.computablefacts.com ne seront plus utilisés (arrêt de Adversary Meter après son transfert vers Towerify) - d'utiliser les domaines existants sur le DEV pour faire les tests de Cyrille

J'ai fait les modifications dans le code sur la branche develop et j'ai poussé. Terraform a fait le déploiement sans erreur. Mais le job sur GitLab était en erreur (ça arrive à cause d'un problème de timing : le job se déclenche avant que les machines à mettre à jour ne soient prêtes...). J'ai donc relancé le job et il a réussi.

Les domaines des honeypots de DEV pour tester : - HTTP : dev1.computablefacts.io - HTTPS : dev2.computablefacts.io - SSH : devssh.computablefacts.io

Malgré quelques accès sur ces domaines, je ne vois pas de logs arriver (ni sur le Bucket de Towerify ni sur celui de AM).

J'ai transmis les domaines à Cyrille pour qu'il utilise l'outil de Pierre pour faire des accès "pirate" dessus.

2024-07-05¶

17:00 - Décommissionnement des 3 machines de Sentinel API donc du cluster infra2

Concerns

Deprecated: Resource - cluster - infra2
Deprecated: Resource - server - sentinel-api-1
Deprecated: Resource - server - sentinel-api-2
Deprecated: Resource - server - sentinel-api-3
Deprecated: Resource - deployment - cf-sentinel-api-dev
Deprecated: Resource - deployment - cf-sentinel-api-staging
Deprecated: Resource - deployment - cf-sentinel-api-prod

J'ai planté les machines du cluster de Sentinel API en faisant une mise à jour apt-get update && apt-get upgrade pour tenter de corriger des erreurs.

Comme j'avais préparé la machine yunohost-sentinel-api avec la PROD, nous avons décidé de basculer sur l'API de cette nouvelle machine et, donc, de décommissionner les 3 machines de l'ancien cluster.

Tous les é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¶

Lur Berri Datalake UI DEV¶

MySQL database for Lur Berri cf-ui DEV¶

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¶

2025-06-20¶

Installation de Superset sur `yunohost-cywise`¶