edujiro5972 56dfcfc3d2 LifePlay UE 5.8 : état de développement au 2026-10-20

Tickets : PUB-20261020-T1

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

2026-10-20 17:35:10 +02:00

36 KiB

Raw Blame History

Fiche STM1-SPEC-07 — Niveau N2 — Modèle prévu opus medium | utilisé claude-opus-5-5 — Agent session « Medium · STM1 » (pas de sous-agent) — Skills sk-protocol

STM1-SPEC-07 : outil de téléchargement des cartes de villes (étude, sans code ni copie UE) (2026-10-20)

Ordre : Big Boss (local_104ff22d). Décisions de l'utilisateur, tapées dans la session STM1, citées mot pour mot : « gardons paris comme ville de référence.. pour le moment sur Forgejo. on doit mettre en place un outils de download des cartes. Peut on monétiser la solutions sans violé la licence? le cout d'hébergement à 1,75€ la carte ». Lecture retenue par Big Boss, à confirmer par l'utilisateur sur cette fiche :

Paris est la ville de référence du pilote ;
hébergement sur le Forgejo de l'utilisateur (releases) pour l'instant ;
un outil de téléchargement des cartes est à mettre en place.

Donnée d'entrée : coût d'hébergement de 1,75 € par carte (utilisateur). Aucun prix de vente n'est calculé ni proposé ici : c'est une décision de l'utilisateur. (Correction : la réponse de la session du 2026-10-20 citait « 1,75 € suggéré » dans un exemple de modèle ; cette mention est retirée.)

1. Rappel des briques (établi : SPEC-05, SPEC-06, B5)

Chaîne de production d'une ville :
- extrait OSM (Overpass, une requête) ;
- LPImportCityOSM (import en UStreetMap, B5 : Paris en 42 s, pic 3,02 Go, 77,2 Mo) ;
- maillage Static (logique OnCreateStaticMeshAssetClicked, à écrire en commandlet) ;
- eau (LPBuildCityWater).
Mods d'assets : Mods/<id>/ monté au démarrage par le moteur et contrôlé par LPModGuard ; cuisson par BuildMod.ps1 contre une version de référence (Docs/23_Cycle_De_Vie_Mod.md).
Résolution des villes : GI.MoveCity, puis ULPAssetRegistryHelpers::GetAssetByObjectPath (C++), qui est le point de redirection vers un pack.
Moteur 5.8 :
- FHttpModule ;
- FPlatformMisc::GetSHA256Signature et FSHA256Signature (GenericPlatformMisc.h:322, 1405) ;
- pas de zip en Shipping (FZipArchiveReader est en Developer), donc fichiers séparés.

2. Questions fermées (décisions 2 à 4 de SPEC-06), avec recommandation

#	Question	Choix	Recommandation et motif
Q1	Format d'un pack	(a) mod d'assets (`Mods/<id>/`) avec redirection C++ des chemins / (b) pak de remplacement des chemins `/Game/…`	(a) : garde `LPModGuard` (version), gestionnaire de mods, désinstallation ; aucune modification du GI ; le jeu de base n'est jamais écrasé
Q2	Taille de zone par ville (hors Paris, Londres et Bath)	(a) format Paris/Londres (≈ 11 × 8 km) / (b) 5 × 5 km / (c) 3 × 3 km	(c) pour commencer : hébergement par carte et temps de téléchargement réduits ; centre-ville suffisant pour le jeu (lieux, aménités). À mesurer sur une ville avant le lot. Paris reste au format de référence (≈ 11 × 8 km)
Q3	Découpage	(a) un pack par ville / (b) un pack par région	(a) : correspond au coût par carte donné par l'utilisateur et au bouton « Download » par ville ; mises à jour indépendantes. Change la recommandation de SPEC-06 (région), au vu du coût par carte

3. Hébergement sur le Forgejo (releases)

Dépôt public dédié aux cartes (par exemple <forgejo>/<propriétaire>/LifePlay-Cities), séparé du dépôt du jeu ; une release par pack et par version (Paris-1.0.0…). Les pièces jointes (.uplugin, .lpmod, CREDITS.txt, .pak/.utoc/.ucas, extrait .osm ou méthode) sont téléchargeables sans authentification.
URL en réglage, jamais en dur :
- Config/DefaultGame.ini, section [/Script/LifePlay.LPCityPacksSubsystem], ManifestUrl= : URL publique du manifeste, attachée à une release fixe ou servie par le dépôt ;
- surcharge possible par l'utilisateur dans GameUserSettings.ini, sans rebuild.
Aucun jeton dans le dépôt ni dans le jeu. La lecture est publique. La publication (création des releases, envoi des fichiers) se fait par un script d'outillage local (Tools/PublishCityPack.ps1, à écrire) qui lit le jeton Forgejo dans une variable d'environnement ou le gestionnaire d'identifiants de Windows, jamais dans un fichier versionné. Le jeton est créé par l'utilisateur.
Quotas : taille maximale des pièces jointes et bande passante du serveur Forgejo à vérifier par l'utilisateur sur son instance (réglage [attachment] MAX_SIZE de Forgejo).

4. Manifeste

JSON publié (une URL), signé en option (étape ultérieure).

{
  "format": 1,
  "attribution": "Map data © OpenStreetMap contributors, ODbL 1.0",
  "packs": [{
    "id": "LPCity_Paris", "city": "Paris", "version": "1.0.0",
    "game_version_min": "2026.11.0", "game_version_max": "2026.12.99", "engine": "5.8",
    "size_bytes": 0, "osm_base": "2026-10-20T12:54:06Z",
    "source": "Overpass, requête et extrait publiés dans la release",
    "files": [{ "path": "LPCity_Paris.uplugin", "url": "https://…", "bytes": 0, "sha256": "…" }]
  }]
}

Règles :

le jeu ne propose que les packs compatibles (game_version_min/max, engine) ;
size_bytes est affiché avant tout téléchargement ;
le manifeste est relu à chaque ouverture du menu, avec un cache local de 24 h.

5. Côté jeu : `ULPCityPacksSubsystem` (C++, module `LifePlay`, aussi en Shipping)

Liste : lecture du manifeste (FHttpModule, délai d'attente de 15 s). Pour chaque ville de GI.Cities (lecture seule), l'état est : installé (pack monté), disponible (dans le manifeste, compatible) ou carte de base (gabarit actuel).
Consentement avant chaque téléchargement, en anglais dans le jeu. Il affiche :
- la taille ;
- la source (URL de l'hôte) ;
- la licence (ODbL, attribution) ;
- le fait que le pack sera actif au prochain lancement. Pas de case précochée.
Téléchargement, fichier par fichier :
- dans Saved/Downloads/<id>/<fichier>.part, avec progression ;
- écriture en flux vers le disque (IHttpRequest::SetResponseBodyReceiveStream, à vérifier en 5.8), sans tout garder en mémoire.
Erreurs réseau et reprise :
- nouvelle tentative avec attente croissante (2, 4 puis 8 s, au plus 3 essais) ;
- reprise d'un .part par l'en-tête Range: bytes=<taille>-, si le serveur répond 206 ; sinon, reprise de zéro (prise en charge de Range par les pièces jointes Forgejo : à vérifier) ;
- annulation par l'utilisateur ;
- délai d'attente ;
- message clair (« Download failed: … ») sans plantage ;
- la ville reste sur sa carte de base.
Vérification : SHA-256 de chaque fichier contre le manifeste (FPlatformMisc::GetSHA256Signature). Un écart supprime le .part et affiche un message ; rien n'est installé.
Installation atomique : quand tous les fichiers sont vérifiés, déplacement de Saved/Downloads/<id>/ vers <jeu>/Mods/<id>/. Si Mods/ n'est pas inscriptible, message et emplacement indiqué (Saved reste intact).
Montage : au prochain lancement, par le moteur (FPluginManager), contrôlé par LPModGuard. Pas de montage à chaud au départ ; ce serait une étape ultérieure (FPakPlatformFile::Mount et registre d'assets).
Redirection (C++, LPAssetRegistryHelpers::GetAssetByObjectPath) :
- /Game/Heavy/StreetMap/[Static/|Water/]<Ville> est redirigé vers /<id>/StreetMap/… si le pack est monté ;
- pack absent : la carte de base (gabarit) reste ;
- journal [LPCity].
Désinstallation : par le gestionnaire de mods existant (supprimer Mods/<id>).
Interface :
- (i) une fenêtre Slate C++ « City maps », ouverte depuis le menu des villes ou le gestionnaire de mods, sans modifier de Blueprint (recommandé au départ) ;
- ou (ii) un bouton dans le widget UI/CityMenu, par MCP (révision du Blueprint).
Sûreté :
- HTTPS seulement ;
- aucun fichier exécuté (paks montés par le moteur) ;
- aucune donnée personnelle envoyée ;
- en-tête User-Agent neutre ;
- le manifeste n'est que de la donnée.

6. Coût (estimé, en jours)

Lot	Contenu	Jours
A	redirection C++ des chemins (`GetAssetByObjectPath`), avec essai sur Paris en pack	0,5
B	production d'un pack : commandlet de maillage `Static` (logique du plugin), découpe à la boîte, eau, `BuildMod`, `CREDITS` (ODbL)	2
C	`Tools/PublishCityPack.ps1` : manifeste, SHA-256, release Forgejo par l'API (jeton hors dépôt)	1
D	`ULPCityPacksSubsystem` : manifeste, HTTP en flux, reprise, SHA-256, installation atomique, journal	2
E	interface Slate (liste, consentement, progression, erreurs)	1,5
F	VAL (réseau coupé, SHA-256 faux, reprise, version incompatible, pack absent) et essai en jeu	1
G	DOC (doc numérotée, crédits, guide de publication)	0,5
	Total	≈ 8,5

Plus la production des cartes (environ 278 villes) : par ville, une requête Overpass, l'import, le maillage, la cuisson, la publication. C'est automatisable, mais la cadence est limitée par la politique d'usage d'Overpass.

7. Monétisation : lecture des licences (pas un avis juridique)

Ce qui suit est une lecture des fichiers de licence du dépôt, pas un avis juridique. Pour un usage commercial, faire vérifier par un juriste.

Composant	Licence (fichier)	Lecture
Données des cartes	ODbL 1.0 (`Licenses/OpenStreetMap_Geodata_License.txt`)	usage commercial permis. Obligations : attribution (« © OpenStreetMap contributors ») ; partage à l'identique de la base dérivée diffusée (les données de la carte restent sous ODbL : l'acheteur peut les repartager) ; pour un « Produced Work » (œuvre produite, par exemple un rendu), licence libre, mais avec attribution et la base dérivée offerte (ou la méthode pour la refaire) ; pas de mesure technique de restriction sans version libre parallèle
Plugin StreetMap	MIT (`StreetMap_Plugin_License.txt`)	aucune contrainte gênante (mention de la licence)
Code et assets de Vinfamy	MIT (`Vinfamy_License.txt`)	vente permise
Jeu dans son ensemble	AGPL, à cause de ManuelLab (`AGPL_License.txt`, `Vinfamy_License.txt`)	le code du jeu, outil de téléchargement compris, doit rester disponible en source (déjà public)
Mods	`Licenses/Modding_License.txt` : « completely belong to YOU the modder … even commercially »	un pack de cartes distribué comme mod peut être vendu ; les données qu'il contient restent sous ODbL

Conséquences (lecture) :

Permis :
- faire payer le service (téléchargement intégré, hébergement, mises à jour) ;
- l'accès anticipé ;
- les dons ;
- le prix libre.
Non permis : interdire le repartage des données de la carte, ou la verrouiller sans version libre.
- Les extraits .osm (ou la requête et la méthode) doivent être publiés avec chaque pack (pièce jointe de la release).
Le coût d'hébergement (1,75 € par carte, donnée de l'utilisateur) n'entre pas en conflit avec la licence.
Le choix d'un prix de vente reste à l'utilisateur.
Hors licence, à vérifier par l'utilisateur : les conditions des services de paiement envers un jeu pour adultes (le pack de cartes lui-même n'a pas de contenu adulte).

7 bis. Conteneurs sur le serveur Forgejo (podman) : étude, rien téléchargé ni exécuté

Information de l'utilisateur citée par Big Boss : « sur Forgejo podman est installé on peut descendre des container de produit adapté ». Aucun podman pull ni podman build n'est fait ici. Chacun sera annoncé, soumis à l'accord de l'utilisateur et lancé par lui sur son serveur. Les informations des images viennent des pages officielles relues le 2026-10-20 ; ce qui n'y figure pas est marqué « à vérifier ».

(a) Servir les packs et le manifeste : conteneur de fichiers statiques

But : garantir Range et 206 (reprise, § 5.4), des en-têtes de cache (ETag, Cache-Control) et un type MIME correct. Les pièces jointes des releases Forgejo n'ont pas ces garanties (à vérifier). Ce conteneur peut tourner à côté des releases (miroir) ou à leur place (le manifeste pointe alors vers lui).

Image	Éditeur	Statut	Licence	Taille	Ports	Volumes	Mise à jour	Avis
`docker.io/library/nginx:1.30.6-alpine` (variante `stable-alpine`)	NGINX Docker Maintainers	Docker Official Image	nginx : licence « 2-clause BSD-like » (page de l'image)	non affichée pour `alpine` (60,9 Mo pour `latest` Debian ; `alpine` plus petite, à vérifier)	80 dans le conteneur	lecture seule : `/usr/share/nginx/html` (packs) et `/etc/nginx/conf.d` (configuration)	suivre les étiquettes `1.30.x-alpine` (correctifs de sécurité)	recommandée si un mandataire HTTPS sert déjà Forgejo : nginx derrière lui, sur `127.0.0.1:<port>` ; `Range` natif
`docker.io/library/caddy:2.11.7-alpine`	Caddy Docker Maintainers	Docker Official Image	Apache-2.0 (dépôt caddyserver/caddy ; non affichée sur la page, à relire)	23,7 Mo (page de l'image)	80, 443, 443/udp	`/data`, `/config` (déclarés) ; packs en lecture seule, par exemple `/srv`	étiquettes `2.11.x-alpine`	alternative si aucun mandataire n'existe : HTTPS automatique (Let's Encrypt)

Configuration proposée (nginx) : location /citypacks/ { root /usr/share/nginx/html; add_header Cache-Control "public, max-age=86400"; } (Range et ETag sont natifs) ; manifeste servi avec Cache-Control: max-age=300. Sûreté :

podman rootless ;
--read-only ;
--cap-drop=ALL ;
--security-opt=no-new-privileges ;
volume des packs monté :ro ;
aucune écriture dans le conteneur ;
port lié à 127.0.0.1 derrière le mandataire HTTPS existant.

(b) Produire les cartes sur le serveur : découper à la boîte sans rien installer sur le poste de jeu

Chemin recommandé : extrait Geofabrik par pays (fichier .osm.pbf, téléchargement annoncé à part), puis osmium extract --bbox (3 × 3 km par ville), puis osmium cat -o ville.osm (XML lisible par LPImportCityOSM). Ce chemin évite les 278 requêtes à Overpass (saturation constatée le 2026-10-20 : HTTP 502).

Image	Éditeur	Statut	Licence	Taille	Ports	Volumes	Mise à jour	Avis
Image construite localement : `Containerfile` à partir de `docker.io/library/debian:stable-slim`, plus le paquet Debian `osmium-tool`	Debian (image de base officielle ; paquet signé par Debian)	base Docker Official Image ; paquet de l'archive Debian (signatures APT)	osmium-tool : GPL-3.0 (dépôt osmcode/osmium-tool, à relire) ; base Debian : licences libres (DFSG)	à mesurer (base `stable-slim` plus un paquet ; quelques dizaines de Mo, estimé)	aucun	`/data` (extraits `.pbf` en lecture seule, sorties `.osm` en écriture)	reconstruire (`podman build --pull`) pour suivre les mises à jour de Debian	recommandée : pas d'image tierce, provenance vérifiable
`docker.io/iboates/osmium`	tiers (iboates)	communautaire, non officielle	osmium : GPL-3.0	non relevée	aucun	`/data` (à vérifier)	reconstruite le 1er de chaque mois, étiquette `nightly` (description Docker Hub)	à défaut : épingler un condensat (`@sha256:`) et relire le `Dockerfile`
`docker.io/wiktorn/overpass-api:0.7.62`	tiers (wiktorn)	communautaire, non officielle	Overpass API : AGPL-3.0 (logiciel drolbr/Overpass-API, à relire) ; licence de l'image non indiquée	≈ 117,9 Mo compressés (page des étiquettes), plus une base de données de plusieurs dizaines à centaines de Go	80	volume de données (`/db`)	—	non recommandée : par défaut, l'image clone un serveur du monde entier (description Docker Hub) ; trop lourd pour découper 278 villes. Geofabrik + osmium suffit

Containerfile proposé pour osmium (texte seulement, non exécuté) :

FROM docker.io/library/debian:stable-slim
RUN apt-get update && apt-get install -y --no-install-recommends osmium-tool && rm -rf /var/lib/apt/lists/*
USER 1000:1000
WORKDIR /data
ENTRYPOINT ["osmium"]

Exemple d'usage (à lancer par l'utilisateur) : podman run --rm --network=none -v /srv/osm:/data:Z lp-osmium extract --bbox 2.3305,48.8395,2.3715,48.8665 france-latest.osm.pbf -o paris-3x3.osm.pbf, puis osmium cat paris-3x3.osm.pbf -o paris-3x3.osm. --network=none : le conteneur de découpe n'a aucun accès réseau.

(c) Autres images utiles (optionnelles)

Aucune autre indispensable : un serveur de fichiers (a) et osmium (b) couvrent le besoin.
Pour automatiser la publication côté serveur : un service planifié (systemd timer et podman run) qui régénère un pack depuis un extrait Geofabrik récent. Pas d'image supplémentaire.
Écartés : MinIO/S3 (inutile pour des fichiers statiques), une instance Overpass locale (voir (b)).

Annonce des `podman pull` (à soumettre à l'utilisateur, aucun lancé)

#	Commande (lancée par l'utilisateur sur son serveur)	Ce qu'elle télécharge	Taille
C1	`podman pull docker.io/library/nginx:1.30.6-alpine`	serveur de fichiers statiques, image officielle	à vérifier (variante Alpine)
C2	`podman build -t lp-osmium -f Containerfile .` (tire `docker.io/library/debian:stable-slim`, puis le paquet `osmium-tool` depuis l'archive Debian)	base Debian officielle et paquet signé	à mesurer
C3 (option)	`podman pull docker.io/library/caddy:2.11.7-alpine`	seulement si aucun mandataire HTTPS n'existe	23,7 Mo

Plus les extraits Geofabrik par pays (fichiers, pas des images), annoncés à part avant chaque téléchargement : URL, taille, licence ODbL.

État réel du serveur (relevé `podman` collé par l'utilisateur, relayé par Big Boss le 2026-10-20) et révision

Conteneur	Image	Ports
`forgejo_db_1`	`docker.io/library/postgres:15-alpine`	5432/tcp (non publié)
`forgejo_caddy_1`	`docker.io/library/caddy:2-alpine`	`0.0.0.0:80->80`, `0.0.0.0:443->443`, 443/udp, 2019/tcp
`forgejo_server_1`	`codeberg.org/forgejo/forgejo:9`	`127.0.0.1:3000->3000`, `0.0.0.0:2222->22`

Conséquences (révision du (a) et de l'annonce) :

Un mandataire HTTPS existe : Caddy. C3 tombe (pas de second Caddy).
C1 (nginx) n'est plus utile : recommandation « Caddy seul ».
- La directive file_server de Caddy sert des fichiers statiques avec les requêtes partielles (Range, réponse 206), ETag, Last-Modified et le type MIME (documentation de Caddy, file_server ; à relire sur la version installée).
- Il suffit d'un bloc de site en plus dans le Caddyfile existant, et d'un volume en lecture seule, sans nouvelle image.
- nginx derrière Caddy n'ajouterait qu'un saut de plus et une image à maintenir.
Bloc proposé (texte seulement, non appliqué), deux variantes au choix de l'utilisateur :
```
# Variante 1 : sous-domaine dédié (DNS à créer), certificat automatique par Caddy
cartes.<domaine> {
    root * /srv/citypacks
    @manifest path /manifest.json
    header @manifest Cache-Control "public, max-age=300"
    header Cache-Control "public, max-age=86400"
    file_server
}

# Variante 2 : chemin sous le domaine actuel de Forgejo (dans son bloc de site existant, avant le reverse_proxy)
handle_path /citypacks/* {
    root * /srv/citypacks
    header Cache-Control "public, max-age=86400"
    file_server
}
```
- Volume à ajouter au conteneur Caddy : /srv/citypacks:/srv/citypacks:ro (option :Z sous SELinux).
- L'ajout d'un volume demande de recréer le conteneur forgejo_caddy_1 (fichier compose ou commande d'origine) : interruption de quelques secondes. Un simple rechargement du Caddyfile (caddy reload) ne suffit pas pour un volume.
- Pas de encode sur les paks (déjà compressés).
- Le ManifestUrl du jeu pointe alors vers https://cartes.<domaine>/manifest.json (variante 1) ou https://<domaine forgejo>/citypacks/manifest.json (variante 2).
Épinglage des images.
- caddy:2-alpine est une étiquette flottante : elle suit toute la série 2.x, et chaque recréation peut changer de version. À épingler sur une version précise (par exemple docker.io/library/caddy:2.11.7-alpine, étiquette officielle relevée le 2026-10-20) ou sur un condensat @sha256:…, et à monter volontairement.
- Même remarque, hors de la fiche mais visible dans le relevé : postgres:15-alpine et forgejo:9 sont flottantes (par version mineure ou majeure) ; même règle conseillée.
Port d'administration de Caddy (2019).
- Dans le relevé, 2019/tcp apparaît sans liaison à l'hôte (pas de 0.0.0.0:…->2019). Il est déclaré par l'image, mais non publié (estimé, d'après le format de podman ps).
- Il ne doit jamais être publié : l'API d'administration de Caddy modifie la configuration à chaud, sans authentification par défaut.
- À vérifier par l'utilisateur : podman port forgejo_caddy_1 ne doit pas lister 2019.
- Option : admin off, ou admin localhost:2019, dans le bloc global du Caddyfile.
C2 (lp-osmium) est inchangé : image construite localement, sans réseau (§ (b)).

Annonce révisée : C1 retiré, C3 retiré ; reste C2 (podman build -t lp-osmium -f Containerfile .), plus la modification de Caddy (bloc de site, volume en lecture seule, épinglage, vérification du port 2019). Ce sont des gestes de l'utilisateur sur son serveur, après son accord.

Ajouts au projet compose « forgejo » (outil de déploiement : podman-compose) — esquisse, précisée par le sous-§ « Compose réel » ci-dessous

Précision de l'utilisateur, citée par Big Boss : « podman-compose est l'outil de déployment ». Les conteneurs forgejo_db_1, forgejo_caddy_1 et forgejo_server_1 viennent d'un projet compose « forgejo ». Ce qui suit est du texte à ajouter par l'utilisateur. Le nom du fichier compose (compose.yml, docker-compose.yml…) et le chemin actuel du Caddyfile ne sont pas connus : ils sont notés <…>. Rien n'est appliqué.

1. Fichier compose : ajouts (service caddy existant, service lp-osmium neuf)

services:
  caddy:
    # ÉPINGLAGE : remplace l'étiquette flottante caddy:2-alpine
    image: docker.io/library/caddy:2.11.7-alpine
    volumes:
      # (existant, à garder tel quel) le Caddyfile et les volumes /data et /config du projet
      # AJOUT : packs de villes et manifeste, en lecture seule
      - ./citypacks:/srv/citypacks:ro,Z
    # ports : inchangés (80, 443, 443/udp) ; NE PAS ajouter 2019

  # AJOUT : outil de découpe des cartes, lancé à la demande, sans réseau
  lp-osmium:
    build:
      context: ./lp-osmium            # dossier contenant le Containerfile du § (b)
      dockerfile: Containerfile
    image: localhost/lp-osmium:1
    network_mode: none
    profiles: ["outils"]              # jamais démarré par « up » sans --profile
    volumes:
      - ./osm:/data:Z                 # extraits Geofabrik (.pbf) en entrée, .osm en sortie
    entrypoint: ["osmium"]

profiles : pris en charge par podman-compose dans ses versions récentes (à vérifier par podman-compose version).
Sinon, solution de repli : mettre lp-osmium dans un second fichier compose.outils.yml, lancé par podman-compose -f compose.outils.yml run --rm lp-osmium ….

2. Caddyfile : ajout (une des deux variantes du sous-§ précédent, par exemple la variante 1)

cartes.<domaine> {
    root * /srv/citypacks
    @manifest path /manifest.json
    header @manifest Cache-Control "public, max-age=300"
    header Cache-Control "public, max-age=86400"
    file_server
}

Le bloc global n'est pas modifié. Option de durcissement : { admin localhost:2019 }, valeur par défaut, à confirmer dans le bloc global existant.

3. Production d'un pack (à la demande) : podman-compose --profile outils run --rm lp-osmium extract --bbox <ouest>,<sud>,<est>,<nord> <pays>-latest.osm.pbf -o <ville>-3x3.osm.pbf, puis podman-compose --profile outils run --rm lp-osmium cat <ville>-3x3.osm.pbf -o <ville>-3x3.osm. Les fichiers produits restent dans ./osm/. Le .osm est ensuite importé sur le poste de développement (LPImportCityOSM), et le pack cuit est déposé dans ./citypacks/ par le script de publication.

4. Séquence de déploiement (lancée par l'utilisateur sur son serveur, dans le dossier du projet compose)

Étape	Commande (texte, à adapter)	Attendu
0. État avant	`podman-compose ps` ; `podman image inspect docker.io/library/caddy:2-alpine --format '{{.Digest}}'`	3 conteneurs actifs ; condensat de l'image Caddy actuelle noté (pour le retour arrière)
1. Sauvegarde	`cp <compose>.yml <compose>.yml.bak-20261020` ; `cp <Caddyfile> <Caddyfile>.bak-20261020`	deux copies présentes
2. Dossiers	`mkdir -p citypacks osm lp-osmium` ; déposer `lp-osmium/Containerfile` ; déposer un fichier d'essai `citypacks/essai.txt`	dossiers créés
3. Édition	ajouts des points 1 et 2 dans le compose et le Caddyfile	—
4. Image épinglée	`podman-compose pull caddy` (tire `caddy:2.11.7-alpine` : téléchargement à accepter)	image présente
5. Redéploiement	`podman-compose up -d caddy` (recrée le seul service `caddy` : coupure de quelques secondes du site Forgejo)	`forgejo_caddy_1` recréé et actif
6. Vérifications	`podman-compose exec caddy caddy validate --config /etc/caddy/Caddyfile` ; `podman port forgejo_caddy_1` (pas de 2019) ; `curl -I https://<domaine forgejo>/` (Forgejo répond) ; `curl -I -H "Range: bytes=0-3" https://cartes.<domaine>/essai.txt`	« Valid configuration » ; ports 80 et 443 seulement ; Forgejo en `200` ; essai en `206 Partial Content` avec `ETag`
7. Outil (option)	`podman-compose --profile outils build lp-osmium` (C2 : tire `debian:stable-slim` et le paquet `osmium-tool`, à accepter) ; `podman-compose --profile outils run --rm lp-osmium --version`	version d'osmium affichée
R. Retour arrière	`cp <compose>.yml.bak-20261020 <compose>.yml` ; `cp <Caddyfile>.bak-20261020 <Caddyfile>` ; `podman-compose up -d caddy` (l'ancienne image `caddy:2-alpine` est encore locale, voir le condensat de l'étape 0)	retour à l'état d'avant ; Forgejo répond

Précautions :

faire l'étape 5 à un moment creux ;
ne pas lancer podman-compose down (il arrêterait Forgejo et la base) ;
les étapes 4 et 7 téléchargent des images : chacune demande l'accord de l'utilisateur.

Compose réel (`~/forgejo/docker-compose.yml`, VPS Ubuntu, podman-compose) : diff exact et séquence

Fichier collé par l'utilisateur et relayé par Big Boss, secrets masqués. Aucun secret n'est recopié ici. Établi par ce fichier :

version: '3.8' ;
services db (postgres:15-alpine, aucun port publié), server (codeberg.org/forgejo/forgejo:9, 127.0.0.1:3000:3000, 2222:22) et caddy (docker.io/library/caddy:2-alpine, 80:80, 443:443) ;
volumes de caddy : ./Caddyfile:/etc/caddy/Caddyfile:z, ./data/caddy_data:/data:Z, ./data/caddy_config:/config:Z ;
le port 2019 n'est pas publié (établi).

1. Diff exact du service caddy (texte ; le reste du fichier est inchangé)

   caddy:
-    image: docker.io/library/caddy:2-alpine
+    image: docker.io/library/caddy:2.11.7-alpine
     restart: always
     ports:
       - "80:80"
       - "443:443"
     volumes:
       - ./Caddyfile:/etc/caddy/Caddyfile:z
       - ./data/caddy_data:/data:Z
       - ./data/caddy_config:/config:Z
+      - ./data/citypacks:/srv/citypacks:ro,Z

(:Z sert aux systèmes SELinux ; sur Ubuntu, qui utilise AppArmor, il est sans effet et sans risque, pour garder le même style que les autres volumes.)

2. Bloc à ajouter au Caddyfile

Variante 1, sous-domaine dédié (enregistrement DNS cartes.<domaine> vers le VPS à créer d'abord ; certificat automatique) : ajouter à la fin du Caddyfile

cartes.<domaine> {
    root * /srv/citypacks
    @manifest path /manifest.json
    header @manifest Cache-Control "public, max-age=300"
    header Cache-Control "public, max-age=86400"
    file_server
}

Variante 2, chemin sous le domaine de Forgejo : à insérer dans le bloc de site existant de Forgejo, avant son reverse_proxy :
```
    handle_path /citypacks/* {
        root * /srv/citypacks
        header Cache-Control "public, max-age=86400"
        file_server
    }
```
L'utilisateur devra montrer son Caddyfile (secrets masqués) pour placer ce bloc exactement. Si le reverse_proxy est déjà dans un handle, il faut un handle sœur.

3. Service lp-osmium (à ajouter sous services:)

  lp-osmium:
    build:
      context: ./lp-osmium
      dockerfile: Containerfile
    image: localhost/lp-osmium:1
    network_mode: none
    profiles: ["tools"]
    volumes:
      - ./data/osm:/data:Z
    entrypoint: ["osmium"]

Lancement à la demande : podman-compose --profile tools run --rm lp-osmium <arguments osmium>. profiles n'est pas démarré par up -d.
profiles et version: '3.8' : la clé appartient à la Compose Specification. Sa prise en charge par la version de podman-compose installée est à vérifier (podman-compose version).
À défaut : fichier séparé docker-compose.tools.yml, lancé par podman-compose -f docker-compose.tools.yml run --rm lp-osmium ….

4. Séquence (lancée par l'utilisateur, dans ~/forgejo)

Étape	Commande	Attendu
0. État	`podman-compose ps` ; `podman image inspect docker.io/library/caddy:2-alpine --format '{{.Digest}}'` (noter le condensat)	3 services actifs
1. Sauvegarde	`cp docker-compose.yml docker-compose.yml.bak-20261020 && cp Caddyfile Caddyfile.bak-20261020`	deux copies
2. Dossiers	`mkdir -p data/citypacks data/osm lp-osmium` ; `echo essai > data/citypacks/essai.txt` ; déposer `lp-osmium/Containerfile`	—
3. Édition	appliquer les points 1, 2 (une variante) et 3	—
4. Image épinglée	`podman-compose pull caddy` (téléchargement à accepter)	`caddy:2.11.7-alpine` présente
5. Redéploiement	`podman-compose up -d caddy` (coupure de quelques secondes, à un moment creux)	`forgejo_caddy_1` recréé
6. Vérifications	`podman-compose exec caddy caddy validate --config /etc/caddy/Caddyfile` ; `curl -I https://<domaine forgejo>/` ; `curl -sI -H "Range: bytes=0-3" https://cartes.<domaine>/essai.txt` (variante 1) ou `https://<domaine forgejo>/citypacks/essai.txt` (variante 2)	« Valid configuration » ; Forgejo en `200` ; essai en `206 Partial Content` avec `Content-Range: bytes 0-3/6` et `ETag`
7. Outil (option)	`podman-compose --profile tools build lp-osmium` (téléchargement à accepter : `debian:stable-slim` et le paquet `osmium-tool`) ; `podman-compose --profile tools run --rm lp-osmium --version`	version d'osmium affichée
R. Retour arrière	`cp docker-compose.yml.bak-20261020 docker-compose.yml && cp Caddyfile.bak-20261020 Caddyfile && podman-compose up -d caddy`	état d'avant (l'image `caddy:2-alpine` est encore locale) ; Forgejo en `200`

Ne pas lancer podman-compose down : il arrêterait aussi Forgejo et la base.

Point de sécurité (sans valeur) : mot de passe de la base. Big Boss signale que le mot de passe PostgreSQL du compose est la valeur d'exemple du gabarit. Recommandations à l'utilisateur :

Le changer. Attention : l'image postgres n'applique POSTGRES_PASSWORD qu'à la première initialisation du volume ./data/postgres. Il faut donc :
- changer le mot de passe dans la base : podman-compose exec db psql -U <utilisateur> -c "ALTER USER <utilisateur> WITH PASSWORD '<nouveau>';", depuis un terminal non journalisé, ou en le saisissant par \password dans psql pour qu'il ne reste pas dans l'historique ;
- puis mettre la même valeur dans FORGEJO__database__PASSWD (service server) ;
- puis podman-compose up -d server.
Le sortir du compose : variables dans ~/forgejo/.env, lu automatiquement par podman-compose pour la substitution ${…}.
- Par exemple FORGEJO_DB_PASSWD=… ; dans le compose, POSTGRES_PASSWORD: ${FORGEJO_DB_PASSWD} et FORGEJO__database__PASSWD: ${FORGEJO_DB_PASSWD}.
- Puis chmod 600 .env, et .env exclu de toute sauvegarde publique ou de tout dépôt.
- Ou un secret podman (podman secret create) monté en fichier, si la version installée le permet.
Sauvegarder ./data/postgres avant l'opération.

Sources :

https://hub.docker.com/_/nginx
https://hub.docker.com/_/caddy
https://hub.docker.com/r/iboates/osmium
https://hub.docker.com/r/wiktorn/overpass-api et https://hub.docker.com/r/wiktorn/overpass-api/tags
recherche « osmium-tool docker image official » : aucune image officielle osmcode trouvée

8. Décisions

Décidé (2026-10-20). Utilisateur, cité par Big Boss (session local_104ff22d) : « approuvé », puis « oui » à la question de Big Boss « ce “approuvé” vaut-il aussi pour les 4 recommandations ? ».

Lecture confirmée :
- Paris est la ville de référence ;
- Forgejo (releases d'un dépôt public dédié) ;
- l'outil de téléchargement est à faire.
Q1 format : (a) mod d'assets avec redirection C++ (décidé).
Q2 taille de zone : (c) 3 × 3 km (décidé ; Paris compris, voir point 6).
Q3 découpage : (a) un pack par ville (décidé).
Interface : (i) fenêtre Slate C++, sans Blueprint (décidé).
Monétisation : reportée en build 3 (décidé, 2026-10-20). Utilisateur, cité par Big Boss : « pour le moment on verra la monétisation en build 3. offrons la carte de Paris pour valider et étudier le modéle technique puis économique ». Paris est le premier pack, gratuit : il sert à valider toute la chaîne technique, puis à étudier le modèle économique. La chaîne comprend :
- la production en 3 × 3 km ;
- la publication sur Forgejo ;
- le téléchargement dans le jeu ;
- le montage au lancement suivant. Aucun prix n'est fixé. Le coût d'hébergement (1,75 € par carte) reste une donnée d'entrée pour la build 3. Tranché (2026-10-20), utilisateur cité par Big Boss : « À la place : Paris sort du jeu de base et n'existe qu'en pack gratuit de 3 × 3 km. » Conséquences :
- le jeu de base garde Londres et Bath seulement ;
- le paquet d'essai _Pilot/Paris (≈ 11 × 8 km, STM1-B5) reste un essai local, sans aucune bascule dans le jeu ;
- sans le pack, Paris reste la ville factice actuelle ;
- le pack Paris de 3 × 3 km est le premier pack de la chaîne. Cela remplace la décision antérieure « Paris, Londres et Bath dans le jeu de base » (SPEC-06) et la mention « Paris reste au format de référence » de Q2.

Reporté en build 2 (2026-10-20). Utilisateur, cité par Big Boss : « on passe ce sujet en build 2 ».

Passent en build 2 :
- le déploiement serveur (Caddy, data/citypacks, lp-osmium, mot de passe de la base) ;
- la chaîne des packs (outil de téléchargement, lots A à G, pack Paris de 3 × 3 km).
Aucun geste ni IMPL d'ici là. SPEC-06 et SPEC-07 restent la base de travail.

Restent ouverts (pour la build 2, via Big Boss) : 7. Conteneurs (§ 7 bis) :

(a) servir les packs par le Caddy existant (file_server, recommandé après le relevé du serveur) : sous-domaine dédié (variante 1) ou chemin /citypacks/ (variante 2) ; C1 (nginx) et C3 (second Caddy) retirés ;
(b) produire les cartes sur le serveur par osmium dans une image Debian construite localement (recommandé) ;
épingler caddy:2-alpine (et, conseillé, postgres:15-alpine et forgejo:9) ; vérifier que le port 2019 n'est pas publié ;
accord pour C2 et pour la modification de Caddy, gestes lancés par l'utilisateur, exprimés en ajouts au projet compose « forgejo » (podman-compose), avec la séquence de déploiement et de retour arrière du § 7 bis.

Tours : ≈ 3 / 40 (déclaré ; FicheStats.py fait foi).

Suite : Big Boss présente le § 8 ; ensuite, lots A à G dans l'ordre (A et B d'abord, avec Paris en pack de test). État : étude close, rien modifié.

36 KiB Raw Blame History Unescape Escape