2. Procédures d’exploitation

2.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

2.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

2.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.

2.4. Sauvegarde de la solution

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

via un playbook de sauvegarde (mongo_backup.yml)
via un dump (commande mongodump)

2.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

2.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`"

2.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:

via un playbook de sauvegarde (mongo_restore.yml)
via un dump (commande mongodump)

2.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

2.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.

2.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.

2.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).

2.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.

2.7. Analyse des problèmes Vitam-UI

2.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.

2.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:

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

2.8. Configuration des profils de mot de passe

2.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.

2.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.policy-pattern: qui contient l’expression ${password.length}$ . l’attribut cas.authn.pm.core.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.

2.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.

2.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.

2.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-internal, dans le fichier /vitamui/conf/iam-internal/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-internal est nécessaire avec ce changement.

2.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
            de:
                messages:
                    - message 1
                    - message 2
                    - ...
                special-chars:
                    title: 'message 3'
                    messages:
                        - message 4
                        - message 5
        ...

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.

2.8.2. Profil personnalisé

2.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.policy-pattern: qui contient l’expression ${password.length}$ , à la fin de l’expression régulière. L’attribut cas.authn.pm.core.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.

2.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-internal pour appliquer ces changements.

2.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-external 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-external

iam-external:
    iam-internal-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.

2.9. Timers Vitam-UI

2.9.1. Bascule des timers en cas de multi-instanciation du service iam-internal

Dans le cadre d’une installation multi-instances du service iam-internal, 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_internal] via le paramètre instance.primary: true configuré dans le fichier /vitamui/conf/iam-internal/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_internal] dans le fichier d’inventaire puis réappliquer le playbook ansible-vitamui/vitamui_apps.yml --tags iam-internal.