console : deux bases confondues, et un etat sans domicile

serveur_icingaweb2 appelle resoudre_base deux fois — moteur puis comptes — et le
second appel ecrase les faits du premier. Les gabarits lisaient donc la seconde
base partout : la console cherchait icingadb_schema dans la base des comptes et
rendait une trace PHP a chaque page, pendant que les 66 tables du moteur etaient
intactes a cote. Celui qui appelle un role partage deux fois doit NOMMER ses
resultats avant de le rappeler.

Et le cadre de migration veut une instance de base quoi qu il arrive :
config_backend db + config_resource icingaweb_db. L erreur des preferences
n apparaissait qu A LA CONNEXION — un journal muet ne prouvait rien tant que
personne n avait ouvert de session, d ou un controle qui en ouvre une vraie.

J ai attribue a tort la fin des erreurs a un rechargement manuel : les horloges
disent que le handler du role avait deja redemarre php-fpm sept minutes plus
tot. Mes fenetres de mesure enjambaient le correctif.

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

CHANGELOG.md

@@ -1,5 +1,68 @@
 # CHANGELOG — Set-OPS
 
+## 2026-09-15 (3) — Le charabia de la console : deux bases confondues, et un etat sans domicile
+
+L'exploitant, apres s'etre connecte : *« icingaweb2 affiche un tas de charabia quand
+j'ouvre une session »*. Deux causes, dont la premiere etait de mon fait.
+
+### UN ROLE PARTAGE REND DES FAITS PARTAGES
+
+`serveur_icingaweb2` appelle `resoudre_base` DEUX fois : une pour la base du MOTEUR
+(`icingadb`, en lecture) et une pour celle des COMPTES (`icingaweb2`). Le second appel
+ecrase les faits du premier — `resoudre_base_entree`, `resoudre_base_db_host`... — et les
+gabarits, rendus apres les deux, lisaient la SECONDE base partout :
+
+    [icingadb]      dbname = "icingaweb2"    <- la base des comptes
+    [icingaweb_db]  dbname = "icingaweb2"
+
+La console cherchait donc `icingadb_schema` dans la base des comptes, ne l'y trouvait pas,
+et rendait une trace PHP a chaque page. **Les 66 tables du moteur etaient intactes a
+cote.** Un defaut qui accuse la base pendant que la base va bien.
+
+Celui qui appelle un role partage deux fois doit NOMMER ses resultats avant de le
+rappeler. C'est « une liste qui suit une autre », appliquee au temps plutot qu'a l'espace.
+
+Introduit la veille, en remontant le bloc de la base au-dessus du rendu des `.ini` — un
+correctif d'ORDRE qui a cree un defaut de PORTEE.
+
+### LA CONSOLE N'AVAIT PAS DE DOMICILE POUR SON PROPRE ETAT
+
+`config_backend = "ini"` laissait les preferences en fichiers. Tenable — sauf que le cadre
+de MIGRATION d'Icinga Web 2 veut une instance de base quoi qu'il arrive :
+
+    Failed to load pending migrations : Please check if a db instance exists at all
+    Cannot load preferences for user "icinga-admin" : Cannot load resource config ""
+
+La seconde n'apparaissait qu'A LA CONNEXION. **Un journal muet ne prouvait donc rien tant
+que personne n'avait ouvert de session** — et c'est pour ca que le controle a consiste a
+en ouvrir une vraie, pas a regarder le journal d'une console au repos.
+
+Des lors que la console a une base, il n'y a aucune raison d'y ranger les comptes et pas
+le reste : `config_backend = "db"`, `config_resource = "icingaweb_db"`. Les preferences
+d'un utilisateur le suivent alors d'un navigateur a l'autre.
+
+### Eprouve en ouvrant une session
+
+    session ouverte   oui
+    tableau de bord   « Current Incidents :: Dashboard »
+    /icingadb/services  44 459 octets, 0 trace
+    /icingadb/hosts     31 169 octets, 0 trace
+    journal             1 ligne en 100 s (aucune erreur)
+
+### CE QUE J'AI ATTRIBUE A TORT A MON PROPRE GESTE
+
+J'ai recharge php-fpm a la main et conclu que c'etait ca. Les horloges disent le
+contraire :
+
+    derniere erreur          10:15:32
+    php-fpm redemarre        10:15:44   <- par le handler du role
+    mon rechargement         ~10:22     <- sur un systeme deja sain
+
+Le role etait deja juste. Mes mesures intermediaires portaient sur une fenetre
+(`--since "-5min"`) qui enjambait le correctif : je lisais des erreurs d'AVANT en croyant
+observer l'APRES. Une fenetre de mesure qui contient le moment du changement ne mesure ni
+l'un ni l'autre etat.
+
 ## 2026-09-15 (2) — Un vestibule devant une application qui savait deja s'authentifier
 
 L'exploitant, en voyant la boite du navigateur sur `vigie` : *« Dans le contexte d'un

roles/serveur_icingaweb2/tasks/main.yml

@@ -5,6 +5,34 @@
   vars:
     resoudre_base_groupe: "{{ serveur_icingaweb2_icinga_groupe }}"
 
+# ON RECOPIE TOUT DE SUITE, PARCE QU'UN SECOND APPEL ECRASE LE PREMIER (2026-09-15).
+#
+# `resoudre_base` rend ses resultats dans des faits PARTAGES — `resoudre_base_entree`,
+# `resoudre_base_db_host`... Ce role l'appelle DEUX fois : une pour la base du MOTEUR
+# (icingadb, en lecture) et une pour celle des COMPTES (icingaweb2). Le second appel
+# remplace les faits du premier, et les gabarits rendus APRES les deux lisaient donc la
+# seconde base partout.
+#
+# CE QUE CA A DONNE, mesure sur la machine :
+#
+#     [icingadb]      dbname = "icingaweb2"   <- la base des comptes
+#     [icingaweb_db]  dbname = "icingaweb2"
+#
+# La console cherchait `icingadb_schema` dans la base des comptes, ne l'y trouvait pas, et
+# rendait une trace PHP a chaque page. Les 66 tables du moteur etaient intactes a cote.
+#
+# UN ROLE PARTAGE REND DES FAITS PARTAGES : celui qui l'appelle deux fois doit nommer ses
+# resultats avant de le rappeler. C'est la meme lecon que « une liste qui suit une autre »,
+# appliquee au temps plutot qu'a l'espace.
+- name: Adopter la base du MOTEUR avant de résoudre celle des comptes
+  ansible.builtin.set_fact:
+    serveur_icingaweb2_moteur_host: "{{ resoudre_base_db_host }}"
+    serveur_icingaweb2_moteur_port: "{{ resoudre_base_db_port }}"
+    serveur_icingaweb2_moteur_base: "{{ resoudre_base_entree.base }}"
+    serveur_icingaweb2_moteur_utilisateur: "{{ resoudre_base_entree.proprietaire }}"
+    serveur_icingaweb2_moteur_motdepasse: "{{ resoudre_base_db_password }}"
+  no_log: true
+
 # --- MODE `db` : LA BASE DES COMPTES, ET LE COMPTE D'AMORCAGE (2026-09-15) ------------
 #
 # TOUT EN HAUT, ET C'EST L'ORDRE QUI L'EXIGE. `resources.ini` nomme cette base ; il est

roles/serveur_icingaweb2/templates/config.ini.j2

@@ -1,7 +1,27 @@
 ; Géré par Set-OPS (rôle serveur_icingaweb2). Ne pas éditer à la main.
 [global]
 show_stacktraces = "0"
+{% if serveur_icingaweb2_auth == 'db' %}
+; LA CONSOLE RANGE SON PROPRE ETAT DANS SA PROPRE BASE (2026-09-15).
+;
+; `config_backend = "ini"` laissait les preferences en fichiers, et c'etait tenable — mais
+; le cadre de MIGRATION d'Icinga Web 2, lui, veut une instance de base quoi qu'il arrive.
+; Sans elle, deux erreurs toutes les quinze secondes :
+;
+;   Failed to load pending migrations : Please check if a db instance exists at all
+;   Cannot load preferences for user "icinga-admin" : Cannot load resource config ""
+;
+; La seconde n'apparaissait qu'A LA CONNEXION — un journal muet ne prouvait donc rien
+; tant que personne n'avait ouvert de session.
+;
+; Des lors que la console A une base — celle de ses comptes — il n'y a aucune raison d'y
+; ranger les comptes et pas le reste. Les preferences d'un utilisateur le suivent alors
+; d'un navigateur a l'autre, ce que des fichiers locaux ne font pas.
+config_backend = "db"
+config_resource = "icingaweb_db"
+{% else %}
 config_backend = "ini"
+{% endif %}
 
 [logging]
 log = "syslog"

roles/serveur_icingaweb2/templates/resources.ini.j2

@@ -1,12 +1,15 @@
 ; Géré par Set-OPS (rôle serveur_icingaweb2). Ne pas éditer à la main.
+; LA BASE DU MOTEUR — nommee par des variables PROPRES a ce role, jamais par les faits
+; partages de `resoudre_base` : ce role l'appelle deux fois, et le second appel ecrase
+; les faits du premier. Voir `tasks/main.yml`.
 [icingadb]
 type = "db"
 db = "pgsql"
-host = "{{ resoudre_base_db_host }}"
+host = "{{ serveur_icingaweb2_moteur_host }}"
-port = "{{ resoudre_base_db_port }}"
+port = "{{ serveur_icingaweb2_moteur_port }}"
-dbname = "{{ resoudre_base_entree.base }}"
+dbname = "{{ serveur_icingaweb2_moteur_base }}"
-username = "{{ resoudre_base_entree.proprietaire }}"
+username = "{{ serveur_icingaweb2_moteur_utilisateur }}"
-password = "{{ resoudre_base_db_password }}"
+password = "{{ serveur_icingaweb2_moteur_motdepasse }}"
 charset = "UTF8"
 {% if serveur_icingaweb2_db_sslmode | default('') %}
 ; LE SERVEUR IMPOSE `hostssl` : sans ces deux lignes, PostgreSQL refuse la connexion et