Set-OPS-Public/roles/serveur_nextcloud/tasks/installer.yml

176 lines
7.8 KiB
YAML
Raw Normal View History

---
# 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/nextcloud-{{ serveur_nextcloud_version }}.tar.bz2"
register: serveur_nextcloud_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 — la cible ne tire jamais d'Internet.
#
# Inventaire du 2026-08-10 : une reconstruction de tenant telecharge ~1,5 Gio, dont
# 490 Mio pour quatre archives EPINGLEES EN VERSION (Nextcloud 230, Keycloak 140,
# Forgejo 101, oauth2-proxy 18) qui vont chacune sur UN SEUL hote. Les retelecharger a
# chaque reconstruction est un pur gaspillage, et une dependance de plus sur le chemin
# critique — un serveur tiers lent a deja fait tomber un deploiement de flotte le
# 2026-08-09.
#
# POURQUOI POUSSER PLUTOT QUE SERVIR UN CACHE. Un cache HTTP sur le poste exigerait que
# les VM du tenant l'atteignent — donc de ROUVRIR un flux vers le plan d'administration,
# que les regles sortantes `!SETOPS_INTERNES` ferment depuis ce matin. Ici, rien de tel :
# on emprunte le canal SSH qui existe deja, aucun port, aucun service, aucune regle.
#
# Effet de bord recherche : ces artefacts deviennent deployables HORS LIGNE une fois le
# cache rempli. Sur une plateforme qui se veut souveraine, ce n'est pas un detail.
- name: Cache d artefacts du contrôleur
ansible.builtin.file:
path: "{{ serveur_nextcloud_cache_local }}"
state: directory
mode: "0700"
delegate_to: localhost
become: false
when: not serveur_nextcloud_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
depot de binaires : le site tient ce que les runners allaient chercher Le cache du site couvrait apt ; quatre artefacts arrivaient autrement, parce qu ils ne vivent dans aucun depot apt. Le controleur les tire puis les pousse par SSH. Mesure du 2026-09-12 : le cache du runner du site est ABSENT. Un second locataire monte depuis lui sortait chercher 570 Mo sur codeberg.org, github.com et download.nextcloud.com, alors que le meme ecosysteme ne demandait plus un seul paquet a Debian. Le poste du mainteneur les a depuis toujours : personne ne l avait vu. Pas de relais transparent, et la mesure tranche : github.com redirige vers une URL signee valable une heure, differente a chaque requete. Un cache qui la prend pour cle ne fait jamais mouche. Le relais marcherait pour deux amonts sur quatre. Donc un vrai depot, dans le service qui existe deja. LocalDirs d apt-cacher-ng publie un repertoire du disque sous un prefixe, eprouve AVANT d ecrire le role. Aucun service, aucun port, aucun certificat, aucun flux nouveaux : l ingress 3142 pair flotte couvre exactement ce chemin. Les versions ne sont pas recopiees : le role lit les defauts des quatre consommateurs. Les quatre roles recoivent une tache AJOUTEE, placee avant leur stat de cache — si le depot sert, le stat le voit et la tache amont se saute d elle-meme. Aucune tache existante n a change. P70 exige que tout dest ecrit sous un cache_local figure au depot. Une liste qui suit une autre prend du retard ; celle-ci est nee avec sa garde. Deux marches payees en chemin : - failed_when: false REECRIT le verdict, donc la premiere garde de signature ne gardait rien. Elles mesurent le fichier desormais. - file: state=directory cree les parents en 0750 : apt-cacher-ng, qui ne tourne pas en root, rendait 403 sur chaque fichier. Un chemin se traverse en entier. Verifie sur l infrastructure : 6/6 artefacts servis (200/206) depuis le runner du site ET depuis une machine du locataire a travers la frontiere ; les 6 empreintes SHA-256 sont identiques a celles qui ont construit Chezlepro ; second passage changed=0. make prouver : 69 OK, 0 echec, 1 saute. ansible-lint : 0 failure, profil production. Inclut aussi force: true sur cinq telechargements de cles : une reprise conditionnelle ne reprend rien (304 Not Modified, size 0, attempts 5). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-12 23:45:00 -04:00
# --- LE DEPOT DU SITE D'ABORD, L'INTERNET ENSUITE (2026-09-12) ----------------
#
# Le site tient ces artefacts dans son cache (`serveur_artefacts`, LocalDirs). Un runner
# qui les y trouve ne sort pas du tout : c'est le meme principe que le cache apt, applique
# aux publications qui ne vivent dans aucun depot apt.
#
# PLACEE AVANT LE `stat` DU CACHE DU CONTROLEUR, ET C'EST TOUT LE MONTAGE : si le depot
# sert le fichier, le `stat` qui suit le voit, et la tache de telechargement amont se
# saute d'elle-meme. Aucune tache existante n'a change.
#
# `failed_when: false` — le depot est une COMMODITE. Site sans depot, depot qui n'a pas
# encore cette version, cache du site tout neuf : on retombe sur l'amont, comme avant.
- name: Prendre l'archive Nextcloud au dépôt du site, avant de sortir sur Internet
ansible.builtin.get_url:
url: "{{ setops_depot_binaires }}/nextcloud-{{ serveur_nextcloud_version }}.tar.bz2"
dest: "{{ serveur_nextcloud_cache_local }}/nextcloud-{{ serveur_nextcloud_version }}.tar.bz2"
mode: "0644"
timeout: 30
delegate_to: localhost
become: false
failed_when: false
when:
- setops_depot_binaires | default('') | length > 0
- not serveur_nextcloud_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_nextcloud_cache_local }}/nextcloud-{{ serveur_nextcloud_version }}.tar.bz2"
register: serveur_nextcloud_cache_present
delegate_to: localhost
become: false
when: not serveur_nextcloud_archive_present.stat.exists
- name: Télécharger le tarball Nextcloud dans le cache du contrôleur (une seule fois)
ansible.builtin.get_url:
url: "{{ serveur_nextcloud_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_nextcloud_cache_local }}/nextcloud-{{ serveur_nextcloud_version }}.tar.bz2"
mode: "0644"
delegate_to: localhost
become: false
when:
- not serveur_nextcloud_archive_present.stat.exists
- not (serveur_nextcloud_cache_present.stat.exists | default(false))
# LA SIGNATURE, MEME CHEMIN QUE L'ARCHIVE : le depot du site d'abord, l'amont ensuite.
- name: Prendre la signature Nextcloud au dépôt du site, avant de sortir sur Internet
ansible.builtin.get_url:
url: "{{ setops_depot_binaires }}/nextcloud-{{ serveur_nextcloud_version }}.tar.bz2.asc"
dest: "{{ serveur_nextcloud_cache_local }}/nextcloud-{{ serveur_nextcloud_version }}.tar.bz2.asc"
mode: "0644"
timeout: 30
force: true
delegate_to: localhost
become: false
failed_when: false
when:
- setops_depot_binaires | default('') | length > 0
- not serveur_nextcloud_archive_present.stat.exists
- name: La signature Nextcloud est-elle dans le cache du contrôleur ?
ansible.builtin.stat:
path: "{{ serveur_nextcloud_cache_local }}/nextcloud-{{ serveur_nextcloud_version }}.tar.bz2.asc"
register: serveur_nextcloud_asc_present
delegate_to: localhost
become: false
when: not serveur_nextcloud_archive_present.stat.exists
- name: Récupérer la signature détachée de l archive Nextcloud
ansible.builtin.get_url:
url: "{{ serveur_nextcloud_signature_url }}"
dest: "{{ serveur_nextcloud_cache_local }}/nextcloud-{{ serveur_nextcloud_version }}.tar.bz2.asc"
mode: "0644"
force: true
delegate_to: localhost
become: false
when:
- not serveur_nextcloud_archive_present.stat.exists
- not ((serveur_nextcloud_asc_present.stat.exists | default(false))
and (serveur_nextcloud_asc_present.stat.size | default(0)) > 0)
- name: Vérifier la signature de l archive Nextcloud contre l empreinte épinglée
ansible.builtin.command:
argv:
- python3
- "{{ role_path }}/../../scripts/verifier_signature.py"
- --artefact
- "{{ serveur_nextcloud_cache_local }}/nextcloud-{{ serveur_nextcloud_version }}.tar.bz2"
- --signature
- "{{ serveur_nextcloud_cache_local }}/nextcloud-{{ serveur_nextcloud_version }}.tar.bz2.asc"
- --cle
- "{{ role_path }}/files/nextcloud-release.asc"
- --empreinte
- "{{ serveur_nextcloud_signature_empreinte }}"
delegate_to: localhost
become: false
changed_when: false
when: not serveur_nextcloud_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: Déposer le tarball Nextcloud sur l hôte depuis le cache
ansible.builtin.copy:
src: "{{ serveur_nextcloud_cache_local }}/nextcloud-{{ serveur_nextcloud_version }}.tar.bz2"
dest: "/tmp/nextcloud-{{ serveur_nextcloud_version }}.tar.bz2"
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_nextcloud_archive_present.stat.exists
# UNE AUTRE VERSION EN PLACE ? Alors on MONTE, avant que l'extraction ci-dessous ne
# constate un `occ` present et ne fasse rien — ce qu'elle faisait jusqu'au 2026-10-03,
# laissant le code de l'ancienne version sous le numero de la nouvelle.
- name: Monter Nextcloud si une autre version est en place
ansible.builtin.include_tasks: monter.yml
- name: Extraire Nextcloud dans /var/www (si absent)
ansible.builtin.unarchive:
src: "/tmp/nextcloud-{{ serveur_nextcloud_version }}.tar.bz2"
dest: "/var/www/"
remote_src: true
owner: "{{ serveur_nextcloud_utilisateur }}"
group: "{{ serveur_nextcloud_utilisateur }}"
creates: "{{ serveur_nextcloud_racine }}/occ"
- name: Installer Nextcloud (occ maintenance:install, PG en TLS ; une seule fois)
ansible.builtin.command:
cmd: >-
php {{ serveur_nextcloud_racine }}/occ maintenance:install
--database pgsql
--database-host {{ serveur_nextcloud_db_host }}
--database-name {{ serveur_nextcloud_db_name }}
--database-user {{ serveur_nextcloud_db_user }}
--database-pass {{ serveur_nextcloud_db_password }}
--admin-user {{ serveur_nextcloud_admin_user }}
--admin-pass {{ serveur_nextcloud_admin_password }}
--data-dir {{ serveur_nextcloud_data_dir }}
creates: "{{ serveur_nextcloud_racine }}/config/config.php"
become: true
become_user: "{{ serveur_nextcloud_utilisateur }}"
environment:
PGSSLMODE: "{{ serveur_nextcloud_pg_sslmode }}"
PGSSLROOTCERT: "{{ serveur_nextcloud_ca_racine }}"
no_log: true
when: not ansible_check_mode