Opérations¶

Dernière mise à jour : 13 octobre 2026

Cette page couvre les opérations quotidiennes de Tolk for Cisco UC — démarrage et arrêt du serveur, supervision, reverse proxy, sauvegarde & restauration, mises à jour, licence, rotation des clés, vérification d'intégrité et génération de bundle de support.

Démarrage & Arrêt¶

# Démarrer le service
docker compose up -d

# Arrêter le service
docker compose down

# Redémarrer le service
docker compose restart

# Vérifier le statut
docker compose ps

# Suivre les journaux
docker compose logs -f

# Redémarrer sur la nouvelle image après une mise à jour
docker compose up -d

Docker inclut un contrôle de santé intégré qui surveille le container toutes les 30 secondes via HTTPS GET sur /health. Consultez l'état de santé avec :

docker inspect --format='{{.State.Health.Status}}' tolk-for-cisco-uc

Préservation des données

docker compose down supprime le container, mais préserve toutes les données des volumes (secrets, clients, logs, sauvegardes). Utilisez docker compose down -v uniquement si vous souhaitez tout supprimer.

Séquence de Démarrage¶

À chaque démarrage, le serveur effectue automatiquement les étapes suivantes :

Étape	Action
1	Charger et valider la configuration `.env`
2	Initialiser la journalisation structurée (`app.log` + `audit.log`)
3	Synchroniser les profils RBAC par défaut (`profiles/_default/` → `profiles/`)
4	Exécuter la vérification d'intégrité du logiciel (`manifest.json` + `manifest.sig`)
5	Vérifier / générer le certificat TLS
6	Vérifier la paire de clés RSA — générer si absente
7	Synchroniser les clients (créer / mettre à jour / supprimer selon `AUTH_CLIENTS`)
8	Vérifier la licence (`secrets/license.jwt`)
9	Charger les modules produit (conditionnel selon le niveau de licence)
10	Démarrer les processus de surveillance en arrière-plan (Licence, Intégrité, Sauvegarde)
11	Démarrer le serveur ASGI (HTTPS)

Arrêt propre

Le serveur gère SIGTERM (docker stop) et SIGINT. Tous les threads de surveillance en arrière-plan sont arrêtés proprement via les gestionnaires atexit avant que le processus ne se termine.

Supervision & Observabilité¶

Fichiers Journaux¶

Fichier	Emplacement	Contenu
`app.log`	`LOGGING_DIR` (défaut `./logs/`)	Événements applicatifs : démarrage, chargement des modules, erreurs, informations
`audit.log`	`LOGGING_DIR`	Piste d'audit de sécurité : tous les événements d'authentification, appels d'outils, opérations sur les identifiants

Les deux fichiers utilisent le format JSON structuré — un objet JSON par ligne — pour une intégration facile dans des outils SIEM ou d'agrégation de journaux (Elastic, Splunk, Loki, etc.).

Rotation des journaux : déclenchée lorsque app.log ou audit.log dépasse LOGGING_ROTATE_SIZE octets (défaut ~5 Mo). Jusqu'à LOGGING_ROTATE_FILES archives compressées sont conservées à côté du fichier actif.

Sortie console : activée par défaut (LOGGING_CONSOLE_ENABLED=1). La sortie est colorisée par niveau de log pour une utilisation interactive.

Points de Terminaison de Santé & Statut¶

Point de terminaison	Auth	Description
`GET /health`	Aucune	Sonde de vivacité — retourne `ok`. Sûr pour les vérifications d'équilibreur de charge.
`GET /status`	Bearer	JSON de statut complet du serveur

La réponse /status inclut :

Version du serveur et durée de fonctionnement
État de la licence (VALID / GRACE / EXPIRED / INVALID), niveau, date d'expiration, produits activés
État de la sauvegarde (horodatage et nom du fichier de la dernière sauvegarde)
Nombre actuel d'adresses IP en liste noire (Fail2Ban)
Modules produit chargés
Statistiques (statistics, sans historique) : dernière réinitialisation, clients actifs sur les 5 dernières minutes, pics depuis le démarrage (clients actifs, requêtes MCP/min) et la dernière heure du Pipeline — requêtes/erreurs MCP, succès de bout en bout, taux d'échec auth/authz, total/erreurs par étape et par produit. Les fenêtres plus longues sont sur /metrics
Certificats TLS du point de terminaison MCP (tls) et de l'interface web d'administration (tls_admin_ui)

# Example status check
curl -sk -H "Authorization: Bearer <token>" \
  https://mcp.domain.com:8443/status | python -m json.tool

Métriques Prometheus¶

GET /metrics — aucune authentification requise. Expose les métriques au format texte Prometheus.

Métriques disponibles :

Métrique	Description
Compteurs de requêtes	Par client, nom d'outil et statut
Compteurs d'échecs d'authentification	Total et par client
Compteurs de limitation de débit	Par client, produit et service (plus les rejets globaux par hôte, produit, service via `mcp_global_rate_limit_hits_total`)
État des surveillances	État des surveillances de licence, intégrité, sauvegarde
Statistiques (`mcp_stats_*`)	Données des pages Statistiques de l'interface d'administration, jauges étiquetées `window` = `1h` / `24h` / `7d` / `30d` : indicateurs (`mcp_stats_mcp_requests`, `_mcp_errors`, `_end_to_end_success_percent`, `_auth_failure_percent`, `_authz_failure_percent`, `_active_clients`, `_tools_used`, `_ip_bans`), pipeline (`mcp_stats_stage_`, `mcp_stats_stage_breakdown_`), produits / services (`mcp_stats_product_`, `mcp_stats_service_`), top 10 (`mcp_stats_top_*`, `board` = clients / tools / profiles / destinations / error_types), première / dernière apparition des clients et outils, `mcp_stats_reset_timestamp_seconds`

Intervalle de collecte

Un intervalle de collecte de 15 secondes est recommandé. Le point de terminaison /metrics est léger et n'effectue aucune requête vers Cisco UC.

Catégories d'Événements du Journal d'Audit¶

Chaque événement pertinent pour la sécurité est écrit dans audit.log en JSON structuré. Les événements sont organisés par catégorie :

Catégorie	Ce qui est journalisé
`AUTH`	Succès/échec de connexion, token émis/révoqué, IP source, identité du client
`ACTIONS`	Chaque appel d'outil MCP — client, nom de l'outil, hôte cible, résultat, temps d'exécution
`RATE_LIMITED`	Violations de limitation de débit — par client (`RATE_LIMITED`) et global par hôte de destination (`RATE_LIMITED_GLOBAL`)
`CREDENTIAL`	Opérations de stockage / mise à jour / suppression d'identifiants
`TRUSTED`	Décisions de confiance et de rejet des empreintes SSH
`WRITTEN` / `EXPORTED`	Événements de génération de rapports et d'export PDF
`SERVER`	Démarrage, arrêt, transitions d'état de la licence
`TRANSPORT`	Alertes TLS, en-têtes `Host`/`Origin` invalides, tentatives de rebinding DNS

Intégrité du journal d'audit

audit.log est un journal structuré en ajout seul. Il n'est jamais modifié après l'écriture d'un événement. Traitez-le comme une piste d'audit immuable et transmettez-le à un SIEM pour une conservation à long terme.

Reverse Proxy (HAProxy)¶

Un reverse proxy web peut publier Tolk derrière une VIP (p. ex. tolk-vip.domain.com) : clients MCP sur le port 8443, interface Web d'administration sur le port 9443. Les exemples ci-dessous utilisent HAProxy, avec le serveur Tolk tolk.domain.com (ou tolk-1 / tolk-2) et les proxys 10.0.0.1 / 10.0.0.2.

Certificat du Reverse Proxy¶

Le certificat présenté par le reverse proxy doit contenir le FQDN de la VIP dans ses SAN (p. ex. tolk-vip.domain.com).

Le proxy valide le certificat du serveur Tolk (verify required, verifyhost) : l'AC qui l'a signé doit figurer dans le ca-file du proxy, et le certificat doit contenir le FQDN du serveur Tolk (tolk.domain.com) — c'est le cas par défaut, l'hôte d'AUTH_ISSUER en étant le CN.

Paramètres du Serveur Tolk¶

À régler depuis l'interface Web d'administration (Paramètres globaux), puis Appliquer & redémarrer :

Onglet / groupe	Paramètre	Valeur (exemple)	Rôle
Server › Reverse proxy	`MCP_SERVER_PUBLIC_URL`	`https://tolk-vip.domain.com:8443`	URL publique annoncée aux clients ; le FQDN de la VIP est ajouté implicitement aux hôtes / origines autorisés (`MCP_SERVER_SECURITY_ALLOWED_HOSTS` / `_ORIGINS`)
Server › Reverse proxy	`TRUSTED_PROXY_IPS`	`10.0.0.1,10.0.0.2`	Proxys dont l'en-tête `X-Forwarded-For` identifie le client réel (logs, liste noire, statistiques, liste blanche d'administration) ; jamais mis en liste noire
Admin UI › Transport	`ADMIN_UI_TRUSTED_IPS`	`10.0.0.1/32,10.0.0.2/32,10.1.0.0/24`	IP des proxys (checks HTTPS de `/admin/health`, envoyés sans `X-Forwarded-For`) et IP / réseaux des PC d'administration (évalués sur l'adresse client transmise)
Server › Autres	`SERVER_HEALTHCHECK_STATUS_RESPONSE`	`ok` (défaut)	Valeur de `status` renvoyée par `/health`, testée par le check du proxy

URL des clients MCP

Avec MCP_SERVER_PUBLIC_URL renseigné, l'URL fournie aux clients (découverte OAuth, URL de connexion des clients) devient https://tolk-vip.domain.com:8443/mcp.

Frontend HAProxy¶

Les ACL ci-dessous se placent dans le frontend HTTPS qui présente le certificat de la VIP (en écoute sur 8443 et 9443) :

# TOLK Frontend
acl ACL_tolk hdr(host) -i tolk-vip.domain.com:8443
http-request del-header X-Forwarded-For if ACL_tolk
http-request set-header X-Forwarded-Proto https if ACL_tolk
http-request set-timeout client 1h if ACL_tolk   # if HA-Proxy >=3.0
use_backend tolk_back if ACL_tolk
# TOLK Frontend (admin)
acl ACL_tolk-admin hdr(host) -i tolk-vip.domain.com:9443
acl ACL_tolk-admin_urls path_dir -i /admin
http-request del-header X-Forwarded-For if ACL_tolk-admin
http-request set-header X-Forwarded-Proto https if ACL_tolk-admin
http-request set-timeout client 1h if ACL_tolk-admin   # if HA-Proxy >=3.0
use_backend tolk-admin_back if ACL_tolk-admin ACL_tolk-admin_urls

del-header X-Forwarded-For supprime tout en-tête envoyé par le client ; option forwardfor (backend) ajoute ensuite l'adresse réelle du client — un client ne peut pas usurper son IP.
set-timeout client 1h maintient ouverts les flux MCP longs (HAProxy ≥ 3.0 ; sinon augmenter timeout client sur le frontend).
Seuls les chemins /admin sont transmis au backend d'administration.

Backends HAProxy¶

Les backends réalisent un check de niveau 7 : certificat TLS du serveur Tolk (verify required, verifyhost), code HTTP et texte de la réponse.

Serveur Tolk uniqueRépartition de charge (plusieurs serveurs Tolk)

# TOLK Backend
backend tolk_back
    description BACKEND - TOLK
    timeout server 1h
    option forwardfor
    option httpchk
    http-check send meth GET uri /health ver HTTP/1.1 hdr Host "%[srv_name].domain.com:8443"
    http-check expect status 200
    http-check expect string "\"status\":\"ok\",\"ready\":true"
    server tolk tolk.domain.com:8443 check ssl verify required ca-file /etc/ssl/certs/Root-CA.cer sni str(tolk.domain.com) verifyhost tolk.domain.com check-sni tolk.domain.com inter 10s fall 2 rise 2

backend tolk-admin_back
    description BACKEND - TOLK (admin)
    option forwardfor
    option httpchk
    http-check send meth GET uri /admin/health ver HTTP/1.1 hdr Host "%[srv_name].domain.com:9443"
    http-check expect status 200
    http-check expect string "ok"
    server tolk tolk.domain.com:9443 check ssl verify required ca-file /etc/ssl/certs/Root-CA.cer sni str(tolk.domain.com) verifyhost tolk.domain.com check-sni tolk.domain.com inter 10s fall 2 rise 2

# TOLK Backend
backend tolk_back
    description BACKEND - TOLK
    timeout server 1h
    option forwardfor
    option httpchk
    http-check send meth GET uri /health ver HTTP/1.1 hdr Host "%[srv_name].domain.com:8443"
    http-check expect status 200
    http-check expect string "\"status\":\"ok\",\"ready\":true"
    server tolk-1 tolk-1.domain.com:8443 check ssl verify required ca-file /etc/ssl/certs/Root-CA.cer sni str(tolk-1.domain.com) verifyhost tolk-1.domain.com check-sni tolk-1.domain.com inter 10s fall 2 rise 2
    server tolk-2 tolk-2.domain.com:8443 check ssl verify required ca-file /etc/ssl/certs/Root-CA.cer sni str(tolk-2.domain.com) verifyhost tolk-2.domain.com check-sni tolk-2.domain.com inter 10s fall 2 rise 2
    balance roundrobin
    stick-table type ip size 10m expire 30m
    stick match src
    stick store-request src

backend tolk-admin_back
    description BACKEND - TOLK (admin)
    option forwardfor
    option httpchk
    http-check send meth GET uri /admin/health ver HTTP/1.1 hdr Host "%[srv_name].domain.com:9443"
    http-check expect status 200
    http-check expect string "ok"
    server tolk-1 tolk-1.domain.com:9443 check ssl verify required ca-file /etc/ssl/certs/Root-CA.cer sni str(tolk-1.domain.com) verifyhost tolk-1.domain.com check-sni tolk-1.domain.com inter 10s fall 2 rise 2
    server tolk-2 tolk-2.domain.com:9443 check ssl verify required ca-file /etc/ssl/certs/Root-CA.cer sni str(tolk-2.domain.com) verifyhost tolk-2.domain.com check-sni tolk-2.domain.com inter 10s fall 2 rise 2
    balance roundrobin
    stick-table type ip size 10m expire 30m
    stick match src
    stick store-request src

La persistance sur l'IP source maintient chaque client sur le même serveur Tolk : une session MCP ou une session de l'interface Web d'administration n'est valide que sur le serveur qui l'a ouverte. Chaque serveur Tolk est configuré comme ci-dessus (MCP_SERVER_PUBLIC_URL, TRUSTED_PROXY_IPS, ADMIN_UI_TRUSTED_IPS).

L'en-tête Host est indispensable

L'en-tête Host du check (%[srv_name].domain.com:<port>, soit tolk.domain.com:8443) doit correspondre à une entrée de MCP_SERVER_SECURITY_ALLOWED_HOSTS : sans lui, les checks HTTPS sont bloqués par la protection anti DNS-rebinding (HTTP 421). Le nom du server (tolk, tolk-1…) doit donc être le nom court du serveur Tolk.

Texte de réponse attendu

/health (MCP) renvoie du JSON, p. ex. {"status":"ok","ready":true,…} : la valeur ok du http-check expect string doit correspondre à SERVER_HEALTHCHECK_STATUS_RESPONSE (ok par défaut). Le serveur est retiré du pool lorsque sa licence est expirée / invalide ("ready":false) ou dès que le mode maintenance a vidé ses clients ("status":"maintenance").
/admin/health (interface Web d'administration) renvoie toujours ok (texte brut), tant que l'IP du proxy figure dans ADMIN_UI_TRUSTED_IPS (sinon 403).

Sauvegarde & Restauration¶

Modèle de Chiffrement des Sauvegardes¶

Couche	Algorithme
Chiffrement de l'archive	AES-256-GCM (clé de session aléatoire)
Encapsulation de la clé de session	RSA-4096 OAEP (clé publique du serveur)
Vérification d'intégrité	Fichier sidecar SHA-512

Le serveur peut créer des sauvegardes en utilisant uniquement la clé publique. La restauration nécessite la clé privée RSA.

Déclencher une Sauvegarde¶

Les sauvegardes s'exécutent automatiquement à l'intervalle configuré dans BACKUP_INTERVAL_HOURS (défaut : 168 heures). La prochaine sauvegarde périodique est planifiée un intervalle après l'archive la plus récente (ou un intervalle après le démarrage si aucune archive n'existe ou si l'échéance est déjà dépassée). La ligne Prochaine sauvegarde de la page Sauvegarde / Restauration affiche cette échéance. Pour déclencher plus tôt, vous pouvez :

Cliquer sur Sauvegarder maintenant dans la page Sauvegarde / Restauration de l'interface web d'administration, ou
Réduire temporairement BACKUP_INTERVAL_HOURS et redémarrer

Restauration — Extraction Sécurisée¶

Extraire et déchiffrer une sauvegarde sans toucher à l'installation en production. Le script écrit dans un dossier auto-généré restore_<backup_id>/ à la racine du projet — aucun drapeau --output n'est nécessaire :

docker compose exec tolk python scripts/backup_restore.py \
  --file backups/backup_202605_hostname_20260508_001207.tar.gz.enc \
  --key secrets/rsa_private.pem

Inspectez le contenu extrait dans ./restore_202605_hostname_20260508_001207/ avant de décider de l'appliquer.

Restauration — En Place (`--replace`)¶

Remplacer les fichiers en production par le contenu de la sauvegarde. Laissez le conteneur en cours d'exécution — le script détecte le processus serveur, demande confirmation interactive, l'arrête, effectue l'extraction en place, puis vous redémarrez la stack :

docker compose exec tolk python scripts/backup_restore.py \
  --file backups/backup_202605_hostname_20260508_001207.tar.gz.enc \
  --key secrets/rsa_private.pem \
  --replace

docker compose up -d

Le script arrête le serveur avant d'écrire

Le mode --replace détecte le PID du serveur dans le conteneur, demande une confirmation interactive (yes), puis envoie SIGTERM avant d'extraire. N'exécutez pas docker compose down au préalable — la commande exec échouerait car le conteneur serait arrêté.

Restauration Après Rotation des Clés RSA¶

Si la sauvegarde a été créée avant une rotation de clés, utilisez la clé archivée :

docker compose exec tolk python scripts/backup_restore.py \
  --file backups/old_backup.enc \
  --key secrets/rsa_private.pem.archived.20260512

Les clés archivées sont conservées dans secrets/ avec un suffixe .archived.YYYYMMDD après la rotation.

Mise à Jour¶

Présentation¶

Une nouvelle version est livrée sous la même archive .tar.gz que l'installation initiale (image Docker pré-construite + fichiers associés). Elle est extraite par-dessus le répertoire d'installation, puis le script tolk-setup.sh charge la nouvelle image et lance l'outil de mise à jour (scripts/upgrade.py, depuis la nouvelle image), qui réconcilie votre .env avec le .env.example de la version.

Vos données sont préservées : l'archive ne contient aucun .env et n'écrit jamais dans secrets/, clients/ (hormis le modèle clients/_default/), logs/, backups/, servers-data/ ni profiles/*/_live/.

Lisez d'abord la sortie du test à blanc

Exécutez toujours ./tolk-setup.sh --dry-run avant d'appliquer une mise à jour. Cela affiche les modifications de .env sans rien écrire.

Procédure de Mise à Jour Étape par Étape¶

Étape 1 — Vérifier l'intégrité du paquet

Avant l'installation, vérifiez l'archive en utilisant la somme de contrôle SHA-512 publiée dans le DNS :

Depuis LinuxDepuis Windows

# 1. Query the DNS TXT record published by the editor (uses a computer with public DNS resolution)
dig tolk-for-cisco-uc-<version>.sha512.check.consulting.sourdeau.com txt +short

# 2. Compute the SHA-512 hash of the downloaded archive
sha512sum tolk-for-cisco-uc-<version>.tar.gz

# 3. Compare both values — they must match exactly

# 1. Query the DNS TXT record published by the editor (uses a computer with public DNS resolution)
nslookup -q=txt tolk-for-cisco-uc-<version>.sha512.check.consulting.sourdeau.com

# 2. Compute the SHA-512 hash of the downloaded archive
Get-FileHash -Algorithm SHA512 tolk-for-cisco-uc-<version>.tar.gz

# 3. Compare both values — they must match exactly

Ne sautez pas cette étape

Si les valeurs ne correspondent pas, n'allez pas plus loin. Contactez tolk@sourdeau.com immédiatement.

Étape 2 — Préparer (recommandé)

Depuis l'interface Web d'administration : effectuez une sauvegarde (page Sauvegarde), puis activez le mode maintenance (Système › Mode maintenance) pour drainer les sessions MCP en cours avant le redémarrage.

Étape 3 — Extraire la version par-dessus l'installation

cd ~/tolk
tar --no-overwrite-dir -xzf tolk-for-cisco-uc-<version>.tar.gz
rm -f tolk-for-cisco-uc-<version>.tar.gz*

--no-overwrite-dir conserve les permissions des répertoires existants.

Étape 4 — Prévisualiser (test à blanc)

./tolk-setup.sh --dry-run

Le script charge la nouvelle image Docker (puis supprime l'archive de l'image) et affiche le rapport de mise à jour : versions installée et livrée, clés .env mises à jour / ajoutées, clés devenues inutilisées. Rien n'est écrit. Le service en cours n'est pas affecté.

Étape 5 — Appliquer

./tolk-setup.sh

L'outil de mise à jour :

vérifie les versions — un retour arrière est refusé (sauf --force) ; relancer sur la même version est sans effet ;
sauvegarde .env dans backups/env/.env.bak-<horodatage UTC> ;
met à jour .env (voir les règles de fusion ci-dessous) ;
signale les paramètres ajoutés comme nouveaux dans l'interface Web d'administration ;
journalise l'opération dans logs/upgrade.log.

Étape 6 — Redémarrer sur la nouvelle image

docker compose up -d
docker image prune -f    # optionnel : supprimer l'image précédente

docker compose up -d recrée le conteneur sur la nouvelle image (pas besoin de docker compose down). Le mode maintenance, s'il est activé, survit au redémarrage : désactivez-le depuis l'interface d'administration une fois le service vérifié.

Étape 7 — Passer en revue les nouveaux paramètres

Une tuile bleue Nouveaux paramètres apparaît dans l'en-tête de l'interface d'administration ; des points bleus signalent les menus et onglets concernés, et les lignes correspondantes sont surlignées en bleu. Vérifiez leurs valeurs par défaut et ajustez-les si besoin.

Comportement de Fusion des Clés `.env`¶

Catégorie de clé	Comportement
Identité du projet	`PROJECT_NAME`, `PROJECT_CREATOR`, `PROJECT_VERSION` — toujours reprises de la version livrée (non modifiables)
Nouvelles clés	Ajoutées avec leur valeur par défaut et leur commentaire, au même endroit que dans `.env.example` (avec l'en-tête pour une nouvelle section)
Clés client existantes	Jamais modifiées — toujours préservées telles que configurées
Clés obsolètes	Les clés que la version n'utilise plus sont listées dans le rapport, jamais supprimées

Votre configuration est en sécurité

L'outil de mise à jour n'écrase jamais les clés configurées par le client. Vos identifiants de cluster, définitions de clients et paramètres personnalisés survivent à chaque mise à jour.

Signalement des nouveaux paramètres — un paramètre ajouté par la mise à jour reste signalé en bleu jusqu'à ce que :

un administrateur clique sur Marquer comme vus dans la page Nouveaux paramètres (tuile de l'en-tête ; droit d'écriture sur la page Paramètres ou Produits), ou
le paramètre soit modifié (toute valeur enregistrée), ou
7 jours se soient écoulés depuis la mise à jour.

Options de la Mise à Jour¶

Option	Description
`--dry-run`	Prévisualiser les modifications de `.env` sans rien écrire
`--force`	Autoriser un retour arrière ou une version non reconnue (déconseillé)

Licence¶

États de la licence¶

Le serveur surveille sa licence en continu et opère dans l'un des quatre états suivants :

État	Signification	Comportement du serveur
✅ VALID	La licence est valide et toutes les vérifications sont passées	Fonctionnement complet
⚠️ GRACE	La licence a expiré mais est dans la période de grâce	Fonctionnement complet — rappel de renouvellement journalisé
❌ EXPIRED	La licence a expiré et la période de grâce est dépassée	Modules produits désactivés — modules infra et common toujours disponibles
🚫 INVALID	Fichier de licence manquant, altéré ou hostname non concordant	Modules produits non chargés

Renouvellement¶

La licence se renouvelle depuis l'UI Web d'administration (administrateur disposant de l'accès en écriture à la page Licence) :

Obtenez un nouveau fichier license.jwt auprès de l'éditeur, comme pour la licence initiale.
Ouvrez la page Licence et dépliez la carte Importer une licence.
Sélectionnez le fichier license.jwt (ou collez le jeton). La signature est validée et la nouvelle licence est prévisualisée (client, niveau, expiration, produits, nombre max de clients, liaison au hostname — une pastille rouge signale que la liaison ne correspond pas au hostname de ce serveur).
Cliquez sur Importer la licence et confirmez le remplacement de la licence actuelle.
La nouvelle licence est mise en attente : cliquez sur Appliquer & redémarrer dans le bandeau pour l'activer (voir Appliquer & redémarrer).
Après le redémarrage, la page Licence affiche la nouvelle date d'expiration et l'état VALID.

Note

Jusqu'au redémarrage, le serveur en cours d'exécution conserve la licence qu'il a chargée (produits, limite de clients).
Un jeton dont la signature est invalide ou sans date d'expiration est refusé : la licence actuelle reste intacte.
Renouvelez avant la fin de la période de grâce pour éviter toute interruption. Si la licence est déjà EXPIRED ou INVALID, l'UI Web d'administration reste disponible comme console de secours et la même procédure rétablit les modules produits.

Rotation des Clés RSA¶

Quand Effectuer une Rotation¶

Périodiquement en tant que bonne pratique de sécurité (ex. annuellement)
Immédiatement après une suspicion de compromission de clé

Procédure de Rotation¶

La paire de clés RSA se régénère depuis l'UI Web d'administration (administrateur disposant de l'accès en écriture aux Paramètres globaux) :

Ouvrez Paramètres globaux → onglet Authentication. Dans le groupe Clés RSA, cliquez sur Régénérer la paire et confirmez.

Le serveur exécute les étapes suivantes dans l'ordre et affiche le résultat de chacune dans un bandeau :

Étape	Action
1. Sauvegarde complète	Sauvegarde chiffrée avec la clé actuelle — l'état antérieur à la rotation reste restaurable
2. Archivage de la paire actuelle	Paire actuelle archivée dans le périmètre Clés RSA de la page Sauvegarde / Restauration
3. Génération de la nouvelle paire	Nouvelle paire RSA (`AUTH_RSA_KEY_SIZE`, 4096 bits par défaut)
4. Réémission des jetons clients	Un nouveau jeton JWT est émis pour chaque client

Si une étape échoue, la procédure s'arrête : la paire actuelle reste en place (ou archivée) et l'erreur est affichée. 3. Sur la page Clients, récupérez le nouveau jeton de chaque client avec son bouton unique Voir les identifiants. 4. Cliquez sur Appliquer & redémarrer dans le bandeau pour activer la nouvelle paire (voir Appliquer & redémarrer). 5. Transmettez les nouveaux jetons aux utilisateurs des agents AI.

Impact de la Rotation des Clés¶

Composant	Impact
Tokens JWT	Nouveaux tokens émis pendant la régénération ; les anciens sont refusés par l'endpoint MCP après le redémarrage
Secrets client OAuth2	Non affectés (basés sur bcrypt, non dépendants de RSA) — les clients redemandent un jeton d'accès
Sauvegardes chiffrées avant la rotation	Déchiffrables avec la clé archivée (périmètre Clés RSA de la page Sauvegarde / Restauration)
Nouvelles sauvegardes	Chiffrées avec la nouvelle clé publique

Redistribuez les tokens après la rotation

À partir du redémarrage, les clients JWT sont refusés tant que leur configuration n'est pas mise à jour avec le nouveau token : planifiez ensemble l'Appliquer & redémarrer et la redistribution des tokens. Les anciens tokens sont définitivement invalides.

Vérification d'Intégrité du Logiciel¶

Chaque fichier du projet est couvert par un manifeste SHA-512 (manifest.json) signé avec RSA-PSS (RSA-4096), produisant manifest.sig.

Vérification Automatique¶

Au démarrage : la vérification d'intégrité s'exécute avant le chargement de tout module
Surveillance en arrière-plan : se réexécute toutes les 24 heures

Toute altération est journalisée dans app.log et audit.log avec une sévérité CRITICAL.

Vérification Manuelle¶

L'état d'intégrité est affiché dans l'UI Web d'administration :

Pages Tableau de bord et Système & reload — l'indicateur Intégrité donne le résultat de la dernière vérification automatique (Vérifiée, Violation ou Pas encore vérifiée) et la date de la prochaine.
Page Appliquer les modifications de configuration — ouverte avec Appliquer / Redémarrer (carte Modifications en attente / Redémarrage de la page Système & reload, même sans modification en attente) ou avec Appliquer & redémarrer dans le bandeau. Sa section Contrôle d'intégrité vérifie chaque fichier par rapport au manifeste signé à l'ouverture de la page, puis s'actualise automatiquement :
- ✅ Intégrité OK — N fichiers correspondent au manifest signé.
- ❌ Intégrité ÉCHOUÉE — chaque fichier concerné est listé sous la forme MODIFIED: <chemin> ou MISSING: <chemin>.

Violation d'intégrité

Une violation détectée par la surveillance en arrière-plan déclenche un arrêt propre du serveur, et un serveur dont la vérification d'intégrité échoue ne peut pas démarrer. Ne redémarrez pas le serveur tant que la section Contrôle d'intégrité signale un échec : réinstallez les fichiers de la version (voir Mise à jour) ou contactez l'éditeur.

Show Tech (Bundle de Support)¶

Show tech assemble un bundle de diagnostic pour les soumissions au support. Il se génère depuis l'UI Web d'administration (administrateur disposant de l'accès en écriture à la page Journaux) :

Ouvrez la page Journaux → onglet Diagnostique.
Dans la carte Générer un rapport, laissez cochée ou décochez Inclure les fichiers de journaux (décochée : bundle plus léger, sans le dossier logs/), puis cliquez sur Lancer show-tech et confirmez.
La carte Progression de la collecte suit la collecte (une seule à la fois ; elle peut prendre quelques minutes).
Le bundle show_tech_<hostname>_<timestamp>.zip apparaît dans la liste Rapports show-tech : cliquez sur Télécharger.

Les bundles sont stockés dans <BACKUP_DIR>/show_tech/ et purgés automatiquement après LOGGING_SHOW_TECH_BACKUP_RETENTION jours (30 par défaut, 0 = jamais) ; la colonne Suppression auto dans indique les jours restants. Supprimer retire un bundle immédiatement.

Ce qui Est Inclus¶

Élément	Inclus
Version du serveur, version Python, informations sur l'OS	Oui
Configuration `.env` (identifiants et secrets masqués)	Oui (adresses IPv4 partiellement masquées)
Modifications en attente (non appliquées)	Oui (valeurs masquées)
`app.log` et `audit.log`	Oui (sauf si Inclure les fichiers de journaux est décochée, adresses IPv4 partiellement masquées)
Résultat de la vérification du manifeste	Oui
État de la licence (sans le contenu du fichier de licence)	Oui
Liste des clients (profil, mode d'auth., dates de jeton / révélation / dernière connexion)	Oui (aucun secret)
Liste du répertoire de sauvegarde (taille, date, SHA-512)	Oui (contenu des archives jamais inclus)
Versions des dépendances Python	Oui

Ce qui N'est Jamais Inclus¶

Les données sensibles ne sont jamais collectées

Show tech exclut explicitement les éléments suivants — ils ne sont jamais présents dans un bundle de support :

Clés privées RSA
Tokens JWT ou secrets client OAuth
Archives de sauvegarde chiffrées
Identifiants Cisco UC (mots de passe AXL, mots de passe SSH)
Le fichier secrets/license.jwt

Soumettre un Bundle¶

Envoyez le bundle à tolk@sourdeau.com avec une description du problème.