diff --git a/CHANGELOG.md b/CHANGELOG.md index 82c7f5a..3e0e31b 100644 --- a/CHANGELOG.md +++ b/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 diff --git a/roles/serveur_icingaweb2/tasks/main.yml b/roles/serveur_icingaweb2/tasks/main.yml index d9da5c7..a3b3ec1 100644 --- a/roles/serveur_icingaweb2/tasks/main.yml +++ b/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 diff --git a/roles/serveur_icingaweb2/templates/config.ini.j2 b/roles/serveur_icingaweb2/templates/config.ini.j2 index 0135f63..40136b8 100644 --- a/roles/serveur_icingaweb2/templates/config.ini.j2 +++ b/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" diff --git a/roles/serveur_icingaweb2/templates/resources.ini.j2 b/roles/serveur_icingaweb2/templates/resources.ini.j2 index b23e8d4..9677606 100644 --- a/roles/serveur_icingaweb2/templates/resources.ini.j2 +++ b/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 }}" -port = "{{ resoudre_base_db_port }}" -dbname = "{{ resoudre_base_entree.base }}" -username = "{{ resoudre_base_entree.proprietaire }}" -password = "{{ resoudre_base_db_password }}" +host = "{{ serveur_icingaweb2_moteur_host }}" +port = "{{ serveur_icingaweb2_moteur_port }}" +dbname = "{{ serveur_icingaweb2_moteur_base }}" +username = "{{ serveur_icingaweb2_moteur_utilisateur }}" +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