Set-OPS-Public/roles/client_journal
Daniel Allaire 1a7c042e5b site : quatre zones d'autorite, et l'ordre inscrit dans les integrations
Le site n'est plus un /24 plat. Une zone par nature d'autorite — pilotage, autorite,
genome, service — chacune son VLAN et sa patte sur la frontiere. L'inversion corrigee,
mesuree : les cinq VM du site n'avaient AUCUN filtrage est-ouest, contre policy_in=DROP
sur une machine de tenant. La plus autoritaire etait la moins protegee.

Filtrage nord-sud par choix de l'exploitant : un seul point de police, un seul devis.
90 -> 117 regles. Chaque flux `flotte` produit une regle par zone SOURCE, destination
nommee — ce qui etait gratuit devient police.

L'ORDRE FAIT PARTIE DE L'INTEGRATION. client_pki tournait en parallele sur tous les hotes ;
sur celui qui porte l'autorite il recharge step-ca, et les quatre autres echouaient dans
cette fenetre sur `TLS handshake timeout` — un message qui accuse le reseau. Chaque
integration declare desormais sa dependance dans meta/integration.yml, les playbooks en
sont le miroir genere, et P44 refuse l'ecart (4 controles negatifs). `serveur: ~` est une
reponse valable : client_metrique pose un exportateur qu'on vient LIRE.

Autres defauts du meme soir :
  - le plancher /etc/hosts venait APRES le premier apt, qui vise le cache par son NOM :
    boucle fermee des que les adresses changent. Il ne s'installe pas, il rend installable.
  - dns_amorcage ecrit en dur a eu tort deux fois ; il se derive de serveur_resolveur.
  - l'ACL du resolveur derivait d'un seul sous-reseau : trois zones refusees sur quatre.

ET UNE ERREUR A MOI : j'ai diagnostique un trou noir de MTU et declare 1450. Faux — pas de
VXLAN sur ce chemin, tout est a 1500 de bout en bout. Ma mesure etait reelle, mon
interpretation non : je venais de debrancher la carte a chaud, et chaque `ip link set mtu`
reconfigurait l'interface. C'est la reconfiguration qui debloquait, pas la valeur.

44 preuves vertes, ansible-lint profil production.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 17:31:07 -04:00
..
defaults client_journal : imposer et DECLARER le port d'Alloy — collision avec le SASL de Dovecot 2026-08-09 09:04:25 -04:00
handlers Set-OPS — moteur d'ecosystemes numeriques souverains (Alliance Boreale) 2026-06-24 20:17:46 -04:00
meta site : quatre zones d'autorite, et l'ordre inscrit dans les integrations 2026-08-25 17:31:07 -04:00
tasks get_url : plus aucun sans garde — la dependance externe tombe a zero 2026-08-09 14:05:25 -04:00
templates Zéro-confiance : flux Logs chiffré (Loki HTTPS + Alloy push https) 2026-07-04 21:15:00 -04:00
README.md Set-OPS — moteur d'ecosystemes numeriques souverains (Alliance Boreale) 2026-06-24 20:17:46 -04:00

client_journal

Intégration cliente journaux : expédie le journal système (journald) de la VM vers serveur_loki, via Grafana Alloy.

Rôle

  • Ajoute le dépôt apt Grafana et installe alloy.
  • Ajoute l'utilisateur alloy au groupe systemd-journal (lecture du journal).
  • Déploie /etc/alloy/config.alloy : loki.source.journal → loki.write vers Loki.

Boucle

VM dans client_journal → Alloy lit journald → pousse vers Loki (obs-01) → visible dans Grafana (datasource Loki).

Variables

Variable Défaut Rôle
client_journal_loki_url http://10.0.14.11:3100/loki/api/v1/push Endpoint Loki (obs-01)

Notes / limites

  • La syntaxe de configuration Alloy évolue entre versions ; la config fournie cible un Alloy récent (loki.source.journal, loki.write). Ajustement mineur possible selon la version installée.
  • Étiquettes par défaut : job=systemd-journal, host=<inventory_hostname>.

Prérequis

  • Dépendance client_journal requiert serveur_loki actif (déjà dans docs/dependances-groupes.yml).