2026-07-03 19:05:04 -04:00
|
|
|
---
|
2026-08-07 11:47:34 -04:00
|
|
|
# L'ISSUER SE DERIVE DE L'EXPOSITION DECLAREE, il ne s'invente pas. Le defaut fabriquait
|
|
|
|
|
# `https://keycloak.<domaine>` par convention de nommage — un nom que rien ne publie : le
|
|
|
|
|
# plan expose Keycloak sous `auth.<domaine>`, et c'est ce nom-la que PowerDNS resout et
|
|
|
|
|
# que nginx sert. Resultat le 2026-08-07 : `lookup keycloak.chezlepro.internal : no such
|
|
|
|
|
# host`, et oauth2-proxy redemarrait en boucle.
|
|
|
|
|
#
|
|
|
|
|
# Le champ `expose` est deja la source pour PowerDNS, nginx et /etc/hosts. C'est la
|
|
|
|
|
# quatrieme fois qu'on le lit : une convention de nommage se contredit, une declaration
|
|
|
|
|
# se corrige.
|
|
|
|
|
- name: Charger les registres applications et domaines (expositions)
|
|
|
|
|
ansible.builtin.include_vars:
|
|
|
|
|
file: "{{ item }}"
|
|
|
|
|
loop:
|
|
|
|
|
- "{{ setops_plan_dir }}/applications.yml"
|
|
|
|
|
- "{{ setops_plan_dir }}/domaines.yml"
|
|
|
|
|
when: serveur_oauth2_proxy_issuer_derive | bool
|
|
|
|
|
|
|
|
|
|
- name: Dériver l'issuer depuis l'exposition de Keycloak
|
|
|
|
|
ansible.builtin.set_fact:
|
|
|
|
|
serveur_oauth2_proxy_issuer: >-
|
|
|
|
|
https://{{ (applications | default({})).get(serveur_oauth2_proxy_app_idp, {}).get('expose', []) | first }}/realms/{{ serveur_oauth2_proxy_realm }}
|
|
|
|
|
when:
|
|
|
|
|
- serveur_oauth2_proxy_issuer_derive | bool
|
|
|
|
|
- ((applications | default({})).get(serveur_oauth2_proxy_app_idp, {}).get('expose', []) | length) > 0
|
|
|
|
|
|
2026-07-03 19:05:04 -04:00
|
|
|
- name: Exiger la configuration OIDC (client, secret, redirect, upstream, cookie)
|
|
|
|
|
ansible.builtin.assert:
|
|
|
|
|
that:
|
|
|
|
|
- serveur_oauth2_proxy_client_id | length > 0
|
|
|
|
|
- serveur_oauth2_proxy_client_secret | length > 0
|
|
|
|
|
- serveur_oauth2_proxy_redirect_url | length > 0
|
|
|
|
|
- serveur_oauth2_proxy_upstream | length > 0
|
|
|
|
|
- serveur_oauth2_proxy_cookie_secret | length > 0
|
|
|
|
|
fail_msg: "client_id, client_secret (voûte), redirect_url, upstream et cookie_secret (voûte) requis."
|
|
|
|
|
|
2026-08-07 11:47:34 -04:00
|
|
|
# Garde d'ENCODAGE, distincte de la garde de présence : un secret présent mais en base64
|
|
|
|
|
# standard fait redémarrer oauth2-proxy en boucle, avec un message qui parle de longueur
|
|
|
|
|
# et jamais d'encodage. Mieux vaut refuser ici, où la cause est nommable.
|
|
|
|
|
- name: Refuser un cookie_secret qui n'est pas du base64 url-safe
|
|
|
|
|
ansible.builtin.assert:
|
|
|
|
|
that:
|
|
|
|
|
- "'+' not in serveur_oauth2_proxy_cookie_secret"
|
|
|
|
|
- "'/' not in serveur_oauth2_proxy_cookie_secret"
|
|
|
|
|
fail_msg: >-
|
|
|
|
|
`vault_oauth2_cookie` contient `+` ou `/` : c'est du base64 STANDARD. oauth2-proxy
|
|
|
|
|
décode en base64 URL-SAFE et retombera sur la chaîne brute, dont la longueur sera
|
|
|
|
|
refusée. Régénérer : openssl rand -base64 32 | tr '+/' '-_'
|
|
|
|
|
|
2026-07-03 19:05:04 -04:00
|
|
|
- name: Créer l'utilisateur système oauth2-proxy
|
|
|
|
|
ansible.builtin.user:
|
|
|
|
|
name: "{{ serveur_oauth2_proxy_utilisateur }}"
|
|
|
|
|
system: true
|
|
|
|
|
shell: /usr/sbin/nologin
|
|
|
|
|
create_home: false
|
|
|
|
|
|
2026-08-09 14:01:12 -04:00
|
|
|
# Le chemin de destination PORTE la version : cet artefact est immuable une fois pose.
|
|
|
|
|
# Sans garde, `get_url` recontacte le serveur distant a CHAQUE deploiement — et un
|
|
|
|
|
# serveur tiers lent suffit alors a faire tomber un deploiement de flotte. Constate le
|
|
|
|
|
# 2026-08-09 sur le binaire Forgejo, meme motif ici.
|
|
|
|
|
- name: L artefact de cette version est-il deja pose ?
|
|
|
|
|
ansible.builtin.stat:
|
|
|
|
|
path: "/tmp/oauth2-proxy-{{ serveur_oauth2_proxy_version }}.tar.gz"
|
|
|
|
|
register: serveur_oauth2_proxy_archive_present
|
|
|
|
|
|
artefacts : le controleur telecharge et pousse, la cible ne tire plus
Inventaire mesure de ce qu'une reconstruction de tenant telecharge — ~1,5 Gio :
Nextcloud 230 Mio, image collabora/code 471 Mio (Docker Hub), Keycloak 140,
Forgejo 101, oauth2-proxy 18, plus les paquets apt (Debian + Grafana +
smallstep + Icinga) sur 14 hotes.
Les quatre archives sont EPINGLEES EN VERSION et vont chacune sur UN SEUL
hote. Les retelecharger a chaque reconstruction est un gaspillage et une
dependance de plus sur le chemin critique — un serveur tiers lent a deja fait
tomber un deploiement le 2026-08-09, sur le binaire Forgejo precisement.
POURQUOI POUSSER PLUTOT QUE SERVIR UN CACHE. L'exploitant proposait son poste
comme cache HTTP ; l'intention est juste mais elle butait sur ce qu'on avait
ferme le matin meme : les regles sortantes visent !SETOPS_INTERNES, donc une
VM de tenant ne peut plus atteindre le poste. Servir un cache aurait exige de
ROUVRIR un flux vers le plan d'administration.
L'inversion evite le probleme entier : le controleur telecharge dans son cache
(~/.cache/setops, garde par un stat), puis pousse par le canal SSH qui existe
deja. Aucun port, aucun service, aucune regle, aucun couplage. Et ces
artefacts deviennent deployables HORS LIGNE une fois le cache rempli.
Ce que ca ne couvre pas, et qu'il faut nommer : l'image collabora/code, seule
entorse a la doctrine « zero Docker » du depot — elle merite sa propre
decision, pas un contournement discret ; et les paquets apt, dont le cache a
sa place cote HEBERGEUR, partage entre tenants.
Et une mesure qui a contredit mon hypothese : le .zip de Nextcloud pese
271 Mio contre 230 pour le .tar.bz2. Il telecharge PLUS pour decompresser
moins lentement. Le changement de format attend une mesure, pas une intuition.
Verifie : cache rempli (491 Mio, 4/4), ansible-lint production sur 79 fichiers,
prouver.py 35 OK, plus aucun get_url n'ecrit sur la cible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 20:58:58 -04:00
|
|
|
# Le controleur telecharge, puis pousse par SSH — la cible ne tire jamais d'Internet.
|
|
|
|
|
# Motif explique en detail dans `roles/serveur_nextcloud/tasks/installer.yml`.
|
|
|
|
|
- name: Cache d artefacts du contrôleur
|
|
|
|
|
ansible.builtin.file:
|
|
|
|
|
path: "{{ serveur_oauth2_proxy_cache_local }}"
|
|
|
|
|
state: directory
|
|
|
|
|
mode: "0700"
|
|
|
|
|
delegate_to: localhost
|
|
|
|
|
become: false
|
2026-08-09 14:01:12 -04:00
|
|
|
when: not serveur_oauth2_proxy_archive_present.stat.exists
|
artefacts : le controleur telecharge et pousse, la cible ne tire plus
Inventaire mesure de ce qu'une reconstruction de tenant telecharge — ~1,5 Gio :
Nextcloud 230 Mio, image collabora/code 471 Mio (Docker Hub), Keycloak 140,
Forgejo 101, oauth2-proxy 18, plus les paquets apt (Debian + Grafana +
smallstep + Icinga) sur 14 hotes.
Les quatre archives sont EPINGLEES EN VERSION et vont chacune sur UN SEUL
hote. Les retelecharger a chaque reconstruction est un gaspillage et une
dependance de plus sur le chemin critique — un serveur tiers lent a deja fait
tomber un deploiement le 2026-08-09, sur le binaire Forgejo precisement.
POURQUOI POUSSER PLUTOT QUE SERVIR UN CACHE. L'exploitant proposait son poste
comme cache HTTP ; l'intention est juste mais elle butait sur ce qu'on avait
ferme le matin meme : les regles sortantes visent !SETOPS_INTERNES, donc une
VM de tenant ne peut plus atteindre le poste. Servir un cache aurait exige de
ROUVRIR un flux vers le plan d'administration.
L'inversion evite le probleme entier : le controleur telecharge dans son cache
(~/.cache/setops, garde par un stat), puis pousse par le canal SSH qui existe
deja. Aucun port, aucun service, aucune regle, aucun couplage. Et ces
artefacts deviennent deployables HORS LIGNE une fois le cache rempli.
Ce que ca ne couvre pas, et qu'il faut nommer : l'image collabora/code, seule
entorse a la doctrine « zero Docker » du depot — elle merite sa propre
decision, pas un contournement discret ; et les paquets apt, dont le cache a
sa place cote HEBERGEUR, partage entre tenants.
Et une mesure qui a contredit mon hypothese : le .zip de Nextcloud pese
271 Mio contre 230 pour le .tar.bz2. Il telecharge PLUS pour decompresser
moins lentement. Le changement de format attend une mesure, pas une intuition.
Verifie : cache rempli (491 Mio, 4/4), ansible-lint production sur 79 fichiers,
prouver.py 35 OK, plus aucun get_url n'ecrit sur la cible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 20:58:58 -04:00
|
|
|
|
|
|
|
|
- name: L artefact est-il déjà dans le cache du contrôleur ?
|
|
|
|
|
ansible.builtin.stat:
|
|
|
|
|
path: "{{ serveur_oauth2_proxy_cache_local }}/oauth2-proxy-{{ serveur_oauth2_proxy_version }}.tar.gz"
|
|
|
|
|
register: serveur_oauth2_proxy_cache_present
|
|
|
|
|
delegate_to: localhost
|
|
|
|
|
become: false
|
|
|
|
|
when: not serveur_oauth2_proxy_archive_present.stat.exists
|
|
|
|
|
|
|
|
|
|
- name: Télécharger oauth2-proxy dans le cache du contrôleur (une seule fois)
|
2026-07-03 19:05:04 -04:00
|
|
|
ansible.builtin.get_url:
|
|
|
|
|
url: "{{ serveur_oauth2_proxy_url }}"
|
artefacts : le controleur telecharge et pousse, la cible ne tire plus
Inventaire mesure de ce qu'une reconstruction de tenant telecharge — ~1,5 Gio :
Nextcloud 230 Mio, image collabora/code 471 Mio (Docker Hub), Keycloak 140,
Forgejo 101, oauth2-proxy 18, plus les paquets apt (Debian + Grafana +
smallstep + Icinga) sur 14 hotes.
Les quatre archives sont EPINGLEES EN VERSION et vont chacune sur UN SEUL
hote. Les retelecharger a chaque reconstruction est un gaspillage et une
dependance de plus sur le chemin critique — un serveur tiers lent a deja fait
tomber un deploiement le 2026-08-09, sur le binaire Forgejo precisement.
POURQUOI POUSSER PLUTOT QUE SERVIR UN CACHE. L'exploitant proposait son poste
comme cache HTTP ; l'intention est juste mais elle butait sur ce qu'on avait
ferme le matin meme : les regles sortantes visent !SETOPS_INTERNES, donc une
VM de tenant ne peut plus atteindre le poste. Servir un cache aurait exige de
ROUVRIR un flux vers le plan d'administration.
L'inversion evite le probleme entier : le controleur telecharge dans son cache
(~/.cache/setops, garde par un stat), puis pousse par le canal SSH qui existe
deja. Aucun port, aucun service, aucune regle, aucun couplage. Et ces
artefacts deviennent deployables HORS LIGNE une fois le cache rempli.
Ce que ca ne couvre pas, et qu'il faut nommer : l'image collabora/code, seule
entorse a la doctrine « zero Docker » du depot — elle merite sa propre
decision, pas un contournement discret ; et les paquets apt, dont le cache a
sa place cote HEBERGEUR, partage entre tenants.
Et une mesure qui a contredit mon hypothese : le .zip de Nextcloud pese
271 Mio contre 230 pour le .tar.bz2. Il telecharge PLUS pour decompresser
moins lentement. Le changement de format attend une mesure, pas une intuition.
Verifie : cache rempli (491 Mio, 4/4), ansible-lint production sur 79 fichiers,
prouver.py 35 OK, plus aucun get_url n'ecrit sur la cible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 20:58:58 -04:00
|
|
|
dest: "{{ serveur_oauth2_proxy_cache_local }}/oauth2-proxy-{{ serveur_oauth2_proxy_version }}.tar.gz"
|
|
|
|
|
mode: "0644"
|
|
|
|
|
delegate_to: localhost
|
|
|
|
|
become: false
|
|
|
|
|
when:
|
|
|
|
|
- not serveur_oauth2_proxy_archive_present.stat.exists
|
|
|
|
|
- not (serveur_oauth2_proxy_cache_present.stat.exists | default(false))
|
|
|
|
|
|
|
|
|
|
- name: Déposer oauth2-proxy sur l hôte depuis le cache
|
|
|
|
|
ansible.builtin.copy:
|
|
|
|
|
src: "{{ serveur_oauth2_proxy_cache_local }}/oauth2-proxy-{{ serveur_oauth2_proxy_version }}.tar.gz"
|
2026-07-03 19:05:04 -04:00
|
|
|
dest: "/tmp/oauth2-proxy-{{ serveur_oauth2_proxy_version }}.tar.gz"
|
|
|
|
|
mode: "0644"
|
artefacts : le controleur telecharge et pousse, la cible ne tire plus
Inventaire mesure de ce qu'une reconstruction de tenant telecharge — ~1,5 Gio :
Nextcloud 230 Mio, image collabora/code 471 Mio (Docker Hub), Keycloak 140,
Forgejo 101, oauth2-proxy 18, plus les paquets apt (Debian + Grafana +
smallstep + Icinga) sur 14 hotes.
Les quatre archives sont EPINGLEES EN VERSION et vont chacune sur UN SEUL
hote. Les retelecharger a chaque reconstruction est un gaspillage et une
dependance de plus sur le chemin critique — un serveur tiers lent a deja fait
tomber un deploiement le 2026-08-09, sur le binaire Forgejo precisement.
POURQUOI POUSSER PLUTOT QUE SERVIR UN CACHE. L'exploitant proposait son poste
comme cache HTTP ; l'intention est juste mais elle butait sur ce qu'on avait
ferme le matin meme : les regles sortantes visent !SETOPS_INTERNES, donc une
VM de tenant ne peut plus atteindre le poste. Servir un cache aurait exige de
ROUVRIR un flux vers le plan d'administration.
L'inversion evite le probleme entier : le controleur telecharge dans son cache
(~/.cache/setops, garde par un stat), puis pousse par le canal SSH qui existe
deja. Aucun port, aucun service, aucune regle, aucun couplage. Et ces
artefacts deviennent deployables HORS LIGNE une fois le cache rempli.
Ce que ca ne couvre pas, et qu'il faut nommer : l'image collabora/code, seule
entorse a la doctrine « zero Docker » du depot — elle merite sa propre
decision, pas un contournement discret ; et les paquets apt, dont le cache a
sa place cote HEBERGEUR, partage entre tenants.
Et une mesure qui a contredit mon hypothese : le .zip de Nextcloud pese
271 Mio contre 230 pour le .tar.bz2. Il telecharge PLUS pour decompresser
moins lentement. Le changement de format attend une mesure, pas une intuition.
Verifie : cache rempli (491 Mio, 4/4), ansible-lint production sur 79 fichiers,
prouver.py 35 OK, plus aucun get_url n'ecrit sur la cible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 20:58:58 -04:00
|
|
|
when: not serveur_oauth2_proxy_archive_present.stat.exists
|
2026-07-03 19:05:04 -04:00
|
|
|
|
|
|
|
|
- name: Extraire le binaire oauth2-proxy
|
|
|
|
|
ansible.builtin.unarchive:
|
|
|
|
|
src: "/tmp/oauth2-proxy-{{ serveur_oauth2_proxy_version }}.tar.gz"
|
|
|
|
|
dest: /usr/local/bin
|
|
|
|
|
remote_src: true
|
|
|
|
|
extra_opts: ["--strip-components=1", "--wildcards", "*/oauth2-proxy"]
|
|
|
|
|
owner: root
|
|
|
|
|
group: root
|
|
|
|
|
mode: "0755"
|
|
|
|
|
creates: "{{ serveur_oauth2_proxy_binaire }}"
|
|
|
|
|
notify: Redémarrer oauth2-proxy
|
|
|
|
|
|
|
|
|
|
- name: Créer le répertoire de configuration
|
|
|
|
|
ansible.builtin.file:
|
|
|
|
|
path: "{{ serveur_oauth2_proxy_config | dirname }}"
|
|
|
|
|
state: directory
|
|
|
|
|
owner: root
|
|
|
|
|
group: "{{ serveur_oauth2_proxy_utilisateur }}"
|
|
|
|
|
mode: "0750"
|
|
|
|
|
|
|
|
|
|
- name: Déployer la configuration oauth2-proxy
|
|
|
|
|
ansible.builtin.template:
|
|
|
|
|
src: oauth2-proxy.cfg.j2
|
|
|
|
|
dest: "{{ serveur_oauth2_proxy_config }}"
|
|
|
|
|
owner: root
|
|
|
|
|
group: "{{ serveur_oauth2_proxy_utilisateur }}"
|
|
|
|
|
mode: "0640"
|
|
|
|
|
no_log: true
|
|
|
|
|
notify: Redémarrer oauth2-proxy
|
|
|
|
|
|
|
|
|
|
- name: Déployer l'unité systemd oauth2-proxy
|
|
|
|
|
ansible.builtin.template:
|
|
|
|
|
src: oauth2-proxy.service.j2
|
|
|
|
|
dest: /etc/systemd/system/oauth2-proxy.service
|
|
|
|
|
owner: root
|
|
|
|
|
group: root
|
|
|
|
|
mode: "0644"
|
|
|
|
|
notify: Redémarrer oauth2-proxy
|
|
|
|
|
|
|
|
|
|
- name: Activer et démarrer oauth2-proxy
|
|
|
|
|
when: not ansible_check_mode
|
|
|
|
|
ansible.builtin.systemd:
|
|
|
|
|
name: "{{ serveur_oauth2_proxy_service }}"
|
|
|
|
|
enabled: true
|
|
|
|
|
state: started
|
|
|
|
|
daemon_reload: true
|