Set-OPS-Public/roles/common_packages/tasks/main.yml
Daniel Allaire 904ece3004 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
2026-09-11 19:02:10 -04:00

139 lines
6.1 KiB
YAML

---
# `lock_timeout` sur CHAQUE tache apt : au premier demarrage, l'image Debian lance ses
# propres mises a jour (apt-daily, unattended-upgrades) et tient le verrou dpkg par
# vagues. Sans attente, la premiere tache echoue sur un verrou — pas sur une vraie
# erreur — et le deploiement d'une VM neuve devient un tirage au sort.
#
# Attendre ici plutot que seulement avant le playbook : le verrou peut etre repris
# ENTRE deux taches, ce qu'une verification ponctuelle en amont ne peut pas empecher.
# DÉSARMER AVANT TOUTE OPÉRATION APT, ET NON APRÈS.
#
# Une tâche apt placée avant celle-ci attendrait le verrou que celle-ci doit justement
# libérer — l'ordre n'est pas cosmétique. `state: stopped` en plus de `masked` : masquer
# empêche un démarrage futur, pas celui qui est déjà en cours.
- name: Désarmer les mises à jour automatiques de Debian (Set-OPS les applique lui-même)
ansible.builtin.systemd_service:
name: "{{ item }}"
state: stopped
enabled: false
masked: true
loop: "{{ common_packages_unites_maj_auto }}"
when: common_packages_desarmer_maj_auto | bool
failed_when: false # une unite absente n'est pas une faute : elle est desarmee
# EFFACER LA TRACE QUE LE DESARMEMENT LAISSE (mesure du 2026-08-30).
#
# Masquer le service pendant que son timer TOURNE lui fait perdre sa cible. systemd le
# note, et le garde :
#
# apt-daily.timer: Unit to trigger vanished.
# apt-daily.timer: Failed with result 'resources'.
#
# `state: stopped` n'efface pas un etat `failed` — seul `reset-failed` le fait. Sans lui,
# CHAQUE machine porte deux unites en echec permanent. Constate sur les quinze de
# Chezlepro : `systemctl list-units --state=failed` en rend deux partout.
#
# CE N'EST PAS COSMETIQUE. Une supervision qui compte les unites en echec compte ces
# deux-la pour toujours — et le jour ou une VRAIE panne s'ajoute, elle se noie dans un
# bruit qu'on a appris a ignorer. C'est le meme defaut que le journal de la frontiere
# noye sous 982 000 entrees : ce qui ment le plus n'est pas ce qui se tait, c'est ce qui
# crie sans raison.
- name: Effacer l'etat d'echec laisse par le desarmement
ansible.builtin.command:
argv: ["systemctl", "reset-failed", "{{ item }}"]
loop: "{{ common_packages_unites_maj_auto }}"
register: common_packages_reset
changed_when: false
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
cache_valid_time: 3600
lock_timeout: "{{ common_packages_lock_timeout }}"
- name: Appliquer les mises à jour disponibles
ansible.builtin.apt:
upgrade: full
lock_timeout: "{{ common_packages_lock_timeout }}"
- name: Installer les paquets communs
ansible.builtin.apt:
name: "{{ common_packages_list }}"
state: present
lock_timeout: "{{ common_packages_lock_timeout }}"
- name: Supprimer les dépendances devenues inutiles
ansible.builtin.apt:
autoremove: true
lock_timeout: "{{ common_packages_lock_timeout }}"
# LA SONDE SE DEPOSE ICI, ELLE SE DECLARE AILLEURS (`roles/serveur_debian/meta/`).
# Ce role est celui qui APPLIQUE les mises a jour ; il est donc le bon porteur. Mais la
# derivation des services d'Icinga croise les GROUPES, et `common_packages` n'en est pas
# un — d'ou la separation, expliquee dans la declaration.
- name: Assurer le repertoire des sondes de supervision
ansible.builtin.file:
path: /usr/local/lib/setops/sondes
state: directory
owner: root
group: root
mode: "0755"
- name: Assurer le repertoire d etat des sondes
ansible.builtin.file:
path: /var/lib/setops
state: directory
owner: root
group: root
mode: "0750"
- name: Deposer la sonde des correctifs de securite
ansible.builtin.template:
src: sonde-correctifs.sh.j2
dest: /usr/local/lib/setops/sondes/correctifs.sh
owner: root
group: root
mode: "0750"