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 |
||
|---|---|---|
| .. | ||
| defaults | ||
| handlers | ||
| meta | ||
| tasks | ||
| templates | ||
| README.md | ||
serveur_collabora
Collabora Online, en natif — paquet coolwsd, systemd, derrière l'edge nginx. Aucun
conteneur.
Pourquoi ce rôle a été réécrit
Il lançait collabora/code dans Docker. C'était la seule exception conteneurisée de
la flotte, et elle contredisait le principe fondateur : logiciel libre en natif, systemd +
paquets + nginx. Elle traînait en plus une dépendance entière — community.docker — qui
n'était même pas déclarée dans requirements.yml, donc absente de tout runner.
Depuis la réécriture, plus aucun rôle du dépôt n'a besoin de Docker.
Ce qui a été éprouvé avant d'écrire
Doctrine du dépôt : éprouver l'outil avant le rôle. Sur une Debian 13.6 réelle, sans rien installer :
apt-get install --simulate coolwsd -> résout jusqu'à « Conf coolwsd (26.04.3.1-1) »
libgcc1 (exigé par le paquet) -> fourni par libgcc-s1 sur trixie
le dépôt CODE-deb -> PLAT : Packages et Release à la racine, pas de dists/
Le paquet livre aussi /etc/nginx/snippets/coolwsd.conf et un profil AppArmor — deux
choses que cette flotte sait exploiter, contrairement à une image opaque.
La configuration : par surcharge, pas par réécriture
Le coolwsd.xml livré fait 439 lignes richement commentées. Le remplacer par un
gabarit maison obligerait à suivre son évolution à chaque version amont, et ferait perdre
les commentaires qui expliquent chaque réglage.
coolwsd accepte des surcharges --o:<clé>=<valeur>. Le rôle pose donc un fragment
systemd : la configuration de Set-OPS tient en un fichier lisible, celle du paquet reste
intacte, et apt purge rend la machine à son état d'origine.
La console d'administration est FERMÉE
Elle expose un formulaire identifiant/mot de passe hors de tout SSO, avec un secret à
créer, faire tourner et surveiller — pour une fonction dont personne n'a besoin au
quotidien. Même raisonnement que serveur_forgejo_connexion_locale.
L'ouvrir (serveur_collabora_admin_actif: true) exige alors vault_collabora_admin en
voûte, et de l'ajouter au gabarit de l'instance.
Variables principales
| Variable | Défaut | Rôle |
|---|---|---|
serveur_collabora_port |
9980 |
écoute, derrière l'edge |
serveur_collabora_server_name |
bureau.<domaine> |
nom externe — vide, coolwsd le déduit mal derrière un mandataire |
serveur_collabora_domaine_nextcloud |
cloud.<domaine> |
l'hôte WOPI autorisé |
serveur_collabora_ssl_termination |
true |
TLS terminé à l'edge, comme le reste de la flotte |
serveur_collabora_admin_actif |
false |
console d'administration |
Ce que ce rôle vérifie
Il interroge /hosting/capabilities après démarrage. Un service « active » qui ne répond
pas là serait découvert par Nextcloud devant un usager, à la première ouverture de
document.
Ce qui n'est pas encore prouvé
L'installabilité est établie par simulation sur Debian 13.6. Le fonctionnement ne l'est pas : aucun écosystème de la flotte ne fait tourner Collabora aujourd'hui. La première mise en service devra vérifier l'édition d'un document de bout en bout, depuis Nextcloud.