OPS-Patient0/inventories/production/group_vars/all/10-intrants.yml
Daniel Allaire b2d087356c poste d'exploitation : patient 0 sait lire son propre genome
Fonction `ops` en zone Services-infra, machine ops-01 (10.29.19.41, VMID
129404101). Sans client_backup : le poste ne detient aucun etat propre, tout ce
qu'il porte se recompose depuis la forge.

Ajoute aussi le group_vars serveur_nginx qui manquait -- sans lui, l'edge
publiait la forge derriere un certificat auto-signe.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 11:58:10 -04:00

51 lines
2.6 KiB
YAML

---
# Intrants d'IDENTITE de patient 0 — SOURCE UNIQUE, partagee par tous les envs.
# Edite par le panneau « Intrants de base » du GUI (make inventaire-ui).
# RESEAU(X) D'ADMINISTRATION — la seule source autorisee a ouvrir SSH sur la flotte,
# ET la source des regles d'admin de la frontiere. Un seul intrant pour les deux (P24) :
# une valeur juste ici ouvre les deux portes, une valeur fausse les ferme toutes les deux.
#
# MESURE DU 2026-08-22, AVANT D'APPLIQUER QUOI QUE CE SOIT. La valeur etait 10.0.0.0/24 —
# l'ancien plan de gestion, recopie de Chezlepro d'avant la migration D-77. Or l'exploitant
# administre depuis 10.17.0.17, en passant par 10.17.0.1. La frontiere aurait donc recu 89
# objets et l'aurait REFUSE quand meme : on aurait conclu que le moteur ne marche pas,
# alors que l'intrant etait faux.
#
# 10.17.0.0/24 le plan de gestion neuf, celui d'ou l'on administre reellement
# 192.168.255.2/32 l'acces par VPN, qui doit franchir la frontiere lui aussi
nftables_admin_ssh:
- 10.17.0.0/24
- 192.168.255.2/32
# Resolveur d'AMORCAGE, pose par cloud-init a la creation d'une VM. Il ne sert qu'une
# fois : `client_unbound` bascule ensuite /etc/resolv.conf vers 127.0.0.1. Sans lui, la
# VM nait sans resolution et `apt` ne peut rien installer.
dns_amorcage: 9.9.9.9,149.112.112.112
domaine_interne: genese.internal
fuseau_horaire: America/Toronto
identite_realm: genese
organisation: Alliance Boréale
# Adresse du compte d'amorcage — la SEULE valeur du role `amorcage_acces` qui ne peut
# pas se deriver : elle designe une personne. Elle doit etre lisible SANS l'ecosysteme
# qu'on amorce — une adresse en @genese.internal serait un piege parfait.
amorcage_acces_courriel: sysadmin@chezlepro.ca
# LE PLAN SUIT L'INVENTAIRE, PAS LE SYMLINK (2026-08-23).
#
# La valeur precedente etait `{{ playbook_dir }}/../../instance/plan` : le lien
# `instance` du moteur, en dur. Tout role lisant le plan lisait donc celui de
# l'instance POINTEE PAR LE LIEN, et non celle qu'on deploie.
#
# CE QUE CA A DONNE. En deployant patient 0 avec `SETOPS_INSTANCE`, le plancher
# /etc/hosts de `ops-01` a recu les FQDN de CHEZLEPRO -- auth.chezlepro.internal,
# forge.chezlepro.internal... -- pointes sur l'edge de patient 0. Un ecosysteme
# annoncait les noms d'un autre. Neuf roles lisent cette variable ; le plancher est
# simplement celui qui l'a rendu visible.
#
# `inventory_dir` est le dossier de l'inventaire REELLEMENT charge. Le plan qui a
# engendre cet inventaire est son voisin : les deux ne peuvent plus se contredire,
# et l'expression reste juste qu'on passe par le symlink ou par SETOPS_INSTANCE.
setops_plan_dir: "{{ inventory_dir }}/../../plan"