Aller au contenu principal

Mises à jour par version

Note : Pour Docker, suivre les exigences SQL et de version ci-dessous ainsi que la procédure de mise à jour Docker. Reconstruire les images et configurer les tâches Compose plutôt que les paquets, CRON et unités systemd de l’hôte.

Mise à jour native depuis Git, étape par étape​

Cette procédure concerne une installation existante dans /opt/lebontag-v2, avec les services systemd sous lbt-integration. Pour une ancienne installation PM2/CRON, lire aussi la transition correspondante plus bas avant de commencer. Les installations Docker suivent leur procédure dédiée.

Une installation neuve utilise sql/lebontag_v2.sql ; une mise à jour utilise uniquement les migrations nécessaires, dans l'ordre du tableau ci-dessous. Ne jamais importer le schéma complet sur une base existante.

1. Vérifier le dépôt et la version installée​

Exécuter les blocs dans le même terminal Bash. set -euo pipefail arrête cette session de maintenance si une commande échoue ; corriger l'erreur avant de reprendre. Noter le chemin de sauvegarde lorsqu'il est créé : après fermeture du terminal, réaffecter LBT_UPDATE_BACKUP à ce chemin pour reprendre.

bash
set -euo pipefail
cd /opt/lebontag-v2
sudo git status --short
sudo git branch --show-current
sudo git log -1 --format='%h %s'
sudo git remote -v

Identifier séparément les migrations déjà appliquées en base. Le numéro du code ne prouve pas la version du schéma. Si git status signale des modifications locales, les examiner et les conserver avant la mise à jour ; ne pas utiliser reset --hard, clean ou un stash automatique. Les fichiers env personnels doivent rester non suivis par Git. Vérifier la branche et son suivi distant : fix/validation-integration pendant le développement actuel, puis la branche de publication retenue. Ne pas changer de branche implicitement pendant une mise à jour.

2. Suspendre la planification et attendre les traitements​

Prévoir une fenêtre de maintenance et empêcher les lancements manuels concurrents. Vérifier aussi les éventuels CRON ou autres ordonnanceurs. Le bloc mémorise les timers LeBonTag actuellement actifs, les arrête puis attend les traitements ; il ne tue pas un append ni un découpage. Si l'attente se prolonge, consulter les journaux dans un second terminal. Ne pas redémarrer la machine pendant cette maintenance : les timers restent activés au démarrage.

LBT_UPDATE_BACKUP="/opt/lebontag-v2/osm/backups/update-$(date -u +%Y%m%dT%H%M%SZ)"
sudo install -d -o root -g root -m 0700 "$LBT_UPDATE_BACKUP"
sudo git rev-parse HEAD | sudo tee "$LBT_UPDATE_BACKUP/commit-before.txt" >/dev/null
sudo systemctl list-units --type=timer --state=active --plain --no-legend 'lbt-*.timer' | awk '{print $1}' | sudo tee "$LBT_UPDATE_BACKUP/active-timers.txt" >/dev/null
sudo systemctl list-timers --all 'lbt-*'
while IFS= read -r lbt_timer; do
  sudo systemctl stop "$lbt_timer"
done < <(sudo cat "$LBT_UPDATE_BACKUP/active-timers.txt")
while true; do
  lbt_running_jobs=$(sudo systemctl list-units --type=service --state=active,activating,deactivating,reloading --plain --no-legend lbt-pipeline.service lbt-integration.service lbt-segmentation.service lbt-cleaning.service lbt-email-digests.service)
  if [ -z "$lbt_running_jobs" ]; then
    break
  fi
  printf '%s\n' "$lbt_running_jobs"
  sleep 5
done
sudo systemctl stop lbt-web.service

3. Sauvegarder avant tout changement​

Remplacer DB_HOST, DB_PORT, DB_USER, DB_NAME par ceux de la base réellement utilisée. Le mot de passe est demandé, pas inscrit dans la commande. Utiliser un pg_dump compatible avec la version majeure du serveur et un rôle disposant des droits de sauvegarde sur toute la base. Tous les producteurs de données doivent être arrêtés, y compris ceux externes à ces services.

sudo -H pg_dump --host=DB_HOST --port=DB_PORT --username=DB_USER --dbname=DB_NAME --password --format=custom --file="$LBT_UPDATE_BACKUP/database.dump"
sudo pg_restore --list "$LBT_UPDATE_BACKUP/database.dump" >/dev/null
sudo tar --acls --xattrs --exclude='./osm/backups' --exclude='./node_modules' --exclude='./.next' --exclude='./.venv' -czf "$LBT_UPDATE_BACKUP/application.tar.gz" -C /opt/lebontag-v2 .
sudo git bundle create "$LBT_UPDATE_BACKUP/repository.bundle" --all
printf 'Backup / sauvegarde : %s\n' "$LBT_UPDATE_BACKUP"

La sauvegarde inclut tous les schémas de la base, les sources, configurations, styles, données et états de réplication. Les dépendances réinstallables et le build sont exclus de l'archive. Les PBF et rapports peuvent rendre celle-ci volumineuse : prévoir l'espace nécessaire. Le répertoire reste privé à root car il contient des secrets. La lecture du catalogue du dump ne remplace pas un essai de restauration. Si un rôle PostgreSQL doit être recréé sur un autre serveur, en conserver séparément les informations nécessaires.

4. Récupérer les sources​

sudo git pull --ff-only
sudo git log -1 --format='%h %s'
sudo git diff --stat "$(sudo cat "$LBT_UPDATE_BACKUP/commit-before.txt")" HEAD

--ff-only refuse une divergence au lieu de créer une fusion sur le serveur. En cas d'échec, résoudre la divergence avant de continuer. Relire les instructions de version ci-dessous dans leur version nouvellement téléchargée et vérifier les changements de dépendances et d'environnement.

5. Installer les dépendances et appliquer les migrations nécessaires​

sudo -H env PATH=/usr/local/bin:/usr/bin:/bin HUSKY=0 /usr/local/bin/npm ci
sudo -H /opt/lebontag-v2/.venv/bin/python3 -m pip install -r /opt/lebontag-v2/python/requirements.txt

Compléter .env.production.local à partir des nouveaux paramètres de l'exemple sans écraser les valeurs existantes. Conserver les secrets, la cible explicitement autorisée et les réglages de traitement. .env.local reste généré par l'application. Installer ou mettre à niveau les outils système seulement si la version cible le demande.

Exemple SQL uniquement pour une base 2.7.4 qui n'a pas déjà reçu cette migration ; adapter la connexion comme à l'étape 3. Pour plusieurs migrations, exécuter chaque fichier séparément, dans l'ordre, et arrêter au premier échec. Si aucun changement SQL n'est nécessaire, sauter ce bloc.

sudo -H psql --host=DB_HOST --port=5432 --username=DB_USER --dbname=DB_NAME --password -v ON_ERROR_STOP=1 -f /opt/lebontag-v2/sql/update_2.7.4_to_2.8.0.sql

6. Vérifier et reconstruire le web​

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 /usr/local/bin/npm run check
sudo -H env PATH=/usr/local/bin:/usr/bin:/bin /usr/local/bin/npm run build

Le web reste arrêté pendant npm ci et le build. Ne pas le redémarrer si le contrôle ou la compilation échoue. Ne pas modifier le code pendant une compilation.

7. Réappliquer les droits après le build​

Le compte lbt-integration et le paquet acl doivent déjà exister. Le code, le venv et les dépendances restent administrés par root ; seul le cache reconstruit est réattribué récursivement. Vérifier que les répertoires de données indiqués sont locaux à cette installation.

sudo install -d -o lbt-integration -g lbt-integration -m 0700 /opt/lebontag-v2/.next/cache /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
sudo chown -R --no-dereference lbt-integration:lbt-integration /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 test -r /opt/lebontag-v2/.env.production.local
sudo -u lbt-integration test -w /opt/lebontag-v2/.next/cache
sudo -u lbt-integration /opt/lebontag-v2/.venv/bin/python3 --version
sudo -u lbt-integration /usr/local/bin/node --version
sudo -u lbt-integration /usr/local/bin/osm2pgsql --version

Les répertoires de données existants doivent déjà appartenir au compte de service. Si des fichiers historiques sont encore sous root, appliquer la transition sans root décrite plus bas, limitée aux données concernées. Ne jamais faire de chown -R sur tout le projet, ni de chmod 777. Ne pas donner au service l'accès aux sauvegardes privées.

8. Recharger les unités, démarrer le web et contrôler​

Les unités installées comme liens vers services/ utilisent les fichiers mis à jour après daemon-reload. Si elles ont été copiées dans /etc/systemd/system, comparer les copies aux sources, sauvegarder les adaptations et installer les versions mises à jour avant de continuer. Examiner les drop-ins ; ils peuvent surcharger les réglages livrés. Une nouvelle unité doit être installée selon les instructions propres à la version.

sudo systemctl daemon-reload
sudo systemctl cat lbt-web.service lbt-pipeline.service lbt-integration.service
sudo systemctl show lbt-web.service -p User -p Group -p FragmentPath -p DropInPaths
sudo systemctl start lbt-web.service
sudo systemctl status lbt-web.service --no-pager
sudo journalctl -u lbt-web.service -n 80 --no-pager
curl --fail --silent --show-error --output /dev/null http://127.0.0.1:3000/fr

Vérifier ensuite l'URL publique via Nginx/HTTPS, la connexion, l'administration et une carte. Le contrôle HTTP local ne couvre pas ces fonctions.

Effectuer un contrôle d'intégration explicite, quel que soit le mode habituel du service. Cette commande utilise les permissions du compte dédié, mais pas le confinement systemd ; les journaux du prochain passage planifié permettront de vérifier ce dernier.

lbt_check_status=0
sudo -u lbt-integration env PYTHONDONTWRITEBYTECODE=1 /opt/lebontag-v2/.venv/bin/python3 /opt/lebontag-v2/python/lbt-run-update.py --env-file /opt/lebontag-v2/.env.production.local --output-root /opt/lebontag-v2/osm/integration/runs --style /opt/lebontag-v2/osm/style/default.style --mode check || lbt_check_status=$?
printf 'Integration check exit code : %s\n' "$lbt_check_status"
if [ "$lbt_check_status" -ne 0 ] && [ "$lbt_check_status" -ne 2 ]; then
  printf 'Integration check failed / contrôle en échec\n' >&2
  exit "$lbt_check_status"
fi

Le code 2 peut signaler des blocages métier ou un lot partiel : lire le rapport et l'administration avant de reprendre. Un état incertain (needs_review) doit être résolu avant reprise des écritures. Le mode check ne fait pas d'append, mais écrit son journal et peut préparer un lot. Ne pas démarrer le service d'intégration simplement pour vérifier sa disponibilité : son mode habituel peut être execute et appeler le découpage.

9. Reprendre les timers précédemment actifs​

Une fois les contrôles satisfaisants, reprendre seulement les timers mémorisés. Cela conserve le choix des modules optionnels et n'active pas les emails ou le découpage s'ils ne l'étaient pas auparavant. Un timer Persistent=true peut déclencher immédiatement un traitement manqué pendant la maintenance.

while IFS= read -r lbt_timer; do
  sudo systemctl start "$lbt_timer"
done < <(sudo cat "$LBT_UPDATE_BACKUP/active-timers.txt")
sudo systemctl list-timers --all 'lbt-*'
sudo systemctl --failed --no-pager

Examiner les journaux et le suivi en administration après les premiers passages. Les éventuels nouveaux timers requis par la version doivent être activés explicitement après leur configuration. Si une étape a échoué, garder les traitements suspendus et utiliser la procédure de restauration cohérente en fin de page ; revenir uniquement au commit précédent ne suffit pas après une migration SQL.

Ordre des scripts​

PassageFichier SQL
2.1.2 → 2.1.3update_2.1.2_to_2.1.3.sql
2.1.3 → 2.2.0update_2.1.3_to_2.2.0.sql
2.2.0 → 2.4.8update_2.2.0_to_2.4.8.sql
2.4.8 → 2.5.2update_2.4.8_to_2.5.2.sql
2.6.2 → 2.6.3update_2.6.2_to_2.6.3.sql
2.6.4 → 2.6.5update_2.6.4_to_2.6.5.sql
2.6.5 → 2.6.6update_2.6.5_to_2.6.6.sql
2.6.8 → 2.6.9update_2.6.8_to_2.6.9.sql
2.6.9 → 2.7.2update_2.6.9_to_2.7.2.sql
2.7.2 → 2.7.3update_2.7.2_to_2.7.3.sql
2.7.3 → 2.7.4update_2.7.3_to_2.7.4.sql
2.7.4 → 2.8.0update_2.7.4_to_2.8.0.sql

Le dépôt ne fournit pas de script pour chaque version intermédiaire. Parcourir cette liste à partir des changements non encore présents ; ne pas rejouer un script parce qu'un numéro intermédiaire n'apparaît pas. En cas d'installation ancienne ou modifiée localement, contrôler son schéma avant la migration. Les scripts ne constituent pas une détection automatique de version.

2.1.2 → 2.2.0 : anciennes règles qualité​

Le passage 2.1.3 → 2.2.0 remplace les anciennes règles qualité par le nouveau modèle et ses règles initiales. Sauvegarder les règles personnalisées pour les recréer ensuite. Si des acquittements qualité existent, la migration s'arrête avant toute modification : leur réinitialisation doit être décidée explicitement, car leurs anciens identifiants de règles ne peuvent pas être réattribués aux nouvelles règles. La contrainte de rattachement aux règles est rétablie dans la migration.

2.2.0 → 2.4.8 : réplication OSM​

Installer osm2pgsql 2.2.0, les utilitaires OSM et les dépendances Python selon Installation. Configurer l'extrait PBF, son état et son serveur de diffs minute selon Configuration, puis recharger le référentiel. Remplacer l'ancien téléchargement Overpass par lbt-pipeline.service et son timer. Ne pas utiliser la séquence zéro pour démarrer la réplication.

2.6.2 → 2.6.9 : interface et fonctions SQL​

npm ci installe notamment Recharts et JSZip depuis le fichier verrouillé. Appliquer les SQL concernés dans l'ordre : statistiques, export et validations partielles. Le passage 2.6.4 → 2.6.5 recalcule les liens aux emprises et peut prendre du temps sur une base volumineuse.

2.6.9 → 2.7.2 : notifications internes​

Appliquer le SQL puis reconstruire l'application ; aucun service supplémentaire n'est requis pour les notifications de Mon territoire.

2.7.2 → 2.7.3 : notifications par email​

npm ci installe le module SMTP prévu par le projet. Configurer AUTH_URL avec l'adresse publique de l'application. Générer deux secrets distincts pour LBT_MAIL_ENCRYPTION_KEY et LBT_EMAIL_DIGEST_SECRET, puis les conserver de manière durable ; changer la clé de chiffrement rendrait la configuration SMTP chiffrée illisible.

openssl rand -hex 32
openssl rand -hex 32

Configurer le worker dans .env.production.local : LBT_EMAIL_DIGEST_SECRET est commun au web et au worker, LBT_DIGEST_WORKER_URL vide utilise AUTH_URL, et LBT_DIGEST_BATCH_SIZE=20. Protéger le fichier comme décrit dans Déploiement. Tester SMTP avant activation. Adapter le chemin absolu de Node dans le service ; ne pas conserver une autre planification des emails.

# Check the Node path in the unit before enabling it.
/usr/local/bin/node --version
sudo systemctl link /opt/lebontag-v2/services/lbt-email-digests.service /opt/lebontag-v2/services/lbt-email-digests.timer
sudo systemctl daemon-reload
sudo systemctl enable --now lbt-email-digests.timer

2.7.3 → 2.7.4 : préférences utilisateur​

Appliquer le SQL et reconstruire l'application. Les préférences enregistrées en base complètent les valeurs par défaut administrateur.

2.7.4 → 2.8.0 : intégration, découpage et nettoyage​

Pour le passage à la version 2.8.0, une réinstallation complète de l'application dans un nouveau répertoire est fortement recommandée. La base de données peut être conservée après mise à jour et procédure de reboot.

  • Appliquer update_2.7.4_to_2.8.0.sql une seule fois sur une base 2.8.0. Il contient les contextes, le journal d'intégration, les identités typées, les fonctions, le curseur et le journal/index du découpage. Les anciens fichiers SQL 001 à 011 ne sont plus des étapes d'installation.
  • Si la migration signale une identité ambiguë, elle annule ses changements. Ne pas deviner le type. Après sauvegarde et résolution des lots actifs, utiliser la procédure de rechargement décrite ci-dessous : Reboot supprime explicitement les diffs et décisions avant le rechargement. Ce nettoyage n'est jamais exécuté automatiquement par la migration.
  • Une base déjà partiellement migrée doit être contrôlée avant toute exécution : cette migration n'est pas rejouable. Ne pas supprimer les gardes pour la forcer.
  • Activer LBT_CAPTURE_RELATION_CONTEXT=1 dans l'environnement du pipeline avant les ingestions.
  • Supprimer les anciens CRON d'intégration et de nettoyage, puis installer les services décrits dans Production. Supprimer cron/lbt-cleaning.sh ainsi que les anciens lbt-update-db-by-osc.py / .sh s'ils subsistent sur le serveur. Conserver les scripts d'ingestion nodes/ways/relations.
  • Le découpage est optionnel. Si ses tables n'existent pas encore, la migration n'essaie pas de les créer : le chargement initial crée les tables et index. Les identifiants des tronçons ne sont pas stables.

Centralisation de la configuration en 2.8.0​

Pour une installation neuve, les exemples .env.production.local.example et .env.development.local.example contiennent les paramètres nécessaires. Utiliser .env.production.local pour un serveur exécutant le build de production. Docker ajoute seulement .env.db ; ses options Compose sont chargées avec docker compose --env-file .env.db .... .env.local reste réservé aux métadonnées publiques générées.

Pour une installation déjà équipée des fichiers séparés :

  1. Arrêter les timers et attendre la fin des écritures. Sauvegarder les configurations sans les publier.
  2. Reporter les réglages de integration-runner.conf dans .env.production.local. Vérifier que ses DB_* correspondent à ceux de l'ancien integration.env ; ne pas changer silencieusement de base ou de rôle.
  3. Reporter le contenu de target.json dans LBT_INTEGRATION_TARGET, JSON sur une ligne entre quotes simples, et enlever LBT_INTEGRATION_TARGET_CONFIG des environnements utilisés. Deux cibles définies simultanément sont refusées.
  4. Reporter uniquement l'URL et la taille du lot de .env.digests.local. Le secret email doit déjà être celui de .env.production.local ; résoudre toute divergence avant activation. Une URL de worker vide utilise AUTH_URL.
  5. Installer les unités mises à jour et appliquer les droits du déploiement. Le déclenchement du découpage est désormais dans lbt-integration.service. Après sauvegarde de l'ancien drop-in, supprimer uniquement celui livré précédemment :
sudo rm -f /etc/systemd/system/lbt-integration.service.d/segmentation.conf
sudo systemctl daemon-reload
sudo systemctl cat lbt-integration.service lbt-segmentation.service lbt-email-digests.service

Vérifier une seule ligne ExecStartPost de découpage et aucune référence aux anciens chemins. Ne pas effacer les autres éventuels drop-ins locaux. Les dossiers source services/integration/ et services/lbt-integration.service.d/ ainsi que .env.digests.local.example ne sont plus nécessaires ; les unités .service et .timer de services/ restent nécessaires.

  1. En Docker, recréer les conteneurs utilisant le fichier env, puis redémarrer Ofelia. Reporter les éventuelles options d'un ancien .env Compose dans .env.db et conserver le nom du projet et le volume.
  2. Après un contrôle réussi sur la bonne cible, archiver puis retirer les anciens fichiers personnels integration.env, integration-runner.conf, target.json et .env.digests.local. Ils ne sont pas supprimés automatiquement. Les commandes Python acceptent encore l'ancien --target-config pour faciliter la transition, mais la procédure normale n'en dépend plus.

Cette simplification ne nécessite aucun SQL supplémentaire. Elle ne modifie ni les lots ni les états métier. Les blocages de dépendances et de contextes restent à traiter dans le suivi ; ils ne justifient pas de contourner les contrôles.

Transition vers les services sans root​

Cette transition concerne l'installation native. Docker conserve sa procédure propre. Le nom du compte Linux lbt-integration est conservé ; aucun compte PostgreSQL ni SQL supplémentaire n'est créé par cette transition.

  1. Arrêter les timers installés (pipeline, intégration, découpage, nettoyage et emails), attendre la fin de leurs services, puis arrêter le web avant de remplacer des fichiers. Désactiver les anciens CRON correspondants. Ne pas tuer un append en cours.
  2. Sauvegarder la base complète, le code, les configurations, le style, les fichiers de réplication et les rapports. Une sauvegarde PostgreSQL doit inclure tables intermédiaires osm2pgsql et journaux, pas seulement les géométries.
  3. Installer les sources et unités actualisées. Sauvegarder et remplacer les anciennes copies d'unités sous /etc/systemd/system par des liens vers les sources, sans écraser les personnalisations locales à l'aveugle. Vérifier les drop-ins avec systemctl cat : aucun User=root résiduel ne doit surcharger les nouvelles unités.
  4. Appliquer la préparation des droits décrite dans Déploiement, après le build et tout rechargement. Les anciennes données écrites sous root nécessitent le changement de propriétaire limité aux répertoires de données listés, y compris sequence.txt et les sous-dossiers de logs. Ne pas changer récursivement le propriétaire du code, du venv ou du dépôt entier.
  5. Si le web utilisait PM2 sous root, identifier puis arrêter uniquement l'application LeBonTag avant d'activer lbt-web.service :
sudo -H env PATH=/usr/local/bin:/usr/bin:/bin /usr/local/bin/pm2 list
# Adapter le nom à celui effectivement trouvé :
sudo -H env PATH=/usr/local/bin:/usr/bin:/bin /usr/local/bin/pm2 delete LeBonTagv2
sudo -H env PATH=/usr/local/bin:/usr/bin:/bin /usr/local/bin/pm2 save --force

Si PM2 ou Node utilise un autre chemin dans l'ancienne installation, utiliser ce chemin. Ne pas désinstaller PM2 ou désactiver pm2-root s'il gère d'autres applications. Si LeBonTag utilisait un autre superviseur, désactiver uniquement son ancienne définition ; un seul serveur doit écouter sur le port 3000.

  1. Lier les unités et faire sudo systemctl daemon-reload. Contrôler chaque User et Group avec systemctl show NOM.service -p User -p Group. Démarrer le web, vérifier la connexion et la lecture des journaux depuis l'admin.
  2. Tester le pipeline, puis l'intégration en check, le découpage et le nettoyage selon Déploiement. Le premier nettoyage applique réellement les rétentions : vérifier leurs valeurs. Tester les emails si utilisés. Ensuite seulement réactiver les timers, en conservant les contrôles de cible et de blocages métier.

L'installation quotidienne du nettoyage est documentée dans installation.md. La seule action spécifique à une mise à jour est de retirer son ancienne planification et de reprendre les droits des caches historiques. Supprimer cron/lbt-cleaning.sh et les anciens scripts d'intégration seulement après bascule ; ne pas supprimer les scripts d'ingestion node/way/relation.

Rechargement d'une ancienne base et retour arrière (reboot)​

Pour une base ancienne sans identités typées fiables, un rechargement du référentiel est recommandé. Après sauvegarde et résolution des lots actifs, lire le document Reboot : ce nettoyage explicite efface les diffs, validations et acquittements qualité, en conservant comptes et paramètres. Il peut précéder la migration d'identité si celle-ci bloque sur des ambiguïtés. Ne jamais deviner les types ni retirer les garde-fous SQL pour forcer la migration.

Appliquer ensuite les migrations nécessaires dans l'ordre, recharger le PBF et initialiser ses deux états de réplication selon Configuration. Archiver les anciens fichiers de réplication pour ne pas mélanger les initialisations. Ne pas transférer un lot préparé depuis une autre base ni modifier simplement sa cible.

Pour revenir à une sauvegarde, arrêter tous les écrivains et restaurer un ensemble cohérent : base complète, code, style et fichiers/états de réplication correspondants. Vérifier la restauration sur une base séparée. Refaire les contrôles avant toute réactivation des timers.

Flux cartographiques protégés​

La migration 2.7.4 → 2.8.0 et le schéma neuf comprennent les colonnes map_auth des tables tuiles, WMS et WMTS. Installez les dépendances du nouveau lockfile npm et reconstruisez le web. Configurez LBT_MAP_ENCRYPTION_KEY seulement si vous utilisez des flux protégés, selon Catalogue des cartes de fond. Aucun changement des workers ni des unités systemd n’est nécessaire.

Complément de migration : représentation de la carte de validation​

Les installations neuves et le fichier actuel update_2.7.4_to_2.8.0.sql incluent ce paramétrage. Si cette mise à jour avait déjà été appliquée avant l’ajout de cette fonctionnalité, jouez uniquement le complément idempotent suivant avant de démarrer l’application web mise à jour (adaptez les valeurs de connexion) :

sudo -H psql --host=DB_HOST --port=5432 --username=DB_USER --dbname=DB_NAME --password -v ON_ERROR_STOP=1 -f /opt/lebontag-v2/sql/validation_appearance.sql

Il ajoute la préférence utilisateur nullable et le mode administrateur action sans modifier les choix déjà enregistrés. Aucun paquet npm, variable d’environnement ou service supplémentaire n’est nécessaire. Recompilez et redémarrez le service web selon la procédure ci-dessus.

Correction des références de tags et de l’auto-validation​

Cette livraison ne change pas le schéma SQL. Déployer ensemble les scripts Python et leurs nouveaux modules lbt_reference.py et lbt_review_db.py, selon la procédure de mise à jour ci-dessus. Les bibliothèques Python requises ne changent pas. Le pipeline conserve ses commandes de service.

Les nouveaux diffs utiliseront les tags des primitives de référence. Les fiches existantes ne sont pas toutes corrigées automatiquement, et les anciennes auto-validations potentiellement excessives ne sont pas annulées : une ancienne approbation explicite n’est pas distinguable de l’auto-validation historique.

Pendant la fenêtre de maintenance, après sauvegarde et suspension des traitements et des écritures utilisateur, lancer d’abord ce diagnostic :

cd /opt/lebontag-v2
sudo -u lbt-integration .venv/bin/python3 python/lbt-repair-reference-tags.py \
  --env-file /opt/lebontag-v2/.env.production.local

L’outil ne propose que les fiches tovalidate sans aucune décision manuelle, dont l’ancienne version correspond à la primitive de référence (ou les créations absentes du référentiel). Il reconstruit les nouveaux tags depuis la racine OSC identifiée par type/ID/version. Les fiches ayant des décisions ou une référence non prouvée figurent dans skipped. Examiner le résultat avant d’appliquer :

sudo -u lbt-integration .venv/bin/python3 python/lbt-repair-reference-tags.py \
  --env-file /opt/lebontag-v2/.env.production.local --apply

Les statuts, décisions, géométries et fragments OSC restent inchangés. Seuls les tags avant/après et leurs différences sont recalculés, en une transaction. L’outil verrouille les tables concernées ; un échec ne publie aucune correction partielle.

Repréparer les lots encore prepared avec la nouvelle politique (lbt-stage-update.py prepare --replace-prepared … avec les options de connexion habituelles), puis relancer l’intégration en mode check avant execute. Ne jamais annuler ni rejouer automatiquement un lot needs_review ou déjà intégré. Pour les fiches ignorées ou les anciennes validations automatiques, privilégier un examen ciblé ; une réinstallation complète reste possible uniquement avec les sauvegardes et la procédure de chargement initial.