# 8. Procédures d’exploitation

## 8.1. Démarrage de la solution

    ansible-playbook --vault-password-file vault_pass.txt --extra-vars=@./environments/vitamui_extra_vars.yml -i environments/<hostfile_vitamui> ansible-vitamui-exploitation/start_vitamui.yml

## 8.2. Arrêt de la solution

    ansible-playbook --vault-password-file vault_pass.txt --extra-vars=@./environments/vitamui_extra_vars.yml -i environments/<hostfile_vitamui> ansible-vitamui-exploitation/stop_vitamui.yml

## 8.3. Upgrade de la solution

Actuellement, un upgrade de solution s’apparente à une installation de la solution.

    ansible-playbook --vault-password-file vault_pass.txt --extra-vars=@./environments/vitamui_extra_vars.yml -i environments/<hostfile_vitamui> ansible-vitamui/vitamui.yml

Les services Vitam-UI sont stateless et vont être remplacés par une nouvelle version lors de l’opération précédente.

Les scripts de base de données MongoDB sont versionnés via un changelog interne. Un même script ne peut pas être joué 2 fois. Les nouveaux scripts vont être intégrés et les anciens scripts ou doublons de scripts ne vont pas être pris en compte.

## 8.4. Sauvegarde de la solution

La base de données Mongodb utilisée par Vitam-UI peut être sauvegardée de 2 manières:

1. via un playbook de sauvegarde (mongo_backup.yml)

2. via un dump (commande mongodump)

### 8.4.1. Sauvegarde via playbook (1)

Au préalable il est nécessaire de valoriser correctement les variables suivantes contenues dans le fichier `environments/group_vars/all/mongodb_vars.yml`:

    mongo_dump_folder: /backup/mongod/
    mongo_backup_reinstall:
      - db: "iam"
        collections: ["customers","externalParameters","groups","owners","profiles",
        "sequences","subrogations","tenants","users","providers"]
      - db: "admin"
        collections: []

La structure `mongo_backup_reinstall` va permettre de sauvegarder la base entière si elle est renseignée de la sorte:

    mongo_backup_reinstall:
      - db: "admin"
        collections: []

Et les collections uniquement lorsque mentionné comme suit:

    mongo_backup_reinstall:
      - db: "iam"
        collections: ["customers","externalParameters","groups","owners","profiles","sequences","subrogations","tenants","users","providers"]

Le résultat du backup pourra se retrouver dans

    mongo_dump_folder: /backup/mongod/

    ansible-playbook -i environments/<hostfile_vitamui> --vault-password-file vault_pass.txt --extra-vars=@./environments/vitamui_extra_vars.yml ansible-vitamui-exploitation/mongo_backup.yml

### 8.4.2. Sauvegarde via la commande mongodump (2)

Se rendre sur la machine (vm) hébergeant l’instance mongodb de Vitam-UI et exécuter la commande suivante:

    mongodump --host "ip_machine:27017" -u [user] -p [mdp] -v --gzip --out="/backup/mongod/`date \+\%Y\%m\%d_\%s`"

## 8.5. Restoration de la solution

De la même manière, la base de données Mongodb utilisée par VitamUI peut être sauvegardée de 2 manières:

1. via un playbook de sauvegarde (mongo_restore.yml)

2. via un dump (commande mongodump)

### 8.5.1. Restoration via playbook (1)

La restoration va chercher le backup présent dans le dossier que renseigne la variable « mongo_dump_folder ».

    ansible-playbook --vault-password-file vault_pass.txt --extra-vars=@./environments/vitamui_extra_vars.yml -i environments/<hostfile_vitamui> ansible-vitamui-exploitation/mongo_restore.yml

### 8.5.2. Restoration via la commande mongodump (2)

Se rendre sur la machine (vm) hébergeant l’instance mongodb de Vitam-UI et exécuter la commande suivante:

    mongorestore --host [ip machinie] --port 27017 --username [user] --password [mdp] "/backup/mongod/[nom_backup] --drop --gzip --maintainInsertionOrder

> Attention ! Certaines informations Vitam sont sauvegardées dans Vitam-UI.

## 8.6. Changement de PKI

Les certificats utilisés par Vitam et VitamUI peuvent être amenés à être changés pour des raisons de sécurité ou simplement suite à leur expiration.

### 8.6.1. Certificat Vitam-UI client expiré dans Vitam

Le certificat client vitamui.crt est utilisé par Vitam afin que l’application Vitam-UI accède aux informations de Vitam. Son échange se fait par les playbooks Vitam remove_contexts.yml et add_contexts.yml dans les sources de Vitam.

Renseigner le fichier `environments/group_vars/all/postinstall_param.yml` avec les informations du certificat actuel et lancer la commande de suppression suivante:

    ansible-playbook --vault-password-file vault_pass.txt -i environments/<hostfile_vitam> ansible-vitam-exploitation/remove_contexts.yml

Se connecter à l’ihm_demo de Vitam pour vérifier la bonne suppression du context vitamui_context dans les contextes applicatifs Vitam.

Une fois cette opération réalisée, il faut :

- Regénérer ou échanger le certificat vitamui.crt afin qu’il soit valide.

- Modifier les informations du fichier postinstall_param.yml avec le nom du nouveau certificat et lancer la commande suivante:

    ansible-playbook --vault-password-file vault_pass.txt -i environments/<hostfile_vitam> ansible-vitam-exploitation/add_contexts.yml

Vérifier alors dans les contextes applicatifs Vitam que le contexte vitamui_context est de nouveau présent (rattaché de manière transparente au nouveau certificat).

### 8.6.2. Certificats expirés dans les services VitamUI

Regénérer la PKI complète VitamUI et Vitam.

Rédéployer la PKI pour les 2 solutions.

Les commandes sont précisées dans le dossier d’installation VitamUI.

## 8.7. Analyse des problèmes Vitam-UI

### 8.7.1. Logs

Les traces applicatives ou techniques de Vitam-UI se trouvent sur les machines hébergeant l’application dans `/vitamui/log/nom_service/` pour le service considéré.

Les logs sont écrits via le service rsyslog installé sur toutes les machines de la solution.

### 8.7.2. MongoDB

Se connecter à la vm où est hébergé l’instance mongod.

Se connecter à la base de données via l’utilitaire mongo.

Exemple de commande:

    mongosh --host <ip machine> --port 27017 admin --username=<user> --password=<password>

## 8.8. Configuration des profils de mot de passe

### 8.8.1. Profil ANSSI

Le profil par défaut chargé au démarrage de CAS, la configuration de ce profil sur une plateforme déjà installé se fait sur la machine hénergeante le serveur CAS, la configuration se situe dans `/vitamui/conf/cas-server/application.yml`, dans la section `password:`

L’exploitant peut changer quelques contraintes de la complexité du mot de passe, sans violer les standards de l’ANSSI.

#### 8.8.1.1. Exemple de changement de la taille du mot de passe

dans la section `password:`, l’attribut `length` est par défaut à 12, le changement de la taille du mot de passe revient à changer cet attribut `length`, cette valeur sera automatiquement portée par l’attribut `cas.authn.pm.core.password-policy-pattern:` qui contient l’expression `${password.length}$`. l’attribut `cas.authn.pm.core.password-policy-pattern:` contient l’expression régulière de validation du mot de passe et qui se trouve dans le meme fichier de configuration.

> Cette valeur ne devra pas etre inférieur à la valeur par défaut, avec le profil anssi.

#### 8.8.1.2. Exemple de désactivation du contrainte de vérification d’existence d’une occurrence d’un nom d’utilisateur dans les mots de passe

Cette contrainte est traduite par l’attribut: `check-occurrence`, qui est un boolean par défaut égal à `true`,

Donc `check-occurrence: false` désactivera cette vérification.

#### 8.8.1.3. Exemple de changement du nombre de caractères tolérables du nom d’utilisateur à utiliser dans le mot de passe

Cette contraintes pourra etre changée avec l’attribut `occurrences-chars-number:`, par défault la valeur est égal à `3`,

Donc `occurrences-chars-number: 5`, augmentera le nombre de caractère tolérable issues du nom de l’utilisateur à utiliser dans un mot de passe.

> Cette valeur ne devra pas etre inférieur à la valeur par défaut.

Si la taille du nom de l’utilisateur est inférieur à cette valeur, la contrainte est tolérable.

#### 8.8.1.4. Exemple de changement du nombre des anciens mots de passe à ne pas réutiliser

Cette contraintes pourra etre changée avec l’attribut `max-old-password:`, par défault la valeur est égal à `12` dans le profil anssi, et `3` dans le profil custom,

Donc `max-old-password: 13`, augmentera le nombre d’anciens mots de passe à ne pas réutiliser”

Ce changement devra etre fait aussi sur le composant `iam`, dans le fichier `/vitamui/conf/iam/application.yml`, dans la section `password`.

> Cette valeur ne devra pas etre inférieur à la valeur par défaut, avec le profil anssi. Le redémarrage du composant iam est nécessaire avec ce changement.

#### 8.8.1.5. Exemple de personnalisation des messages redues à l’utilisateur

Les messages peuvent etre personnalisés par l’exploitant dans le bloc, par langue

    constraints:
        defaults:
            fr:
                messages:
                    - message 1
                    - message 2
                    - ...
                special-chars:
                    title: 'message 3'
                    messages:
                        - message 4
                        - message 5
                en:
                    messages:
                        - message 1
                        - message 2
                        - ...
                    special-chars:
                        title: 'message 3'
                        messages:
                            - message 4
                            - message 5
        customs:
          fr:
            title: 'Pour des raisons de sécurité, votre mot de passe doit:'
            messages:
              - Au moins ${password.length} caractères
              - Des minuscules et des majuscules
              - Au moins un chiffre et un caractère spécial (!"#$%&£'()*+,-./:;<=>?@[]^_`{|}~)
          en:
            title: 'For security reasons, your password must:'
            messages:
              - At least ${password.length} characters
              - Lowercase and uppercase
              - At least one number and one special character (!"#$%&£'()*+,-./:;<=>?@[]^_`{|}~)
            ...

> C’est à charge de l’exploitant de respecter les contraintes traduites, qui devront etre en cohérence avec les blocs / attributs de son profil anssi, et qui devront pas violer les standards préconisés par l’ANSSI et la PSSI du ministère de la culture.

### 8.8.2. Profil personnalisé

#### 8.8.2.1. Exemple de changement de la taille du mot de passe pour le profil custom

dans la section `password:`, l’attribut `length` est par défaut à 12, le changement de la taille du mot de passe revient à changer cet attribut `length`, cette valeur sera automatiquement portée par l’attribut `cas.authn.pm.core.password-policy-pattern:` qui contient l’expression `${password.length}$` , à la fin de l’expression régulière. L’attribut `cas.authn.pm.core.password-policy-pattern:` contient l’expression régulière globale de validation du mot de passe et qui se trouve dans le meme fichier de configuration.

> Cette valeur est par défaut égal à 8 pour le profil custom.

#### 8.8.2.2. Exemple de changement du nombre des anciens mots de passe à ne pas réutiliser pour le profil custom

Les memes configurations que pour le profil anssi.

> Veillez à redémarrer le serveur CAS et le composant iam pour appliquer ces changements.

### 8.8.3. Gestion du timeout lors de création d’organisations

La création d’oranisations est un worflow nécessitant l’execution de plusieurs actions, c’est pour cette raison que dans certains cas en fonction des performances de l’infrastructure, le super-admin peut constater un timeout dans ce workflow. Dans ce cas, on peut augmenter la valeur de ce timeout admin dans les fichiers de configurations des deux applications: iam et ui-identity-admin:

- Dans ui-identity-admin

    ui-identity:
        iam-external-client:
            connect-time-out: 30
            read-time-out: 30
            write-time-out: 30

- Dans iam

    iam:
        iam-external-client:
            connect-time-out: 30
            read-time-out: 30
            write-time-out: 30

Cette section est détaillée dans le document d’installation de Vitam-UI.

## 8.9. Timers Vitam-UI

### 8.9.1. Bascule des timers en cas de multi-instanciation du service iam

Dans le cadre d’une installation multi-instances du service `iam`, les timers de journalisation des évènements métiers de Vitam-UI sont exécutés sur la première instance du groupe `[hosts_vitamui_iam]` via le paramètre `instance.primary: true` configuré dans le fichier `/vitamui/conf/iam/application.yml`.

Si cette machine « primaire » est arrêtée, les timers ne sont pas automatiquement redémarrés sur une autre instance.

Pour effectuer la bascule, il sera nécessaire de modifier l’ordre de définition des machines du groupe `[hosts_vitamui_iam]` dans le fichier d’inventaire puis réappliquer le playbook `ansible-vitamui/vitamui_apps.yml --tags iam`.