alpinux.cedrica5l/alpinux-owni

Fork 0

Les alertes de certificats n'atteignent personne : owni-certs-sync hors de cronwrap #6

New issue

Closed

opened 2026-09-27 09:54:27 +02:00 by Cédric A5L · 1 comment

Cédric A5L commented

2026-09-27 09:54:27 +02:00

Owner

owni-certs-sync.sh a signalé l'expiration du certificat de
cloud.alpinux.org chaque nuit pendant 54 jours, et personne ne l'a vu.
Le site est hors service en HTTPS depuis le 4 août (#5).

La cause est nette

La machine a un tableau de bord — admin.alpinux.org — alimenté par
cronwrap, qui écrit un état JSON par tâche dans
/var/lib/alpinux-admin/crons/ : dernier passage, durée, code de retour,
échecs consécutifs.

Quatre tâches y figurent :

  certbot          (« Certificats — renouvellement »)
  dolibarr-jobs
  goaccess
  wiki-calendrier

owni-certs-sync.sh n'y est pas. Il tourne depuis /etc/cron.d/owni-certs-sync
avec MAILTO=root, hors du dispositif de surveillance :

20 4 * * * root /usr/local/sbin/owni-certs-sync.sh --fix --quiet

Un courriel vers root sur une machine dont personne ne lit la boîte locale
n'est pas une alerte. Et c'est d'autant plus dommage que le script rend déjà
le bon code : 0 si tout est cohérent, 1 s'il subsiste une anomalie —
exactement ce que cronwrap sait interpréter.

Ironie du dispositif : certbot renew est surveillé, mais pas le script qui
vérifie que le renouvellement a bien été appliqué. On surveille l'étape qui
marche et pas celle qui casse.

Le correctif minimal

20 4 * * * root /usr/local/bin/cronwrap certs-sync \
    --label "Certificats — cohérence des copies" --period 86400 \
    -- /usr/local/sbin/owni-certs-sync.sh --fix --quiet

Une ligne. À partir de là, l'anomalie de cloud apparaît sur
admin.alpinux.org avec son compteur d'échecs consécutifs, et se voit.

Ce qu'on peut faire de mieux, si l'envie vient

Le tableau de bord n'affiche aujourd'hui que « la tâche a échoué ». Pour les
certificats, ce qui compte est quel domaine, et dans combien de jours.
owni-certs-sync.sh connaît déjà ces valeurs (il applique un seuil de 21
jours) : il pourrait écrire un second JSON, une ligne par domaine —
expiration, mécanisme, état — qu'admin.alpinux.org afficherait en tableau.

On saurait alors d'un coup d'œil que dix noms dépendent d'un même certificat,
et qu'il expire dans 49 jours.

Et les autres tâches non surveillées

Le même examen montre que le worker de la messagerie tourne aussi hors
cronwrap, chaque minute. Là, c'est délibéré — une tâche à la minute
saturerait le tableau de bord — mais il vaut la peine de décider quelles
tâches méritent d'être vues, plutôt que de le laisser au hasard de qui a
écrit quoi.

`owni-certs-sync.sh` a signalé l'expiration du certificat de `cloud.alpinux.org` **chaque nuit pendant 54 jours**, et personne ne l'a vu. Le site est hors service en HTTPS depuis le 4 août (#5). ## La cause est nette La machine a un tableau de bord — `admin.alpinux.org` — alimenté par `cronwrap`, qui écrit un état JSON par tâche dans `/var/lib/alpinux-admin/crons/` : dernier passage, durée, code de retour, échecs consécutifs. Quatre tâches y figurent : ``` certbot (« Certificats — renouvellement ») dolibarr-jobs goaccess wiki-calendrier ``` **`owni-certs-sync.sh` n'y est pas.** Il tourne depuis `/etc/cron.d/owni-certs-sync` avec `MAILTO=root`, hors du dispositif de surveillance : ```cron 20 4 * * * root /usr/local/sbin/owni-certs-sync.sh --fix --quiet ``` Un courriel vers `root` sur une machine dont personne ne lit la boîte locale n'est pas une alerte. Et c'est d'autant plus dommage que le script **rend déjà le bon code** : `0` si tout est cohérent, `1` s'il subsiste une anomalie — exactement ce que `cronwrap` sait interpréter. Ironie du dispositif : `certbot renew` est surveillé, mais pas le script qui vérifie que le renouvellement a bien été **appliqué**. On surveille l'étape qui marche et pas celle qui casse. ## Le correctif minimal ```cron 20 4 * * * root /usr/local/bin/cronwrap certs-sync \ --label "Certificats — cohérence des copies" --period 86400 \ -- /usr/local/sbin/owni-certs-sync.sh --fix --quiet ``` Une ligne. À partir de là, l'anomalie de `cloud` apparaît sur `admin.alpinux.org` avec son compteur d'échecs consécutifs, et se voit. ## Ce qu'on peut faire de mieux, si l'envie vient Le tableau de bord n'affiche aujourd'hui que « la tâche a échoué ». Pour les certificats, ce qui compte est **quel domaine, et dans combien de jours**. `owni-certs-sync.sh` connaît déjà ces valeurs (il applique un seuil de 21 jours) : il pourrait écrire un second JSON, une ligne par domaine — expiration, mécanisme, état — qu'`admin.alpinux.org` afficherait en tableau. On saurait alors d'un coup d'œil que dix noms dépendent d'un même certificat, et qu'il expire dans 49 jours. ## Et les autres tâches non surveillées Le même examen montre que le **worker de la messagerie** tourne aussi hors `cronwrap`, chaque minute. Là, c'est délibéré — une tâche à la minute saturerait le tableau de bord — mais il vaut la peine de décider quelles tâches méritent d'être vues, plutôt que de le laisser au hasard de qui a écrit quoi.

Cédric A5L commented

2026-09-27 10:05:51 +02:00

Author

Owner

Fait, et l'anomalie remonte déjà

/etc/cron.d/owni-certs-sync passe désormais par cronwrap :

MAILTO=""
20 4 * * * root /usr/local/bin/cronwrap certs-sync \
    --label "Certificats — cohérence des copies" --period 86400 \
    -- /usr/local/sbin/owni-certs-sync.sh --fix --quiet

MAILTO passe de root à vide : c'est cronwrap qui décide désormais s'il faut
alerter, comme pour les quatre autres tâches. L'ancien fichier est gardé en
/root/owni-certs-sync.avant-cronwrap.

Le commentaire en tête du fichier dit pourquoi, pour que personne ne le
défasse : l'alerte partait vers une boîte que personne ne lit, et l'expiration
de cloud.alpinux.org a été signalée chaque nuit pendant 54 jours sans être
vue.

Vérifié sans attendre 4 h 20

La tâche a été déclenchée à la main, et admin.alpinux.org a désormais son
état :

  label                  Certificats — cohérence des copies
  code de retour         1
  échecs consécutifs     1
  durée                  1,45 s
  dernier passage        2026-09-27 10:05
  sortie retenue :
     ORPHELIN  cloud.alpinux.org — expiré depuis 53 j et inconnu de certbot
     1 anomalie(s) subsistante(s).

L'anomalie est donc visible sur le tableau de bord, avec son compteur
d'échecs consécutifs qui montera tant que #5 ne sera pas réglé. C'était tout
l'objet de ce ticket.

Le --period 86400 fait aussi surveiller le silence : si la tâche cessait de
tourner, cronwrap le signalerait — une tâche muette est aussi inquiétante
qu'une tâche en échec.

Ce qui reste, et qui n'est pas dans ce ticket

L'idée d'un second JSON, une ligne par domaine — expiration, mécanisme,
état — reste ouverte. Aujourd'hui le tableau de bord dit « cette tâche
échoue » et donne les trois dernières lignes de sortie ; il ne dit pas d'un
coup d'œil que dix noms dépendent du même certificat et qu'il expire dans
49 jours. C'est un confort, pas un manque : l'alerte, elle, passe.

## Fait, et l'anomalie remonte déjà `/etc/cron.d/owni-certs-sync` passe désormais par cronwrap : ```cron MAILTO="" 20 4 * * * root /usr/local/bin/cronwrap certs-sync \ --label "Certificats — cohérence des copies" --period 86400 \ -- /usr/local/sbin/owni-certs-sync.sh --fix --quiet ``` `MAILTO` passe de `root` à vide : c'est cronwrap qui décide désormais s'il faut alerter, comme pour les quatre autres tâches. L'ancien fichier est gardé en `/root/owni-certs-sync.avant-cronwrap`. Le commentaire en tête du fichier dit pourquoi, pour que personne ne le défasse : l'alerte partait vers une boîte que personne ne lit, et l'expiration de `cloud.alpinux.org` a été signalée chaque nuit pendant 54 jours sans être vue. ## Vérifié sans attendre 4 h 20 La tâche a été déclenchée à la main, et `admin.alpinux.org` a désormais son état : ``` label Certificats — cohérence des copies code de retour 1 échecs consécutifs 1 durée 1,45 s dernier passage 2026-09-27 10:05 sortie retenue : ORPHELIN cloud.alpinux.org — expiré depuis 53 j et inconnu de certbot 1 anomalie(s) subsistante(s). ``` L'anomalie est donc **visible sur le tableau de bord**, avec son compteur d'échecs consécutifs qui montera tant que #5 ne sera pas réglé. C'était tout l'objet de ce ticket. Le `--period 86400` fait aussi surveiller le silence : si la tâche cessait de tourner, cronwrap le signalerait — une tâche muette est aussi inquiétante qu'une tâche en échec. ## Ce qui reste, et qui n'est pas dans ce ticket L'idée d'un **second JSON, une ligne par domaine** — expiration, mécanisme, état — reste ouverte. Aujourd'hui le tableau de bord dit « cette tâche échoue » et donne les trois dernières lignes de sortie ; il ne dit pas d'un coup d'œil que dix noms dépendent du même certificat et qu'il expire dans 49 jours. C'est un confort, pas un manque : l'alerte, elle, passe.

Cédric A5L closed this issue

2026-09-27 10:05:51 +02:00

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: alpinux.cedrica5l/alpinux-owni#6

No description provided.