Active servers¶
Summary¶
| Name | CPU | Memory | Disks | Description |
|---|---|---|---|---|
| angardia-ai | 24 | 192G | 2 x 1 To SSD | Machine YunoHost pour Angardia |
| poc-ynh01 | 3 | 4G | 50 GB | Machine pour tester YunoHost |
| poc-ynh99 | 3 | 4G | 40 GB | Machine pour tester YunoHost |
| postface01 | 8 | 16G | 250G | Machine YunoHost pour Postface |
| s001 | 12 | 64G | 2 x 1 To SSD | Manager du cluster swarm01 |
| s004 | 8 | 96G | 4 x 12 To HDD | Noeud du cluster swarm01 |
| s005 | 24 | 192G | 2 x 1 To SSD | Noeud du cluster swarm01 |
| s008 | 24 | 192G | 2 x 1 To SSD | Noeud du cluster swarm01 |
| tower | 2 | 2G | 20 GB | Machine avec ansible pour déployer sur le cluster swarm01 (et autres) |
| ynh-package-check | 3 | 4G | 30 GB | Machine pour vérifier les packages YunoHost avec leur outil |
| yunohost-addapps | 8 | 32G | 260 GB | Machine YunoHost pour AddApps |
| yunohost-cywise | 24 | 192G | 2 x 1 To SSD | Serveur pour les applications Cywise de ComputableFacts |
| yunohost-dev02 | 12 | 64G | 2 x 1 To SSD | Serveur de DEV pour ComputableFacts |
| yunohost-ista-dev | 24 | 192G | 2 x 1 To SSD | Machine YunoHost pour Ista DEV |
| yunohost-ista-prod | 24 | 192G | 2 x 1 To SSD | Machine YunoHost pour Ista PROD |
| yunohost-josiane | 8 | 96G | 4 x 12 To HDD | Serveur de stockage pour ComputableFacts |
| Name | IP v4 | IP v6 |
|---|---|---|
| angardia-ai | 51.159.101.88 | ??? |
| poc-ynh01 | 51.159.134.2 | 2001:bc8:1210:4a6:dc00:ff:fe23:7f41 |
| poc-ynh99 | 51.159.130.244 | 2001:bc8:1210:4a7:dc00:ff:fe23:7f45 |
| postface01 | 51.15.25.123 | None |
| s001 | 51.159.100.42 | 2001:bc8:1201:14:2e59:e5ff:fe3a:aa3c |
| s004 | 51.159.101.150 | 2001:bc8:1201:2a:b283:feff:fee3:d3fd |
| s005 | 51.159.101.11 | 2001:bc8:1201:25:a65d:36ff:fefc:cdc0 |
| s008 | 51.159.214.44 | 2001:bc8:1201:61e:569f:35ff:fe1f:3dc |
| tower | 51.159.174.4 | 2001:bc8:1210:4ad:dc00:ff:fe23:7fb7 |
| ynh-package-check | 51.159.145.44 | 2001:bc8:1210:4ab:dc00:ff:fe23:7fa7 |
| yunohost-addapps | 51.15.140.162 | 2001:bc8:710:1644:dc00:ff:fe81:67db |
| yunohost-cywise | 51.159.100.198 | 2001:bc8:1201:38:46a8:42ff:fe18:d621 |
| yunohost-dev02 | 62.210.145.142 | 2001:bc8:701:40d:ae16:2dff:fea6:4980 |
| yunohost-ista-dev | 62.210.90.116 | 2001:bc8:701:19:46a8:42ff:fe18:eb25 |
| yunohost-ista-prod | 51.159.221.199 | 2001:bc8:1201:63a:1618:77ff:fe46:e4fc |
| yunohost-josiane | 62.210.89.37 | 2001:bc8:701 46a8:42ff:fe0e:97a3 |
angardia-ai¶
[Système : angardia] [Lifecycle : production]
Machine YunoHost pour Angardia
| CPU | Memory | Disks | IP v4 | IP v6 |
|---|---|---|---|---|
| 24 | 192G | 2 x 1 To SSD | 51.159.101.88 | ??? |
Events¶
2025-09-17 - Tunnel SSH pour accès à la base MySQL
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 - Script pour nettoyer les interfaces VXLAN orphelines
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-07-31 - Angardia DEV - error creating vxlan interface file exists
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-16 - Backups des bases de données MariaDB du YunoHost de Angardia AI
Comme mes backups sur yunohost-addapps et yunohost-cywise fonctionnent bien,
je les mets en place également sur la machine angardia-ai.
2025-07-08 - Accès tunnel SSH pour Angardia
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
2025-04-25 - Plus de mémoire pour MariaDB
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
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
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>
/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-02-05 - Déploiement du serveur Angardia AI avec Cywise (suite)
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=falseThis 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
sudo systemctl reload nginx.service
sudo systemctl restart jenkins.service
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"
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>";
?>
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
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
sudo yunohost app ssowatconf
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-01-31 - Déploiement du serveur Angardia AI avec Cywise
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'.
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.
Labels¶
-
supplier: scaleway
-
model: EM-B112X-SSD
-
ssh_port: 22
Dependencies¶
poc-ynh01¶
[Système : None] [Lifecycle : experimental]
Machine pour tester YunoHost
| CPU | Memory | Disks | IP v4 | IP v6 |
|---|---|---|---|---|
| 3 | 4G | 50 GB | 51.159.134.2 | 2001:bc8:1210:4a6:dc00:ff:fe23:7f41 |
Labels¶
-
supplier: scaleway
-
model: DEV1-M
-
dns_public: e028bf78-8986-476f-b0fc-8c613daf1c70.pub.instances.scw.cloud
-
ssh_port: 22
-
ssh_user: cfadmin
Links¶
poc-ynh99¶
[Système : None] [Lifecycle : experimental]
Machine pour tester YunoHost
| CPU | Memory | Disks | IP v4 | IP v6 |
|---|---|---|---|---|
| 3 | 4G | 40 GB | 51.159.130.244 | 2001:bc8:1210:4a7:dc00:ff:fe23:7f45 |
Events¶
2024-11-14 - 13:50 - Perte de l'IPv6 pour 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).
Labels¶
-
supplier: scaleway
-
model: DEV1-M
-
dns_public: 3249dd53-38b5-4231-8ccc-c35d306c697b.pub.instances.scw.cloud
-
ssh_port: 22
-
ssh_user: cfadmin
Links¶
postface01¶
[Système : postface] [Lifecycle : production]
Machine YunoHost pour Postface
| CPU | Memory | Disks | IP v4 | IP v6 |
|---|---|---|---|---|
| 8 | 16G | 250G | 51.15.25.123 | None |
Events¶
2025-09-12 - Script pour nettoyer les interfaces VXLAN orphelines
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-07-17 - Backups des bases de données MariaDB du YunoHost de Postface
Comme mes backups sur yunohost-addapps et yunohost-cywise fonctionnent bien,
je les mets en place également sur la machine postface01.
2025-02-21 - Problème de place disque sur 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
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)
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-01-14 - 17:00 - Logo Cywise pour le login YunoHost sur 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).
2025-01-07 - 09:00 - Problème de publication avec Towerify CLI suite à la mise à jour de Jenkins
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:35 - Installation de cf_custom sur Postface
Fait en utilisant l'UI Admin de YunoHost, activée pour l'occasion.
Choix du thème ComputableFacts à l'installation. Affiche le logo Towerify.
2025-01-06 - 12:40 - Mise à jour Jenkins sur Postface
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.
2025-01-06 - Ajout d'une surveillance Freshping pour l'application de Postface
La surveillance Freshping : https://computablefacts.freshping.io/reports?check_id=1096025. L'URL de l'application surveillée : https://www.postface.towerify.io/login.
2025-01-06 - 12:00 - Mise à jour YunoHost sur Postface
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.
2025-01-06 - 11:55 - Changement du mot de passe de twr_admin sur Postface
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>.
2024-11-12 - 08:30 - Peu de place disque libre sur la machine de Postface
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).
Labels¶
-
supplier: scaleway
-
model: Start-2-M-SSD
-
compute: dedibox
-
ssh_port: 22
Links¶
Dependencies¶
s001¶
[Système : None] [Lifecycle : production]
Manager du cluster swarm01
| CPU | Memory | Disks | IP v4 | IP v6 |
|---|---|---|---|---|
| 12 | 64G | 2 x 1 To SSD | 51.159.100.42 | 2001:bc8:1201:14:2e59:e5ff:fe3a:aa3c |
Labels¶
-
supplier: scaleway
-
model: EM-A410X-SSD
-
ssh_port: 22178
-
ssh_user: ansible
-
compute: elastic-metal
Links¶
Dependencies¶
s004¶
[Système : None] [Lifecycle : production]
Noeud du cluster swarm01
| CPU | Memory | Disks | IP v4 | IP v6 |
|---|---|---|---|---|
| 8 | 96G | 4 x 12 To HDD | 51.159.101.150 | 2001:bc8:1201:2a:b283:feff:fee3:d3fd |
Labels¶
-
supplier: scaleway
-
model: EM-L110X-SATA
-
ssh_port: 22178
-
ssh_user: ansible
-
compute: elastic-metal
Links¶
Dependencies¶
s005¶
[Système : None] [Lifecycle : production]
Noeud du cluster swarm01
| CPU | Memory | Disks | IP v4 | IP v6 |
|---|---|---|---|---|
| 24 | 192G | 2 x 1 To SSD | 51.159.101.11 | 2001:bc8:1201:25:a65d:36ff:fefc:cdc0 |
Events¶
2024-11-19 - Déplacement de notre Jenkins et de celui de Lur Berri vers s005
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.
Labels¶
-
supplier: scaleway
-
model: EM-B112X-SSD
-
ssh_port: 22178
-
ssh_user: ansible
-
compute: elastic-metal
Links¶
Dependencies¶
s008¶
[Système : None] [Lifecycle : production]
Noeud du cluster swarm01
| CPU | Memory | Disks | IP v4 | IP v6 |
|---|---|---|---|---|
| 24 | 192G | 2 x 1 To SSD | 51.159.214.44 | 2001:bc8:1201:61e:569f:35ff:fe1f:3dc |
Labels¶
-
supplier: scaleway
-
model: EM-B112X-SSD
-
ssh_port: 22178
-
ssh_user: ansible
-
compute: elastic-metal
Links¶
Dependencies¶
tower¶
[Système : None] [Lifecycle : production]
Machine avec ansible pour déployer sur le cluster swarm01 (et autres)
| CPU | Memory | Disks | IP v4 | IP v6 |
|---|---|---|---|---|
| 2 | 2G | 20 GB | 51.159.174.4 | 2001:bc8:1210:4ad:dc00:ff:fe23:7fb7 |
Labels¶
-
supplier: scaleway
-
model: DEV1-S
-
dns_public: d2466545-9327-480f-b78c-428f5f3e98c4.pub.instances.scw.cloud
-
ssh_port: 22
-
ssh_user: ansible
Links¶
ynh-package-check¶
[Système : None] [Lifecycle : experimental]
Machine pour vérifier les packages YunoHost avec leur outil
| CPU | Memory | Disks | IP v4 | IP v6 |
|---|---|---|---|---|
| 3 | 4G | 30 GB | 51.159.145.44 | 2001:bc8:1210:4ab:dc00:ff:fe23:7fa7 |
Labels¶
-
supplier: scaleway
-
model: DEV1-M
-
dns_public: bfb592d0-041b-4c1b-9cc4-10ced488f40b.pub.instances.scw.cloud
-
ssh_port: 22
-
ssh_user: root
Links¶
yunohost-addapps¶
[Système : None] [Lifecycle : production]
Machine YunoHost pour AddApps
| CPU | Memory | Disks | IP v4 | IP v6 |
|---|---|---|---|---|
| 8 | 32G | 260 GB | 51.15.140.162 | 2001:bc8:710:1644:dc00:ff:fe81:67db |
Events¶
2025-09-25 - AddApps - Arrêt de 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.
2025-09-25 - AddApps - Déplacement des redirections
Je continue le déplacement des applications déployées sur yunohost-addapps
vers yunohost-cywise.
Il reste 2 redirections sur addapps :
- https://sentinel.computablefacts.com/ vers https://app.cywise.io/
- https://app.towerify.io/ vers https://app.cywise.io/
J'ai supprimé les applications YunoHost qui faisaient ces redirections et je vais les faire directement dans Gandi.
2025-09-25 - AddApps - Déplacement de site pour installer Towerify CLI
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
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
2025-09-25 - AddApps - Déplacement de la doc de l'infra
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
docs.infra 1800 IN A 51.159.100.198
docs.infra 1800 IN AAAA 2001:bc8:1201:38:46a8:42ff:fe18:d621
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/.
2025-09-25 - AddApps - Déplacement de la doc de Towerify
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-07-10 - Backups des bases de données MariaDB
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-06-06 - 14:00 - Alertes Freshping pour les applications de AddApps (suite et fin)
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
2025-06-06 - 09:00 - Alertes Freshping pour les applications de AddApps
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
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-05-27 - 09:05 - Augmentation de la place disque de 80Go
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.
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-19 - 22:20 - Augmentation de la place disque de 50Go
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.
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
2025-05-19 - 16:35 - Interruption de service pour les applications de AddApps
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.
2025-05-07 - 09:00 - Réglage MariaDB pour place disque
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.
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
2025-03-03 - Redirection de sentinel.computablefacts.com vers app.cywise.io
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-18 - 11:00 - Beaucoup de place disque consommée
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
log_bin = 0 # Désactiver le log binaire si pas de réplication
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-01-14 - 20:30 - Compression de la table ynh_osquery de cywise_ui_prod
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.
2025-01-14 - Mise à jour des pages de login de YunoHost pour avoir le logo de Cywise
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.
2025-01-14 - Augmentation de la place disque de 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
2025-01-07 - 09:00 - Problème de publication avec Towerify CLI suite à la mise à jour de Jenkins
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
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.
2025-01-03 - 18:25 - Mise à jour phpMyAdmin sur yunohost-addapps
Fait en utilisant l'UI Admin de YunoHost, activée pour l'occasion.
Passage à la version 5.2.1.
2025-01-03 - 17:20 - Mise à jour YunoHost sur 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-12 - 17:40 - Limiter la taille des logs de chaque container
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.
2024-12-12 - 11:00 - Limiter la taille des logs de chaque container
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
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
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-26 - 23:15 - Perte de 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
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
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-18 - 11:30 - Perte de l'IPv4 de yunohost-addapps - remarque intéressante
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.
2024-11-18 - 01:35 - Perte de l'IPv4 de 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
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à
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 - 12:45 - Perte de l'IPv6 de yunohost-addapps à nouveau malgré la mise à jour du package scaleway-ecosystem
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
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
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
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
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-11 - 20:30 - Redémarrage préventif de yunohost-addapps pour IPv6
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
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
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
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 - 01:15 - La machine yunohost-addapps est indisponible
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.
2024-11-07 - 16:35 - Redémarrage préventif de yunohost-addapps pour IPv6
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-07 - 08:10 - Fermeture du port LDAP sur 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
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 - 16:30 - yunohost-addapps - Perte de l'IP v6
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.
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
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
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.
2024-11-05 - 15:45 - Suppression de toutes les apps Flarum
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
2024-11-04 - 15:15 - Perte de l'IP v6 de yunohost-addapps - Redémarrage
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é.
2024-11-04 - 12:10 - app.cywise.io n'est pas accessible pour certaines machines - Perte IP v6 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
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"
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
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
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
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).
Labels¶
-
supplier: scaleway
-
model: PRO2-S
-
dns_public: 8c95b943-f7d2-4444-992f-0906b3717482.pub.instances.scw.cloud
-
ssh_port: 22
-
ssh_user: cfadmin
Links¶
Dependencies¶
-
Deprecated: Resource - deployment - dev-towerify-ui
-
Deprecated: Resource - deployment - prod-towerify-ui
yunohost-cywise¶
[Système : None] [Lifecycle : production]
Serveur pour les applications Cywise de ComputableFacts
| CPU | Memory | Disks | IP v4 | IP v6 |
|---|---|---|---|---|
| 24 | 192G | 2 x 1 To SSD | 51.159.100.198 | 2001:bc8:1201:38:46a8:42ff:fe18:d621 |
Events¶
2025-11-20 - 10:00 - Problème d'accès à Portainer sur yunohost-cywise - again
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
2025-11-20 - 10:45 - Erreur à la publication de Cywise PROD sur yunohost-cywise - Docker version
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.
2025-11-20 - 14:00 - Plantage apt-get update sur yunohost-cywise dû à Yarn - Résolu
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
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
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.
2025-11-18 - 09:30 - Cywise PROD - Plus d'envoi des mails avec les rapports d'audit.
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.
2025-11-18 - 14:00 - Plantage apt-get update sur yunohost-cywise dû à Yarn
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
2025-11-18 - 14:00 - Plantage apt-get update sur yunohost-cywise dû à MariaDB Tools - Résolu
J'ai décommenté la ligne de la repo "Tools" de MariaDB dans
2025-11-18 - 14:15 - Retour à Docker 29.0.0 sur 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
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).
2025-11-17 - 13:00 - Problème de certificat SSL pour www.cywise.io
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
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-09-25 - AddApps - Déplacement des redirections
Je continue le déplacement des applications déployées sur yunohost-addapps
vers yunohost-cywise.
Il reste 2 redirections sur addapps :
- https://sentinel.computablefacts.com/ vers https://app.cywise.io/
- https://app.towerify.io/ vers https://app.cywise.io/
J'ai supprimé les applications YunoHost qui faisaient ces redirections et je vais les faire directement dans Gandi.
2025-09-25 - AddApps - Déplacement de site pour installer Towerify CLI
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
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
2025-09-25 - AddApps - Déplacement de la doc de l'infra
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
docs.infra 1800 IN A 51.159.100.198
docs.infra 1800 IN AAAA 2001:bc8:1201:38:46a8:42ff:fe18:d621
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/.
2025-09-25 - AddApps - Déplacement de la doc de Towerify
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-12 - MariaDB de yunohost-cywise ne répond plus
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
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.
2025-09-12 - Script pour nettoyer les interfaces VXLAN orphelines
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
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).
2025-09-11 - Déplacement des Performa de yunohost-addapps vers yunohost-cywise
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/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
2025-09-04 - Cywise PROD - error creating vxlan interface file exists
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-07-30 - Cywise PROD ng - error creating vxlan interface file exists
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-16 - Plus de mémoire pour MariaDB
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-11 - Upgrade MariaDB from 10.11 to 11.8
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
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
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
.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-02 - Déploiement du serveur yunohost-cywise depuis Cywise (suite)
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
sudo yunohost app ssowatconf
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/
2025-07-02 - Déploiement du serveur yunohost-cywise depuis 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-cywiseip_address:51.159.100.198ssh_username:twr_adminuser_id: 17is_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.
Labels¶
-
supplier: scaleway
-
model: EM-B112X-SSD
-
ssh_port: 22
-
ssh_user: twr_admin
-
compute: elastic-metal
Links¶
Dependencies¶
yunohost-dev02¶
[Système : None] [Lifecycle : production]
Serveur de DEV pour ComputableFacts
| CPU | Memory | Disks | IP v4 | IP v6 |
|---|---|---|---|---|
| 12 | 64G | 2 x 1 To SSD | 62.210.145.142 | 2001:bc8:701:40d:ae16:2dff:fea6:4980 |
Events¶
2025-09-12 - Script pour nettoyer les interfaces VXLAN orphelines
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-09 - Generic RAG STAGING - error creating vxlan interface file exists
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-02-12 - 10:00 - Docker arrêté sur 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.
2025-01-14 - Mise à jour des pages de login de YunoHost pour avoir le logo de Cywise
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.
2025-01-07 - 09:00 - Problème de publication avec Towerify CLI suite à la mise à jour de Jenkins
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-03 - 19:10 - Installation de cf_custom sur 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.
2025-01-03 - 18:40 - Mise à jour Jenkins sur 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.
2025-01-03 - 18:30 - Mise à jour YunoHost sur 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.
2024-11-05 - 14:20 - generic-rag DEV ne répond plus
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.
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 - 10:50 - DEV02 n'est plus accessible
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...
Labels¶
-
supplier: scaleway
-
model: EM-A410X-SSD
-
ssh_port: 22
-
ssh_user: twr_admin
-
compute: elastic-metal
Links¶
Dependencies¶
yunohost-ista-dev¶
[Système : ista] [Lifecycle : production]
Machine YunoHost pour Ista DEV
| CPU | Memory | Disks | IP v4 | IP v6 |
|---|---|---|---|---|
| 24 | 192G | 2 x 1 To SSD | 62.210.90.116 | 2001:bc8:701:19:46a8:42ff:fe18:eb25 |
Events¶
2025-09-12 - Script pour nettoyer les interfaces VXLAN orphelines
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-08-20 - ISTA DEV - Certificats SSL expirés
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.
2025-07-15 - Backups des bases de données MariaDB des YunoHost d'ISTA
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.
2025-05-20 - 09:00 - ISTA DEV - Redémarrage régulier de Clickhouse pour prise en compte du certificat LE
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
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
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
2025-04-23 - Mot de passe de Matthieu non propagé sur yunohost-ista-dev
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-08 - Problème d'intégration de données par Marlène d'Ista
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-03-27 - 15:15 - Erreur 500 sur ISTA DEV et ISTA PROD
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-02-04 - 14:20 - ISTA - Erreur Jobs to Dataset - Problème répertoire durable-xxx
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
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-14 - 17:25 - Mise à jour de Portainer 2.21.5 sur 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.
2025-01-14 - 17:15 - Logo Cywise pour le login YunoHost sur 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).
2024-11-05 - 17:45 - ISTA - Erreur Jobs to Dataset - Erreur pour syndics-clients-avec-codes-communes-2/select.sh
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/
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}
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
2024-11-05 - 14:45 - ISTA - Erreur Jobs to Dataset - Problème répertoire durable-xxx
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
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
TODOs¶
- Remettre en place la conf spécifique de Jupyter Lab (notament client_max_body_size 100m)
Labels¶
-
supplier: scaleway
-
model: EM-B112X-SSD
-
ssh_port: 22
Links¶
Dependencies¶
yunohost-ista-prod¶
[Système : ista] [Lifecycle : production]
Machine YunoHost pour Ista PROD
| CPU | Memory | Disks | IP v4 | IP v6 |
|---|---|---|---|---|
| 24 | 192G | 2 x 1 To SSD | 51.159.221.199 | 2001:bc8:1201:63a:1618:77ff:fe46:e4fc |
Events¶
2025-09-12 - Script pour nettoyer les interfaces VXLAN orphelines
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 - Datalake ISTA PROD - error creating vxlan interface file exists
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-08-20 - ISTA PROD - Certificats SSL expirés
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-15 - Désinstallation de Restic sur yunohost-ista-prod
Maintenant que je backupe yunohost-ista-prod avec mon nouveau système,
j'ai désinstallé Restic.
2025-07-15 - Backups des bases de données MariaDB des YunoHost d'ISTA
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.
2025-05-20 - 09:25 - ISTA PROD - Redémarrage régulier de Clickhouse pour prise en compte du certificat LE
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
2025-04-23 - Mot de passe de Matthieu non propagé sur yunohost-ista-dev
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-03-27 - 15:15 - Erreur 500 sur ISTA DEV et ISTA PROD
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-02-25 - Mot de passe de Marlène non propagé sur yunohost-ista-prod
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-prodavec une commandeyunohost 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-01-14 - 17:30 - Logo Cywise pour le login YunoHost sur 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).
TODOs¶
- Remettre en place la conf spécifique de Jupyter Lab (notament client_max_body_size 100m)
Labels¶
-
supplier: scaleway
-
model: EM-B112X-SSD
-
ssh_port: 22
Links¶
Dependencies¶
yunohost-josiane¶
[Système : None] [Lifecycle : production]
Serveur de stockage pour ComputableFacts
| CPU | Memory | Disks | IP v4 | IP v6 |
|---|---|---|---|---|
| 8 | 96G | 4 x 12 To HDD | 62.210.89.37 | 2001:bc8:70146a8:42ff:fe0e:97a3 |
Events¶
2025-04-07 - Création d'une repo pour le code de 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
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-07 - Installation de YunoHost sur yunohost-josiane
J'ai installé YunoHost sur yunohost-josiane depuis app.cywise.io.
Labels¶
-
supplier: scaleway
-
model: EM-L110X-SATA
-
ssh_port: 22
-
ssh_user: twr_admin
-
compute: elastic-metal