4.2.5. Procédure de première installation¶

4.2.5.1. Déploiement¶

4.2.5.1.1. Cas particulier : utilisation de ClamAv en environnement Debian¶

Dans le cas de l’installation en environnement Debian, la base de donnée 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 s’installer manuellement. Les liens suivants indiquent la procédure à suivre: Installation ClamAv et Section Virus Database

4.2.5.1.2. Fichier de mot de passe¶

Par défaut, le mot de passe des « vault » sera demandé à chaque exécution d’ansible. Si le fichier deployment/vault_pass.txt est renseigné avec le mot de passe du fichier environments/group_vars/all/vault-vitam.yml, le mot de passe ne sera pas demandé (dans ce cas, changez l’option --ask-vault-pass des invocations ansible par l’option --vault-password-file=VAULT_PASSWORD_FILES.

4.2.5.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 environments/group_vars/all/repositories.yml à partir des modèles suivants (décommenter également les lignes) :

Pour une cible de déploiement CentOS :

#vitam_repositories:
#- key: repo 1
#  value: "file:///code"
#  proxy: http://proxy
#- key: repo 2
#  value: "http://www.programmevitam.fr"
#  proxy: _none_
#- key: repo 3
#  value: "ftp://centos.org"
#  proxy:

Pour une cible de déploiement Debian :

#vitam_repositories:
#- key: repo 1
#  value: "file:///code"
#  subtree: "./"
#  trusted: "[trusted=yes]"
#- key: repo 2
#  value: "http://www.programmevitam.fr"
#  subtree: "./"
#  trusted: "[trusted=yes]"
#- key: repo 3
#  value: "ftp://centos.org"
#  subtree: "binary"
#  trusted: "[trusted=yes]"

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/<fichier d'inventaire>  --ask-vault-pass

Note

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

4.2.5.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.5.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 ansible-vitam/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 communication d’administration et de service transiteront donc toutes les deux via l’unique interface réseau disponible.

4.2.5.1.4.2. Cas 2: Machines avec plusieurs interfaces réseau¶

Si les machines sur lesquelles Vitam sera déployé disposent de plusieurs interfaces, 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-extra/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.5.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 environments/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.5.1.5. Passage des identifiants des référentiels en mode esclave¶

La génération des identifiants des référentiels est géré par Vitam quand il fonctionne en mode maître.

Par exemple :

Préfixé par PR- pour les profils
Préfixé par IC- pour les contrats d’entrée
Préfixé par AC- pour les contrats d’accès

Si vous souhaitez gérer vous-même les identifiants sur un service référentiel, il faut qu’il soit en mode esclave. Par défaut tous les services référentiels de Vitam fonctionnent en mode maître. Pour désactiver le mode maître de Vitam, il faut modifier le fichier ansible deployment/ansible-vitam/roles/vitam/templates/functional-administration/functional-administration.conf.j2. Un exemple de ce fichier se trouve dans la Documentation d’exploitation au chapitre « Exploitation des composants de la solution logicielle VITAM ».

# ExternalId configuration

listEnableExternalIdentifiers:
 0:
   - INGEST_CONTRACT
   - ACCESS_CONTRACT
 1:
   - INGEST_CONTRACT
   - ACCESS_CONTRACT
   - PROFILE
   - SECURITY_PROFILE
   - CONTEXT

Depuis la version 1.0.4, la configuration par défaut de Vitam autorise des identifiants externes (ceux qui sont dans le fichier json importé).

pour le tenant 0 pour les référentiels : contrat d’entrée et contrat d’accès.

pour le tenant 1 pour les référentiels : contrat d’entrée, contrat d’accès, profil, profil de sécurité et contexte.

La liste des choix possibles, pour chaque tenant, est :

INGEST_CONTRACT : contrats d’entrée

ACCESS_CONTRACT : contrats d’accès

PROFILE : profils SEDA

SECURITY_PROFILE : profils de sécurité (utile seulement sur le tenant d’administration)

CONTEXT : contextes applicatifs (utile seulement sur le tenant d’administration)

ARCHIVEUNITPROFILE : profils d’unités archivistiques

4.2.5.1.6. Durées minimales permettant de contrôler les valeurs saisies¶

Afin de se prémunir contre une alimentation du référentiel des règles de gestion avec des durées trop courtes susceptibles de déclencher des actions indésirables sur la plate-forme (ex. éliminations) – que cette tentative soit intentionnelle ou non –, la solution logicielle VITAM vérifie que l’association de la durée et de l’unité de mesure saisies pour chaque champ est supérieure ou égale à une durée minimale définie lors du paramétrage de la plate-forme, dans un fichier de configuration.

Pour mettre en place le comportement attendu par le métier, il faut modifier le contenu de la directive listMinimumRuleDuration dans le fichier ansible deployment/ansible-vitam/roles/vitam/templates/functional-administration/functional-administration.conf.j2.

Exemple:

listMinimumRuleDuration:
  2:
    AppraisalRule : 1 year
    DisseminationRule : 10 year

  3:
    AppraisaleRule : 5 year
    StorageRule : 5 year
    ReuseRule : 2 year

Par tenant, les directives possibles sont :

AppraisalRule
DisseminationRule
StorageRule
ReuseRule
AccessRule (valeur par défaut : 0 year)
ClassificationRule

Les valeurs associées sont une durée au format <nombre> <unité en angais, au singulier>

Exemples:

month
year
year

Pour plus de détails, se rapporter à la documentation métier « Règles de gestion ».

4.2.5.1.7. Déploiement¶

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 a été effectuée avec succès, le déploiement est à réaliser avec la commande suivante :

ansible-playbook ansible-vitam/vitam.yml -i environments/<ficher d'inventaire> --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é).

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.