From 904ece3004fb8704aadc9cdc0e0011a47e18d2c2 Mon Sep 17 00:00:00 2001 From: Daniel Allaire Date: Fri, 11 Sep 2026 19:02:10 -0400 Subject: [PATCH] les correctifs de securite reviennent au quotidien, sans personne MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q --- CHANGELOG.md | 62 +++++++++++++++++++++++++ roles/common_packages/defaults/main.yml | 43 ++++++++++------- roles/common_packages/tasks/main.yml | 40 ++++++++++++++++ 3 files changed, 129 insertions(+), 16 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index ee20dc6..60d5243 100644 --- a/CHANGELOG.md +++ b/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 diff --git a/roles/common_packages/defaults/main.yml b/roles/common_packages/defaults/main.yml index 24eacd7..db17c95 100644 --- a/roles/common_packages/defaults/main.yml +++ b/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 diff --git a/roles/common_packages/tasks/main.yml b/roles/common_packages/tasks/main.yml index be64939..18b3726 100644 --- a/roles/common_packages/tasks/main.yml +++ b/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