vigie : psycopg2 sur l'hôte de la vigie ; base appliquée chez les locataires

- serveur_icingaweb2 : python3-psycopg2 avant la première requête vers sa base ;
  au site il venait de PostgreSQL, co-localisé, chez un locataire il manquait
- CHANGELOG 64 : déploiement relu chez Chezlepro et Technolibre

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CHANGELOG.md

@@ -15,11 +15,20 @@ et utilise sa base dans TOUS les modes (`config_backend = "db"`, ressource `icin
 schéma chargé une fois) ; les comptes en base et le compte d'amorçage restent propres au
 mode `db`. Base `icingaweb2` ajoutée aux plans de Chezlepro, Technolibre, du lab et des
 deux modèles qui portent une vigie (`observabilite`, `integral`) ; `vault_bd_icingaweb2`
-aux gabarits de voûte et à l'exemple public. **Reste à l'exploitant** : la valeur réelle
+aux gabarits de voûte et à l'exemple public. **Appliqué chez les deux locataires** — secret posé par l'exploitant dans les trois voûtes
-dans trois voûtes (l'écriture a été refusée à l'assistant), puis le déploiement chez les
+(relu par l'assistant sans en afficher la valeur : 40 caractères, trois valeurs distinctes),
-deux locataires (`serveur_postgresql`, `serveur_icingaweb2`, `serveur_ops_tenant` pour
+puis `serveur_postgresql`, `serveur_icingaweb2`, `serveur_nginx` et `serveur_ops_tenant`.
-que le runner reçoive la voûte). Les préférences déjà rangées en fichiers ne sont pas
+Relu : vigie en `config_backend = "db"`, schéma chargé (6 tables), plus aucune erreur de
-reprises : ce ne sont que des réglages d'affichage.
+migrations depuis le redémarrage de php-fpm (elle revenait toutes les 15 s) ; voûte du runner
+identique à celle du poste, à l'empreinte près, toujours chiffrée. Les préférences déjà rangées
+en fichiers ne sont pas reprises : ce ne sont que des réglages d'affichage.
+
+**Ce que le premier passage a révélé : `psycopg2` absent du `mon-01` d'un locataire.** Les
+requêtes du rôle vers la base s'exécutent sur l'hôte de la vigie. Au site, c'est aussi celui
+de PostgreSQL, qui y avait posé `python3-psycopg2` ; chez un locataire, la vigie est sur
+`mon-01` et la base sur `data-sql-01`. Échec masqué par `no_log`, et invisible en simulation
+(la requête y est sautée : la base n'existe pas encore). **Fait** : le rôle pose
+`python3-psycopg2` avant sa première requête.
 
 **5a. Le cache du site donné aux hyperviseurs, qui ne l'atteignent pas.** Mesuré depuis
 asgard : `10.37.33.21:3142` injoignable. Or `artefacts_amorcage` leur était transmis par

roles/serveur_icingaweb2/tasks/main.yml

@@ -79,6 +79,18 @@
       passe deviné : renseigner la clé dans la voûte de cet écosystème.
   when: serveur_icingaweb2_auth == 'db'
 
+# LE CLIENT POSTGRESQL DES MODULES `community.postgresql`, SUR CETTE MACHINE (2026-10-03).
+#
+# Les requetes ci-dessous s'executent sur l'hote de la vigie, pas sur le serveur de base.
+# Au site, les deux sont la meme machine : `serveur_postgresql` y avait deja pose
+# `python3-psycopg2`, et l'absence ne se voyait pas. Chez un locataire, la vigie vit sur
+# `mon-01` et la base sur `data-sql-01` — premier passage apres que la base est devenue
+# commune a tous les modes : `No module named 'psycopg2'`, masque par `no_log`.
+- name: Installer le client PostgreSQL de Python (modules community.postgresql)
+  ansible.builtin.apt:
+    name: python3-psycopg2
+    state: present
+
 # LE SCHEMA NE SE CHARGE QU'UNE FOIS. Le rejouer sur une base deja peuplee echouerait sur
 # les objets existants — on lit donc d'abord si la table des comptes est la.
 - name: La base de la console est-elle déjà en place ?