Installation depuis les sources

Cette procédure installe une nouvelle instance sous Debian 12 ou 13, depuis un compte disposant de sudo. Pour une base existante, suivre Mises à jour ; pour Docker, suivre Installation Docker.

Le dépôt, le venv et les dépendances sont administrés par root dans /opt/lebontag-v2. Toutes les commandes qui y écrivent utilisent sudo. Les commandes de lecture et cd n'en ont pas besoin. Il n'est pas nécessaire de rendre le projet accessible en écriture à tous, ni d'en changer récursivement le propriétaire.

Tous les services natifs s’exécutent sous le compte dédié lbt-integration, créé pendant la mise en service. Root reste propriétaire du code et des dépendances. Les commandes sudo ci-dessous servent uniquement à l’installation, à la compilation et à l’administration.

Cette page est à suivre dans l'ordre : installation, compte de service, web, chargement OSM, contrôles et planification. Les étapes facultatives sont signalées ; ne pas activer les timers avant la dernière étape.

1. Préparer le serveur

Prévoir PostgreSQL avec PostGIS 3, hstore et pgRouting, localement ou sur un serveur distant, ainsi qu'un nom de domaine et un reverse proxy HTTPS en production.

sudo apt update
sudo apt upgrade
sudo apt install -y ca-certificates curl wget xz-utils dos2unix git openssl acl postgresql-client

Proxy éventuel

Configurer le proxy selon les règles de votre infrastructure. Pour une commande exécutée via sudo, les variables du shell utilisateur ne sont pas automatiquement conservées. Si nécessaire et autorisé par sudoers, utiliser sudo --preserve-env=http_proxy,https_proxy,no_proxy ... pour la commande concernée, ou configurer le proxy de l'outil (APT, Git, etc.). Les services ont leur propre environnement : vérifier également l'accès réseau depuis les traitements. Aucune configuration de CRON n'est nécessaire.

2. Cloner le dépôt

L'emplacement doit être libre ; archiver l'ancienne installation avant de commencer. Ne pas cloner dans un répertoire déjà utilisé par une instance active.

sudo git clone --branch main https://gitlab.com/Geonov/lebontag-v2.git /opt/lebontag-v2
sudo git -C /opt/lebontag-v2 rev-parse HEAD

Conserver le SHA du commit déployé. Les commandes suivantes utilisent les fichiers de cette révision.

3. Créer la base et le schéma initial

Exemple sur un serveur PostgreSQL local, avec un nouveau rôle osm et une nouvelle base lebontag_production. Le mot de passe du rôle est demandé de manière interactive. Si le rôle existe déjà, vérifier ses droits et réutiliser son mot de passe ; ne pas le recréer ni le changer sans tenir compte des autres bases.

sudo -u postgres createuser --login --pwprompt osm
sudo -u postgres createdb --owner=osm lebontag_production
sudo -u postgres psql -v ON_ERROR_STOP=1 -d lebontag_production -c 'CREATE EXTENSION postgis; CREATE EXTENSION hstore; CREATE EXTENSION pgrouting;'
sudo psql -h localhost -U osm -d lebontag_production -v ON_ERROR_STOP=1 -f /opt/lebontag-v2/sql/lebontag_v2.sql

sudo concerne le compte Linux ; -U osm sélectionne le rôle PostgreSQL. Pour un serveur distant, effectuer la création via son administrateur PostgreSQL et adapter -h, -p et -d pour l'import. Ne pas placer le mot de passe dans la commande.

Le script crée notamment les schémas lebontag, osm2pgsql et osm2pgrouting, avec les propriétaires attendus. Il contient déjà les migrations de la version courante : ne pas appliquer ensuite les SQL de mise à jour à cette base neuve.

4. Installer les dépendances

Outils OSM et osm2pgsql

sudo apt install -y --no-install-recommends osmctools gdal-bin osmium-tool pyosmium
sudo apt install -y make cmake g++ libboost-dev libexpat1-dev zlib1g-dev libbz2-dev libpq-dev libproj-dev libluajit-5.1-dev pandoc nlohmann-json3-dev

Compiler osm2pgsql 2.2.0, correspondant au profil pris en charge. Le binaire sera dans /usr/local/bin, indépendamment d'une éventuelle version APT utilisée par d'autres applications.

sudo install -d -m 0755 /usr/local/src
sudo curl --fail --location --retry 3 https://github.com/osm2pgsql-dev/osm2pgsql/archive/refs/tags/2.2.0.tar.gz -o /usr/local/src/osm2pgsql-2.2.0.tar.gz
sudo tar -xzf /usr/local/src/osm2pgsql-2.2.0.tar.gz -C /usr/local/src
sudo cmake -S /usr/local/src/osm2pgsql-2.2.0 -B /usr/local/src/osm2pgsql-2.2.0/build -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTS=OFF -DWITH_LUAJIT=ON
sudo cmake --build /usr/local/src/osm2pgsql-2.2.0/build --parallel 2
sudo cmake --install /usr/local/src/osm2pgsql-2.2.0/build
/usr/local/bin/osm2pgsql --version

Python (environnement virtuel)

Le venv est créé et alimenté par root. Utiliser directement son interpréteur ; aucune activation du shell n'est nécessaire et aucun paquet n'est installé dans le Python système.

sudo apt install -y python3 python3-pip python3-venv python3-dev libpq-dev
sudo python3 -m venv /opt/lebontag-v2/.venv
sudo -H /opt/lebontag-v2/.venv/bin/python3 -m pip install --upgrade pip
sudo -H /opt/lebontag-v2/.venv/bin/python3 -m pip install -r /opt/lebontag-v2/python/requirements.txt
/opt/lebontag-v2/.venv/bin/python3 --version

Le compte d'intégration recevra ensuite un accès en lecture/exécution au code et au venv, sans droit de modification.

Node.js et npm

Installer Node 26.3.0 au niveau système. Cela évite de dépendre d'un fnm propre à une session utilisateur et garantit que sudo et les services trouvent le même Node. La procédure suivante couvre amd64 et arm64, vérifie le SHA256 publié puis installe dans /usr/local. Si une autre application utilise déjà le Node de ce préfixe, vérifier sa compatibilité avant de le remplacer.

sudo bash <<'NODE'
set -euo pipefail
case "$(dpkg --print-architecture)" in
  amd64) lbt_node_arch=x64 ;;
  arm64) lbt_node_arch=arm64 ;;
  *) echo "Architecture non prise en charge par cet exemple" >&2; exit 1 ;;
esac
lbt_node_version=26.3.0
lbt_node_archive="node-v${lbt_node_version}-linux-${lbt_node_arch}.tar.xz"
install -d -m 0755 "/usr/local/src/node-${lbt_node_version}"
cd "/usr/local/src/node-${lbt_node_version}"
curl --fail --location --retry 3 "https://nodejs.org/dist/v${lbt_node_version}/${lbt_node_archive}" -o "$lbt_node_archive"
curl --fail --location --retry 3 "https://nodejs.org/dist/v${lbt_node_version}/SHASUMS256.txt" -o SHASUMS256.txt
awk -v archive="$lbt_node_archive" '$2 == archive {print}' SHASUMS256.txt > selected.sha256
test -s selected.sha256
sha256sum --check selected.sha256
tar --extract --xz --file="$lbt_node_archive" --directory=/usr/local --strip-components=1 --no-same-owner
NODE
sudo /usr/local/bin/node --version
sudo env PATH=/usr/local/bin:/usr/bin:/bin /usr/local/bin/npm --version

Dans la suite, le PATH explicite assure que npm et ses sous-processus utilisent /usr/local/bin/node. Un éventuel fnm personnel ne participe pas à cette installation.

Dépendances de l'application

cd /opt/lebontag-v2
sudo -H env PATH=/usr/local/bin:/usr/bin:/bin HUSKY=0 /usr/local/bin/npm ci

Utiliser npm ci et le lockfile du dépôt, sans exécuter ensuite npm install pour modifier arbitrairement les versions.

5. Configurer le fichier env applicatif

Créer le fichier uniquement s'il n'existe pas, puis l'éditer :

sudo test -e /opt/lebontag-v2/.env.production.local || sudo install -m 0600 /opt/lebontag-v2/.env.production.local.example /opt/lebontag-v2/.env.production.local
sudoedit /opt/lebontag-v2/.env.production.local

Renseigner :

• DB_HOST, DB_PORT, DB_NAME, DB_USER=osm, DB_PASS et DB_SSL selon PostgreSQL ; conserver DB_SCHEMA=lebontag et DB_SRID=4326.
• AUTH_URL, AUTH_TRUST_HOST=true, AUTH_DEBUG=false, AUTH_SECRET et au moins un fournisseur AUTH_XXX_ID / AUTH_XXX_SECRET, selon les liens de l'exemple.
• Les secrets email distincts LBT_MAIL_ENCRYPTION_KEY et LBT_EMAIL_DIGEST_SECRET, puis les options de traitement ci-dessous. Conserver LBT_INTEGRATION_MODE=check au départ.

Générer une nouvelle valeur indépendante avec openssl rand -hex 32 pour chacun des secrets concernés. Ne pas régénérer une clé SMTP existante lors d'une mise à jour.

.env.production.local sert au web et aux traitements. .env.development.local n'est pas nécessaire pour un serveur exécutant le build de production. .env.local ne contient que les métadonnées publiques de version générées ci-dessous ; aucun secret n'y est ajouté.

Paramètres des traitements planifiés

Le web et les traitements utilisent .env.production.local, créé à partir de son exemple. .env.development.local est réservé au développement ; il n'est pas nécessaire sur un serveur exécutant le build de production, même si ce serveur sert à la recette d'installation. .env.local contient uniquement les métadonnées publiques générées de version. Docker ajoute .env.db pour l'initialisation PostgreSQL et les options Compose.

LBT_INTEGRATION_TARGET tient sur une ligne, entre quotes. Remplacer host, port, database, user et schema par les valeurs explicitement autorisées. Elles sont comparées à DB_*, puis à la connexion réelle. Calculer style_sha256 avec sha256sum /opt/lebontag-v2/osm/style/default.style, après vérification qu'il s'agit du style du chargement initial. Le profil reste osm2pgsql 2.2.0, sortie pgsql, référence osm2pgsql.osm, EPSG:2154 ; DB_SRID=4326 concerne LeBonTag. Une cible vide n'autorise pas une base réelle. Ne pas générer cette autorisation automatiquement depuis la connexion : elle doit détecter une erreur de cible.

LBT_DIGEST_WORKER_URL vide utilise AUTH_URL. Une URL locale HTTP est possible uniquement en loopback pour une installation native. Dans Docker, utiliser l'URL publique HTTPS joignable depuis le conteneur. Le secret du worker est déjà LBT_EMAIL_DIGEST_SECRET dans ce même fichier. Les autres secrets SMTP et OAuth ne changent pas.

Utiliser des valeurs littérales, sans export, sans substitution shell et sans interpolation ${VARIABLE}. Pour les nouveaux secrets, des valeurs hexadécimales évitent les différences d’interpolation entre lecteurs. Ne pas charger le fichier avec source ; Python, Node, systemd et Compose le lisent directement. Les services sont liés à .env.production.local ; les commandes Python manuelles peuvent sélectionner l'environnement avec --env-file.

6. Vérifier et compiler

cd /opt/lebontag-v2
sudo -H env PATH=/usr/local/bin:/usr/bin:/bin /usr/local/bin/npm run prepare:env
sudo -H env PATH=/usr/local/bin:/usr/bin:/bin NEXT_TELEMETRY_DISABLED=1 /usr/local/bin/npm run check
sudo -H env PATH=/usr/local/bin:/usr/bin:/bin NEXT_TELEMETRY_DISABLED=1 /usr/local/bin/npm run build
sudo dos2unix /opt/lebontag-v2/scripts/*.sh
sudo chmod +x /opt/lebontag-v2/scripts/*.sh

Ne pas démarrer l'application si la vérification ou le build échoue.

7. Créer le compte de service et préparer les droits

Les six services natifs (web, pipeline, integration, segmentation, cleaning, email-digests) utilisent le compte système lbt-integration. Ce compte Linux est distinct du rôle PostgreSQL osm, propriétaire des objets applicatifs et du référentiel, sans SUPERUSER.

Le code, les unités, Node, le venv et les dépendances restent administrés par root. Les installations, builds et migrations utilisent sudo ; les traitements courants n'en ont pas besoin. Le compte lit le fichier env commun : il s'agit d'un compte applicatif de confiance, pas d'une isolation entre modules.

Après compilation, préparer les répertoires et les ACL :

sudo apt install -y acl
getent group lbt-integration >/dev/null || sudo groupadd --system lbt-integration
id lbt-integration >/dev/null 2>&1 || sudo useradd --system --gid lbt-integration --home-dir /nonexistent --no-create-home --shell /usr/sbin/nologin lbt-integration
sudo install -d -o lbt-integration -g lbt-integration -m 0700 /opt/lebontag-v2/log /opt/lebontag-v2/osm/replication /opt/lebontag-v2/osm/changeset /opt/lebontag-v2/osm/osc_update /opt/lebontag-v2/osm/integration/runs /opt/lebontag-v2/.next/cache
sudo setfacl -m u:lbt-integration:--x /opt /opt/lebontag-v2 /opt/lebontag-v2/osm /opt/lebontag-v2/osm/integration /opt/lebontag-v2/osm/style
sudo setfacl -R -m u:lbt-integration:r-X /opt/lebontag-v2/python /opt/lebontag-v2/scripts /opt/lebontag-v2/.venv /opt/lebontag-v2/node_modules /opt/lebontag-v2/.next /opt/lebontag-v2/public
sudo setfacl -m u:lbt-integration:r-- /opt/lebontag-v2/package.json /opt/lebontag-v2/next.config.ts /opt/lebontag-v2/tsconfig.json /opt/lebontag-v2/.env.local /opt/lebontag-v2/osm/style/default.style
sudo chmod 0600 /opt/lebontag-v2/.env.production.local
sudo setfacl -m u:lbt-integration:r-- /opt/lebontag-v2/.env.production.local
sudo -u lbt-integration /opt/lebontag-v2/.venv/bin/python3 --version
sudo -u lbt-integration /usr/local/bin/osm2pgsql --version
sudo -u lbt-integration /usr/local/bin/node --version

Si le venv contient des liens vers Python, vérifier également leur cible. Ne pas installer les exécutables sous /root : ProtectHome=true en bloque l'accès. Réappliquer les ACL après remplacement du code, des dépendances ou du build.

Service	Écriture persistante autorisée
Web	.next/cache/
Pipeline	log/, osm/replication/, osm/changeset/, osm/osc_update/
Intégration et découpage	osm/integration/runs/
Nettoyage	log/, osm/changeset/, osm/osc_update/
Emails	Aucune ; appel HTTP à l'application

Tous conservent ProtectSystem=strict, NoNewPrivileges=true et un espace temporaire privé. Les droits Linux ne suffisent pas : les unités limitent également leurs chemins d'écriture. Les journaux privés restent lisibles dans l'admin, car le web utilise le même compte.

8. Installer les unités sans activer les timers

Les fichiers .service et .timer sont fournis dans le dépôt ; aucun drop-in n'est nécessaire. Installer seulement les options souhaitées. Ne pas activer les timers avant les contrôles.

sudo systemctl link /opt/lebontag-v2/services/lbt-web.service
sudo systemctl link /opt/lebontag-v2/services/lbt-pipeline.service /opt/lebontag-v2/services/lbt-pipeline.timer
sudo systemctl link /opt/lebontag-v2/services/lbt-integration.service /opt/lebontag-v2/services/lbt-integration.timer
sudo systemctl link /opt/lebontag-v2/services/lbt-cleaning.service /opt/lebontag-v2/services/lbt-cleaning.timer
# OPTIONAL / OPTIONNEL :
sudo systemctl link /opt/lebontag-v2/services/lbt-segmentation.service /opt/lebontag-v2/services/lbt-segmentation.timer
sudo systemctl link /opt/lebontag-v2/services/lbt-email-digests.service /opt/lebontag-v2/services/lbt-email-digests.timer
sudo systemctl daemon-reload

9. Démarrer le web et configurer Nginx

Le service lance directement Next.js avec le Node système, sous le compte dédié, sans PM2. Il écoute sur 127.0.0.1:3000, derrière Nginx.

sudo systemctl enable --now lbt-web.service
sudo systemctl status lbt-web.service
sudo journalctl -u lbt-web.service -n 80 --no-pager

Nginx

sudo apt install -y nginx

Choisir un seul des deux exemples ci-dessous. HTTPS nécessite un certificat et sa clé déjà disponibles aux chemins renseignés.

# HTTP :
sudo cp /opt/lebontag-v2/nginx/nginx-80.conf /etc/nginx/sites-available/lebontag.conf
# OU HTTPS :
sudo cp /opt/lebontag-v2/nginx/nginx-443.conf /etc/nginx/sites-available/lebontag.conf

sudoedit /etc/nginx/sites-available/lebontag.conf

Remplacer [WEB_SITE_URL], les chemins de certificat et de clé, et vérifier les directives listen. Sur un serveur partagé, ne pas déclarer un second default_server et ne pas supprimer le site par défaut sans vérifier qu'il est inutilisé. Le reverse proxy doit viser le port 3000 de LeBonTag ; ce port ne doit pas être exposé directement sur Internet.

Sur une machine neuve dédiée, si le site Debian par défaut est inutilisé et entre en conflit avec default_server, retirer son lien avant le contrôle :

# Uniquement dans ce cas :
sudo rm /etc/nginx/sites-enabled/default

sudo ln -s /etc/nginx/sites-available/lebontag.conf /etc/nginx/sites-enabled/lebontag.conf
sudo nginx -t
# Exécuter seulement si la vérification réussit :
sudo systemctl enable --now nginx
sudo systemctl reload nginx

Si le lien existe déjà, le vérifier au lieu de le recréer. Pour une installation neuve dédiée utilisant listen ... default_server, retirer le lien du site par défaut uniquement après l'avoir contrôlé, puis refaire nginx -t.

10. Créer le premier administrateur

Connectez-vous à l'application avec le service d'authentification préalablement configuré.

Pour faire de ce premier utilisateur un administrateur (après sa connexion), exécutez en SQL :

INSERT INTO lebontag.lbt_user_userrole (u_id, ur_id) VALUES(1, 1);

11. Charger le PBF et initialiser la réplication

Activer LBT_CAPTURE_RELATION_CONTEXT=1 dans .env.production.local avant la première ingestion. Le PBF, son état et le serveur de réplication doivent correspondre au même extrait. Ne pas utiliser les numéros ci-dessous tels quels : ce sont des exemples.

sudo install -d -m 0755 /opt/lebontag-v2/osm/source

Données OSM de référence

Les données OSM de référence doivent contenir certaines métadonnées (contributeur, date, changeset, etc.).

Rendez-vous sur https://download.openstreetmap.fr/extracts/europe/ et téléchargez le fichier contenant votre zone de travail, par exemple :

• https://download.openstreetmap.fr/extracts/europe/france.osm.pbf [ou]
• https://download.openstreetmap.fr/extracts/europe/france/languedoc_roussillon.osm.pbf [ou]
• https://download.openstreetmap.fr/extracts/europe/france/languedoc_roussillon/herault.osm.pbf

Placez le fichier téléchargé sur le serveur, dans "/opt/lebontag-v2/osm/source/" et renommez-le "data.osm.pbf" (ou alors modifiez le paramètre "osm_pbffile" en base ou depuis l'interface d'administration).

Attention : ne jamais supprimer ce fichier, il sera utilisé par l'application pour charger les données.

Téléchargez également le fichier "state.txt" associé, par exemple :

• https://download.openstreetmap.fr/extracts/europe/france.state.txt [ou]
• https://download.openstreetmap.fr/extracts/europe/france/languedoc_roussillon.state.txt [ou]
• https://download.openstreetmap.fr/extracts/europe/france/languedoc_roussillon/herault.state.txt

Exemple de téléchargement direct pour l’Hérault, à adapter si vous choisissez un autre extrait. Le fichier d’état doit correspondre à la version du PBF téléchargée ; si la publication change pendant le téléchargement, récupérer de nouveau la paire cohérente.

sudo curl --fail --location --retry 3 https://download.openstreetmap.fr/extracts/europe/france/languedoc_roussillon/herault.osm.pbf -o /opt/lebontag-v2/osm/source/data.osm.pbf
sudo curl --fail --location --retry 3 https://download.openstreetmap.fr/extracts/europe/france/languedoc_roussillon/herault.state.txt -o /opt/lebontag-v2/osm/source/state.txt

Déclencher maintenant le chargement des données de référence dans la base à l'aide d'un script osm2pgsql :

sudo /opt/lebontag-v2/scripts/lbt-load-data.sh

Le fichier journal du chargement sera créé dans "/opt/lebontag-v2/log/lbt-load-data/". Vérifiez son contenu.

Continuer seulement après un chargement réussi. En cas d’erreur, ne pas démarrer le pipeline ni marquer la séquence comme chargée.

Notez le nombre de la "sequenceNumber" contenu dans le fichier d’état associé au PBF, par exemple : 6844104.

Écrivez ce nombre dans le nouveau fichier /opt/lebontag-v2/osm/replication/sequence.txt, par exemple :

printf '%s\n' 6844104 | sudo tee /opt/lebontag-v2/osm/replication/sequence.txt >/dev/null

Remplacez 0000000 par ce nombre dans la table lebontag.lbt_repl_state, par exemple :

UPDATE lebontag.lbt_repl_state SET last_done_seq=6844104 WHERE id=1;

Spécifiez l'URL de réplication des données (fichiers de diff par minute) à partir de "https://download.openstreetmap.fr/replication".

Par exemple "https://download.openstreetmap.fr/replication/europe/france/languedoc_roussillon/herault/minute/".

En SQL :

INSERT INTO lebontag.lbt_setting (s_name, s_value) VALUES ('osm_repl_server','https://download.openstreetmap.fr/replication/europe/france/languedoc_roussillon/herault/minute/') ON CONFLICT (s_name) DO UPDATE SET s_value = EXCLUDED.s_value;

12. Attribuer les droits des données chargées

Le chargement initial, exécuté avec sudo, peut créer des logs ou le fichier de séquence sous root. Avant de lancer les traitements, attribuer uniquement les répertoires de données ci-dessous au compte de service. Vérifier qu'il s'agit des répertoires locaux attendus, pas de liens vers d'autres installations. Ne jamais appliquer ce changement à tout /opt/lebontag-v2.

sudo chown -R --no-dereference lbt-integration:lbt-integration /opt/lebontag-v2/log /opt/lebontag-v2/osm/replication /opt/lebontag-v2/osm/changeset /opt/lebontag-v2/osm/osc_update /opt/lebontag-v2/osm/integration/runs /opt/lebontag-v2/.next/cache

13. Configurer les emprises et les droits métier

• Associez les utilisateurs à des emprises, des groupes métier, des rôles, etc.
• Activez des groupes d'objets ou créez-en de nouveaux.
• Paramétrez les droits de validation.

14. Contrôler le pipeline, l’intégration et le découpage

sudo systemctl start lbt-pipeline.service
sudo journalctl -u lbt-pipeline.service -n 100 --no-pager

Après ce passage réussi, examiner et valider quelques objets dans l’application. Contrôler ensuite l’intégration :

# LBT_INTEGRATION_MODE=check
sudo systemctl start lbt-integration.service
sudo systemctl show lbt-integration.service -p Result -p ExecMainStatus
sudo journalctl -u lbt-integration.service -n 150 --no-pager

Le pipeline exécute ses quatre étapes dans l'ordre et s'arrête à la première erreur. En mode check, l'intégration ne fait aucun append mais journalise ses contrôles. Valider quelques objets depuis l'application et examiner les blocages. Result=success avec ExecMainStatus=2 indique des blocages métier, éventuellement après une intégration partielle : ce n'est pas une panne.

Après contrôle de la cible, passer LBT_INTEGRATION_MODE=execute dans le fichier env et relancer l'intégration. Vérifier le lot integrated, commit_confirmed, verification.json et l'admin. Le hook appelle le découpage après intégration si nécessaire ; son échec est journalisé séparément et n'annule pas un append confirmé.

Le découpage est activé par db_pgr_update=1. Les tables dérivées sont créées au chargement initial. La publication est transactionnelle mais ses identifiants de tronçons ne sont pas stables ; ce n'est pas une garantie de routage complet. Les lecteurs peuvent attendre pendant la publication. Pour un premier calcul manuel, seulement si le hook ne vient pas de publier :

sudo -u lbt-integration /opt/lebontag-v2/.venv/bin/python3 /opt/lebontag-v2/python/lbt-rebuild-segments.py --env-file /opt/lebontag-v2/.env.production.local --output-root /opt/lebontag-v2/osm/integration/runs --reason manual

15. Contrôler le nettoyage

Le service de nettoyage est installé à l’étape 8. Il utilise log_retention et osm_retention, exprimés en jours strictement positifs. Il conserve les métadonnées encore référencées par l'historique et ne suit pas les liens symboliques. Il ne purge ni le PBF, ni la queue de réplication, ni les rapports ou journaux d'intégration.

sudo systemctl start lbt-cleaning.service
sudo journalctl -u lbt-cleaning.service -n 100 --no-pager

16. Configurer les emails facultatifs

Configurer SMTP dans l'admin, vérifier un envoi de test et les abonnements avant d'activer le timer email. Le worker partage le fichier env, s'exécute sous lbt-integration et n'a besoin d'aucune écriture persistante. LBT_DIGEST_WORKER_URL vide utilise AUTH_URL ; conserver le même secret LBT_EMAIL_DIGEST_SECRET que le web.

17. Activer les timers et surveiller

sudo systemctl enable --now lbt-pipeline.timer lbt-integration.timer lbt-cleaning.timer
# OPTIONAL / OPTIONNEL :
sudo systemctl enable --now lbt-segmentation.timer lbt-email-digests.timer
sudo systemctl list-timers 'lbt-*' --all

Le pipeline passe environ chaque heure, l'intégration à 00:30 et le découpage à 01:30 Europe/Paris (avec un décalage aléatoire pour ces deux derniers). Le nettoyage est quotidien à 02:30 Europe/Paris. Le découpage nocturne s'exécute aussi sans nouvelle intégration ; son timer persistant peut démarrer dès activation. After= ordonne des démarrages simultanés, mais ne garantit pas le succès du service précédent. Les verrous métier restent nécessaires.

Surveiller le premier cycle nocturne, la fraîcheur dans À propos et les lots dans l'admin. Un état needs_review impose d'arrêter le timer d'intégration et d'inspecter le lot ; ne pas relancer aveuglément l'append. Un échec de découpage conserve la publication précédente par rollback. Les rapports restent sous osm/integration/runs/.

Emplacement des journaux

• /log/lbt-autovalidation : objets OSM auto-validés
• /log/lbt-fetch : récupération des objets OSM modifiés
• /log/lbt-footprints-intersection : intersection entre objets modifiés et emprises
• /log/lbt-ingest : insertion en base des objets OSM modifiés
• /log/lbt-load-data : chargement des données de référence
• /osm/integration/runs/ : rapports d’intégration et de découpage des données OSM validées ; journaux systemd via journalctl.