4.2.6. Procédure de première installation

4.2.6.1. Déploiement

4.2.6.1.1. Cas particulier : utilisation de ClamAv en environnement Debian

Dans le cas de l’installation en environnement Debian, la base de données n’est pas intégrée avec l’installation de ClamAv, C’est la commande freshclam qui en assure la charge. Si vous n’êtes pas connecté à internet, la base de données doit être installée manuellement. Les liens suivants indiquent la procédure à suivre: Installation ClamAv et Section Virus Database

4.2.6.1.2. Fichier de mot de passe des vaults ansible

Par défaut, le mot de passe des vault sera demandé à chaque exécution d’ansible avec l’utilisation de l’option --ask-vault-pass de la commande ansible-playbook.

Pour simplifier l’exécution des commandes ansible-playbook, vous pouvez utiliser un fichier |repertoire_deploiement|``vault_pass.txt`` contenant le mot de passe des fichiers vault. Ainsi, vous pouvez utiliser l’option --vault-password-file=vault_pass.txt à la place de l’option --ask-vault-pass dans les différentes commandes de cette documentation.

Avertissement

Il est déconseillé de conserver le fichier vault_pass.txt sur la machine de déploiement ansible car ce fichier permet d’avoir accès à l’ensemble des secrets de VITAM.

4.2.6.1.3. Mise en place des repositories VITAM (optionnel)

VITAM fournit un playbook permettant de définir sur les partitions cible la configuration d’appel aux repositories spécifiques à VITAM :

Editer le fichier |repertoire_inventory|``group_vars/all/main/repositories.yml`` à partir du modèle suivant (décommenter également les lignes) :

1
2
3
4
5
6
7
8
9
---

# vitam_repositories:
#   - key: repo1 # Mandatory: Only on CentOS/AlmaLinux
#     value: http://path_to_repo1 # Mandatory: Path to the repository
#     gpgcheck: 1 # Optionnal: Default to 0 (equivalent as [trusted=yes] on Debian)
#     gpgkey: path_to_custom_key # Optionnal: Only if gpgcheck is enabled; Default to official Vitam GPG Key
#     subtree: "./" # Optionnal: Only on Debian; Default to ./
#     proxy: http://proxy_url # Optionnal: Only on CentOS/AlmaLinux; Default to _none_

Ce fichier permet de définir une liste de repositories. Décommenter et adapter à votre cas.

Pour mettre en place ces repositories sur les machines cibles, lancer la commande :

ansible-playbook ansible-vitam-extra/bootstrap.yml -i environments/hosts.<environnement> --ask-vault-pass

Note

En environnement CentOS, il est recommandé de créer des noms de repository commençant par vitam- .

4.2.6.1.4. Génération des hostvars

Une fois l’étape de PKI effectuée avec succès, il convient de procéder à la génération des hostvars, qui permettent de définir quelles interfaces réseau utiliser. Actuellement la solution logicielle VITAM est capable de gérer 2 interfaces réseau :

  • Une d’administration
  • Une de service

4.2.6.1.4.1. Cas 1: Machines avec une seule interface réseau

Si les machines sur lesquelles VITAM sera déployé ne disposent que d’une interface réseau, ou si vous ne souhaitez en utiliser qu’une seule, il convient d’utiliser le playbook |repertoire_playbook ansible|``generate_hostvars_for_1_network_interface.yml``

Cette définition des host_vars se base sur la directive ansible ansible_default_ipv4.address, qui se base sur l’adresse IP associée à la route réseau définie par défaut.

Avertissement

Les communications d’administration et de service transiteront donc toutes les deux via l’unique interface réseau disponible.

4.2.6.1.4.2. Cas 2: Machines avec plusieurs interfaces réseau

Si les machines sur lesquelles VITAM sera déployé disposent de plusieurs interfaces et si celles-ci respectent cette règle:

  • Interface nommée eth0 = ip_service
  • Interface nommée eth1 = ip_admin

Alors il est possible d’utiliser le playbook ansible-vitam-exploitation/generate_hostvars_for_2_network_interfaces.yml

Note

Pour les autres cas de figure, il sera nécessaire de générer ces hostvars à la main ou de créer un script pour automatiser cela.

4.2.6.1.4.3. Vérification de la génération des hostvars

A l’issue, vérifier le contenu des fichiers générés sous |repertoire_inventory|``host_vars/`` et les adapter au besoin.

Prudence

Cas d’une installation multi-sites. Sur site secondaire, s’assurer que, pour les machines hébergeant les offres, la directive ip_wan a bien été déclarée (l’ajouter manuellement, le cas échéant), pour que site le site primaire sache les contacter via une IP particulière. Par défaut, c’est l’IP de service qui sera utilisée.

4.2.6.1.5. Tests d’infrastructure

Il est possible de lancer une série de tests d’infrastructure en amont du déploiement, ceci afin de se prémunir d’éventuelles erreurs durant l’installation.

Les tests sont basés sur des prérequis de la solution VITAM et sont génériques. De ce fait, des « faux-posififs » peuvent être remontés dû à une configuration spécifique de votre environnement. Il est à votre charge d’analyser le rapport à l’issue des tests et de juger de la pertinence des résultats.

Les tests sont les suivants :

  • Version d’Ansible
  • Accès aux recursors (serveurs DNS)
  • Présence de Java
  • Accès aux repositories
  • Accès aux offres objet

Comme pour le déploiement, les tests s’effectuent depuis la machine ansible. La commande pour les effectuer est la suivante :

ansible-playbook ansible-vitam/checks_infra.yml -i environments/hosts.<environnement> --ask-vault-pass

4.2.6.1.6. Déploiement

Une fois les étapes précédentes correctement effectuées (en particulier, la section Génération des magasins de certificats), le déploiement s’effectue depuis la machine ansible et va distribuer la solution VITAM selon l’inventaire correctement renseigné.

Une fois l’étape de la génération des hosts effectuée avec succès, le déploiement est à réaliser avec la commande suivante :

ansible-playbook ansible-vitam/vitam.yml -i environments/hosts.<environnement> --ask-vault-pass

Note

Une confirmation est demandée pour lancer ce script. Il est possible de rajouter le paramètre -e confirmation=yes pour bypasser cette demande de confirmation (cas d’un déploiement automatisé).

Note

Il est possible d’effectuer les tests d’infrastructure décrits dans la partie précédente en ajoutant le paramètre -e checks_infra=yes. Un rapport s’affichera à l’issue des tests et il sera donné la possibilité de poursuivre ou non le déploiement.

Note

Il est également possible de forcer la suppression de profils de sécurité et de leurs données associées (contextes applicatifs et certificats) en ajoutant le paramètre -e delete_security_profiles=yes. Cela peut éventuellement être utile dans le cas d’un nouveau lancement de l’installation suite à un échec.

Prudence

Dans le cas où l’installateur souhaite utiliser un repository de binaires qu’il gère par lui-même, il est fortement recommandé de rajouter --skip-tags "enable_vitam_repo" à la commande ansible-playbook ; dans ce cas, le comportement de yum n’est pas impacté par la solution de déploiement.