Set-OPS-Public/roles/serveur_ops_tenant/defaults/main.yml

---
# LE RUNNER D'UN TENANT — celui qui CONFIGURE.
#
# Le travail d'un runner se divise en trois portées, et chacune a son rôle :
#
#   calculer      plan -> inventaire        aucune voûte        `serveur_ops`
#   configurer    rôles sur ses machines    voûte du TENANT     CE RÔLE
#   matérialiser  créer/détruire des VM     voûte du SITE       `serveur_ops_site`
#
# CE QUI MANQUAIT (2026-08-26). La portée « configurer » était attribuée à `serveur_ops`
# dans la doctrine — mais rien ne déposait jamais la voûte du tenant sur son runner. Un
# runner pouvait donc dériver son inventaire et ne rien pouvoir en faire : chaque rôle qui
# demande un secret échouait sur son assertion, et l'échec ne disait pas qu'il manquait un
# FICHIER, seulement que les valeurs étaient vides.
#
# Découvert en préparant la reconstruction de Chezlepro : le runner du SITE peut
# matérialiser ses quinze machines, mais ne peut pas les configurer — Chezlepro a sa
# PROPRE autorité de certification, donc `client_pki` y réclame un secret de Chezlepro.
# Le runner du site ne l'a pas, et ne doit pas l'avoir : c'est la ligne qui rend
# l'hébergement mutualisé défendable.
#
# POURQUOI UN RÔLE À PART, et non une option de `serveur_ops`. Donner sa voûte à un runner
# est un POUVOIR, pas un réglage. Le déclarer explicitement au plan force à répondre à la
# question « cette machine a-t-elle le droit de configurer cet écosystème ? » — alors
# qu'une option activée par défaut y répondrait à notre place. C'est le même patron que
# `serveur_artefacts` + `serveur_cache_site` : un installateur, puis un marqueur qui
# ajoute un pouvoir.
#
# QUI PEUT LE DÉCLARER : l'écosystème lui-même, pour SA machine. Un runner de SITE ne le
# déclare jamais — il porte les plans des tenants en `role: tenant` précisément pour dire
# qu'il prépare leur terrain sans les piloter.

serveur_ops_tenant_utilisateur: "setops"
serveur_ops_tenant_racine: "/opt/setops"

# Le dossier du dépôt de CET écosystème chez le runner, cloné par `serveur_ops`
# (entrée `role: instance` de `serveur_ops_depots`). Par défaut : celui que le lien
# `instance` désigne déjà — le pilote et sa voûte ne peuvent pas viser deux écosystèmes.
serveur_ops_tenant_depot: "{{ serveur_ops_instance | default('') }}"

# --- LA VOÛTE DU TENANT ------------------------------------------------------
#
# Déposée CHIFFRÉE, jamais en clair. Le mot de passe n'est pas stocké : l'exploitant le
# tape au moment d'agir.
#
# `decrypt: false` EST OBLIGATOIRE sur la copie. Sans lui, Ansible DÉCHIFFRE la source
# quand il détient le mot de passe — mesuré le 2026-08-24 sur la voûte du site, 776 octets
# en clair au lieu de 3465 chiffrés, sur une machine où ils n'avaient rien à faire.
serveur_ops_tenant_voute_source: ""
serveur_ops_tenant_voute_deposer: true

# LE DOSSIER D'INVENTAIRE SE DÉCOUVRE, il ne s'écrit pas. Le dépôt en connaît deux noms
# — `principal` et `production` — et l'ordre de préférence est celui de
# `inventory_rules.dossier_inventaire`. Écrire le nom en dur ici le ferait mentir pour
# l'écosystème qui emploie l'autre.
serveur_ops_tenant_inventaires_connus:
  - principal
  - production

# --- ARMER LE RUNNER : LA CLE DE SA VOUTE ------------------------------------
#
# UN RUNNER MAITRE DE SA VOUTE (decision de l'exploitant, 2026-08-28). Deposer le chiffre
# sans la cle laisse un runner qui calcule son inventaire et ne peut rien en faire : chaque
# role reclamant un secret echoue sur son assertion, et l'echec ne dit pas qu'il manque un
# FICHIER — seulement que les valeurs sont vides.
#
# `false` PAR DEFAUT, ET CE N'EST PAS DE LA PRUDENCE DECORATIVE. Armer est un ACTE, pas un
# reglage : c'est le moment ou un humain remet la cle, et c'est le seul geste que la
# reproduction exige de lui (cf. docs/filiation-emancipation.md). Un defaut a `true`
# armerait des machines sans que personne ne l'ait decide.
#
# LA SOURCE EST UN POINTEUR, JAMAIS UNE VALEUR : le chemin du fichier de mot de passe sur
# le poste de l'exploitant. Il ne vit dans aucun depot, et rien ici n'en lit le contenu.
#
# DESTINATION : `<racine>/.config/setops-vault-<depot-en-minuscules>`, la meme convention
# que `scripts/voutes.py` — le runner derive donc sa propre liste d'identites sans qu'on
# ait a la lui ecrire. Hors de tout depot git, en 0600.
serveur_ops_tenant_cle_deposer: false
serveur_ops_tenant_cle_source: ""
serveur_ops_tenant_cle_destination: >-
  {{ serveur_ops_tenant_racine }}/.config/setops-vault-{{ serveur_ops_tenant_depot | lower }}

# --- Sonde de supervision -----------------------------------------------------------
# Le chemin ou le RUNNER lit la voute de son ecosysteme.
# LE DEPOT VIENT DU ROLE, PAS D'UNE SUPPOSITION : `serveur_ops_tenant_depot` designe
# deja le dossier clone sur le runner.
serveur_ops_tenant_sonde_depot: "{{ serveur_ops_tenant_depot }}"
serveur_ops_tenant_sonde_voute: >-
  /opt/setops/{{ serveur_ops_tenant_sonde_depot }}/inventories/principal/group_vars/all/vault.yml