les correctifs de securite reviennent au quotidien, sans personne

Decision de l exploitant, et elle corrige un mauvais jugement de ma part :
j avais decrit la situation correctement — la seule operation de la flotte
qui exige un humain — puis propose un minuteur maison plutot que le mecanisme
que Debian fournit exactement pour ca.

Le desarmement d aout avait un motif reel (48 minutes de verrou dpkg apres un
rattrapage) mais une contrepartie ecrite sans etre mesuree. Ce qui rend la
coexistence tenable existe maintenant : _attendre-hote attend apt-daily et le
verrou, lock_timeout est pose partout, unattended-upgrades ne traite que
l origine -security, et Automatic-Reboot reste false.

Rearmer ne se deduit pas de ne plus desarmer : passer le drapeau a false
saute la tache, il ne demasque rien. Une tache de rearmement explicite est
donc posee le jour meme ou la decision s inverse.

ET LA PREMIERE VERSION A REJOUE LA COURSE. state: started sur les trois
unites lance le rattrapage en plein deploiement : dix machines sur vingt et
une, avec l erreur meme qui avait motive le masquage. Le travail quotidien ne
passe pas par ce service — le timer appelle apt.systemd.daily directement. On
ARME sans declencher : les minuteurs demarres, le service seulement active.

21 machines, minuteurs armes, prochain passage demain vers 06h, zero unite en
echec.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q

CHANGELOG.md

@@ -1,5 +1,67 @@
 # CHANGELOG — Set-OPS
 
+## 2026-09-11 (5) — Les correctifs de securite reviennent au quotidien, sans personne
+
+Decision de l'exploitant, et elle corrige un mauvais jugement de ma part. J'avais decrit
+la situation correctement — « la seule operation de la flotte qui exige un humain » — puis
+propose un minuteur MAISON pour appliquer le socle, plutot que le mecanisme que Debian
+fournit exactement pour ca.
+
+### Ce qui etait desarme, et pourquoi ca ne tenait plus
+
+Depuis le 2026-08-25, `common_packages` masquait `apt-daily.timer`,
+`apt-daily-upgrade.timer` et `unattended-upgrades.service` sur toute la flotte.
+
+LE MOTIF ETAIT REEL : apres six redemarrages et des heures sans reseau, le rattrapage
+d'`unattended-upgrades` a tenu le verrou dpkg 48 minutes et fait echouer trois
+deploiements de suite.
+
+MAIS LA CONTREPARTIE ETAIT ECRITE ICI SANS ETRE MESUREE — « les correctifs ne s'appliquent
+plus qu'au passage de Set-OPS ». Mesure le 2026-09-11 : les sauvegardes tournent seules,
+les certificats se renouvellent seuls, la sante se rapporte seule. Les correctifs, non.
+Une absence de trois jours devenait une exposition sur vingt et une machines.
+
+### Ce qui rend la coexistence tenable, et qui n'existait pas en aout
+
+    _attendre-hote        attend apt-daily* ET le verrou avant tout deploiement
+    lock_timeout: 300     pose en module_defaults sur chaque playbook de groupe
+    Origins-Pattern       `-security` SEULEMENT — pas un `upgrade: full`
+    Automatic-Reboot      false : aucun demon ne redemarre un service seul
+
+La course de premier demarrage reste. Elle est desormais ATTENDUE plutot que supprimee —
+c'est la difference entre subir un concurrent et le connaitre.
+
+### Rearmer ne se deduit pas de ne plus desarmer
+
+Passer le drapeau a `false` SAUTE la tache de desarmement ; il ne defait rien. Une machine
+deja masquee le serait restee pour toujours, et le drapeau aurait dit le contraire de
+l'etat reel. Une tache de rearmement explicite est donc posee le jour meme ou la decision
+s'inverse — masque retire, unite activee, unite demarree.
+
+### On arme, on ne declenche pas — et la nuance a coute dix machines
+
+La premiere version du rearmement faisait `state: started` sur les trois unites. Demarrer
+`unattended-upgrades.service` apres des semaines de masquage lance son RATTRAPAGE
+immediatement — en plein deploiement :
+
+    'apt-get autoremove' failed: E: Could not get lock /var/lib/dpkg/lock-frontend.
+    It is held by process 185135 (unattended-upgr)
+
+Exactement la course qui avait motive le desarmement en aout, rejouee par la tache censee
+le defaire, et malgre `lock_timeout: 300`. Dix machines sur vingt et une.
+
+LE TRAVAIL QUOTIDIEN NE PASSE PAS PAR CE SERVICE : `apt-daily-upgrade.timer` appelle
+`apt.systemd.daily`, qui invoque `unattended-upgrade` lui-meme. Le `.service` ne sert
+qu'aux passages de demarrage et d'extinction. L'ACTIVER suffit — il partira au prochain
+redemarrage, sur une machine au repos. Armer un minuteur, en revanche, ne declenche pas
+sa cible : il la programme.
+
+### Ce que la sonde `correctifs` devient
+
+Elle ne mesure plus un geste manquant mais un mecanisme en panne. Son seuil de 72 h
+cesse d'etre une tolerance pour devenir une alarme : avec un passage quotidien, trois
+jours de retard veulent dire que quelque chose ne tourne plus.
+
 ## 2026-09-11 (4) — L'heure vient de la frontiere : la derniere dependance vivante tombe
 
 L'exploitant a presume qu'un ecosysteme fonctionnel n'avait plus besoin d'Internet pour ses

roles/common_packages/defaults/main.yml

@@ -51,26 +51,37 @@ common_packages_list:
 # jour automatiques de Debian le tiennent par vagues pendant plusieurs minutes.
 common_packages_lock_timeout: 300
 
-# --- QUI DÉCIDE DE CE QUI S'INSTALLE (2026-08-25) -----------------------------
+# --- QUI DÉCIDE DE CE QUI S'INSTALLE ------------------------------------------
 #
-# Debian arme `unattended-upgrades` et les minuteurs `apt-daily` par défaut. Set-OPS
-# applique DÉJÀ les mises à jour, explicitement, dans ce rôle. **Deux mécanismes font le
-# même travail sur la même flotte, et se disputent le même verrou dpkg.**
+# RÉARMÉ LE 2026-09-11, SUR DÉCISION DE L'EXPLOITANT. C'était `true` depuis le
+# 2026-08-25 : Set-OPS désarmait `unattended-upgrades` et les minuteurs `apt-daily`
+# pour rester seul maître du verrou dpkg.
 #
-# Sur une machine tranquille ça ne se voit jamais. Après six redémarrages et des heures
-# sans réseau — ce qu'a vécu le site le 2026-08-25 — `unattended-upgrades` rattrape tout
-# son retard et tient le verrou 48 minutes. `lock_timeout` vaut 300 s : les déploiements
-# échouent, trois fois de suite, sur une course que personne n'a décidée.
+# LE MOTIF ÉTAIT RÉEL. Après six redémarrages et des heures sans réseau, le rattrapage
+# d'`unattended-upgrades` a tenu le verrou 48 minutes et fait échouer trois déploiements
+# de suite. La course existait.
 #
-# Allonger l'attente serait un pansement : on patienterait plus longtemps devant un
-# concurrent qu'on n'a pas voulu. On désarme donc, et Set-OPS reste seul maître de ce qui
-# s'installe — un écosystème souverain ne laisse pas un démon décider seul quand redémarrer
-# ses services.
+# MAIS LE REMÈDE COÛTAIT PLUS CHER QUE LE MAL, et sa contrepartie était écrite ici sans
+# être mesurée : « les correctifs de sécurité ne s'appliquent plus qu'au passage de
+# Set-OPS ». Autrement dit, la seule opération récurrente de la flotte qui exigeait
+# UN HUMAIN. Les sauvegardes tournent seules, les certificats se renouvellent seuls, la
+# santé se rapporte seule. Les correctifs attendaient quelqu'un — et une absence de trois
+# jours devenait une exposition, sur vingt et une machines.
 #
-# CONTREPARTIE ASSUMÉE, ET ELLE EST RÉELLE : les correctifs de sécurité ne s'appliquent
-# plus qu'au passage de Set-OPS. C'est tenable si les déploiements sont réguliers, et ça
-# devient une dette sinon. Mettre à `false` pour rendre la main à Debian.
-common_packages_desarmer_maj_auto: true
+# CE QUI REND LA COEXISTENCE TENABLE, ET QUI N'EXISTAIT PAS EN AOÛT :
+#
+#   - `_attendre-hote` (Makefile) attend `apt-daily*` ET le verrou avant tout déploiement ;
+#   - `lock_timeout: 300` est posé en `module_defaults` sur chaque playbook de groupe ;
+#   - `unattended-upgrades` ne traite QUE l'origine `-security` (voir le rôle dédié),
+#     pas un `upgrade: full` — un travail court, pas un rattrapage de distribution ;
+#   - `Automatic-Reboot "false"` : aucun démon ne décide seul de redémarrer un service.
+#
+# La course de premier démarrage reste, et elle est ATTENDUE plutôt que supprimée. C'est
+# la différence entre subir un concurrent et le connaître.
+#
+# Mettre à `true` pour désarmer de nouveau — le réarmement est alors sans objet, et les
+# correctifs redeviennent un geste manuel.
+common_packages_desarmer_maj_auto: false
 common_packages_unites_maj_auto:
   - apt-daily.timer
   - apt-daily-upgrade.timer

roles/common_packages/tasks/main.yml

@@ -47,6 +47,46 @@
   failed_when: false        # rien a effacer n'est pas une faute
   when: common_packages_desarmer_maj_auto | bool
 
+# REARMER NE SE DEDUIT PAS DE NE PLUS DESARMER (2026-09-11).
+#
+# Passer `common_packages_desarmer_maj_auto` a `false` SAUTE la tache de desarmement —
+# il ne defait rien. Une machine deja masquee le resterait pour toujours, et le drapeau
+# dirait le contraire de l'etat reel. Le desarmement laisse une trace ; il faut donc une
+# tache qui la retire, et elle doit exister le jour meme ou l'on inverse la decision.
+#
+# L'ORDRE COMPTE, COMME POUR LE DESARMEMENT : on reamorce AVANT les operations apt de ce
+# role. Un demarrage d'`apt-daily` declenche pendant nos propres taches se disputerait le
+# verrou au pire moment ; declenche avant, il est attendu par `lock_timeout`.
+# ON ARME, ON NE DECLENCHE PAS — ET LA NUANCE A COUTE DIX MACHINES (2026-09-11).
+#
+# La premiere version faisait `state: started` sur les trois unites. Demarrer
+# `unattended-upgrades.service` apres des semaines de masquage lance son RATTRAPAGE
+# immediatement — en plein deploiement. Il a pris le verrou dpkg et l'a garde plus
+# longtemps que `lock_timeout` (300 s) :
+#
+#   'apt-get autoremove' failed: E: Could not get lock /var/lib/dpkg/lock-frontend.
+#   It is held by process 185135 (unattended-upgr)
+#
+# Exactement la course qui avait motive le desarmement en aout, rejouee par la tache
+# censee le defaire. Dix machines sur vingt et une.
+#
+# LE TRAVAIL QUOTIDIEN NE PASSE PAS PAR CE SERVICE : `apt-daily-upgrade.timer` appelle
+# `apt.systemd.daily`, qui invoque `unattended-upgrade` lui-meme. Le `.service` ne sert
+# qu'aux passages de demarrage et d'extinction. L'ACTIVER suffit donc — il partira au
+# prochain redemarrage, sur une machine au repos, et non pendant qu'Ansible tient apt.
+#
+# Demarrer les MINUTEURS, en revanche, est sans danger : armer un minuteur ne declenche
+# pas sa cible, il la programme.
+- name: Réarmer les mises à jour automatiques de Debian (sans les déclencher)
+  ansible.builtin.systemd_service:
+    name: "{{ item }}"
+    masked: false
+    enabled: true
+    state: "{{ 'started' if item.endswith('.timer') else omit }}"
+  loop: "{{ common_packages_unites_maj_auto }}"
+  when: not (common_packages_desarmer_maj_auto | bool)
+  failed_when: false        # une unite absente sur cette image n'est pas une faute
+
 - name: Mettre à jour le cache APT
   ansible.builtin.apt:
     update_cache: true