Active deployments¶
-
manual (1)
-
stack (42)
-
yunohost (24)
api1_dev¶
[Système : ista] [Lifecycle : dev] [Subtype : yunohost]
Ista module api1 de DEV
Links¶
Dependencies¶
api1_prod¶
[Système : ista] [Lifecycle : production] [Subtype : yunohost]
Ista module api1 de PROD
Links¶
Dependencies¶
api1_staging¶
[Système : ista] [Lifecycle : staging] [Subtype : yunohost]
Ista module api1 de STAGING
Details¶
2023-12-26 : ce déploiement n'existe pas encore. Il existera quand Ista poussera la branche release/x.x.x vers
la repo au moment de faire une MEP.
Links¶
Dependencies¶
c4p-demo¶
[Système : None] [Lifecycle : experimental] [Subtype : stack]
Site de C4P publié rapidement pour démontrer notre capacité à le faire
Links¶
Dependencies¶
cf-ynh-apps¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Catalogue d'apps YunoHost de ComputableFacts
TODOs¶
- Ajouter la repo qui contient le catalogue et un lien vers la doc pour le mettre à jour
Links¶
Dependencies¶
ciblage-commercial_dev¶
[Système : ista] [Lifecycle : dev] [Subtype : yunohost]
Ista module Ciblage Commercial de DEV
Links¶
Dependencies¶
ciblage-commercial_prod¶
[Système : ista] [Lifecycle : production] [Subtype : yunohost]
Ista module Ciblage Commercial de PROD
Events¶
2025-01-07 - Données erronées sur le Datalake de PROD Ista qui impactent le module Ciblage Commercial
Voir le ticket #8738.
Le plus problable : quand j'ai déplacé le dataset de PROD d'Ista, j'ai déposé seulement les derniers fichiers du dataset conso-gaz. Le premier fichier ne contenait que 10 colonnes au lieu des 27 dans les autres. Le concept créé ne contenait pas les colonnes attendues donc cela provoquait l'erreur dans l'UI.
Pourquoi l'ancienne PROD fonctionnait : certainement car la création du concept avait été fait après le dépôt d'un ou plusieurs fichiers corrects (avec les 27 colonnes). Déposer le fichier erroné n'avait alors pas eu d'impact.
Links¶
Dependencies¶
ciblage-commercial_staging¶
[Système : ista] [Lifecycle : staging] [Subtype : yunohost]
Ista module Ciblage Commercial de STAGING
Details¶
2023-12-26 : ce déploiement n'existe pas encore. Il existera quand Ista poussera la branche release/x.x.x vers
la repo au moment de faire une MEP.
Links¶
Dependencies¶
common-cve-search¶
[Système : None] [Lifecycle : production] [Subtype : stack]
CVE Search utilisé par AdversaryMeter (ex Sentinel)
Links¶
Dependencies¶
cywise-ui_dev¶
[Système : cywise] [Lifecycle : dev] [Subtype : yunohost]
Cywise UI DEV
Events¶
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-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.
Links¶
Dependencies¶
cywise-ui_prod¶
[Système : cywise] [Lifecycle : production] [Subtype : yunohost]
Cywise UI PROD
Events¶
2025-09-19 - Cywise - Intégration Entra ID pour Hermès
Hermès migre de ADFS vers Entra ID.
Je vais créé un nouveau tenant, donc de nouvelles metadata, puis régler l'intégration
pour tester avec le suffixe .test.
Voici le plan décidé après le point de ce jour, vendredi 19 à 14h30:
- Echange de nos metadata dès maintenant
- Je mets en place la nouvelle intégration Entra ID dans l'après-midi (en phase de test)
- Hermès (Amine et Nicolas) teste le bon fonctionnement
- Si tout va bien, basculement en PROD mardi 23 prochain 10h
- Si ça coince, séance de debug lundi 22
Je crée un nouveau tenant SAML pour Hermès avec les informations contenues dans les metadata de leur Entra ID : https://login.microsoftonline.com/e4a52391-cb73-4feb-b3f5-aec2ef5593bb/federationmetadata/2007-06/federationmetadata.xml?appid=120712e9-02b4-405d-a794-558423b56e47
Sur le serveur, dans le container de Cywise PROD app, je fais la commande :
php artisan saml2:create-tenant \
--key=hermesentra \
--entityId=https://sts.windows.net/e4a52391-cb73-4feb-b3f5-aec2ef5593bb/ \
--loginUrl=https://login.microsoftonline.com/e4a52391-cb73-4feb-b3f5-aec2ef5593bb/saml2 \
--logoutUrl=https://login.microsoftonline.com/e4a52391-cb73-4feb-b3f5-aec2ef5593bb/saml2 \
--x509cert="MIIC8DCCAdigAwIBAgIQYDQE1k6C8pNAqop25/BtQDANBgkqhkiG9w0BAQsFADA0MTIwMAYDVQQDEylNaWNyb3NvZnQgQXp1cmUgRmVkZXJhdGVkIFNTTyBDZXJ0aWZpY2F0ZTAeFw0yNTA5MTkxMjE4NDVaFw0yNzA5MTkxMjE4NDJaMDQxMjAwBgNVBAMTKU1pY3Jvc29mdCBBenVyZSBGZWRlcmF0ZWQgU1NPIENlcnRpZmljYXRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy3JrWBKF+cjIyOGK3ckP9G4kCNaRVei1Km6R3F1pXJjD1Hkh8OzIjpuXbj2scy6B38B3QVUBoJQNr24s7egFhyxCn//KuQXah+Y39ZrcUIp3laA4y2rClj9EQZ+VUSt0AGFAP01YugNMfb7iTezIbtRZKJXz2roEBpoziF1Z+7CCL+G5gbeiPQXVP47OeXwax+syJvu9gG4nodG2PtfwqxGqJDD5ro2Qq04lDaYYda911qHuj7PPunimIVgflC0HudS7RLRXZ9E2KPlBDYG61aYXe63QS+XZ9IGxQxYUScNXZzvGCPS5hw1kTdtDpt+TW3aJimZFoQxJTErdcOKYXQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQC8FsyfRmd4kcC3JNW2t/8E9DLDRtBolkuICE0Y5uZnDycur99VMj2yfI99GUG2vsXLjYNN3tBHbh9llFAO48q24F80+3Yo/9atz7GsqCHW7MkIGq6WuQLoxRfuY25vMa3aegzakU9pfMemuPOdOcX9JVhdgvLkxE0wvSNNI0AH/Y9g9TkS2G3maWYg2mbYSm7cheBoWZ9yHeMGsMsvEt84ex35gp9XKXnaJsCKQmpzLwO4pH+0j1PF05FaIHtv9dn8ZfRlfIUR5FMz9tsx8tUGxF8ySNfB7KWIh40t7Ma8ULH9z5NsaJKuM+FTl01nd6Zu56mZx8eYToLdsvjJlzQV"
The tenant #3 (b204f7c1-b52a-4f6d-8812-26469f8a6ca8) was successfully created.
Credentials for the tenant
--------------------------
Identifier (Entity ID): https://www.cywise.io/saml/b204f7c1-b52a-4f6d-8812-26469f8a6ca8/metadata
Reply URL (Assertion Consumer Service URL): https://www.cywise.io/saml/b204f7c1-b52a-4f6d-8812-26469f8a6ca8/acs
Sign on URL: https://www.cywise.io/saml/b204f7c1-b52a-4f6d-8812-26469f8a6ca8/login
Logout URL: https://www.cywise.io/saml/b204f7c1-b52a-4f6d-8812-26469f8a6ca8/logout
Relay State: (optional)
Je préfère remplacer le www par app pour être cohérent avec l'URL des metadata de l'ADFS.
D'autant que les 2 domaines www.cywise.io et app.cywise.io fonctionnent tous les deux.
Donc, nouveau metadata pour Cywise : https://app.cywise.io/saml/b204f7c1-b52a-4f6d-8812-26469f8a6ca8/metadata
Avec phpMyAdmin, je modifie l'entrée dans la table saml2_tenants pour :
- changer
tenant_id= 18 - changer
customer_id= 9 - changer
domain=hermes.com.test - changer
alt_domain1=~hermes\.com\.test~
Reste la colonne metadata à modifier. Elle contient les réglages des claims et le comportement pour les rôles.
Celle de l'ADFS est la suivante :
{
"claims": {
"email": {
"name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
},
"name": {
"name": "lastname"
},
"role": {
"friendlyName": "group",
"name": "http://schemas.xmlsoap.org/claims/Group"
}
},
"roles": {
"default": ["App\\Models\\Role::CYBERBUDDY_ONLY"],
"idp_roles": ["SG-WORLD-APP-CU-CYBERBUDDY-ADMIN-SSO"],
"SG-WORLD-APP-CU-CYBERBUDDY-ADMIN-SSO_to_cywise": ["App\\Models\\Role::CYBERBUDDY_ADMIN"]
}
}
Le nom du groupe des Administrateurs de CyberBuddy est différent dans Entra ID : SGC-WORLD-BUD-PRD-RBAC-Admins
Pour Entra ID, ce sera :
{
"claims": {
"email": {
"name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
},
"name": {
"name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
},
"role": {
"name": "http://schemas.microsoft.com/ws/2008/06/identity/claims/groups"
}
},
"roles": {
"default": ["App\\Models\\Role::CYBERBUDDY_ONLY"],
"idp_roles": ["SGC-WORLD-BUD-PRD-RBAC-Admins"],
"SGC-WORLD-BUD-PRD-RBAC-Admins_to_cywise": ["App\\Models\\Role::CYBERBUDDY_ADMIN"]
}
}
En faisant mon premier test, je me rends compte que patrick@hermes.com.test matche avec
~hermes\.com~ donc je suis renvoyé vers l'ADFS.
Je fais donc le changement suivant dans la colonne alt_domain1 :
- ADFS : changer
alt_domain1=~hermes\.com$~ - Entra ID : changer
alt_domain1=~hermes\.com\.test$~
Quand je mets l'email patrick@hermes.com.test, je suis bien redirigé vers Entra ID.
Quand je mets l'email patrick@hermes.com, je suis bien redirigé vers ADFS.
Je communique les metadata à Amine et Nicolas.
Après des échanges pendant 1 jour ou 2, l'intégration Entra ID est validée.
2025-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-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-15 - 12:45 - Problème de mise à jour de Cywise PROD
Interruption 15 minutes
Du jeudi 15/05 12h50 au jeudi 15/05 13h05 soit 15 minutes
J'ai fait une MEP et j'ai constaté que l'image Docker des services de la
stack Cywise PROD n'était pas à jour. J'ai arrêté le service cywise-ui_prod
puis je l'ai redémarré mais il ne redémarrait pas.
J'ai fini par comprendre que la stack cywise-ui_prod ne démarrait pas à cause
d'une erreur dans le fichier .env (les secrets) : une ligne qui n'était pas
du type KEY=VALUE.
J'ai corrigé le fichier .env et le service cywise-ui_prod a pu redémarrer
avec la bonne image Docker.
J'ai également mis à jour le fichier des secrets sur mon poste pour supprimer la ligne qui posait problème.
2025-05-13 - 17:00 - Bug à l'embarquement - Problème de token
Un propect de Cywise a eu un problème d'embarquement :
De : Christophe GRENIER cgrenier@globalsp.com Date : mardi 13 mai 2025 à 15:50 À : Eric Esmerian eesmerian@computablefacts.com Objet : RE: Offre de Pentest
Il y a eu un bug lors de la finalisation de l’inscription. « Ce jeton de réinitialisation du mot de passe n'est pas valide. » J’ai contourné le problème avec « Perte de mot de passe ».
Je vois, dans les logs de app qu'il a fait plusieurs appels aux URL de reset de mot de passe :
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:34:09 +0000] "GET /password/reset/f82523df8b7afbbbd4e7f47cba4646778395254437804f59b689442b2cbdefe8?email=grenier%40cgsecurity.org&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe HTTP/1.0" 200 3877 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:34:29 +0000] "POST /password/reset HTTP/1.0" 302 2703 "https://app.cywise.io/password/reset/f82523df8b7afbbbd4e7f47cba4646778395254437804f59b689442b2cbdefe8?email=grenier%40cgsecurity.org&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:34:29 +0000] "GET /password/reset/f82523df8b7afbbbd4e7f47cba4646778395254437804f59b689442b2cbdefe8?email=grenier%40cgsecurity.org&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe HTTP/1.0" 200 3947 "https://app.cywise.io/password/reset/f82523df8b7afbbbd4e7f47cba4646778395254437804f59b689442b2cbdefe8?email=grenier%40cgsecurity.org&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:34:45 +0000] "GET /password/reset/f82523df8b7afbbbd4e7f47cba4646778395254437804f59b689442b2cbdefe8?email=grenier%40cgsecurity.org&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe HTTP/1.0" 200 3877 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:34:58 +0000] "POST /password/reset HTTP/1.0" 302 2703 "https://app.cywise.io/password/reset/f82523df8b7afbbbd4e7f47cba4646778395254437804f59b689442b2cbdefe8?email=grenier%40cgsecurity.org&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:34:58 +0000] "GET /password/reset/f82523df8b7afbbbd4e7f47cba4646778395254437804f59b689442b2cbdefe8?email=grenier%40cgsecurity.org&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe HTTP/1.0" 200 3947 "https://app.cywise.io/password/reset/f82523df8b7afbbbd4e7f47cba4646778395254437804f59b689442b2cbdefe8?email=grenier%40cgsecurity.org&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:35:12 +0000] "GET /login HTTP/1.0" 200 3231 "https://app.cywise.io/password/reset/f82523df8b7afbbbd4e7f47cba4646778395254437804f59b689442b2cbdefe8?email=grenier%40cgsecurity.org&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:36:27 +0000] "GET /password/reset/ea6ebb95aecbbb34e2545323b9f666fbe39365673963cdb6fa963bc2d5dee263?email=grenier%40cgsecurity.org HTTP/1.0" 200 3856 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:36:38 +0000] "POST /password/reset HTTP/1.0" 302 1516 "https://app.cywise.io/password/reset/ea6ebb95aecbbb34e2545323b9f666fbe39365673963cdb6fa963bc2d5dee263?email=grenier%40cgsecurity.org" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.124:80 10.0.0.2 - - [13/May/2025:13:36:38 +0000] "GET /home HTTP/1.0" 200 14338 "https://app.cywise.io/password/reset/ea6ebb95aecbbb34e2545323b9f666fbe39365673963cdb6fa963bc2d5dee263?email=grenier%40cgsecurity.org" "Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
Lien reçu avec Mandat@Archers-Guyancourt.fr : https://app.cywise.io/password/reset/8c2dec94d5a5f77483dcf3caf8667e25e51be8bb64356980644ff447b122409e?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe
10.0.6.130:80 10.0.0.2 - - [13/May/2025:15:47:55 +0000] "GET /password/reset/8c2dec94d5a5f77483dcf3caf8667e25e51be8bb64356980644ff447b122409e?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe HTTP/1.0" 200 3883 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.130:80 10.0.0.2 - - [13/May/2025:15:49:06 +0000] "POST /password/reset HTTP/1.0" 302 1516 "https://app.cywise.io/password/reset/8c2dec94d5a5f77483dcf3caf8667e25e51be8bb64356980644ff447b122409e?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.6.130:80 10.0.0.2 - - [13/May/2025:15:49:06 +0000] "GET /home HTTP/1.0" 200 10472 "https://app.cywise.io/password/reset/8c2dec94d5a5f77483dcf3caf8667e25e51be8bb64356980644ff447b122409e?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
=> Je n'ai pas reproduit le problème avec ce lien
Je refais un test avec Mandat@Archers-Guyancourt.fr (après avoir supprimer ce compte dans la base). Nouveau lien reçu : https://dev.cywise-ui.myapps.addapps.io/password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe
Oups, il pointe vers le site de DEV !
Je retrouve bien une ligne dans la table password_resets avec le mail Mandat@Archers-Guyancourt.fr dans la base de DEV.
10.0.10.47:80 10.0.0.2 - - [13/May/2025:16:17:56 +0000] "GET /password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe HTTP/1.0" 200 3914 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.10.47:80 10.0.0.2 - - [13/May/2025:16:24:08 +0000] "POST /password/reset HTTP/1.0" 302 2839 "https://dev.cywise-ui.myapps.addapps.io/password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.10.47:80 10.0.0.2 - - [13/May/2025:16:24:08 +0000] "GET /password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe HTTP/1.0" 200 3960 "https://dev.cywise-ui.myapps.addapps.io/password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.10.47:80 10.0.0.2 - - [13/May/2025:16:24:22 +0000] "POST /password/reset HTTP/1.0" 302 2839 "https://dev.cywise-ui.myapps.addapps.io/password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.10.47:80 10.0.0.2 - - [13/May/2025:16:24:22 +0000] "GET /password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe HTTP/1.0" 200 3960 "https://dev.cywise-ui.myapps.addapps.io/password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.10.47:80 10.0.0.2 - - [13/May/2025:16:24:37 +0000] "POST /password/reset HTTP/1.0" 302 1622 "https://dev.cywise-ui.myapps.addapps.io/password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
10.0.10.47:80 10.0.0.2 - - [13/May/2025:16:24:37 +0000] "GET /home HTTP/1.0" 200 10327 "https://dev.cywise-ui.myapps.addapps.io/password/reset/8904208667f39073281eaba62827c4db799f35143f469ae1ad2b8d2b4eaed236?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0"
J'ai mis 2 fois un mot de passe erroné donc le formulaire s'est réaffiché avec l'erreur. Malgré cela, j'ai pu valider une troisième fois avec un password valide et le compte a été créé.
https://app.cywise.io/password/reset/5cbd2e0db1150f88b90d99191829eb6d0f5b9f1146967df6f113f304a9c72a72?email=Mandat%40Archers-Guyancourt.fr&reason=Finalisez%20votre%20inscription%20en%20cr%C3%A9ant%20un%20mot%20de%20passe&action=Cr%C3%A9er%20mon%20mot%20de%20passe
J'ai testé la modification de l'email avant validation du formulaire. J'obtiens le message : "Aucun utilisateur n'a été trouvé avec cette adresse email.". Donc pas le même problème.
Finalement, pour reproduire le problème, il faut attendre plus de 60 minutes avant d'utiliser le lien de réinitialisation du mot de passe. En effet, par défaut, il expire au bout de 60 minutes. Il faut donc que le prospect attende plus de 60 minutes avant de valider le formulaire de réinitialisation du mot de passe. Il reçoit alors le message "Ce jeton de réinitialisation du mot de passe n'est pas valide.".
Actions : - j'ai mis en lecture seule l'email pour éviter la tentation de le changer - j'ai passé l'expiration à 90 minutes pour tester que j'ai trouvé le bon réglage - je mettrais 15j (durée de la période d'essai) après validation
2025-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-02-17 - 09:30 - Erreur 504 Gateway Time-out sur Cywise et non réception du rapport d'audit par mail (suite et fin)
Cyrille se rend compte que nous avons à nouveau 55k jobs en attente dans queue-critical.
Les rapports d'audit ont été envoyés samedi matin mais pas envoyé dimanche ni ce matin.
La file ne se vide pas malgré les 3 containers qui traitent queue-critical maintenant.
Cyrille et moi faisons une conf de 16h30 à 19h30 : - nous avons déplacé les jobs des événements de DC2 vers la queue-medium (18.1k) - nous avons donc laissé environ 40k de jobs dans la queue-critical - après un peu plus d'une heure, il nous reste 5k jobs dans queue-critical et 18k jobs dans queue medium - certains jobs mettaient 50s à ingérer 63 events contre quelques centaines de ms pour les autres jobs - après analyse, il s'agit d'événements firefox venant d'un serveur de Elephantastic - Nous déplaçons les événements de DC2 vers queue-critical (qui est vide) et nous ne gardons que ceux du serveur Elephantastic dans queue-medium - Les événements de DC2 sont ingérés rapidement (200ms/job) alors que dans queue-medium tous les jobs prennent 50s - Nous ajoutons du chronométrage et nous repérons la requête qui est lente (0.7s par event à la place de 0.007 habituellement) - C'est dû à un hash qui est présent en grande quantité pour d'autres événements (même événement firefox) et qui ralentit la recherche d'un événement déjà existant pour éviter de créer un doublon - Finalement, en ajoutant calendar_time en plus de unix_time dans la comparaison le temps revient dans la norme des 0.007s (calendar_time est indexée alors que unix_time ne l'est pas et les deux représentent le même instant)
Problem solved.
2025-02-14 - 07:30 - Erreur 504 Gateway Time-out sur Cywise et non réception du rapport d'audit par mail (suite)
Je me rends compte que le scheduler n'a pas démarré depuis ma mise en PROD d'hier soir. Le seeder plante car l'URL où nous allons chercher les règles OSSEC n'existe plus. La branche principale de la repo est passée de master à main, il faut donc modifier toutes les URLs. Par exemple, https://raw.githubusercontent.com/wazuh/wazuh-agent/refs/heads/master/etc/ruleset/sca/nginx/cis_nginx_1.yml devient https://raw.githubusercontent.com/wazuh/wazuh-agent/refs/heads/main/etc/ruleset/sca/nginx/cis_nginx_1.yml.
Je fais les changements et j'en profite pour décaler l'heure d'envoi des rapports d'audit à 8h40.
Je fais la requête SQL qui était très lentes (70s) lors du rapport d'audit Oppscience d'hier ce qui permet de l'obtenir en quelques secondes les fois suivantes (MySQL a mis les données en mémoire).
Les rapports d'audit se génèrent sans erreur.
Je remets l'heure des rapports à 7h45.
2025-02-13 - 11:45 - Erreur 504 Gateway Time-out sur Cywise et non réception du rapport d'audit par mail
Sylvain Moreau prévient Cyrille par mail qu'il a des problèmes avec Cywise PROD.
Uniquement 6 jobs dans queue-critical, ce n'est pas l'origine des problèmes.
Je l'appelle et il a 2 problèmes : - il a une erreur 504 Gateway Time-out quand il se connecte à Cywise - il n'a pas reçu le rapport d'audit par mail ce matin
J'ouvre le ticket #8758 dans Freshdesk.
Après analyse, nous arrivons à la conclusion que les lenteurs viennent de la classe Messages. Elle est utilisée pour les rapports d'audits et aussi pour afficher les derniers événements sur la page d'accueil de Cywise (donc juste après le login).
En essayant l'URL Cywise qui permet d'afficher le rapport d'audit dans mon navigateur, j'ai une erreur la première fois (504 Gateway Timoeout) et un rapport qui s'affiche en quelques secondes la fois suivante.
J'identifie la requête SQL qui prend la majeure partie du temps :
select * from `ynh_osquery`
where `calendar_time` >= '2025-02-12 15:45:14'
and `ynh_server_id` in (...)
and `name` = 'ld_preload'
Finalement, nous trouvons que la classe Messages utilise des vues sur la table ynh_osquery_latest_events
dans plusieurs méthodes mais elle utilise aussi des requêtes, comme celle ci-dessus qui est lente, qui
attaque directement la table ynh_osquery.
ynh_osquery contient plusieurs millions de lignes alors que ynh_osquery_latest_events n'en contient
que quelques milliers puisqu'elle a été conçue pour ça (ne garder que les 1000 derniers événements pour
chaque type de chaque serveurs).
La solution doit être de faire des vues sur ynh_osquery_latest_events là où ce n'est pas encore le cas.
Cyrille le fera lundi.
Mais je n'ai pas compris non plus pourquoi le rapport d'audit de Oppscience n'est pas parti ce matin : je n'ai pas trouvé d'erreur, juste des containers qui ont redémarré car la tâche (queue:work) a renvoyé un code non nul.
Je décide d'ajouter l'option --memory 1024 à la commande queue:work. La valeur par défaut est 128 et
mon hypothèse est que le rapport a besoin de plus de 128Mo pour se générer donc il est peut-être interrompu
et il fait sortir la commande avec un code non nul. Modif poussé en PROD vers 22h.
2025-02-12 - 09:50 - Non traitement des événements de Cywise (suite)
Restait 14k jobs à 22h hier soir et la file était vide vers 1h30 ce matin.
Je fait un commit pour qu'il y ait toujours 3 containers qui traitent la file des jobs critiques.
2025-02-11 - 15:30 - Non traitement des événements de Cywise (suite)
Reste 27.9k jobs. Ca va plus vite que mon calcul de ce matin : 3200 jobs par heure.
2025-02-11 - 08:10 - Non traitement des événements de Cywise (suite)
Il y a encore 52k jobs en attente de traitement dans queue-critical.
Environ 1650 jobs par heure traités depuis hier soir. Reste 30h de traitement d'après mes calculs.
2025-02-10 - 08:30 - Non traitement des événements de Cywise (suite)
Il y a encore 69k jobs en attente de traitement dans queue-critical.
J'augmente le nombre de containers de 1 à 3 pour traiter queue-critical.
Je passe même de 3 à 5 containers entre 10h30 et 12h mais je reviens à 3
containers car je trouve la machine yunohost-addapps trop chargée.
Je m'aperçois que MySQL n'utilise que 128Mo de mémoire alors que la VM a maintenant 32Go de mémoire au total. Je décide de modifier les réglages de MySQL pour lui donner plus de mémoire (12Go).
Paramètres ajoutés dans /etc/mysql/mariadb.conf.d/50-server.cnf
############# Ajout Patrick - 2025-02-10
# Mémoire
innodb_buffer_pool_size = 12G # ~75% de la RAM si MariaDB est le principal service
innodb_buffer_pool_instances = 6 # Diviser le buffer en plusieurs instances (nombre conseillé = RAM/2G>
innodb_log_file_size = 1G # Taille du journal pour accélérer les transactions
innodb_log_buffer_size = 256M # Buffer pour le journal, réduit les écritures disque
innodb_flush_method = O_DIRECT # Évite la mise en cache du système de fichiers
# Optimisation CPU et threads
innodb_thread_concurrency = 8 # Généralement 2x le nombre de CPU
innodb_read_io_threads = 8
innodb_write_io_threads = 8
innodb_flush_log_at_trx_commit = 2 # Bon compromis entre performance et sécurité
# Cache et requêtes
query_cache_type = 0 # Désactiver le Query Cache (obsolète et ralentit les performances)
query_cache_size = 0
table_open_cache = 8000
table_definition_cache = 4000
max_connections = 300 # À ajuster selon l'usage réel
tmp_table_size = 256M
max_heap_table_size = 256M
# Logs et monitoring
log_bin = OFF # Désactiver le log binaire si pas de réplication
#slow_query_log = 1
#slow_query_log_file = /var/log/mysql/slow.log
#long_query_time = 2 # Loguer les requêtes de plus de 2 secondes
# Buffers supplémentaires
join_buffer_size = 16M
sort_buffer_size = 16M
read_buffer_size = 8M
read_rnd_buffer_size = 8M
############# FIN Ajout Patrick - 2025-02-10
Encore 50h de traitement d'après mes calculs et le rythme actuel.
2025-02-09 - 17:55 - Non traitement des événements de Cywise
Cyrille par slack :
Bon, second pb : on ne reçoit plus d'events depuis la MEP de jeudi.
19h05 : Cyrille s'aperçoit qu'il y a 79.1k jobs en attente de traitement dans queue-critical. Ce sont des jobs d'ingestion d'événements.
2025-02-09 - 10:50 - Non réception du rapport d'audit par mail
Cyrille par slack :
Apparemment Cywise est down... C'est oppscience qui vient de me prévenir car ils ne reçoivent plus les emails du matin.
Cyrille pense que c'est dû à une modification des droits d'accès aux menus de Cywise qu'il a mis en PROD jeudi 06/02. Il a fait un correctif et l'a poussé vers 13h30.
2025-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.
2024-12-18 - 17:40 - Erreur lors du déploiement
Interruption du mercredi 18/12 12h10 au vendredi 18/12 13h10 soit 1 heure
Toutes les applications hébergées sur la machine yunohost-addapps ont été indisponibles.
Je déploie Cywise PROD pour debugger la connexion de engineering sur tous les performa mais j'ai une erreur de syntaxe dans config/towerify.php qui empêche l'application de démarrer.
Le temps de comprendre le problème et de déployer le correctif.
Puis une nouvelle erreur : network sandbox join failed: subnet sandbox join failed for "10.0.0.0/24": error creating vxlan interface: file exists.
J'arrête Docker puis je démarre Docker mais j'ai toujours la même erreur (NOTA: Docker avait été redémarré 5 minutes plus tôt. le hook de règles du firewall ?).
Je redémarre la machine cette fois.
C'était un problème de place disque finalement. J'ai fait le ménage dans les tables de telescope et des événements.
2024-11-27 - Traitement des événements très lent sur Cywise PROD²
Le 2024-11-26, Cyrille remarque que Cywise affiche les serveurs en rouge comme si ceux-ci n'avaient pas contacté Cywise depuis longtemps. Bien sûr, nous pensons à une perte d'IP v6 ou v4 mais ce n'était pas le cas.
L'historique des métriques des serveurs n'est pas à jour et les dernières métriques
affichées datent de la veille vers 23h. Pourtant, des requêtes venant des serveurs
arrivent et sont traitées rapidement et sans erreur. Elles créent un événement qui
doit être traité par la queue.
Le container qui traite les événements en attente fonctionne et il n'y a pas d'erreur dans les logs.
Cela me rappelle également le mail que Cywise envoie tous les matins et qui s'était décalé pour passer de 7h45 à 15h05 en 3 ou 4 jours.
Finalement, nous comprenons que le traitement est ralenti car il y a beaucoup trop d'événements
à traiter. Plus de 960k événements en attente...
Dont 590k d'événements ProcessPendingUpdates qui sont des événements Lavarel liés à Telescope.
Cyrille supprime ces événements ProcessPendingUpdates et plusieurs autres qui sont lancés à
intervalle régulier (EmbedChunks, DeleteEmbeddedChunks, TriggerScan, PullServersInfos,
TriggerDiscoveryShallow).
Cela débloque le traitement des événements pour les métriques qui se mettent à jour en rattrappant leur retard.
Pour les événements Laravel liés à Telescope, une option existe pour les désactiver. Nous ajoutons
TELESCOPE_JOB_WATCHER=false dans les secrets pour ça.
Nous décidons de séparer les événements dans 3 files d'attente distinctes : low, medium, critical
Nous enverrons les événements liés à la remontée d'information des serveurs dans la file critical afin que leur prise en compte en soit pas retardée par d'autres événements plus long à traiter.
Fait en DEV vers 11h.
Links¶
Dependencies¶
deploy-redirect¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Redirections pour les webhooks de portainer
Events¶
2025-03-21 - Suppression des hooks Portainer pour les apps qui n'existent plus sur swarm01
Pour mettre à jour les stacks de swarm01, j'utilisais les hooks Portainer permettant de mettre à jour un service et j'avais mis ces hooks derrière des redirections avec la stack deploy-redirect.
Comme j'ai supprimé quasiment toutes les stacks sauf les 3 cf-ui de Lur Berri, je vais supprimer les redirections pour les apps qui n'existent plus.
Les redirections que j'ai supprimées (dans ansible/roles/stack-deploy-redirect/templates/deploy-redirect.stack.yaml.j2) :
- cf-ui Sentinel DEV
- cf-ui Ista DEV
- cf-ui Smacl DEV
- module Smacl DEV, STAGING, PROD
- cf-ui Sentinel STAGING
- cf-ui Ista STAGING
- cf-ui Smacl STAGING
- modules-smacl contracts DEV, STAGING, PROD
- cf-ui Sentinel PROD
- cf-ui appscompose DEV
Il reste donc les redirections pour les hooks de cf-ui Lur Berri DEV et STAGING (je n'avais pas fait celles pour la PROD).
Puis je mets à jour la stack avec la commande :
ansible-playbook -i ansible/inventory.yml ansible/client-common.yaml --tags deploy-redirect
Links¶
Dependencies¶
dev-stack-mysql¶
[Système : None] [Lifecycle : dev] [Subtype : stack]
Stack MySQL pour les bases de DEV sur swarm01
Détails¶
Cette stack doit stocker ses données sur le disque du serveur donc elle est stickée sur un noeud du Swarm : s008.
Links¶
Dependencies¶
dev-stack-mysql-backup¶
[Système : None] [Lifecycle : dev] [Subtype : stack]
Backup des bases de DEV vers S3
Links¶
Dependencies¶
dev-stack-redis-stateless¶
[Système : None] [Lifecycle : dev] [Subtype : stack]
Redis pour les applications de DEV
Links¶
Dependencies¶
fast-t-epcis¶
[Système : None] [Lifecycle : experimental] [Subtype : stack]
Test de ghcr.io/louisaxel-ambroise/epcis:latest
Links¶
Dependencies¶
generic-rag_dev¶
[Système : None] [Lifecycle : dev] [Subtype : stack]
Generic RAG DEV déployé sur yunohost-dev02
Events¶
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).
Links¶
Dependencies¶
generic-rag_prod¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Generic RAG PROD déployé sur yunohost-dev02
Links¶
Dependencies¶
generic-rag_staging¶
[Système : None] [Lifecycle : staging] [Subtype : stack]
Generic RAG STAGING déployé sur yunohost-dev02
Links¶
Dependencies¶
http-echo¶
[Système : None] [Lifecycle : experimental] [Subtype : stack]
mendhak/http-https-echo:latest pour tester des requêtes HTTP et HTTPS
Links¶
Dependencies¶
ista-prod-superset¶
[Système : ista] [Lifecycle : production] [Subtype : stack]
Superset pour Ista déployé sur yunohost-ista-prod
Links¶
Dependencies¶
maintenance¶
[Système : None] [Lifecycle : experimental] [Subtype : stack]
Page de maintenance aux couleurs de ComputableFacts
TODOs¶
-
Expliquer comment s'en servir. Avec un CNAME ?
-
Je ne m'en sers quasiment jamais, la supprimer ?
Links¶
Dependencies¶
maintenance-ip-publique¶
[Système : None] [Lifecycle : experimental] [Subtype : stack]
Page de maintenance aux couleurs de ComputableFacts
TODOs¶
-
Expliquer comment s'en servir. Avec un CNAME ?
-
Je ne m'en sers quasiment jamais, la supprimer ?
Links¶
Dependencies¶
nifi-all¶
[Système : None] [Lifecycle : production] [Subtype : stack]
NiFi pour l'ingestion des données de notre Datalake
TODOs¶
-
lister les autres éléments déployés par cette stack i.e. Redis et Tika
-
décrire les volumes et donc la machine sXXX sur laquelle NiFi est stické
Links¶
Dependencies¶
passeport-immeuble_dev¶
[Système : ista] [Lifecycle : dev] [Subtype : yunohost]
Ista module Passport Immeuble de DEV
Links¶
Dependencies¶
passeport-immeuble_prod¶
[Système : ista] [Lifecycle : production] [Subtype : yunohost]
Ista module Passport Immeuble de PROD
Links¶
Dependencies¶
passeport-immeuble_staging¶
[Système : ista] [Lifecycle : staging] [Subtype : yunohost]
Ista module Passport Immeuble de STAGING
Details¶
2023-12-26 : ce déploiement n'existe pas encore. Il existera quand Ista poussera la branche release/x.x.x vers
la repo au moment de faire une MEP.
Links¶
Dependencies¶
performa_hf5y-rhal-8tr4¶
[Système : cywise] [Lifecycle : production] [Subtype : yunohost]
Cywise Performa pour Elephantastic
Events¶
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-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-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-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-04-20 - 19:30 - Nos 5 performa ne répondent plus
Interruption du vendredi 18/04 18h15 au dimanche 20/04 20h15 soit 50 heures
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 3 alertes à 18h12 venant de mes surveillances Freshping. Puis les 2 autres alertes à 18h17 puis 18h22.
Les images des 5 performa ne sont plus présentes.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Je décide de mettre en commentaire le cron qui fait le ménage dans les images Docker
(docker builder prune -f) pour éviter de supprimer les images.
En principe, cette commande ne devrait pas supprimer les images utilisées par les containers
mais je ne vois pas ce qui pourrait les supprimer à part cette commande. D'où ma décision
de la mettre en commentaire.
2025-04-17 - 16:50 - Nos 5 performa ne répondent plus
Interruption du jeudi 17/04 16h45 au jeudi 17/04 17h05 soit 20 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 4 alertes à 16h47 venant de mes surveillances Freshping. Puis la 5ème à 16h51.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Je constate que Docker a redémarré à 16h32. Certainement suite à un towerify deploy.
Les images des performa ont pu être supprimées plus tôt et c'est au moment du redémarrage
que Docker ne les trouve plus et que les performa ne peuvent donc pas redémarrer...
2025-03-21 - 20:10 - Nos 5 performa ne répondent plus
Interruption du mardi 25/03 17h au mercredi 26/03 15h soit 22 heures
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 5 alertes à 16h51 venant de mes surveillances Freshping que je n'ai vues que le lendemain vers 15h.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Deux déploiements de Cywise DEV ont été faits par Cyrille à 16h28 puis 16h34. Je pense qu'ils sont à l'origine de la perte des images des Performa mais je n'arrive pas à trouver le lien.
2025-03-21 - 20:10 - Nos 5 performa ne répondent plus
Interruption du vendredi 21/03 17h40 au vendredi 21/03 20h25 soit 2 heures et 45 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 2 alertes à 17h42 venant de mes surveillances Freshping. Puis 2 alertes à 17h46. Puis une alerte pour le cinquième performa à 18h12.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Cela s'est produit à nouveau après un towerify deploy de ma doc d'infra.
Je ne sais pas si c'est lié.
2025-02-28 - 09:40 - Nos 5 performa ne répondent plus
Interruption du vendredi 28/02 9h30 au vendredi 28/02 9h55 soit 25 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 3 alertes vers 9h40 venant de mes surveillances Freshping. Puis 2 autres alertes vers 9h50.
En regardant en SSH, le symptôme est le même : les images performa ne sont plus là.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
L'hypothèse se confirme : j'ai fait un towerify deploy de Cywise DEV peu avant les
alertes. Comme si un déploiement d'une autre appli supprimait les images des
performa.
Je constate que Docker a redémarré à 9h31. Certainement suite à mon towerify deploy.
Les images des performa ont pu être supprimées plus tôt et c'est au moment du redémarrage
que Docker ne les trouve plus et que les performa ne peuvent donc pas redémarrer...
2025-02-21 - 12:40 - Nos 5 performa ne répondent plus
Interruption du vendredi 21/02 12h10 au vendredi 21/02 12h55 soit 45 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 3 alertes vers 12h10 venant de mes surveillances Freshping. Puis une alerte vers 12h15. Puis une alerte pour le cinquième performa vers 12h20.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Je n'ai pas d'hypothèse mais j'ai fait un towerify deploy de ma doc d'infra peu avant les
alertes. Je ne sais pas si c'est lié.
2025-01-23 - 09:35 - Nos 5 performa ne répondent plus
Interruption du jeudi 23/01 9h20 au jeudi 23/01 9h50 soit 30 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 4 alertes vers 9h35 venant de mes surveillances Freshping. Puis une alerte pour le cinquième performa vers 9h40.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
2025-01-13 - 21:15 - Nos 5 performa ne répondent plus
Interruption du lundi 13/01 19h45 au lundi 13/01 21h30 soit 1 heure 45 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 2 alertes vers 20h05 venant de mes 2 surveillances Freshping (CF et Ista). Les 3 autres performa n'ont pas de surveillance Freshping.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Links¶
Dependencies¶
performa_js5f-4t7e-5er8¶
[Système : cywise] [Lifecycle : production] [Subtype : yunohost]
Cywise Performa pour Oppscience
Events¶
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-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-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-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-04-20 - 19:30 - Nos 5 performa ne répondent plus
Interruption du vendredi 18/04 18h15 au dimanche 20/04 20h15 soit 50 heures
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 3 alertes à 18h12 venant de mes surveillances Freshping. Puis les 2 autres alertes à 18h17 puis 18h22.
Les images des 5 performa ne sont plus présentes.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Je décide de mettre en commentaire le cron qui fait le ménage dans les images Docker
(docker builder prune -f) pour éviter de supprimer les images.
En principe, cette commande ne devrait pas supprimer les images utilisées par les containers
mais je ne vois pas ce qui pourrait les supprimer à part cette commande. D'où ma décision
de la mettre en commentaire.
2025-04-17 - 16:50 - Nos 5 performa ne répondent plus
Interruption du jeudi 17/04 16h45 au jeudi 17/04 17h05 soit 20 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 4 alertes à 16h47 venant de mes surveillances Freshping. Puis la 5ème à 16h51.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Je constate que Docker a redémarré à 16h32. Certainement suite à un towerify deploy.
Les images des performa ont pu être supprimées plus tôt et c'est au moment du redémarrage
que Docker ne les trouve plus et que les performa ne peuvent donc pas redémarrer...
2025-03-21 - 20:10 - Nos 5 performa ne répondent plus
Interruption du mardi 25/03 17h au mercredi 26/03 15h soit 22 heures
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 5 alertes à 16h51 venant de mes surveillances Freshping que je n'ai vues que le lendemain vers 15h.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Deux déploiements de Cywise DEV ont été faits par Cyrille à 16h28 puis 16h34. Je pense qu'ils sont à l'origine de la perte des images des Performa mais je n'arrive pas à trouver le lien.
2025-03-21 - 20:10 - Nos 5 performa ne répondent plus
Interruption du vendredi 21/03 17h40 au vendredi 21/03 20h25 soit 2 heures et 45 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 2 alertes à 17h42 venant de mes surveillances Freshping. Puis 2 alertes à 17h46. Puis une alerte pour le cinquième performa à 18h12.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Cela s'est produit à nouveau après un towerify deploy de ma doc d'infra.
Je ne sais pas si c'est lié.
2025-02-28 - 09:40 - Nos 5 performa ne répondent plus
Interruption du vendredi 28/02 9h30 au vendredi 28/02 9h55 soit 25 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 3 alertes vers 9h40 venant de mes surveillances Freshping. Puis 2 autres alertes vers 9h50.
En regardant en SSH, le symptôme est le même : les images performa ne sont plus là.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
L'hypothèse se confirme : j'ai fait un towerify deploy de Cywise DEV peu avant les
alertes. Comme si un déploiement d'une autre appli supprimait les images des
performa.
Je constate que Docker a redémarré à 9h31. Certainement suite à mon towerify deploy.
Les images des performa ont pu être supprimées plus tôt et c'est au moment du redémarrage
que Docker ne les trouve plus et que les performa ne peuvent donc pas redémarrer...
2025-02-21 - 12:40 - Nos 5 performa ne répondent plus
Interruption du vendredi 21/02 12h10 au vendredi 21/02 12h55 soit 45 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 3 alertes vers 12h10 venant de mes surveillances Freshping. Puis une alerte vers 12h15. Puis une alerte pour le cinquième performa vers 12h20.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Je n'ai pas d'hypothèse mais j'ai fait un towerify deploy de ma doc d'infra peu avant les
alertes. Je ne sais pas si c'est lié.
2025-01-23 - 09:35 - Nos 5 performa ne répondent plus
Interruption du jeudi 23/01 9h20 au jeudi 23/01 9h50 soit 30 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 4 alertes vers 9h35 venant de mes surveillances Freshping. Puis une alerte pour le cinquième performa vers 9h40.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
2025-01-13 - 21:15 - Nos 5 performa ne répondent plus
Interruption du lundi 13/01 19h45 au lundi 13/01 21h30 soit 1 heure 45 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 2 alertes vers 20h05 venant de mes 2 surveillances Freshping (CF et Ista). Les 3 autres performa n'ont pas de surveillance Freshping.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
2025-01-08 - 19:30 - Mise à jour Performa de Oppscience pour Windows
J'ai mis au point une façon de calculer le Load Average sous Windows. Je recopie ma commande windows_load et je modifie le monitor load_avg du Performa de DEV vers celui de Oppscience. J'ai fait le même chose pour le pourcentage de CPU.
Links¶
Dependencies¶
performa_ka8u-e1fs-3qmh¶
[Système : cywise] [Lifecycle : production] [Subtype : yunohost]
Cywise Performa pour Postface
Events¶
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-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-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-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-04-20 - 19:30 - Nos 5 performa ne répondent plus
Interruption du vendredi 18/04 18h15 au dimanche 20/04 20h15 soit 50 heures
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 3 alertes à 18h12 venant de mes surveillances Freshping. Puis les 2 autres alertes à 18h17 puis 18h22.
Les images des 5 performa ne sont plus présentes.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Je décide de mettre en commentaire le cron qui fait le ménage dans les images Docker
(docker builder prune -f) pour éviter de supprimer les images.
En principe, cette commande ne devrait pas supprimer les images utilisées par les containers
mais je ne vois pas ce qui pourrait les supprimer à part cette commande. D'où ma décision
de la mettre en commentaire.
2025-04-17 - 16:50 - Nos 5 performa ne répondent plus
Interruption du jeudi 17/04 16h45 au jeudi 17/04 17h05 soit 20 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 4 alertes à 16h47 venant de mes surveillances Freshping. Puis la 5ème à 16h51.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Je constate que Docker a redémarré à 16h32. Certainement suite à un towerify deploy.
Les images des performa ont pu être supprimées plus tôt et c'est au moment du redémarrage
que Docker ne les trouve plus et que les performa ne peuvent donc pas redémarrer...
2025-03-21 - 20:10 - Nos 5 performa ne répondent plus
Interruption du mardi 25/03 17h au mercredi 26/03 15h soit 22 heures
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 5 alertes à 16h51 venant de mes surveillances Freshping que je n'ai vues que le lendemain vers 15h.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Deux déploiements de Cywise DEV ont été faits par Cyrille à 16h28 puis 16h34. Je pense qu'ils sont à l'origine de la perte des images des Performa mais je n'arrive pas à trouver le lien.
2025-03-21 - 20:10 - Nos 5 performa ne répondent plus
Interruption du vendredi 21/03 17h40 au vendredi 21/03 20h25 soit 2 heures et 45 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 2 alertes à 17h42 venant de mes surveillances Freshping. Puis 2 alertes à 17h46. Puis une alerte pour le cinquième performa à 18h12.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Cela s'est produit à nouveau après un towerify deploy de ma doc d'infra.
Je ne sais pas si c'est lié.
2025-02-28 - 09:40 - Nos 5 performa ne répondent plus
Interruption du vendredi 28/02 9h30 au vendredi 28/02 9h55 soit 25 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 3 alertes vers 9h40 venant de mes surveillances Freshping. Puis 2 autres alertes vers 9h50.
En regardant en SSH, le symptôme est le même : les images performa ne sont plus là.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
L'hypothèse se confirme : j'ai fait un towerify deploy de Cywise DEV peu avant les
alertes. Comme si un déploiement d'une autre appli supprimait les images des
performa.
Je constate que Docker a redémarré à 9h31. Certainement suite à mon towerify deploy.
Les images des performa ont pu être supprimées plus tôt et c'est au moment du redémarrage
que Docker ne les trouve plus et que les performa ne peuvent donc pas redémarrer...
2025-02-21 - 12:40 - Nos 5 performa ne répondent plus
Interruption du vendredi 21/02 12h10 au vendredi 21/02 12h55 soit 45 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 3 alertes vers 12h10 venant de mes surveillances Freshping. Puis une alerte vers 12h15. Puis une alerte pour le cinquième performa vers 12h20.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Je n'ai pas d'hypothèse mais j'ai fait un towerify deploy de ma doc d'infra peu avant les
alertes. Je ne sais pas si c'est lié.
2025-01-23 - 09:35 - Nos 5 performa ne répondent plus
Interruption du jeudi 23/01 9h20 au jeudi 23/01 9h50 soit 30 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 4 alertes vers 9h35 venant de mes surveillances Freshping. Puis une alerte pour le cinquième performa vers 9h40.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
2025-01-13 - 21:15 - Nos 5 performa ne répondent plus
Interruption du lundi 13/01 19h45 au lundi 13/01 21h30 soit 1 heure 45 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 2 alertes vers 20h05 venant de mes 2 surveillances Freshping (CF et Ista). Les 3 autres performa n'ont pas de surveillance Freshping.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Links¶
Dependencies¶
performa_v29m-tcdr-kqx2¶
[Système : cywise] [Lifecycle : production] [Subtype : yunohost]
Cywise Performa pour ComputableFacts
Events¶
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-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-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-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-04-20 - 19:30 - Nos 5 performa ne répondent plus
Interruption du vendredi 18/04 18h15 au dimanche 20/04 20h15 soit 50 heures
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 3 alertes à 18h12 venant de mes surveillances Freshping. Puis les 2 autres alertes à 18h17 puis 18h22.
Les images des 5 performa ne sont plus présentes.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Je décide de mettre en commentaire le cron qui fait le ménage dans les images Docker
(docker builder prune -f) pour éviter de supprimer les images.
En principe, cette commande ne devrait pas supprimer les images utilisées par les containers
mais je ne vois pas ce qui pourrait les supprimer à part cette commande. D'où ma décision
de la mettre en commentaire.
2025-04-17 - 16:50 - Nos 5 performa ne répondent plus
Interruption du jeudi 17/04 16h45 au jeudi 17/04 17h05 soit 20 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 4 alertes à 16h47 venant de mes surveillances Freshping. Puis la 5ème à 16h51.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Je constate que Docker a redémarré à 16h32. Certainement suite à un towerify deploy.
Les images des performa ont pu être supprimées plus tôt et c'est au moment du redémarrage
que Docker ne les trouve plus et que les performa ne peuvent donc pas redémarrer...
2025-03-21 - 20:10 - Nos 5 performa ne répondent plus
Interruption du mardi 25/03 17h au mercredi 26/03 15h soit 22 heures
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 5 alertes à 16h51 venant de mes surveillances Freshping que je n'ai vues que le lendemain vers 15h.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Deux déploiements de Cywise DEV ont été faits par Cyrille à 16h28 puis 16h34. Je pense qu'ils sont à l'origine de la perte des images des Performa mais je n'arrive pas à trouver le lien.
2025-03-21 - 20:10 - Nos 5 performa ne répondent plus
Interruption du vendredi 21/03 17h40 au vendredi 21/03 20h25 soit 2 heures et 45 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 2 alertes à 17h42 venant de mes surveillances Freshping. Puis 2 alertes à 17h46. Puis une alerte pour le cinquième performa à 18h12.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Cela s'est produit à nouveau après un towerify deploy de ma doc d'infra.
Je ne sais pas si c'est lié.
2025-02-28 - 09:40 - Nos 5 performa ne répondent plus
Interruption du vendredi 28/02 9h30 au vendredi 28/02 9h55 soit 25 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 3 alertes vers 9h40 venant de mes surveillances Freshping. Puis 2 autres alertes vers 9h50.
En regardant en SSH, le symptôme est le même : les images performa ne sont plus là.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
L'hypothèse se confirme : j'ai fait un towerify deploy de Cywise DEV peu avant les
alertes. Comme si un déploiement d'une autre appli supprimait les images des
performa.
Je constate que Docker a redémarré à 9h31. Certainement suite à mon towerify deploy.
Les images des performa ont pu être supprimées plus tôt et c'est au moment du redémarrage
que Docker ne les trouve plus et que les performa ne peuvent donc pas redémarrer...
2025-02-21 - 12:40 - Nos 5 performa ne répondent plus
Interruption du vendredi 21/02 12h10 au vendredi 21/02 12h55 soit 45 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 3 alertes vers 12h10 venant de mes surveillances Freshping. Puis une alerte vers 12h15. Puis une alerte pour le cinquième performa vers 12h20.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Je n'ai pas d'hypothèse mais j'ai fait un towerify deploy de ma doc d'infra peu avant les
alertes. Je ne sais pas si c'est lié.
2025-01-23 - 09:35 - Nos 5 performa ne répondent plus
Interruption du jeudi 23/01 9h20 au jeudi 23/01 9h50 soit 30 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 4 alertes vers 9h35 venant de mes surveillances Freshping. Puis une alerte pour le cinquième performa vers 9h40.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
2025-01-13 - 21:15 - Nos 5 performa ne répondent plus
Interruption du lundi 13/01 19h45 au lundi 13/01 21h30 soit 1 heure 45 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 2 alertes vers 20h05 venant de mes 2 surveillances Freshping (CF et Ista). Les 3 autres performa n'ont pas de surveillance Freshping.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Links¶
Dependencies¶
performa_zdhi-8skn-fu6v¶
[Système : cywise] [Lifecycle : production] [Subtype : yunohost]
Cywise Performa pour Ista
Events¶
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-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-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-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-04-20 - 19:30 - Nos 5 performa ne répondent plus
Interruption du vendredi 18/04 18h15 au dimanche 20/04 20h15 soit 50 heures
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 3 alertes à 18h12 venant de mes surveillances Freshping. Puis les 2 autres alertes à 18h17 puis 18h22.
Les images des 5 performa ne sont plus présentes.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Je décide de mettre en commentaire le cron qui fait le ménage dans les images Docker
(docker builder prune -f) pour éviter de supprimer les images.
En principe, cette commande ne devrait pas supprimer les images utilisées par les containers
mais je ne vois pas ce qui pourrait les supprimer à part cette commande. D'où ma décision
de la mettre en commentaire.
2025-04-17 - 16:50 - Nos 5 performa ne répondent plus
Interruption du jeudi 17/04 16h45 au jeudi 17/04 17h05 soit 20 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 4 alertes à 16h47 venant de mes surveillances Freshping. Puis la 5ème à 16h51.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Je constate que Docker a redémarré à 16h32. Certainement suite à un towerify deploy.
Les images des performa ont pu être supprimées plus tôt et c'est au moment du redémarrage
que Docker ne les trouve plus et que les performa ne peuvent donc pas redémarrer...
2025-03-21 - 20:10 - Nos 5 performa ne répondent plus
Interruption du mardi 25/03 17h au mercredi 26/03 15h soit 22 heures
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 5 alertes à 16h51 venant de mes surveillances Freshping que je n'ai vues que le lendemain vers 15h.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Deux déploiements de Cywise DEV ont été faits par Cyrille à 16h28 puis 16h34. Je pense qu'ils sont à l'origine de la perte des images des Performa mais je n'arrive pas à trouver le lien.
2025-03-21 - 20:10 - Nos 5 performa ne répondent plus
Interruption du vendredi 21/03 17h40 au vendredi 21/03 20h25 soit 2 heures et 45 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 2 alertes à 17h42 venant de mes surveillances Freshping. Puis 2 alertes à 17h46. Puis une alerte pour le cinquième performa à 18h12.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Cela s'est produit à nouveau après un towerify deploy de ma doc d'infra.
Je ne sais pas si c'est lié.
2025-02-28 - 09:40 - Nos 5 performa ne répondent plus
Interruption du vendredi 28/02 9h30 au vendredi 28/02 9h55 soit 25 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 3 alertes vers 9h40 venant de mes surveillances Freshping. Puis 2 autres alertes vers 9h50.
En regardant en SSH, le symptôme est le même : les images performa ne sont plus là.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
L'hypothèse se confirme : j'ai fait un towerify deploy de Cywise DEV peu avant les
alertes. Comme si un déploiement d'une autre appli supprimait les images des
performa.
Je constate que Docker a redémarré à 9h31. Certainement suite à mon towerify deploy.
Les images des performa ont pu être supprimées plus tôt et c'est au moment du redémarrage
que Docker ne les trouve plus et que les performa ne peuvent donc pas redémarrer...
2025-02-21 - 12:40 - Nos 5 performa ne répondent plus
Interruption du vendredi 21/02 12h10 au vendredi 21/02 12h55 soit 45 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 3 alertes vers 12h10 venant de mes surveillances Freshping. Puis une alerte vers 12h15. Puis une alerte pour le cinquième performa vers 12h20.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Je n'ai pas d'hypothèse mais j'ai fait un towerify deploy de ma doc d'infra peu avant les
alertes. Je ne sais pas si c'est lié.
2025-01-23 - 09:35 - Nos 5 performa ne répondent plus
Interruption du jeudi 23/01 9h20 au jeudi 23/01 9h50 soit 30 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 4 alertes vers 9h35 venant de mes surveillances Freshping. Puis une alerte pour le cinquième performa vers 9h40.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
2025-01-13 - 21:15 - Nos 5 performa ne répondent plus
Interruption du lundi 13/01 19h45 au lundi 13/01 21h30 soit 1 heure 45 minutes
Les remontées des machines de nos 5 performa ont été perdues.
J'ai eu 2 alertes vers 20h05 venant de mes 2 surveillances Freshping (CF et Ista). Les 3 autres performa n'ont pas de surveillance Freshping.
En regardant dans Portainer, le symptôme est le même : les containers ne démarrent pas car Docker ne trouve pas l'image correspondante.
Je refais donc le towerify deploy pour chaque Performa ce qui rétabli la situation.
Links¶
Dependencies¶
postface01-jenkins¶
[Système : postface] [Lifecycle : production] [Subtype : yunohost]
Jenkins déployé sur postface01
Links¶
Dependencies¶
postface01-portainer¶
[Système : postface] [Lifecycle : production] [Subtype : stack]
Portainer déployé sur postface01
Events¶
2025-01-14 - 17:05 - Mise à jour de Portainer 2.21.5 sur postface01
Depuis l'Admin YunoHost de postface01, je vais dans "Mise à jour du système".
La nouvelle version de notre package portainer_ynh est bien détectée.
Je clique sur "Mettre à jour". Tout se déroule sans erreur.
Je peux me connecter à Portainer qui est en version 2.21.5 maintenant.
Et la connexion au LDAP fonctionne toujours.
2025-01-13 - Problème d'accès au Portainer de postface
Cyrille reproduit l'erreur LDAP de Christian :
failed creating LDAP connection: LDAP Result Code 200 "Network Error": dial tcp 172.17.0.1:389: connect: connection refused
Mon compte ne fait pas partie du LDAP ce qui explique que j'arrivais à me connecter. J'ai créé un compte de test, dans le LDAP donc, et je reproduis également l'erreur LDAP avec.
J'ai redémarré le container de portainer mais le problème persiste. J'ai redémarré le service Docker mais le problème persiste. J'ai redémarré la machine Scaleway mais le problème persiste.
J'ai fini par trouver l'origine du problème : la configuration du LDAP (slapd) n'autorise que des connexions venant de localhost (donc celles venant des containers comme Portainer sont rejetées).
J'ai pourtant, dans mon installation portainer_ynh un hook qui change la conf de slapd
afin qu'il accepte les connexions de tous les IPs : je remplace ldap://127.0.0.1:389/
par ldap:/// dans son fichier de conf.
Je me rends compte que ce n'est plus ldap://127.0.0.1:389/ mais ldap://localhost:389/
qu'il y a dans le fichier de conf.
J'ai tenté de faire le remplacement en modifiant mon hook mais sans succès...
J'ai fini par modifier à la main la conf, par redémarrer slapd et j'ai corrigé le problème.
Ne pas arrêter le service LDAP (slapd)
J'ai redémarré le service slapd plusieurs fois. J'ai pensé que arrêter puis démarrer serait mieux.
Grave erreur : une fois le service arrêté, sudo demande le mot de passe
de twr_admin... Donc, impossible de redémarrer le service si on ne
connait pas le mot de passe.
Cela veut dire que le sudo utilise le LDAP ?!?
2025-01-10 - 16:50 - Problème d'accès au Portainer de postface ?
Christian de Postface qui m'a envoyé, à 16h50, ce message d'erreur qu'il a eu en accédant à son Portainer :
failed creating LDAP connection: LDAP Result Code 200 "Network Error": dial tcp 172.17.0.1:389: connect: connection refused
Quand j'ai essayé de mon côté, pas d'erreur. Peut-être un problème temporaire.
Links¶
Dependencies¶
prod-keycloak¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Keycloak pour les IdP de nos applications
TODOs¶
- ajouter la repo qui génère notre image Docker pour Keycloak
Links¶
Dependencies¶
prod-stack-mysql¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Stack MySQL pour les bases de PROD sur swarm01
Détails¶
Cette stack doit stocker ses données sur le disque du serveur donc elle est stickée sur un noeud du Swarm : s008.
Links¶
Dependencies¶
prod-stack-mysql-backup¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Backup des bases de PROD vers S3
Links¶
Dependencies¶
prod-stack-redis-stateless¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Redis pour les applications de PROD
Links¶
Dependencies¶
redisinsight¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Web UI for Redis
Links¶
Dependencies¶
staging-stack-mysql¶
[Système : None] [Lifecycle : staging] [Subtype : stack]
Stack MySQL pour les bases de STAGING sur swarm01
Links¶
Dependencies¶
staging-stack-mysql-backup¶
[Système : None] [Lifecycle : staging] [Subtype : stack]
Backup des bases de STAGING vers S3
Links¶
Dependencies¶
staging-stack-redis-stateless¶
[Système : None] [Lifecycle : staging] [Subtype : stack]
Redis pour les applications de STAGING
Links¶
Dependencies¶
statpingng¶
[Système : None] [Lifecycle : dev] [Subtype : stack]
statping-ng déployé sur yunohost-dev02
Links¶
Dependencies¶
swarm01-clickhouse¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Stack pour la base de données Clickhouse
Events¶
2025-03-12 - Mise à jour de Clickhouse sur swarm01
Nous avons besoin de manipuler des fichiers stockés dans Azure avec Clickhouse mais la version actuelle de Clickhouse, v21.10, ne supporte pas les fichiers Azure car il n'y a pas le moteur AzureBlobStorage. Ce moteur n'a été ajouté que à partir de la version v22.1.
Backup
La stack clickhouse utilise 3 volumes :
- clickhouse_clickhouse-data -> /var/lib/clickhouse
- clickhouse_clickhouse-conf -> /etc/clickhouse-server
- clickhouse_clickhouse-materializations -> /opt/materializations
Pour sauvegarder les données, je vais recopier ces 3 répertoires.
Le container de clickhouse est stické sur la machine s005.
En regardant la place disque occupée, je vois que le volume data occupe 430Go.
Je vais donc d'abord faire du ménage en supprimant les bases de données de la Smacl
et d'Ista.
Pour ça, je me connecte depuis mon PC au Clickhouse avec le compte nifi :
clickhouse-client --secure --host clickhouse.swarm01.computablefacts.io --user nifi --password ***
Pour le backup, je préfère synchroniser les volumes dans un autre dossier avec rsync :
sudo rsync -avzP --delete /var/lib/docker/volumes/clickhouse_clickhouse-data ./clickhouse-backups/
sudo rsync -avzP --delete /var/lib/docker/volumes/clickhouse_clickhouse-conf ./clickhouse-backups/
sudo rsync -avzP --delete /var/lib/docker/volumes/clickhouse_clickhouse-materializations ./clickhouse-backups/
185G de backup :
ansible@s005:~$ sudo du -h -d 1 ./clickhouse-backups/
8.0K ./clickhouse-backups/clickhouse_clickhouse-materializations
120K ./clickhouse-backups/clickhouse_clickhouse-conf
185G ./clickhouse-backups/clickhouse_clickhouse-data
185G ./clickhouse-backups/
J'ai fait une montée de version progressive :
- v22.1 (première version avec AzureBlobStorage) : pas de moteur AzureBlobStorage
- v22.12 : pas de moteur AzureBlobStorage
- v23.12 : le moteur AzureBlobStorage est bien présent
- v24.12 : mes imports depuis Azure et depuis AWS fonctionnent
- v25.2 : les imports depuis Azure et depuis AWS fonctionnent
NOTA : j'ai fait les 3 premières montées de versions mercredi 12 mars 2025 et les 2 dernières vendredi 14 mars 2025.
Je suis donc avec la dernière version de Clickhouse, v25.2.
2025-01-30 - Autorisation d'accès à AWS S3 pour Clickhouse
Pour Cywise, nous avons besoin d'accéder aux données de nos clients sur leurs buckets S3.
Nous le faisons avec Clickhouse, celui qui est sur swarm01.
Cela revient à créer une table Clickhouse avec le moteur S3 comme dans l'exemple suivant :
clickhouse-client --host=clickhouse.swarm01.computablefacts.io --secure --user=cyrille --password=**** --query="CREATE TABLE IF NOT EXISTS weekly_100k_patrick (REGION_ID Nullable(Int64), REGION_NAME Nullable(String), REGION_TYPE Nullable(String), REGION_TYPE_ID Nullable(Int64)) ENGINE = S3('https://s3.eu-west-3.amazonaws.com/towerify-public/dev/datasets/out/weekly_100k.parquet', 'AKIAS7C7WWRZCYEA7EL3', '****', 'Parquet')"
J'ai dû autoriser les URL de AWS S3 pour ne plus avoir l'erreur UNACCEPTABLE_URL. Je l'ai fait dans
le fichier ansible/files/clickhouse-conf/config.d/remote_url_allow_hosts.xml. J'ai dû mettre toutes
les régions AWS car le wildcard s3.*.amazonaws.com ne fonctionne pas.
remote_url_allow_hosts.xml
<?xml version="1.0"?>
<yandex>
<remote_url_allow_hosts>
<host>s3.af-south-1.amazonaws.com</host>
<host>s3.ap-east-1.amazonaws.com</host>
<host>s3.ap-northeast-1.amazonaws.com</host>
<host>s3.ap-northeast-2.amazonaws.com</host>
<host>s3.ap-northeast-3.amazonaws.com</host>
<host>s3.ap-south-1.amazonaws.com</host>
<host>s3.ap-southeast-1.amazonaws.com</host>
<host>s3.ap-southeast-2.amazonaws.com</host>
<host>s3.ca-central-1.amazonaws.com</host>
<host>s3.eu-central-1.amazonaws.com</host>
<host>s3.eu-north-1.amazonaws.com</host>
<host>s3.eu-south-1.amazonaws.com</host>
<host>s3.eu-west-1.amazonaws.com</host>
<host>s3.eu-west-2.amazonaws.com</host>
<host>s3.eu-west-3.amazonaws.com</host>
<host>s3.me-central-1.amazonaws.com</host>
<host>s3.me-south-1.amazonaws.com</host>
<host>s3.sa-east-1.amazonaws.com</host>
<host>s3.us-east-1.amazonaws.com</host>
<host>s3.us-east-2.amazonaws.com</host>
<host>s3.us-west-1.amazonaws.com</host>
<host>s3.us-west-2.amazonaws.com</host>
</remote_url_allow_hosts>
</yandex>
2025-01-28 - 09:00 - Ajout d'une base de tests Clickhouse pour Cyrille
Cyrille a besoin d'une base de tests Clickhouse pour ses développements.
J'ai ajouté un compte cyrille sur le Clickhouse de swarm01. Et j'ai déployé
avec ansible :
ansible-playbook -i ansible/inventory.yml ansible/clickhouse-stack.yaml --tags configure
Puis, j'ai créé une base de tests cyrille_dev en utilisant le compte nifi.
Enfin, j'ai vérifié que je pouvais bien y accéder avec clickhouse-client :
patrick@SpectreMate:~
[09:32:13]$ clickhouse-client --host=clickhouse.swarm01.computablefacts.io --secure --user=cyrille --password=**** --query="SHOW DATABASES;"
cyrille_dev
TODOs¶
-
Expliquer l'utilisation du port "secure" 9440
-
Expliquer dépendance s005
Links¶
Dependencies¶
swarm01-phpmyadmin¶
[Système : None] [Lifecycle : production] [Subtype : stack]
phpMyAdmin déployé sur swarm01
Links¶
Dependencies¶
swarm01-portainer¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Portainer déployé sur swarm01
Events¶
2025-01-10 - 18:20 - Suppression de 2 managers du cluster swarm01 (s002 et s003)
Comme nous avons réduit le nombre de clients utilisant swarm01, nous voulons réduire le nombre de machines. Je veux commencer par retirer les 2 managers.
Je choisi de garder s001 comme manager et de supprimer s002 et s003.
Je sauvegarde le répertoire /var/lib/docker/swarm sur s001.
Commande
ansible@s001:~$ sudo tar -czvf var_lib_docker_swarm.20250110.tar.gz /var/lib/docker/swarm
tar: Removing leading `/' from member names
/var/lib/docker/swarm/
/var/lib/docker/swarm/worker/
/var/lib/docker/swarm/worker/tasks.db
/var/lib/docker/swarm/state.json
/var/lib/docker/swarm/docker-state.json
/var/lib/docker/swarm/raft/
/var/lib/docker/swarm/raft/wal-v3-encrypted/
/var/lib/docker/swarm/raft/wal-v3-encrypted/0000000000000282-0000000000fb5e32.wal
/var/lib/docker/swarm/raft/wal-v3-encrypted/0.tmp
/var/lib/docker/swarm/raft/snap-v3-encrypted/
/var/lib/docker/swarm/raft/snap-v3-encrypted/0000000000000184-0000000000fb7703.snap
/var/lib/docker/swarm/certificates/
/var/lib/docker/swarm/certificates/swarm-node.key
/var/lib/docker/swarm/certificates/swarm-root-ca.crt
/var/lib/docker/swarm/certificates/swarm-node.crt
Pour restaurer, faire (non testé) :
sudo systemctl stop docker
sudo tar -xzvf swarm-backup.tar.gz -C /
sudo systemctl start docker
Le status des noeuds de mon swarm :
ansible@s001:~$ sudo docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
k232lszqgaa76qas459m9v9c1 * s001 Ready Active Reachable 24.0.4
0u3khzcl9z51ht6mkm4faejxw s002 Ready Active Leader 24.0.4
ljt3zkvuzii9f90k7o0g5jx6d s003 Ready Active Reachable 24.0.4
wvjk3zj5trf7shi8sk4lwaiau s004 Ready Active 24.0.4
julb8p7h0lakc89ivtmhmtmhd s005 Ready Active 24.0.4
yt8tm5wpiigklqt3zi7n1x2q8 s008 Ready Active 24.0.4
Je vais d'abord enlever le rôle de manager à s003. s002 devrait rester Leader.
Puis je vais enlever le rôle de manager à s002 donc s001 sera le seul manager restant
et devrait devenir Leader.
Commandes
ansible@s001:~$ sudo docker node demote ljt3zkvuzii9f90k7o0g5jx6d
Manager ljt3zkvuzii9f90k7o0g5jx6d demoted in the swarm.
ansible@s001:~$ sudo docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
k232lszqgaa76qas459m9v9c1 * s001 Ready Active Reachable 24.0.4
0u3khzcl9z51ht6mkm4faejxw s002 Ready Active Leader 24.0.4
ljt3zkvuzii9f90k7o0g5jx6d s003 Ready Active 24.0.4
wvjk3zj5trf7shi8sk4lwaiau s004 Ready Active 24.0.4
julb8p7h0lakc89ivtmhmtmhd s005 Ready Active 24.0.4
yt8tm5wpiigklqt3zi7n1x2q8 s008 Ready Active 24.0.4
ansible@s001:~$ sudo docker node demote 0u3khzcl9z51ht6mkm4faejxw
Manager 0u3khzcl9z51ht6mkm4faejxw demoted in the swarm.
ansible@s001:~$ sudo docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
k232lszqgaa76qas459m9v9c1 * s001 Ready Active Leader 24.0.4
0u3khzcl9z51ht6mkm4faejxw s002 Ready Active 24.0.4
ljt3zkvuzii9f90k7o0g5jx6d s003 Ready Active 24.0.4
wvjk3zj5trf7shi8sk4lwaiau s004 Ready Active 24.0.4
julb8p7h0lakc89ivtmhmtmhd s005 Ready Active 24.0.4
yt8tm5wpiigklqt3zi7n1x2q8 s008 Ready Active 24.0.4
Je teste :
- l'accès à l'admin de Keycloak fonctionne
- l'accès au datalake de DEV puis de PROD ISTA, en passant par Keycloak fonctionne
Je dois maintenant retirer s002 et s003 du swarm. Je veux le faire avec ansible.
Je mets à jour mon inventaire :
swarm01_nodes:
children:
# Must be one of the Swarm managers hosts (only the first host is used)
swarm_initiator:
hosts:
s001:
# Hosts that will be Swarm manager (at least one)
swarm01_managers:
hosts:
s001:
# Hosts that will be Swarm worker. Must not be in Swarm managers list.
swarm01_workers:
hosts:
s004:
s005:
s008:
# Hosts that will be remove from Swarm
swarm01_leave:
hosts:
s002:
s003:
Puis je fais la commande : ansible-playbook -i ansible/inventory.yml ansible/02-swarm.yaml --tags swarm-leave -e "infra=swarm01".
Elle est restée bloquée après avoir affichée Ok [s002]. J'ai donc fait aussi la commande sudo docker swarm leave directement sur s002
qui a réussi car elle a affiché : Node left the swarm..
s002 ne fait plus partie du swarm01
ansible@s001:~$ sudo docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
k232lszqgaa76qas459m9v9c1 * s001 Ready Active Leader 24.0.4
0u3khzcl9z51ht6mkm4faejxw s002 Down Active 24.0.4
ljt3zkvuzii9f90k7o0g5jx6d s003 Ready Active 24.0.4
wvjk3zj5trf7shi8sk4lwaiau s004 Ready Active 24.0.4
julb8p7h0lakc89ivtmhmtmhd s005 Ready Active 24.0.4
yt8tm5wpiigklqt3zi7n1x2q8 s008 Ready Active 24.0.4
Mais j'ai un problème car Portainer était stické sur s002.
Comment j'ai rétabli Portainer
J'ai d'abord mis le tag qui sticke Portainer sur s001 avec la commande
sudo docker node update --label-add portainer.portainer-data=true k232lszqgaa76qas459m9v9c1.
Portainer a démarré mais comme si je venais de l'installer. Je dois donc transférer le contenu
du volume de s002 vers s001.
J'ai commencé par arrêter le service de Portainer qui utilise le volume avec cette commande sur s001 :
sudo docker service scale portainer_portainer=0.
Puis j'ai transféré depuis mon poste avec ces 3 commandes :
ssh swarm01-s002 "sudo tar czf - /var/lib/docker/volumes/portainer_portainer-data/_data" > portainer_portainer-data/portainer-data.tar.gzscp portainer_portainer-data/portainer-data.tar.gz swarm01-s001:/home/ansible/portainer-data.tar.gzssh swarm01-s001 "sudo tar xzf /home/ansible/portainer-data.tar.gz -C /home/ansible/ && sudo mv /home/ansible/var/lib/docker/volumes/portainer_portainer-data/_data/* /var/lib/docker/volumes/portainer_portainer-data/_data && sudo rm -rf /var/lib/docker/volumes/portainer_portainer-data/var"
Je redémarre le service avec sudo docker service scale portainer_portainer=1. J'arrive à me connecter.
Je vois le swarm et je vois qu'il a 49 stacks mais je n'arrive pas à lister les stacks ni les services.
Par contre je vois la liste des containers.
J'ai des messages d'erreur "Unable to retrieve stacks" ou "Unable to retreive services". Parfois les stacks
se sont affichées mais les services jamais.
Je décide de publier à nouveau portainer sur s001 avec ansible et la commande :
ansible-playbook -i ansible/inventory.yml ansible/04-swarm01-utility-stacks.yaml --tags portainer
(j'ai changé hosts: s002 par hosts: s001 avant).
Les agents de chaque node redémarrent (comme je le pensais) et, maintenant, mon portainer fonctionne à nouveau comme avant.
Je vois toujours s002 avec la commande sudo docker node ls exécutée sur s001. Il a le statut down
depuis que je l'ai retiré du swarm.
Je fais la commande sudo docker node rm 0u3khzcl9z51ht6mkm4faejxw pour l'enlever définitivement de la
liste.
Je passe à s003.
Sur s003, je fais la commande sudo docker swarm leave qui réussie avec le retour Node left the swarm..
Comme s002, s003 reste présent avec le statut down dans la liste de sudo docker node ls.
Je le supprime donc avec la commande sudo docker node rm s003. Ca fonctionne : je n'ai plus que 4 serveurs
dans swarm01.
J'arrête là pour aujourd'hui. Je supprimerai les machines la semaine prochaine.
Links¶
Dependencies¶
swarm01-sftp¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Serveur SFTP de ComputableFacts sur swarm01. Domaine communiqué aux clients : sftp.computablefacts.com
Events¶
2025-01-08 - 14:00 - Désactivation de l'accès SFTP de la Smacl
La Smacl a résilié son contrat avec nous.
J'ai donc désactivé les 3 comptes qui leur permettaient de déposer des fichiers sur notre SFTP.
Links¶
Dependencies¶
swarm01-swarmprom¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Ensemble d'outils pour surveiller le Docker Swarm swarm01
Links¶
Dependencies¶
towerify-cli-install_dev¶
[Système : cywise] [Lifecycle : production] [Subtype : yunohost]
Towerify CLI installation - acme
Links¶
Dependencies¶
towerify-cli-install_prod¶
[Système : cywise] [Lifecycle : production] [Subtype : yunohost]
Towerify CLI Installation PROD
Links¶
Dependencies¶
towerify-docs_dev¶
[Système : cywise] [Lifecycle : dev] [Subtype : yunohost]
Towerify Docs DEV
Links¶
Dependencies¶
towerify-docs_prod¶
[Système : cywise] [Lifecycle : production] [Subtype : yunohost]
Towerify Docs PROD
Links¶
Dependencies¶
traefik-public¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Traefik déployé sur swarm01
Events¶
2025-01-10 - 16:30 - Mise à jour des certificats SSL dans l'image du container de Traefik
Comme nous avons réduit le nombre de clients utilisant swarm01, nous voulons réduire le nombre de machines. Je veux commencer par retirer les 2 managers. Mais je risque de déplacer le container de Traefik et de provoquer le regénération des certificats. Et, pire, si je sature Let's Encrypt, de ne pas réussir à les regénérer...
J'ai donc récupéré les fichiers /etc/acme.json et /etc/acme-tls.json pour les mettre à jour dans la repo cf-infra puis j'ai mis à jour Traefik (cela reconstruit l'image Docker avec la dernière version des certificats donc en cas de redémarrage, pas besoin de les mettre à jour).
Pas d'interruption perceptible.
Links¶
Dependencies¶
-
Deprecated: Resource - deployment - dev-ista-cf-ui
-
Deprecated: Resource - deployment - staging-ista-cf-ui
-
Deprecated: Resource - deployment - prod-ista-cf-ui
-
Deprecated: Resource - deployment - dev-modules-ista-api1
-
Deprecated: Resource - deployment - staging-modules-ista-api1
-
Deprecated: Resource - deployment - prod-modules-ista-api1
-
Deprecated: Resource - deployment - dev-modules-ista-passeport-immeuble
-
Deprecated: Resource - deployment - staging-modules-ista-passeport-immeuble
-
Deprecated: Resource - deployment - prod-modules-ista-passeport-immeuble
-
Deprecated: Resource - deployment - dev-modules-ista-ciblage-commercial
-
Deprecated: Resource - deployment - staging-modules-ista-ciblage-commercial
-
Deprecated: Resource - deployment - prod-modules-ista-ciblage-commercial
-
Deprecated: Resource - deployment - dev-sentinel-cf-ui
-
Deprecated: Resource - deployment - staging-sentinel-cf-ui
-
Deprecated: Resource - deployment - cf-ui-sentinel-prod
-
Deprecated: Resource - deployment - ista-superset
-
Deprecated: Resource - deployment - ista-jenkins
-
Deprecated: Resource - deployment - lurberri-superset
-
Deprecated: Resource - deployment - lurberri-jenkins
-
Deprecated: Resource - deployment - common-jenkins
-
Deprecated: Resource - deployment - dev-lurberri-cf-ui
-
Deprecated: Resource - deployment - staging-lurberri-cf-ui
-
Deprecated: Resource - deployment - prod-lurberri-cf-ui
-
Deprecated: Resource - deployment - ista-agent-portainer
-
Deprecated: Resource - deployment - dev-appscompose-cf-ui
-
Deprecated: Resource - deployment - appscompose-jenkins
-
Deprecated: Resource - deployment - common-superset
-
Deprecated: Resource - deployment - smacl-jenkins
-
Deprecated: Resource - deployment - dev-smacl-cf-ui
-
Deprecated: Resource - deployment - staging-smacl-cf-ui
-
Deprecated: Resource - deployment - prod-smacl-cf-ui
-
Deprecated: Resource - deployment - dev-smacl-module
-
Deprecated: Resource - deployment - staging-smacl-module
-
Deprecated: Resource - deployment - prod-smacl-module
-
Deprecated: Resource - deployment - dev-modules-smacl-contracts
-
Deprecated: Resource - deployment - staging-modules-smacl-contracts
-
Deprecated: Resource - deployment - prod-modules-smacl-contracts
twr-mysql-backup_angardia-ai¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Backup des bases de angardia-ai vers S3
Events¶
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.
Links¶
Dependencies¶
twr-mysql-backup_cywise¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Backup des bases de yunohost-cywise vers S3
Events¶
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.
Links¶
Dependencies¶
twr-mysql-backup_ista-dev¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Backup des bases de yunohost-ista-dev vers S3
Events¶
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.
Links¶
Dependencies¶
twr-mysql-backup_ista-prod¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Backup des bases de yunohost-ista-prod vers S3
Events¶
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.
Links¶
Dependencies¶
twr-once-campfire_prod¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Chat pour ComputableFacts
Links¶
Dependencies¶
twr-openobserve_prod¶
[Système : None] [Lifecycle : production] [Subtype : stack]
OpenObserve pour ComputableFacts
Links¶
Dependencies¶
yunohost-addapps-jenkins¶
[Système : cywise] [Lifecycle : production] [Subtype : yunohost]
Jenkins déployé sur yunohost-addapps
Events¶
2025-05-22 - 07:45 - Mise à jour du Jenkins de AddApps
Je mets à jour les plugins du Jenkins de AddApps : 88 mises à jour disponibles dans l'UI.
Puis, je mets à jour Jenkins lui-même en utilisant l'UI Admin de YunoHost, activée pour l'occasion.
Dans cf_custom, je bascule sur le catalogue par défaut. Puis je vais dans "Mise à jour du système". YunoHost détecte une nouvelle version de Jenkins : 2.510~ynh1. Je lance la mise à jour depuis l'UI Admin. Dans cf_custom, je remets notre catalogue spécifique.
Passage de la version 2.479.2~ynh1 à la version 2.510~ynh1.
J'ai dû remettre client_max_body_size 100m; (à la place de 10m) dans la conf nginx de Jenkins
(fichier /etc/nginx/conf.d/jenkins.myapps.addapps.io.d/jenkins.conf)
2025-02-09 - 11:10 - Problème de déploiement de Cywise avec Jenkins
Cyrille par slack :
je ne peux pas déployer mon fix, j'ai la même erreur Jenkins que Marlène
Ce n'était pas la même erreur, pas les dossiers durable-xxx, mais un problème de récupération
de la repo Git https://github.com/computablefacts/towerify.git.
Après plusieurs essais de résolution infructeux, j'ai décidé de supprimer le job cywise-ui_dev.
Le towerify deploy suivant de Cyrille l'a recréé et le déploiement a fonctionné.
J'ai supprimé également le job cywise-ui_prod qui avait le même problème.
TODOs¶
- Configurer ce Jenkins pour avoir un message dans le Slack de CF après chaque build
Links¶
Dependencies¶
yunohost-addapps-portainer¶
[Système : None] [Lifecycle : production] [Subtype : stack]
Portainer déployé sur yunohost-addapps
Events¶
2025-01-14 - Mise à jour de Portainer 2.21.5 avec le package portainer_ynh de YunoHost sur yunohost-dev02 puis sur yunohost-addapps
Comme je dois corriger le hook conf_regen du package portainer_ynh, je vais en
profiter pour mettre à jour la version du container Portainer que nous utilisons.
J'ai corrigé le hook. Je suis passé de la version 2.19.1 à la version 2.21.5 de Portainer (dernière LTS).
J'ai mis à jour notre catalogue d'applications YunoHost.
Sur yunohost-dev02, la nouvelle version a bien été détectée.
J'ai fait la mise à jour sans erreur.
Mon Portainer est à jour et fonctionne correctement sur yunohost-dev02.
J'ai fait de même avec le Portainer de yunohost-addapps.
2025-01-14 - Problème d'accès au Portainer de yunohost-addapps et de yunohost-dev02
Il y a le même problème que pour Postface : l'accès au LDAP depuis le container de Portainer ne fonctionne plus.
Détails de ma manip sur yunohost-dev02
J'ai bien SLAPD_SERVICES="ldap://localhost:389/ ldaps:/// ldapi:///"
dans la conf /etc/default/slapd.
Quand je fais la commande qui met à jour la conf et qui doit appliquer le hook de portainer_ynh, je n'ai pas de différence :
twr_admin@dev02:~$ sudo yunohost tools regen-conf slapd --dry-run --with-diff
twr_admin@dev02:~$
Je modifie le hook /etc/yunohost/hooks.d/conf_regen/50-portainer pour ajouter
cette ligne :
ynh_replace_string --match_string="^SLAPD_SERVICES=\"ldap://localhost:389/ ldaps:/// ldapi:///\"" --replace_string="SLAPD_SERVICES=\"ldap:/// ldaps:/// ldapi:///\"" --target_file="${slapd_conf}"
Mais la commande ne trouve aucune différence à nouveau :
twr_admin@dev02:~$ sudo yunohost tools regen-conf slapd --dry-run --with-diff
twr_admin@dev02:~$
Par contre, quand je demande les différences pour tous les fichiers (pas que slapd), YunoHost m'affiche des différences pour slapd :
twr_admin@dev02:~$ sudo yunohost tools regen-conf --dry-run --with-diff
Success! The configuration would have been updated for category 'slapd'
Success! The configuration would have been updated for category 'dnsmasq'
Warning: The configuration file '/etc/fail2ban/jail.conf' has been manually modified and will not be updated
...
slapd:
applied:
/etc/default/slapd:
diff: @@ -21,7 +21,7 @@
# sockets.
# Example usage:
# SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///"
-SLAPD_SERVICES="ldap://localhost:389/ ldaps:/// ldapi:///"
+SLAPD_SERVICES="ldap:/// ldaps:/// ldapi:///"
# If SLAPD_NO_START is set, the init script will not start or restart
# slapd (but stop will still work). Uncomment this if you are
status: updated
pending:
Donc mon hook corrigé fonctionne. Mais je ne veux pas mettre à jour les autres fichiers de conf
donc je modifie à la main /etc/default/slapd.
Puis je redémarre slapd avec la commande sudo systemctl restart slapd.service.
Le problème est résolu.
J'applique la même méthode pour résoudre le problème sur yunohost-addapps.
Links¶
Dependencies¶
yunohost-dev02-jenkins¶
[Système : None] [Lifecycle : dev] [Subtype : stack]
Jenkins déployé sur yunohost-dev02
Links¶
Dependencies¶
yunohost-dev02-portainer¶
[Système : None] [Lifecycle : dev] [Subtype : stack]
Portainer déployé sur yunohost-dev02
Events¶
2025-01-14 - Mise à jour de Portainer 2.21.5 avec le package portainer_ynh de YunoHost sur yunohost-dev02 puis sur yunohost-addapps
Comme je dois corriger le hook conf_regen du package portainer_ynh, je vais en
profiter pour mettre à jour la version du container Portainer que nous utilisons.
J'ai corrigé le hook. Je suis passé de la version 2.19.1 à la version 2.21.5 de Portainer (dernière LTS).
J'ai mis à jour notre catalogue d'applications YunoHost.
Sur yunohost-dev02, la nouvelle version a bien été détectée.
J'ai fait la mise à jour sans erreur.
Mon Portainer est à jour et fonctionne correctement sur yunohost-dev02.
J'ai fait de même avec le Portainer de yunohost-addapps.
2025-01-14 - Problème d'accès au Portainer de yunohost-addapps et de yunohost-dev02
Il y a le même problème que pour Postface : l'accès au LDAP depuis le container de Portainer ne fonctionne plus.
Détails de ma manip sur yunohost-dev02
J'ai bien SLAPD_SERVICES="ldap://localhost:389/ ldaps:/// ldapi:///"
dans la conf /etc/default/slapd.
Quand je fais la commande qui met à jour la conf et qui doit appliquer le hook de portainer_ynh, je n'ai pas de différence :
twr_admin@dev02:~$ sudo yunohost tools regen-conf slapd --dry-run --with-diff
twr_admin@dev02:~$
Je modifie le hook /etc/yunohost/hooks.d/conf_regen/50-portainer pour ajouter
cette ligne :
ynh_replace_string --match_string="^SLAPD_SERVICES=\"ldap://localhost:389/ ldaps:/// ldapi:///\"" --replace_string="SLAPD_SERVICES=\"ldap:/// ldaps:/// ldapi:///\"" --target_file="${slapd_conf}"
Mais la commande ne trouve aucune différence à nouveau :
twr_admin@dev02:~$ sudo yunohost tools regen-conf slapd --dry-run --with-diff
twr_admin@dev02:~$
Par contre, quand je demande les différences pour tous les fichiers (pas que slapd), YunoHost m'affiche des différences pour slapd :
twr_admin@dev02:~$ sudo yunohost tools regen-conf --dry-run --with-diff
Success! The configuration would have been updated for category 'slapd'
Success! The configuration would have been updated for category 'dnsmasq'
Warning: The configuration file '/etc/fail2ban/jail.conf' has been manually modified and will not be updated
...
slapd:
applied:
/etc/default/slapd:
diff: @@ -21,7 +21,7 @@
# sockets.
# Example usage:
# SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///"
-SLAPD_SERVICES="ldap://localhost:389/ ldaps:/// ldapi:///"
+SLAPD_SERVICES="ldap:/// ldaps:/// ldapi:///"
# If SLAPD_NO_START is set, the init script will not start or restart
# slapd (but stop will still work). Uncomment this if you are
status: updated
pending:
Donc mon hook corrigé fonctionne. Mais je ne veux pas mettre à jour les autres fichiers de conf
donc je modifie à la main /etc/default/slapd.
Puis je redémarre slapd avec la commande sudo systemctl restart slapd.service.
Le problème est résolu.
J'applique la même méthode pour résoudre le problème sur yunohost-addapps.
Links¶
Dependencies¶
yunohost-dev02-tika_ds¶
[Système : None] [Lifecycle : dev] [Subtype : stack]
Tika déployé sur yunohost-dev02
Links¶
Dependencies¶
yunohost-ista-dev_jenkins¶
[Système : ista] [Lifecycle : dev] [Subtype : yunohost]
Jenkins déployé sur yunohost-ista-dev
Events¶
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-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
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
Links¶
Dependencies¶
yunohost-ista-prod_jenkins¶
[Système : ista] [Lifecycle : production] [Subtype : yunohost]
Jenkins déployé sur yunohost-ista-prod
Détails¶
Ce Jenkins pour ISTA installé sur leur Towerify est utilisé également pour mettre à jour les Datasets grâce à ce Job.
Manipulations¶
Résolution d'un problème de mise à jour du Jenkins
Events¶
2025-01-09 - 11:40 - Problème avec le Job to Dataset qui appelait l'ancienne URL de api1
Matthieu remonte un problème avec le Job to Dataset du Jenkins de PROD : l'URL de api1 n'était pas la bonne (c'était l'ancienne). Voir le ticket #8740.
J'ai résolu le problème le lendemain 2025-01-10.
Links¶
Dependencies¶
yunohost-ista-yunohost¶
[Système : ista] [Lifecycle : production] [Subtype : manual]
YunoHost déployé sur yunohost-ista-prod