4.3.13. Notes et procédures spécifiques V10.0

Prudence

Veuillez appliquer les procédures spécifiques à chacune des versions précédentes en fonction de la version de départ selon la suite suivante: V8.1 -> V9.0 -> V9.1 -> V10.0

4.3.13.1. Adaptation des sources de déploiement ansible

4.3.13.1.1. Réorganisation du stockage workspace par tenant et seuils de saturation

Le composant workspace-collect organise désormais ses fichiers sous un répertoire propre à chaque tenant, ce qui permet de refuser les versements du module de collecte lorsque le stockage approche de la saturation. Le composant workspace conserve son organisation historique.

Prudence

Assurez-vous qu’il n’y ait aucune opérations en cours ou en pause avant de procéder à la montée de version. En effet, après la montée de version, ces opérations ne pourront pas être reprise suite à la modification de leur chemin d’accès sur les workspaces.

Note

L’organisation par tenant et les contrôles de saturation sont imposés : workspace-collect stocke toujours ses fichiers par tenant, workspace conserve toujours son organisation historique. Ces valeurs ne sont pas configurables.

L’organisation du stockage, la configuration des seuils et les précautions d’usage sont décrites dans la documentation d’exploitation, au chapitre workspace_storage_thresholds.

4.3.13.1.2. Validation de la chaîne de confiance des certificats TSA

Le composant worker peut désormais valider la chaîne de confiance des certificats TSA utilisés lors de la vérification des preuves d’horodatage. Cette validation est désactivée par défaut ; aucune action n’est requise lors de la montée de version si vous ne souhaitez pas l’activer.

Pour activer cette validation, positionner la variable suivante (par exemple dans le bloc worker du fichier environments/group_vars/all/advanced/vitam_vars.yml) :

vitam:
  worker:
    timestamp_truststore_enabled: true

Avant le déploiement, déposez ensuite les certificats TSA de confiance dans le répertoire environments/certs/timestamping/trusted, sous forme de fichiers portant l’extension .crt (encodés indifféremment en DER ou en PEM), puis exécutez :

./generate_stores.sh

Prudence

Le répertoire environments/certs/timestamping/trusted doit contenir l’ensemble des certificats TSA utilisés au fil du temps : les certificats actuellement en service, mais également les anciens certificats si des renouvellements ont eu lieu. Les preuves d’horodatage déjà produites ont été signées avec les anciens certificats ; leur vérification échouerait si ceux-ci étaient absents du truststore.

Cette commande génère le fichier environments/keystores/timestamping/truststore_timestamping.p12 en utilisant le mot de passe truststores.timestamping défini dans environments/group_vars/all/main/vault-keystores.yml.

Lorsque la validation est activée, le déploiement du composant worker échoue en l’absence de ce truststore. Après le déploiement, une preuve d’horodatage dont le certificat TSA ne peut pas être rattaché à l’un des certificats de confiance est rejetée lors de sa vérification.

4.3.13.1.3. Gestion du démarrage des Jobs Vitam lors d’une montée de version

Les Jobs Vitam sont démarrés automatiquement à la fin du master playbook ansible-vitam/vitam.yml. Ce démarrage est désormais conditionné par l’extra var prevent_scheduling_start, positionnée à false par défaut.

Lors d’une montée de version, il faut impérativement passer prevent_scheduling_start=true au lancement du master playbook, afin que les Jobs Vitam ne se relancent pas alors que la post-migration n’est pas terminée :

ansible-playbook -i environments/<inventaire> ansible-vitam/vitam.yml --ask-vault-pass -e prevent_scheduling_start=true

Une fois les procédures de post-migration finalisées, les Jobs Vitam devront être démarrés explicitement via le playbook d’exploitation :

ansible-playbook -i environments/<inventaire> ansible-vitam-exploitation/start_vitam_scheduling.yml --ask-vault-pass