Daniel Allaire
f11bb11ad7
- serveur_icingaweb2 : base de console résolue et utilisée en SSO comme en db (config_backend db) ; le badge de migrations la réclame sans condition - serveur_icingaweb2 : php8.4-fpm et nginx avant les paquets tiers ; apache2 retiré s'il part seul (apt-get -s purge) - serveur_nginx : ssl_protocols de Debian neutralisé (doublon à chaque reload) - site_inventaire : les hyperviseurs ne reçoivent plus le cache du site ni ses amorçages, qu'ils n'atteignent pas - exemple de voûte : vault_bd_icingaweb2 dans tous les modes ; CHANGELOG 64 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
26 lines
1.2 KiB
Django/Jinja
26 lines
1.2 KiB
Django/Jinja
; Géré par Set-OPS (rôle serveur_icingaweb2). Ne pas éditer à la main.
|
|
[global]
|
|
show_stacktraces = "0"
|
|
; LA CONSOLE RANGE SON PROPRE ETAT DANS SA PROPRE BASE (2026-09-15 au site, 2026-10-03
|
|
; partout : les locataires en SSO etaient restes en `ini`, avec la premiere erreur ci-dessous).
|
|
;
|
|
; `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"
|
|
|
|
[logging]
|
|
log = "syslog"
|
|
level = "ERROR"
|
|
application = "icingaweb2"
|