Daniel Allaire
c6a7150c60
Deux mouvements d une seule doctrine : le site fournit tout ce dont un
tenant a besoin pour venir au monde.
1. LES DEPOTS TIERS. Grafana, Icinga, Smallstep et Collabora ne publient
qu en HTTPS ; apt-cacher-ng ne relaie pas un tunnel, et le socle pose donc
Acquire::https::Proxy DIRECT. Chaque machine sortait elle-meme sur
Internet. Le cache declare desormais un Remap par fournisseur, et chaque
role demande en {{ ..._depot_schema }}:// - http des qu un cache est
declare, https sinon. Le TLS n est rompu nulle part : il est TERMINE au
cache, qui est notre machine, et l integrite vient des signatures.
avant : 4 fournisseurs en HTTPS direct, 14 machines sortant seules
apres : 0 source en HTTPS direct, 0 erreur apt sur 14 machines
Trois lecons. Le remap appartient au cache qui SORT : pose sur un cache
chaine, il tente le HTTPS a travers son amont et rend 503. apt_repository
AJOUTE au lieu de remplacer, donc l ancienne ligne https sortait toujours.
Et la liste des fournisseurs ne se devine pas - j en avais trois, l audit
en a revele un quatrieme.
2. LE CACHE DU TENANT. Sa ligne portait son propre retrait depuis toujours
- service MUTUALISABLE, un ecosysteme au premier age peut pointer sur celui
de son hote. Retiree. Ce qu on perd, dit franchement : plus de trafic
inter-zone et plus de charge sur site-cache-01, contre un service de moins
a poser, superviser et reproduire.
3. UN ROLE QU ON RETIRE DOIT DEFAIRE CE QU IL A FAIT. Le retrait a montre
que rien ne nettoie derriere. Le fichier apt visait un cache eteint en
ecrasant le plancher qui fonctionnait - le defaut deja paye a quinze
machines. Et les sondes du cache restaient, le porteur poussant pour des
services qu Icinga ne definit plus (404). Le socle retire le premier,
client_sante derive les sondes attendues et retire les orphelines.
P65 refuse tout role visant un depot relaye en https ecrit en dur. Sa
limite est dite : elle empeche une regression sur ce qui est connu, elle ne
decouvre pas l inconnu.
Mesure : Icinga 87 OK sur 96, prouver 65 OK, lint 0 defaut.
Reste, et c est dit : apt-cacher-ng tourne toujours sur forge-01 que plus
aucun plan ne declare.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
|
||
|---|---|---|
| .. | ||
| defaults | ||
| handlers | ||
| meta | ||
| tasks | ||
| templates | ||
| README.md | ||
serveur_icinga
Supervision active Icinga — cœur de surveillance. Portée actuelle : Icinga 2 + Icinga DB (avec son Redis dédié et sa base PostgreSQL). Icinga Web 2 est différé à une phase dédiée.
Rôle (cœur)
- Ajoute le dépôt apt officiel Icinga (trousseau + source signée) et installe
icinga2,icingadb,icingadb-redis. icinga2 api setup+ activation de la fonctionnalitéicingadb.- Base PostgreSQL via le registre (
instance/plan/bases-donnees.yml, entréeicingadb) : PostgreSQL crée la base/compte, ce rôle importe le schéma et écrit/etc/icingadb/config.yml(BD + Redis).
Base de données
Entrée registre icingadb (PostgreSQL sur data-01). Mot de passe partagé via Vault
(vault_bd_icingadb), comme Keycloak. Dépendance serveur_icinga requiert serveur_postgresql actif (déjà dans docs/dependances-groupes.yml).
Différé (phase Icinga Web 2)
icingaweb2+ sa 2e base (icingaweb) + PHP-FPM + vhost nginx + assistant de configuration (jeton de setup). À faire proprement avec sa doc verbatim.
Limites / caveats honnêtes
- Les pages détaillées Icinga DB/Web ont renvoyé des 404 ; la config Icinga DB
(
config.yml, chemin du schéma/usr/share/icingadb/schema/pgsql/schema.sql, port Redis6380) suit la structure documentée standard mais n'a pas pu être vérifiée verbatim — à confirmer/ajuster selon la version installée (variables prévues). - Non testé live (mon-01 planifié).
- L'import de schéma s'exécute une seule fois (marqueur
/etc/icingadb/.schema-imported).
Prérequis
serveur_postgresqlactif (baseicingadbcréée), accès réseau à data-01:5432.