4.2.5. Paramétrages supplémentaires

4.2.5.1. Tuning JVM

Prudence

En cas de colocalisation, bien prendre en compte la taille JVM de chaque composant (VITAM : -Xmx512m par défaut) pour éviter de swapper.

Un tuning fin des paramètres JVM de chaque composant VITAM est possible. Pour cela, il faut modifier le contenu du fichier environments/group_vars/all/jvm_opts.yml

Pour chaque composant, il est possible de modifier ces 3 variables:

• memory: paramètres Xms et Xmx
• gc: parmètres gc
• java: autres paramètres java

4.2.5.2. Installation des griffins (greffons de préservation)

Note

Fonctionnalité disponible partir de la R9 (2.1.1) .

Prudence

Cette version de VITAM ne mettant pas encore en oeuvre de mesure d’isolation particulière des griffins, il est recommandé de veiller à ce que l’usage de chaque griffin soit en conformité avec la politique de sécurité de l’entité. Il est en particulier déconseillé d’utiliser un griffon qui utiliserait un outil externe qui n’est plus maintenu.

Il est possible de choisir les griffins installables sur la plate-forme. Pour cela, il faut éditer le contenu du fichier environments/group_vars/all/vitam_vars.yml au niveau de la directive vitam_griffins. Cette action est à rapprocher de l’incorporation des binaires d’installation : les binaires d’installation des greffons doivent être accessibles par les machines hébergeant le composant worker.

Exemple:

vitam_griffins: ["vitam-imagemagick-griffin", "vitam-jhove-griffin"]

Voici la liste des greffons disponibles au moment de la présente publication :

vitam-imagemagick-griffin
vitam-jhove-griffin
vitam-libreoffice-griffin
vitam-odfvalidator-griffin
vitam-siegfried-griffin
vitam-tesseract-griffin
vitam-verapdf-griffin
vitam-ffmpeg-griffin

Avertissement

Ne pas oublier d’avoir déclaré au préalable sur les machines cibles le dépôt de binaires associé aux griffins.

4.2.5.3. Rétention liée aux logback

La solution logicielle VITAM utilise logback pour la rotation des log, ainsi que leur rétention.

Il est possible d’appliquer un paramétrage spécifique pour chaque composant VITAM.

Editer le fichier environments/group_vars/all/vitam_vars.yml (et extra_vars.yml, dans le cas des extra) et appliquer le paramétrage dans le bloc logback_total_size_cap de chaque composant sur lequel appliquer la modification de paramétrage. Pour chaque APPENDER, la valeur associée doit être exprimée en taille et unité (exemple : 14GB ; représente 14 gigabytes).

Note

des appenders supplémentaires existent pour le composant storage-engine (appender offersync) et offer (offer_tape et offer_tape_backup).

4.2.5.3.1. Cas des access_log

Il est également possible d’appliquer un paramétrage différent par composant VITAM sur le logback access.

Editer le fichier environments/group_vars/all/vitam_vars.yml (et extra_vars.yml, dans le cas des extra) et appliquer le paramétrage dans les directives access_retention_days et access_total_size_GB de chaque composant sur lequel appliquer la modification de paramétrage.

4.2.5.4. Paramétrage de l’antivirus (ingest-external)

L’antivirus utilisé par ingest-external est modifiable (par défaut, ClamAV) ; pour cela :

• Modifier le fichier environments/group_vars/all/vitam_vars.yml pour indiquer le nom de l’antivirus qui sera utilisé (norme : scan-<nom indiqué dans vitam_vars.yml>.sh)

• Créer un shell (dont l’extension doit être .sh) sous environments/antivirus/ (norme : scan-<nom indiqué dans vitam_vars.yml>.sh) ; prendre comme modèle le fichier scan-clamav.sh. Ce script shell doit respecter le contrat suivant :

  • Argument : chemin absolu du fichier à analyser

  • Sémantique des codes de retour

    • 0 : Analyse OK - pas de virus
    • 1 : Analyse OK - virus trouvé et corrigé
    • 2 : Analyse OK - virus trouvé mais non corrigé
    • 3 : Analyse NOK

  • Contenu à écrire dans stdout / stderr

    • stdout : Nom des virus trouvés, un par ligne ; Si échec (code 3) : raison de l’échec
    • stderr : Log « brut » de l’antivirus

Prudence

En cas de remplacement de clamAV par un autre antivirus, l’installation de celui-ci devient dès lors un prérequis de l’installation et le script doit être testé.

Avertissement

Sur plate-forme Debian, ClamAV est installé sans base de données. Pour que l’antivirus soit fonctionnel, il est nécessaire, durant l’installation, de le télécharger ; il est donc nécessaire de renseigner dans l’inventaire la directive http_proxy_environnement.

4.2.5.5. Paramétrage des certificats externes (*-externe)

Se reporter au chapitre dédié à la gestion des certificats: Gestion des certificats

4.2.5.6. Placer « hors Vitam » le composant ihm-demo

Sous deployment/environments/host_vars, créer ou éditer un fichier nommé par le nom de machine qui héberge le composant ihm-demo et ajouter le contenu ci-dessous

consul_disabled: true

Il faut également modifier le fichier deployment/environments/group_vars/all/vitam_vars.yml en remplaçant :

• dans le bloc accessexternal, la directive host: "access-external.service.{{ consul_domain }}" par host: "<adresse IP de access-external>" (l’adresse IP peut être une FIP)
• dans le bloc ingestexternal, la directive host: "ingest-external.service.{{ consul_domain }}" par host: "<adresse IP de ingest-external>" (l’adresse IP peut être une FIP)

A l’issue, le déploiement n’installera pas l’agent Consul. Le composant ihm-demo appellera, alors, par l’adresse IP de service les composants « access-external » et « ingest-external ».

Il est également fortement recommandé de positionner la valeur de la directive vitam.ihm_demo.metrics_enabled à false dans le fichier deployment/environments/group_vars/all/vitam_vars.yml, afin que ce composant ne tente pas d’envoyer des données sur « elasticsearch-log ».

4.2.5.7. Paramétrer le secure_cookie pour ihm-demo

Le composant ihm-demo (ainsi qu’ihm-recette) dispose d’une option suplémentaire, par rapport aux autres composants VITAM, dans le fichier deployment/environments/group_vars/all/vitam_vars.yml: le secure_cookie qui permet de renforcer ces deux IHM contre certaines attaques assez répandues comme les CSRF (Cross-Site Request Forgery).

Il faut savoir que si cette variable est à true (valeur par défaut), le client doit obligatoirement se connecter en https sur l”IHM, et ce même si un reverse proxy se trouve entre le serveur web et le client.

Cela peut donc obliger le reverse proxy frontal de la chaine d’accès à écouter en https.

4.2.5.8. Paramétrage de la centralisation des logs VITAM

2 cas sont possibles :

• Utiliser le sous-système de gestion des logs fourni par la solution logicielle VITAM ;
• Utiliser un SIEM tiers.

4.2.5.8.1. Gestion par VITAM

Pour une gestion des logs par VITAM, il est nécessaire de déclarer les serveurs ad-hoc dans le fichier d’inventaire pour les 3 groupes suivants :

• hosts_logstash
• hosts_kibana_log
• hosts_elasticsearch_log

4.2.5.8.2. Redirection des logs sur un SIEM tiers

En configuration par défaut, les logs VITAM sont tout d’abord routés vers un serveur rsyslog installé sur chaque machine. Il est possible d’en modifier le routage, qui par défaut redirige vers le serveur logstash, via le protocole syslog en TCP.

Pour cela, il est nécessaire de placer un fichier de configuration dédié dans le dossier /etc/rsyslog.d/ ; ce fichier sera automatiquement pris en compte par rsyslog. Pour la syntaxe de ce fichier de configuration rsyslog, se référer à la documentation rsyslog.

Astuce

Pour cela, il peut être utile de s’inspirer du fichier de référence VITAM deployment/ansible-vitam/roles/rsyslog/templates/vitam_transport.conf.j2 (attention, il s’agit d’un fichier template ansible, non directement convertible en fichier de configuration sans en ôter les directives jinja2).

4.2.5.9. 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 lorsqu’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

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 :

Description des identifiants de référentiels

Nom du référentiel	Description
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

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/environments/group_vars/all/vitam_vars.yml dans les sections vitam_tenants_usage_external (pour gérer, par tenant, les collections en mode esclave).

4.2.5.10. Paramétrage du batch de calcul pour l’indexation des règles héritées

La paramétrage du batch de calcul pour l’indexation des règles héritées peut être réalisé dans le fichier /group_vars/all/vitam_vars.yml.

La section suivante du fichier vitam_vars.yml permet de paramétrer la fréquence de passage du batch :

vitam_timers:
    metadata:
        - name: vitam-metadata-computed-inherited-rules
          frequency: "*-*-* 02:30:00"

La section suivante du fichier vitam_vars.yml permet de paramétrer la liste des tenants sur lequels s’exécute le batch :

vitam:
  worker:
        # api_output_index_tenants : permet d'indexer les règles de gestion, les chemins des règles et les services producteurs
        api_output_index_tenants: [0,1,2,3,4,5,6,7,8,9]
        # rules_index_tenants : permet d'indexer les règles de gestion
        rules_index_tenants: [0,1,2,3,4,5,6,7,8,9]

4.2.5.11. 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 vitam_tenant_rule_duration dans le fichier ansible deployment/environments/group_vars/all/vitam_vars.yml.

Exemple:

vitam_tenant_rule_duration:
  - name: 2 # applied tenant
    rules:
      - AppraisalRule : "1 year" # rule name : rule value
  - name: 3
    rules:
      AppraisaleRule : "5 year" # rule name : rule value
      StorageRule : "5 year" # rule name : rule value
      ReuseRule : "2 year" # rule name : rule value

Par tenant, les directives possibles sont :

Description des règles

Règle	Valeur par défaut
AppraisalRule
DisseminationRule
StorageRule
ReuseRule
AccessRule	0 year
ClassificationRule

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

Exemples:

6 month
1 year
5 year

Voir aussi

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

4.2.5.12. Fichiers complémentaires

A titre informatif, le positionnement des variables ainsi que des dérivations des déclarations de variables sont effectuées dans les fichiers suivants :

• environments /group_vars/all/vitam_vars.yml, comme suit :

  ---
  ### global ###
  
  # Disable epel or Debian backports repositories install
  disable_internet_repositories_install: false
  
  # TODO MAYBE : permettre la surcharge avec une syntax du genre vitamopts.folder_root | default(vitam_default.folder_root) dans les templates ?
  droid_filename: "DROID_SignatureFile_V95.xml"
  droid_container_filename: "container-signature-20180920.xml"
  
  vitam_defaults:
      folder:
          root_path: /vitam
          folder_permission: "0750"
          conf_permission: "0640"
          folder_upload_permission: "0770"
          script_permission: "0750"
      users:
          vitam: "vitam"
          vitamdb: "vitamdb"
          group: "vitam"
      services:
          # Default log level for vitam components: logback values (TRACE, DEBUG, INFO, WARN, ERROR, OFF)
          log_level: WARN
          start_timeout: 300
          stop_timeout: 3600
          port_service_timeout: 86400
          api_call_timeout: 120
          api_long_call_timeout: 300
          status_retries_number: 60
          status_retries_delay: 5
      # Filter for the vitam package version to install
      # FIXME : commented as has to be removed becuase doesn't work under Debain
      #package_version: "*"
      ### Trust X-SSL-CLIENT-CERT header for external api auth ? (true | false) ###
      vitam_ssl_user_header: true
      ### Force chunk mode : set true if chunk header should be checked
      vitam_force_chunk_mode: false
      # syslog_facility
      syslog_facility: local0
      # Configuration of log for reconstruction services (INFO or DEBUG for active logs). Logs will be present only on secondary site.
      reconstruction:
          log_level: INFO
  
  # Used in ingest, unitary update, mass-update
  classificationList: ["Non protégé","Secret Défense", "Confidentiel Défense"]
  # Used in ingest, unitary update, mass-update
  classificationLevelOptional: true
  # Packages install retries
  packages_install_retries_number: 1
  packages_install_retries_delay: 10
  
  
  vitam_timers:
  # systemd nomenclature
  #    minutely → *-*-* *:*:00
  #    hourly → *-*-* *:00:00
  #    daily → *-*-* 00:00:00
  #    monthly → *-*-01 00:00:00
  #    weekly → Mon *-*-* 00:00:00
  #    yearly → *-01-01 00:00:00
  #    quarterly → *-01,04,07,10-01 00:00:00
  #    semiannually → *-01,07-01 00:00:00
      logbook: # all have to run on only one machine
          # Sécurisation des journaux des opérations
          - name: vitam-traceability-operations
            frequency: "*-*-* 0/2:00:00" # every 2 hours
          # Sécurisation des journaux du cycle de vie des groupes d'objets
          - name: vitam-traceability-lfc-objectgroup
            frequency: "*-*-* 0/4:00:00" # every 4 hours
          # Sécurisation des journaux du cycle de vie des unités archivistiques
          - name: vitam-traceability-lfc-unit
            frequency: "*-*-* 0/3:00:00" # every 3 hours
          # Audit de traçabilité
          - name: vitam-traceability-audit
            frequency: "*-*-* 00:00:00"
          # Reconstruction
          - name: vitam-logbook-reconstruction
            frequency: "*-*-* *:0/5:00"
      storage:
          # Sauvegarde des journaux des écritures
          - name: vitam-storage-accesslog-backup
            frequency: "*-*-* 0/4:00:00" # every 4 hours
          # Sécurisation du journal des écritures
          - name: vitam-storage-log-backup
            frequency: "*-*-* 0/2:00:00" # every 2 hours
          # Log traceability
          - name: vitam-storage-log-traceability
            frequency: "*-*-* 0/2:10:00" # every 2 hours (10 minutes)
      functional_administration:
          - name: vitam-create-accession-register-symbolic
            frequency: "*-*-* 00:00:00"
          - name: vitam-functional-administration-accession-register-reconstruction
            frequency: "*-*-* *:0/5:00"
          - name: vitam-rule-management-audit
            frequency: "*-*-* *:00:00"
          - name: vitam-functional-administration-reconstruction
            frequency: "*-*-* *:0/5:00"
      metadata:
          - name: vitam-metadata-store-graph
            frequency: "*-*-* *:0/30:00"
          - name: vitam-metadata-reconstruction
            frequency: "*-*-* *:0/5:00"
          - name: vitam-metadata-computed-inherited-rules
            frequency: "*-*-* 02:30:00"
          - name: vitam-metadata-purge-dip
            frequency: "*-*-* 02:20:00"
          - name: vitam-metadata-purge-transfers-SIP
            frequency: "*-*-* 02:20:00"
      offer:
        # Compaction offer logs
        - name: vitam-offer-log-compaction
          frequency: "*-*-* *:00:00" # every hour
  
  ### consul ###
  # WARNING: consul_domain should be a supported domain name for your organization
  #          You will have to generate server certificates with the same domain name and the service subdomain name
  #          Example: consul_domain=vitam means you will have to generate some certificates with .service.vitam domain
  #                   access-external.service.vitam, ingest-external.service.vitam, ...
  consul_domain: consul
  consul_component: consul
  consul_folder_conf: "{{ vitam_defaults.folder.root_path }}/conf/{{ consul_component }}"
  
  # Workspace should be useless but storage have a dependency to it...
  # elastic-kibana-interceptor is present as kibana is present, if kibana-data & interceptor are not needed in the secondary site, just do not add them in the hosts file
  vitam_secondary_site_components: [ "logbook" , "metadata" , "functional-administration" , "storage" , "storageofferdefault" , "offer" , "elasticsearch-log" , "elasticsearch-data" , "logstash" , "kibana" , "mongoc" , "mongod" , "mongos", "elastic-kibana-interceptor" , "consul" ]
  
  # Vitams griffins required to launch preservation scenario
  # Example:
  # vitam_griffins: ["vitam-imagemagick-griffin", "vitam-libreoffice-griffin", "vitam-jhove-griffin", "vitam-odfvalidator-griffin", "vitam-siegfried-griffin", "vitam-tesseract-griffin", "vitam-verapdf-griffin", "vitam-ffmpeg-griffin"]
  vitam_griffins: []
  
  ### Composants Vitam ###
  
  vitam:
      # Ontology cache settings (max entries in cache & retention timeout in seconds)
      ontologyCacheMaxEntries: 100
      ontologyCacheTimeoutInSeconds: 300
      # Elasticsearch scroll timeout in milliseconds settings
      elasticSearchScrollTimeoutInMilliseconds: 300000
      accessexternal:
          # Component name: do not modify
          vitam_component: access-external
          # DNS record for the service:
          # Modify if ihm-demo is not using consul (typical production deployment)
          host: "access-external.service.{{ consul_domain }}"
          port_admin: 28102
          port_service: 8444
          baseuri: "access-external"
          https_enabled: true
          # Use platform secret for this component ? : do not modify
          secret_platform: "false"
          # Force the log level for this component: this are logback values (TRACE, DEBUG, INFO, WARN, ERROR, OFF)
          # If this var is not set, the default one will be used (vitam_defaults.services.log_level)
          # log_level: "DEBUG"
          metrics_enabled: true
          logback_rolling_policy: true
          logback_max_file_size: "10MB"
          logback_total_size_cap:
            file:
              history_days: 10
              totalsize: "5GB"
            security:
              history_days: 10
              totalsize: "5GB"
          jvm_log: false
          performance_logger: "false"
          reconstruction:
          consul_check_business: 10 # value in seconds
          consul_admin_check: 10 # value in seconds
          acceptableRequestTime: 10 # value in seconds
          # metricslevel: DEBUG
          # metricsinterval: 3
          # metricsunit: MINUTES
          access_retention_days: 15 # Number of days for file retention
          access_total_size_cap: "14GB" # total acceptable size
      accessinternal:
          vitam_component: access-internal
          host: "access-internal.service.{{ consul_domain }}"
          port_service: 8101
          port_admin: 28101
          baseuri: "access-internal"
          https_enabled: false
          secret_platform: "true"
          # log_level: "DEBUG"
          metrics_enabled: true
          logback_rolling_policy: true
          logback_max_file_size: "10MB"
          logback_total_size_cap:
            file:
              history_days: 10
              totalsize: "5GB"
            security:
              history_days: 10
              totalsize: "5GB"
          jvm_log: false
          performance_logger: "false"
          reconstruction:
          consul_check_business: 10 # value in seconds
          consul_admin_check: 10 # value in seconds
          acceptableRequestTime: 10 # value in seconds
          # metricslevel: DEBUG
          # metricsinterval: 3
          # metricsunit: MINUTES
          access_retention_days: 15 # Number of days for file retention
          access_total_size_cap: "14GB" # total acceptable size
      functional_administration:
          vitam_component: functional-administration
          host: "functional-administration.service.{{ consul_domain }}"
          port_service: 8004
          port_admin: 18004
          baseuri: "adminmanagement"
          https_enabled: false
          secret_platform: "true"
          cluster_name: "{{ elasticsearch.data.cluster_name }}"
          # log_level: "DEBUG"
          metrics_enabled: true
          logback_rolling_policy: true
          logback_max_file_size: "10MB"
          logback_total_size_cap:
            file:
              history_days: 10
              totalsize: "5GB"
            security:
              history_days: 10
              totalsize: "5GB"
          jvm_log: false
          performance_logger: "false"
          reconstruction:
          consul_check_business: 10 # value in seconds
          consul_admin_check: 10 # value in seconds
          acceptableRequestTime: 10 # value in seconds
          # metricslevel: DEBUG
          # metricsinterval: 3
          # metricsunit: MINUTES
          access_retention_days: 15 # Number of days for file retention
          access_total_size_cap: "14GB" # total acceptable size
      elastickibanainterceptor:
          vitam_component: elastic-kibana-interceptor
          host: "elastic-kibana-interceptor.service.{{ consul_domain }}"
          port_service: 8014
          port_admin: 18014
          baseuri: ""
          https_enabled: false
          secret_platform: "false"
          cluster_name: "{{ elasticsearch.data.cluster_name }}"
          # log_level: "DEBUG"
          metrics_enabled: true
          logback_rolling_policy: true
          logback_max_file_size: "10MB"
          logback_total_size_cap:
            file:
              history_days: 10
              totalsize: "5GB"
            security:
              history_days: 10
              totalsize: "5GB"
          jvm_log: false
          performance_logger: "false"
          reconstruction:
          consul_check_business: 10 # value in seconds
          consul_admin_check: 10 # value in seconds
          acceptableRequestTime: 10 # value in seconds
          # metricslevel: DEBUG
          # metricsinterval: 3
          # metricsunit: MINUTES
          access_retention_days: 15 # Number of days for file retention
          access_total_size_cap: "14GB" # total acceptable size
      batchreport:
          vitam_component: batch-report
          host: "batch-report.service.{{ consul_domain }}"
          port_service: 8015
          port_admin: 18015
          baseuri: "batchreport"
          https_enabled: false
          secret_platform: "false"
          # log_level: "DEBUG"
          metrics_enabled: true
          logback_rolling_policy: true
          logback_max_file_size: "10MB"
          logback_total_size_cap:
            file:
              history_days: 10
              totalsize: "5GB"
            security:
              history_days: 10
              totalsize: "5GB"
          jvm_log: false
          performance_logger: "false"
          reconstruction:
          consul_check_business: 10 # value in seconds
          consul_admin_check: 10 # value in seconds
          acceptableRequestTime: 10 # value in seconds
          # metricslevel: DEBUG
          # metricsinterval: 3
          # metricsunit: MINUTES
          access_retention_days: 15 # Number of days for file retention
          access_total_size_cap: "14GB" # total acceptable size
      ingestexternal:
          vitam_component: ingest-external
          # DNS record for the service:
          # Modify if ihm-demo is not using consul (typical production deployment)
          host: "ingest-external.service.{{ consul_domain }}"
          port_admin: 28001
          port_service: 8443
          baseuri: "ingest-external"
          https_enabled: true
          secret_platform: "false"
          antivirus: "clamav"
          # uncomment if huge files need to be analyzed in more than 60s (default behavior)
          #scantimeout: 60000 # value in milliseconds
          # Directory where files should be placed for local ingest
          upload_dir: "/vitam/data/ingest-external/upload"
          # Directory where successful ingested files will be moved to
          success_dir: "/vitam/data/ingest-external/upload/success"
          # Directory where failed ingested files will be moved to
          fail_dir: "/vitam/data/ingest-external/upload/failure"
          # Action done to file after local ingest (see below for further information)
          upload_final_action: "MOVE"
          # log_level: "DEBUG"
          # upload_final_action can be set to three different values (lower or upper case does not matter)
          #   MOVE : After upload, the local file will be moved to either success_dir or fail_dir depending on the status of the ingest towards ingest-internal
          #   DELETE : After upload, the local file will be deleted if the upload succeeded
          #   NONE : After upload, nothing will be done to the local file (default option set if the value entered for upload_final_action does not exist)
          metrics_enabled: true
          logback_rolling_policy: true
          logback_max_file_size: "10MB"
          logback_total_size_cap:
            file:
              history_days: 10
              totalsize: "5GB"
            security:
              history_days: 10
              totalsize: "5GB"
          jvm_log: false
          performance_logger: "false"
          reconstruction:
          consul_check_business: 10 # value in seconds
          consul_admin_check: 10 # value in seconds
          acceptableRequestTime: 10 # value in seconds
          # metricslevel: DEBUG
          # metricsinterval: 3
          # metricsunit: MINUTES
          access_retention_days: 15 # Number of days for file retention
          access_total_size_cap: "14GB" # total acceptable size
      ingestinternal:
          vitam_component: ingest-internal
          host: "ingest-internal.service.{{ consul_domain }}"
          port_service: 8100
          port_admin: 28100
          baseuri: "ingest"
          https_enabled: false
          secret_platform: "true"
          # log_level: "DEBUG"
          metrics_enabled: true
          logback_rolling_policy: true
          logback_max_file_size: "10MB"
          logback_total_size_cap:
            file:
              history_days: 10
              totalsize: "5GB"
            security:
              history_days: 10
              totalsize: "5GB"
          jvm_log: false
          performance_logger: "false"
          reconstruction:
          consul_check_business: 10 # value in seconds
          consul_admin_check: 10 # value in seconds
          acceptableRequestTime: 10 # value in seconds
          # metricslevel: DEBUG
          # metricsinterval: 3
          # metricsunit: MINUTES
          access_retention_days: 15 # Number of days for file retention
          access_total_size_cap: "14GB" # total acceptable size
      ihm_demo:
          vitam_component: ihm-demo
          host: "ihm-demo.service.{{ consul_domain }}"
          port_service: 8446
          port_admin: 28002
          baseurl: "/ihm-demo"
          static_content: "{{ vitam_defaults.folder.root_path }}/app/ihm-demo/v2"
          baseuri: "ihm-demo"
          https_enabled: true
          secret_platform: "false"
          # User session timeout in milliseconds (for shiro)
          session_timeout: 1800000
          secure_cookie: true
          # Specify here the realms you want to use for authentication in ihm-demo
          # You can set multiple realms, one per line
          # With multiple realms, the user will be able to choose between the allowed realms
          # Example: authentication_realms:
          #               - x509Realm
          #               - ldapRealm
          # Authorized values:
          # x509Realm: certificate
          # iniRealm: ini file
          # ldapRealm: ldap
          authentication_realms:
              # - x509Realm
              - iniRealm
              # - ldapRealm
          # log_level: "DEBUG"
          allowedMediaTypes:
              - type: "application"
                subtype: "pdf"
              - type: "text"
                subtype: "plain"
              - type: "image"
                subtype: "jpeg"
              - type: "image"
                subtype: "tiff"
          metrics_enabled: true
          logback_rolling_policy: true
          logback_max_file_size: "10MB"
          logback_total_size_cap:
            file:
              history_days: 10
              totalsize: "5GB"
            security:
              history_days: 10
              totalsize: "5GB"
          jvm_log: false
          performance_logger: "false"
          reconstruction:
          consul_check_business: 10 # value in seconds
          consul_admin_check: 10 # value in seconds
          acceptableRequestTime: 10 # value in seconds
          # metricslevel: DEBUG
          # metricsinterval: 3
          # metricsunit: MINUTES
          access_retention_days: 15 # Number of days for file retention
          access_total_size_cap: "14GB" # total acceptable size
      logbook:
          vitam_component: logbook
          host: "logbook.service.{{ consul_domain }}"
          port_service: 9002
          port_admin: 29002
          baseuri: "logbook"
          https_enabled: false
          secret_platform: "true"
          cluster_name: "{{ elasticsearch.data.cluster_name }}"
          # Temporization delay (in seconds) for recent logbook operation events.
          # Set it to a reasonable delay to cover max clock difference across servers + VM/GC pauses
          operationTraceabilityTemporizationDelay: 300
          # Max delay between 2 logbook operation traceability operations.
          # A new logbook operation traceability is generated after this delay, even if tenant has no
          # new logbook operations to secure
          # Unit can be in DAYS, HOURS, MINUTES, SECONDS
          # Hint: Set it to 690 MINUTES (11 hours and 30 minutes) to force new traceability after +/- 12 hours (supposing
          # logbook operation traceability timer run every hour +/- some clock delays)
          operationTraceabilityMaxRenewalDelay: 690
          operationTraceabilityMaxRenewalDelayUnit: MINUTES
          # Temporization delay (in seconds) for recent logbook lifecycle events.
          # Set it to a reasonable delay to cover max clock difference across servers + VM/GC pauses
          lifecycleTraceabilityTemporizationDelay: 300
          # Max entries selected per (Unit or Object Group) LFC traceability operation
          lifecycleTraceabilityMaxEntries: 100000
          # log_level: "DEBUG"
          metrics_enabled: true
          logback_rolling_policy: true
          logback_max_file_size: "10MB"
          logback_total_size_cap:
            file:
              history_days: 10
              totalsize: "5GB"
            security:
              history_days: 10
              totalsize: "5GB"
          jvm_log: false
          performance_logger: "false"
          reconstruction:
          consul_check_business: 10 # value in seconds
          consul_admin_check: 10 # value in seconds
          acceptableRequestTime: 10 # value in seconds
          # metricslevel: DEBUG
          # metricsinterval: 3
          # metricsunit: MINUTES
          access_retention_days: 15 # Number of days for file retention
          access_total_size_cap: "14GB" # total acceptable size
      metadata:
          vitam_component: metadata
          host: "metadata.service.{{ consul_domain }}"
          port_service: 8200
          port_admin: 28200
          baseuri: "metadata"
          https_enabled: false
          secret_platform: "true"
          cluster_name: "{{ elasticsearch.data.cluster_name }}"
          # log_level: "DEBUG"
          metrics_enabled: true
          logback_rolling_policy: true
          logback_max_file_size: "10MB"
          logback_total_size_cap:
            file:
              history_days: 10
              totalsize: "5GB"
            security:
              history_days: 10
              totalsize: "5GB"
          jvm_log: false
          performance_logger: "false"
          reconstruction:
          consul_check_business: 10 # value in seconds
          consul_admin_check: 10 # value in seconds
          # Archive Unit Profile cache settings (max entries in cache & retention timeout in seconds)
          archiveUnitProfileCacheMaxEntries: 100
          archiveUnitProfileCacheTimeoutInSeconds: 300
          # Schema validator cache settings (max entries in cache & retention timeout in seconds)
          schemaValidatorCacheMaxEntries: 100
          schemaValidatorCacheTimeoutInSeconds: 300
          acceptableRequestTime: 10 # value in seconds
          # DIP cleanup delay (in minutes)
          dipTimeToLiveInMinutes: 10080 # 7 days
          transfersSIPTimeToLiveInMinutes: 10080 # 7 days
          # metricslevel: DEBUG
          # metricsinterval: 3
          # metricsunit: MINUTES
          access_retention_days: 15 # Number of days for file retention
          access_total_size_cap: "14GB" # total acceptable size
          elasticsearch_mapping_dir: "{{ vitam_defaults.folder.root_path }}/conf/metadata/mapping" # Directory of elasticsearch metadata mapping
      processing:
          vitam_component: processing
          host: "processing.service.{{ consul_domain }}"
          port_service: 8203
          port_admin: 28203
          baseuri: "processing"
          https_enabled: false
          secret_platform: "true"
          # log_level: "DEBUG"
          metrics_enabled: true
          logback_rolling_policy: true
          logback_max_file_size: "10MB"
          logback_total_size_cap:
            file:
              history_days: 10
              totalsize: "5GB"
            security:
              history_days: 10
              totalsize: "5GB"
          jvm_log: false
          performance_logger: "false"
          maxDistributionInMemoryBufferSize: 100000
          maxDistributionOnDiskBufferSize: 100000000
          reconstruction:
          consul_check_business: 10 # value in seconds
          consul_admin_check: 10 # value in seconds
          acceptableRequestTime: 10 # value in seconds
          # metricslevel: DEBUG
          # metricsinterval: 3
          # metricsunit: MINUTES
          access_retention_days: 15 # Number of days for file retention
          access_total_size_cap: "14GB" # total acceptable size
      security_internal:
          vitam_component: security-internal
          host: "security-internal.service.{{ consul_domain }}"
          port_service: 8005
          port_admin: 28005
          baseuri: "security-internal"
          https_enabled: false
          secret_platform: "true"
          # log_level: "DEBUG"
          metrics_enabled: true
          logback_rolling_policy: true
          logback_max_file_size: "10MB"
          logback_total_size_cap:
            file:
              history_days: 10
              totalsize: "5GB"
            security:
              history_days: 10
              totalsize: "5GB"
          jvm_log: false
          performance_logger: "false"
          reconstruction:
          consul_check_business: 10 # value in seconds
          consul_admin_check: 10 # value in seconds
          acceptableRequestTime: 10 # value in seconds
          # metricslevel: DEBUG
          # metricsinterval: 3
          # metricsunit: MINUTES
          access_retention_days: 15 # Number of days for file retention
          access_total_size_cap: "14GB" # total acceptable size
      storageengine:
          vitam_component: storage
          host: "storage.service.{{ consul_domain }}"
          port_service: 9102
          port_admin: 29102
          baseuri: "storage"
          https_enabled: false
          secret_platform: "true"
          storageTraceabilityOverlapDelay: 300
          restoreBulkSize: 1000
          # batch thread pool size
          minBatchThreadPoolSize: 4
          maxBatchThreadPoolSize: 32
          # Digest computation timeout in seconds
          batchDigestComputationTimeout: 300
          # Offer synchronization batch size & thread pool size
          offerSynchronizationBulkSize: 1000
          # Retries attempts
          offerSyncNumberOfRetries: 3
          offerSyncFirstAttemptWaitingTime: 15
          offerSyncWaitingTime: 30
          offerSyncThreadPoolSize: 32
          # log_level: "DEBUG"
          metrics_enabled: true
          logback_rolling_policy: true
          logback_max_file_size: "10MB"
          logback_total_size_cap:
            file:
              history_days: 10
              totalsize: "5GB"
            security:
              history_days: 10
              totalsize: "5GB"
            offersync:
              history_days: 10
              totalsize: "5GB"
            offerdiff:
              history_days: 10
              totalsize: "5GB"
          jvm_log: false
          # unit time per kB (in ms) used while calculating the timeout of an http request between storage and offer (if the calculated result is less than 60s, this time is used)
          timeoutMsPerKB: 100
          performance_logger: "false"
          reconstruction:
          consul_check_business: 10 # value in seconds
          consul_admin_check: 10 # value in seconds
          acceptableRequestTime: 60 # value in seconds
          # metricslevel: DEBUG
          # metricsinterval: 3
          # metricsunit: MINUTES
          access_retention_days: 15 # Number of days for file retention
          access_total_size_cap: "14GB" # total acceptable size
      storageofferdefault:
          vitam_component: "offer"
          port_service: 9900
          port_admin: 29900
          baseuri: "offer"
          https_enabled: false
          secret_platform: "true"
          # log_level: "DEBUG"
          metrics_enabled: true
          logback_rolling_policy: true
          logback_max_file_size: "10MB"
          logback_total_size_cap:
            file:
              history_days: 10
              totalsize: "5GB"
            security:
              history_days: 10
              totalsize: "5GB"
            offer_tape:
              history_days: 10
              totalsize: "5GB"
            offer_tape_backup:
              history_days: 10
              totalsize: "5GB"
          jvm_log: false
          performance_logger: "false"
          reconstruction:
          consul_check_business: 10 # value in seconds
          consul_admin_check: 10 # value in seconds
          acceptableRequestTime: 60 # value in seconds
          # metricslevel: DEBUG
          # metricsinterval: 3
          # metricsunit: MINUTES
          access_retention_days: 15 # Number of days for file retention
          access_total_size_cap: "14GB" # total acceptable size
      worker:
          vitam_component: worker
          host: "worker.service.{{ consul_domain }}"
          port_service: 9104
          port_admin: 29104
          baseuri: "worker"
          https_enabled: false
          secret_platform: "true"
          # log_level: "DEBUG"
          metrics_enabled: true
          logback_rolling_policy: true
          logback_max_file_size: "10MB"
          logback_total_size_cap:
            file:
              history_days: 10
              totalsize: "5GB"
            security:
              history_days: 10
              totalsize: "5GB"
          jvm_log: false
          performance_logger: "false"
          reconstruction:
          consul_check_business: 10 # value in seconds
          consul_admin_check: 10 # value in seconds
          acceptableRequestTime: 60 # value in seconds
          api_output_index_tenants: [0,1,2,3,4,5,6,7,8,9]
          rules_index_tenants: [0,1,2,3,4,5,6,7,8,9]
          # Archive Unit Profile cache settings (max entries in cache & retention timeout in seconds)
          archiveUnitProfileCacheMaxEntries: 100
          archiveUnitProfileCacheTimeoutInSeconds: 300
          # Schema validator cache settings (max entries in cache & retention timeout in seconds)
          schemaValidatorCacheMaxEntries: 100
          schemaValidatorCacheTimeoutInSeconds: 300
          # metricslevel: DEBUG
          # metricsinterval: 3
          # metricsunit: MINUTES
          access_retention_days: 15 # Number of days for file retention
          access_total_size_cap: "14GB" # total acceptable size
      workspace:
          vitam_component: workspace
          host: "workspace.service.{{ consul_domain }}"
          port_service: 8201
          port_admin: 28201
          baseuri: "workspace"
          https_enabled: false
          secret_platform: "true"
          # log_level: "DEBUG"
          metrics_enabled: true
          logback_rolling_policy: true
          logback_max_file_size: "10MB"
          logback_total_size_cap:
            file:
              history_days: 10
              totalsize: "5GB"
            security:
              history_days: 10
              totalsize: "5GB"
          jvm_log: false
          performance_logger: "false"
          reconstruction:
          consul_check_business: 10 # value in seconds
          consul_admin_check: 10 # value in seconds
          acceptableRequestTime: 10 # value in seconds
          # metricslevel: DEBUG
          # metricsinterval: 3
          # metricsunit: MINUTES
          access_retention_days: 15 # Number of days for file retention
          access_total_size_cap: "14GB" # total acceptable size
  
  # for functional-administration, manage master/slave tenant configuration
  vitam_tenants_usage_external:
    - name: 0
      identifiers:
          - INGEST_CONTRACT
          - ACCESS_CONTRACT
          - MANAGEMENT_CONTRACT
          - ARCHIVE_UNIT_PROFILE
    - name: 1
      identifiers:
        - INGEST_CONTRACT
        - ACCESS_CONTRACT
        - MANAGEMENT_CONTRACT
        - PROFILE
        - SECURITY_PROFILE
        - CONTEXT
  
  vitam_tenant_rule_duration:
    - name: 2 # applied tenant
      rules:
        - AppraisalRule : "1 year" # rule name : rule value
  
  # If you want to deploy vitam in a single VM, add the vm name in this array
  single_vm_hostnames: ['localhost']
  

Note

Cas du composant ingest-external. Les directives upload_dir, success_dir, fail_dir et upload_final_action permettent de prendre en charge (ingest) des fichiers déposés dans upload_dir et appliquer une règle upload_final_action à l’issue du traitement (NONE, DELETE ou MOVE dans success_dir ou fail_dir selon le cas). Se référer au DEX pour de plus amples détails. Se référer au manuel de développement pour plus de détails sur l’appel à ce cas.

Avertissement

Selon les informations apportées par le métier, redéfinir les valeurs associées dans les directives classificationList et classificationLevelOptional. Cela permet de définir quels niveaux de protection du secret de la défense nationale, supporte l’instance. Attention : une instance de niveau supérieur doit toujours supporter les niveaux inférieurs.

• environments /group_vars/all/cots_vars.yml, comme suit :

  ---
  
  consul:
      retry_interval: 10 # in seconds
      check_internal: 10 # in seconds
      check_timeout: 5 # in seconds
      network: "ip_admin" # Which network to use for consul communications ? ip_admin or ip_service ?
  
  consul_remote_sites:
      # wan contains the wan addresses of the consul server instances of the external vitam sites
      # Exemple, if our local dc is dc1, we will need to set dc2 & dc3 wan conf:
      # - dc2:
      #   wan: ["10.10.10.10","1.1.1.1"]
      # - dc3:
      #   wan: ["10.10.10.11","1.1.1.1"]
  # Please uncomment and fill values if you want to connect VITAM to external SIEM
  # external_siem:
  #     host:
  #     port:
  
  elasticsearch:
      log:
          host: "elasticsearch-log.service.{{ consul_domain }}"
          port_http: "9201"
          groupe: "log"
          baseuri: "elasticsearch-log"
          cluster_name: "elasticsearch-log"
          consul_check_http: 10 # in seconds
          consul_check_tcp: 10 # in seconds
          action_log_level: error
          https_enabled: false
          indices_fielddata_cache_size: '30%' # related to https://www.elastic.co/guide/en/elasticsearch/reference/7.6/modules-fielddata.html
          indices_breaker_fielddata_limit: '40%' # related to https://www.elastic.co/guide/en/elasticsearch/reference/7.6/circuit-breaker.html#fielddata-circuit-breaker
          dynamic_timeout: 30s
          # default index template
          index_templates:
              default:
                  shards: 1
                  replica: 1
              packetbeat:
                  shards: 5
          log_appenders:
              root:
                  log_level: "info"
              rolling:
                  max_log_file_size: "100MB"
                  max_total_log_size: "5GB"
                  max_files: "50"
              deprecation_rolling:
                  max_log_file_size: "100MB"
                  max_total_log_size: "1GB"
                  max_files: "10"
                  log_level: "warn"
              index_search_slowlog_rolling:
                  max_log_file_size: "100MB"
                  max_total_log_size: "1GB"
                  max_files: "10"
                  log_level: "warn"
              index_indexing_slowlog_rolling:
                  max_log_file_size: "100MB"
                  max_total_log_size: "1GB"
                  max_files: "10"
                  log_level: "warn"
          # By default, is commented. Should be uncommented if ansible computes badly vCPUs number ;  values are associated vCPUs numbers ; please adapt to your configuration
          # thread_pool:
          #     index:
          #         size: 2
          #     get:
          #         size: 2
          #     search:
          #         size: 2
          #     write:
          #         size: 2
          #     warmer:
          #         max: 2
      data:
          host: "elasticsearch-data.service.{{ consul_domain }}"
          # default is 0.1 (10%) and should be quite enough in most cases
          #index_buffer_size_ratio: "0.15"
          port_http: "9200"
          groupe: "data"
          baseuri: "elasticsearch-data"
          cluster_name: "elasticsearch-data"
          consul_check_http: 10 # in seconds
          consul_check_tcp: 10 # in seconds
          action_log_level: debug
          https_enabled: false
          # discovery_zen_minimum_master_nodes: 2 # comented by default ; by default, value is half the length of ansible associated group whose racks have the same number of machine. If it is not the case, this value have to be set with the smallest rack (if using param is_balancing). ONLY EXISTS FOR DATA CLUSTER !!!! DO NOT FORGET TO APPLY PARAMETER WITH REPLICA NUMBER !!!!
          indices_fielddata_cache_size: '30%' # related to https://www.elastic.co/guide/en/elasticsearch/reference/6.5/modules-fielddata.html
          indices_breaker_fielddata_limit: '40%' # related to https://www.elastic.co/guide/en/elasticsearch/reference/6.5/circuit-breaker.html#fielddata-circuit-breaker
          dynamic_timeout: 30s
          # default index template
          index_templates:
              default:
                  shards: 10
                  replica: 2
          log_appenders:
              root:
                  log_level: "info"
              rolling:
                  max_log_file_size: "100MB"
                  max_total_log_size: "5GB"
                  max_files: "50"
              deprecation_rolling:
                  max_log_file_size: "100MB"
                  max_total_log_size: "5GB"
                  max_files: "50"
                  log_level: "warn"
              index_search_slowlog_rolling:
                  max_log_file_size: "100MB"
                  max_total_log_size: "5GB"
                  max_files: "50"
                  log_level: "warn"
              index_indexing_slowlog_rolling:
                  max_log_file_size: "100MB"
                  max_total_log_size: "5GB"
                  max_files: "50"
                  log_level: "warn"
          # By default, is commented. Should be uncommented if ansible computes badly vCPUs number ;  values are associated vCPUs numbers ; please adapt to your configuration
          # thread_pool:
          #     index:
          #         size: 2
          #     get:
          #         size: 2
          #     search:
          #         size: 2
          #     write:
          #         size: 2
          #     warmer:
          #         max: 2
  
  mongodb:
      mongos_port: 27017
      mongoc_port: 27018
      mongod_port: 27019
      mongo_authentication: "true"
      host: "mongos.service.{{ consul_domain }}"
      check_consul: 10 # in seconds
      drop_info_log: false # Drop mongo (I)nformational log, for Verbosity Level of 0
  
  logstash:
      host: "logstash.service.{{ consul_domain }}"
      user: logstash
      port: 10514
      rest_port: 20514
      check_consul: 10 # in seconds
      # logstash xms & xmx in Megabytes
      # jvm_xms: 2048
      # jvm_xmx: 2048
      # workers_number: 4
      log_appenders:
          rolling:
              max_log_file_size: "100MB"
              max_total_log_size: "5GB"
          json_rolling:
              max_log_file_size: "100MB"
              max_total_log_size: "5GB"
  
  # Prometheus params
  prometheus:
      metrics_path: /admin/v1/metrics
      check_consul: 10 # in seconds
      prometheus_config_file_target_directory: # Set path where "prometheus.yml" file will be generated. Example: /tmp/
      server:
          enabled: false
          port: 19090
      node_exporter:
          enabled: true
          port: 19100
          metrics_path: /metrics
      alertmanager:
          enabled: false
          api_port: 19093
          cluster_port: 19094
  grafana:
      enabled: false
      check_consul: 10 # in seconds
      http_port: 13000
  
  # Curator units: days
  curator:
      log:
          metrics:
              close: 5
              delete: 30
          logstash:
              close: 5
              delete: 30
          metricbeat:
              close: 5
              delete: 30
          packetbeat:
              close: 5
              delete: 30
  
  kibana:
      header_value: "reporting"
      import_delay: 10
      import_retries: 10
      log:
          baseuri: "kibana_log"
          api_call_timeout: 120
          groupe: "log"
          port: 5601
          default_index_pattern: "logstash-vitam*"
          check_consul: 10 # in seconds
          # default shards & replica
          shards: 5
          replica: 1
          # pour index logstash-*
          metrics:
              shards: 5
              replica: 1
          # pour index metrics-vitam-*
          logs:
              shards: 5
              replica: 1
          # pour index metricbeat-*
          metricbeat:
              shards: 5 # must be a factor of 30
              replica: 1
      data:
          baseuri: "kibana_data"
          # OMA : bugdette : api_call_timeout is used for retries ; should ceate a separate variable rather than this one
          api_call_timeout: 120
          groupe: "data"
          port: 5601
          default_index_pattern: "logbookoperation_*"
          check_consul: 10 # in seconds
          # index template for .kibana
          shards: 1
          replica: 1
  
  syslog:
      # value can be syslog-ng or rsyslog
      name: "rsyslog"
  
  cerebro:
      baseuri: "cerebro"
      port: 9000
      check_consul: 10 # in seconds
  
  siegfried:
      port: 19000
      consul_check: 10 # in seconds
  
  clamav:
      port: 3310
      # frequency freshclam for database update per day (from 0 to 24 - 24 meaning hourly check)
      db_update_periodicity: 1
  
  mongo_express:
      baseuri: "mongo-express"
  
  ldap_authentification:
      ldap_protocol: "ldap"
      ldap_server: "{% if groups['ldap']|length > 0 %}{{ groups['ldap']|first }}{% endif %}"
      ldap_port: "389"
      ldap_base: "dc=programmevitam,dc=fr"
      ldap_login: "cn=Manager,dc=programmevitam,dc=fr"
      uid_field: "uid"
      ldap_userDn_Template: "uid={0},ou=people,dc=programmevitam,dc=fr"
      ldap_group_request: "(&(objectClass=groupOfNames)(member={0}))"
      ldap_admin_group: "cn=admin,ou=groups,dc=programmevitam, dc=fr"
      ldap_user_group: "cn=user,ou=groups,dc=programmevitam, dc=fr"
      ldap_guest_group: "cn=guest,ou=groups,dc=programmevitam, dc=fr"
  
  java_prerequisites:
      debian: "openjdk-11-jre-headless"
      redhat: "java-11-openjdk-headless"
  

Note

Installation multi-sites. Déclarer dans consul_remote_sites les datacenters Consul des autres site ; se référer à l’exemple fourni pour renseigner les informations.

Note

Concernant Curator, en environnement de production, il est recommandé de procéder à la fermeture des index au bout d’une semaine pour les index de type « logstash » ( 3 jours pour les index « metrics »), qui sont le reflet des traces applicatives des composants de la solution logicielle VITAM. Il est alors recommandé de lancer le delete de ces index au bout de la durée minimale de rétention : 1 an (il n’y a pas de durée de rétention minimale légale sur les index « metrics », qui ont plus une vocation technique et, éventuellement, d’investigations).

• environments /group_vars/all/jvm_vars.yml, comme suit :

  ---
  
  vitam:
      accessinternal:
          jvm_opts:
              # memory: "-Xms512m -Xmx512m"
              # gc: ""
              # java: ""
      accessexternal:
          jvm_opts:
              # memory: "-Xms512m -Xmx512m"
              # gc: ""
              # java: ""
      elastickibanainterceptor:
          jvm_opts:
              # memory: "-Xms512m -Xmx512m"
              # gc: ""
              # java: ""
      batchreport:
            jvm_opts:
                # memory: "-Xms512m -Xmx512m"
                # gc: ""
                # java: ""
      ingestinternal:
          jvm_opts:
              # memory: "-Xms512m -Xmx512m"
              # gc: ""
              # java: ""
      ingestexternal:
          jvm_opts:
              # memory: "-Xms512m -Xmx512m"
              # gc: ""
              # java: ""
      metadata:
          jvm_opts:
              # memory: "-Xms512m -Xmx512m"
              # gc: ""
              # java: ""
      ihm_demo:
          jvm_opts:
              # memory: "-Xms512m -Xmx512m"
              # gc: ""
              # java: ""
      ihm_recette:
          jvm_opts:
              # memory: "-Xms512m -Xmx512m"
              # gc: ""
              # java: ""
      logbook:
          jvm_opts:
              # memory: "-Xms512m -Xmx512m"
              # gc: ""
              # java: ""
      workspace:
          jvm_opts:
              # memory: "-Xms512m -Xmx512m"
              # gc: ""
              # java: ""
      processing:
          jvm_opts:
              # memory: "-Xms512m -Xmx512m"
              # gc: ""
              # java: ""
      worker:
          jvm_opts:
              # memory: "-Xms512m -Xmx512m"
              # gc: ""
              # java: ""
      storageengine:
          jvm_opts:
              # memory: "-Xms512m -Xmx512m"
              # gc: ""
              # java: ""
      storageofferdefault:
          jvm_opts:
              # memory: "-Xms512m -Xmx512m"
              # gc: ""
              # java: ""
      functional_administration:
          jvm_opts:
              # memory: "-Xms512m -Xmx512m"
              # gc: ""
              # java: ""
      security_internal:
          jvm_opts:
              # memory: "-Xms512m -Xmx512m"
              # gc: ""
              # java: ""
      library:
          jvm_opts:
              memory: "-Xms32m -Xmx128m"
              # gc: ""
              # java: ""
  

Note

Cette configuration est appliquée à la solution logicielle VITAM ; il est possible de créer un tuning par « groupe » défini dans ansible.

4.2.5.13. Paramétrage de l’Offre Froide ( librairies de cartouches )

Suite à l’introduction des offres bandes, plusieurs notions supplémentaires sont prises en compte dans ce fichier. De nouvelles entrées ont été ajoutées pour décrire d’une part le matériel robotique assigné à l’offre froide, et les répertoires d’échanges temporaires d’autre part. Les élements de configuration doivent être renseignés par l’exploitant.

• Lecture asynchrone

Un paramètre a été ajouté aux définitions de statégie. AsyncRead permet de déterminer si l’offre associée fonctionne en lecture asynchrone, et désactive toute possibilité de lecture directe sur l’offre. Une offre froide « offer-tape » doit être configurée en lecture asynchrone. La valeur par défaut pour asyncRead est False.

Exemple:

vitam_strategy:
  - name: offer-tape-1
    referent: false
    asyncRead: **true**
  - name: offer-fs-2
    referent: true
    asyncRead: false

• Périphériques liés à l’usage des bandes magnétiques

Terminologie:

• tapeLibrary une librairie de bande dans son ensemble. Une tapeLibrary est constituée de 1 à n « robot » et de 1 à n « drives ». Une offre froide nécessite la déclaration d’au moins une librairie pour fonctionner. L’exploitant doit déclarer un identifiant pour chaque librairie. Ex: TAPE_LIB_1
• drive un drive est un lecteur de cartouches. Il doit être identifié par un path scsi unique. Une offre froide nécessite la déclaration d’au moins un lecteur pour fonctionner.

Note

il existe plusieurs fichiers périphériques sur Linux pour un même lecteur

Les plus classiques sont par exemple /dev/st0 et /dev/nst0 pour le premier drive détecté par le système. L’usage de /dev/st0 indique au système que la bande utilisée dans le lecteur associé devra être rembobinée après l’exécution de la commande appelante. A contrario, /dev/nst0 indique au système que la bande utilisée dans le lecteur associé devra rester positionnée après le dernier marqueur de fichier utilisé par l’exécution de la commande appelante.

Important

Pour que l’offre froide fonctionne correctement, il convient de configurer une version /dev/nstxx

Note

Il peut arriver sur certains systèmes que l’ordre des lecteurs de bandes varient après un reboot de la machine. Pour s’assurer la persistence de l’ordre des lecteurs dans la configuration VITAM, il est conseillé d’utiliser les fichiers périphériques présents dans /dev/tape/by-id/ qui s’appuient sur des références au hardware pour définir les drives.

• robot un robot est le composant chargé de procéder au déplacement des cartouches dans une tapeLibrary, et de procéder à l’inventaire de ses ressources. Une offre froide nécessite la déclaration d’au moins un robot pour fonctionner. L’exploitant doit déclarer un fichier de périphérique scsi générique ( ex: /dev/sg4 ) associé à la robotique sur son système. A l’instar de la configuration des drives, il est recommandé d’utiliser le device présent dans /dev/tape/by-id pour déclarer les robots.

Définition d’une offre froide:

Une offre froide (OF) doit être définie dans la rubrique « vitam_offers » avec un provider de type tape-library

Exemple:

vitam_offers:
  offer-tape-1:
    provider: tape-library
    tapeLibraryConfiguration:

.

La description « tapeLibraryConfiguration » débute par la définition des répertoires de sockage ainsi que le paramétrage des tar.

inputFileStorageFolder Répertoire où seront stockés les objets à intégrer à l’OF inputTarStorageFolder Répertoire où seront générés et stockés les tars avant transfert sur bandes outputTarStorageFolder Répertoire où seront rapatriés les tars depuis les bandes. MaxTarEntrySize Taille maximale au-delà de la laquelle les fichiers entrant seront découpés en segment, en octets maxTarFileSize Taille maximale des tars à constituer, en octets. forceOverrideNonEmptyCartridge Permet de passer outre le contrôle vérifiant que les bandes nouvellement introduites sont vides. Par défaut à false useSudo Réservé à un usage futur – laisser à false.

Note

N.B.: MaxTarEntrySize doit être strictement inférieur à maxTarFileSize

Exemple:

inputFileStorageFolder: "/vitam/data/offer/offer/inputFiles"
inputTarStorageFolder: "/vitam/data/offer/offer/inputTars"
outputTarStorageFolder: "/vitam/data/offer/offer/outputTars"
maxTarEntrySize: 10000000
maxTarFileSize: 10000000000
ForceOverrideNonEmptyCartridge: False
useSudo: false

.

Par la suite, un paragraphe « topology » décrivant la topologie de l’offre doit être renseigné. L’objectif de cet élément est de pouvoir définir une segmentation de l’usage des bandes pour répondre à un besoin fonctionnel. Il convient ainsi de définir des buckets, qu’on peut voir comme un ensemble logique de bandes, et de les associer à un ou plusieurs tenants.

tenants tableau de 1 à n identifiants de tenants au format [1,…,n] tarBufferingTimeoutInMinutes Valeur en minutes durant laquelle un tar peut rester ouvert

Exemple:

topology:
  buckets:
    test:
      tenants: [0]
      tarBufferingTimeoutInMinutes: 60
    admin:
      tenants: [1]
      tarBufferingTimeoutInMinutes: 60
    prod:
      tenants: [2,3,4,5,6,7,8,9]
      tarBufferingTimeoutInMinutes: 60

.

Enfin, la définition des équipements robotiques proprement dite doit être réalisée dans le paragraphe « tapeLibraries ».

robots: Définition du bras robotique de la librairie.

device: Chemin du fichier de périphérique scsi générique associé au bras.

mtxPath: Chemin vers la commande Linux de manipulation du bras.

timeoutInMilliseconds: timeout en millisecondes à appliquer aux ordres du bras.

drives: Définition du/ou des lecteurs de cartouches de la librairie.

index: Numéro de lecteur, valeur débutant à 0

device: Chemin du fichier de périphérique scsi SANS REMBOBINAGE associé au lecteur.

mtPath: Chemin vers la commande Linux de manipulation des lecteurs.

ddPath: Chemin vers la commande Linux de copie de bloc de données.

tarPath: Chemin vers la commande Linux de création d’archives tar.

timeoutInMilliseconds: timeout en millisecondes à appliquer aux ordres du lecteur.

Exemple:

tapeLibraries:
  TAPE_LIB_1:
    robots:
      -
        device: /dev/tape/by-id/scsiQUANTUM_10F73224E6664C84A1D00000
        mtxPath: "/usr/sbin/mtx"
        timeoutInMilliseconds: 3600000
    drives:
      -
        index: 0
        device: /dev/tape/by-id/scsi-1IBM_ULT3580-TD6_1235308739-nst
        mtPath: "/bin/mt"
        ddPath: "/bin/dd"
        tarPath: "/bin/tar"
        timeoutInMilliseconds: 3600000
      -
        index: 1
        device: /dev/tape/by-id/scsi-1IBM_ULT3580-TD6_0951859786-nst
        mtPath: "/bin/mt"
        ddPath: "/bin/dd"
        tarPath: "/bin/tar"
        timeoutInMilliseconds: 3600000
      -
        index: 2
        device: /dev/tape/by-id/scsi-1IBM_ULT3580-TD6_0269493808-nst
        mtPath: "/bin/mt"
        ddPath: "/bin/dd"
        tarPath: "/bin/tar"
        timeoutInMilliseconds: 3600000
      -
        index: 3
        device: /dev/tape/by-id/scsi-1IBM_ULT3580-TD6_0566471858-nst
        mtPath: "/bin/mt"
        ddPath: "/bin/dd"
        tarPath: "/bin/tar"
        timeoutInMilliseconds: 3600000

4.2.5.14. Sécurisation SELinux

Depuis la release R13, la solution logicielle VITAM prend désormais en charge l’activation de SELinux sur le périmètre du composant worker et des processus associés aux griffins (greffons de préservation).

SELinux (Security-Enhanced Linux) permet de définir des politiques de contrôle d’accès à différents éléments du système d’exploitation en répondant essentiellement à la question « May <subject> do <action> to <object> », par exemple « May a web server access files in users” home directories ».

Chaque processus est ainsi confiné à un (voire plusieurs) domaine(s), et les fichiers sont étiquetés en conséquence. Un processus ne peut ainsi accéder qu’aux fichiers étiquetés pour le domaine auquel il est confiné.

Note

La solution logicielle VITAM ne gère actuellement que le mode targeted (« only targeted processes are protected »)

Les enjeux de la sécurisation SELinux dans le cadre de la solution logicielle VITAM sont de garantir que les processus associés aux griffins (greffons de préservation) n’auront accès qu’au ressources système strictement requises pour leur fonctionnement et leurs échanges avec les composants worker.

Note

La solution logicielle VITAM ne gère actuellement SELinux que pour le système d’exploitation Centos

Avertissement

SELinux n’a pas vocation à remplacer quelque système de sécurité existant, mais vise plutôt à les compléter. Aussi, la mise en place de politiques de sécurité reste de mise et à la charge de l’exploitant. Par ailleurs, l’implémentation SELinux proposée avec la solution logicielle VITAM est minimale et limitée au greffon de préservation Siegfried. Cette implémentation pourra si nécessaire être complétée ou améliorée par le projet d’implémentation.

SELinux propose trois modes différents :

• Enforcing : dans ce mode, les accès sont restreints en fonction des règles SELinux en vigueur sur la machine ;
• Permissive : ce mode est généralement à considérer comme un mode de déboguage. En mode permissif, les règles SELinux seront interrogées, les erreurs d’accès logguées, mais l’accès ne sera pas bloqué.
• Disabled : SELinux est désactivé. Rien ne sera restreint, rien ne sera loggué.

La mise en oeuvre de SELinux est prise en charge par le processus de déploiement et s’effectue de la sorte :

• Isoler dans l’inventaire de déploiement les composants worker sur des hosts dédiés (ne contenant aucun autre composant VITAM)

• Positionner pour ces hosts un fichier hostvars sous environments/host_vars/ contenant la déclaration suivante

  selinux_state: "enforcing"
  

• Procéder à l’installation de la solution logicielle VITAM grâce aux playbooks ansible fournis, et selon la procédure d’installation classique décrite dans le DIN

4.2.5.15. Installation de la stack prometheus

Prometheus server et alertmanager sont des addons dans la solution VITAM. Il possible de les installer ou désinstaller via la configuration dans le fichier cots_var.yml. Voici à quoi correspond une configuration qui permettra d’installer toute la stack prometheus.

prometheus:
    metrics_path: /admin/v1/metrics
    check_consul: 10 # in seconds
    prometheus_config_file_target_directory: # Set path where "prometheus.yml" file will be generated. Example: /tmp/
    server:
        enabled: true
        port: 19090
    node_exporter:
        enabled: true
        port: 19100
        metrics_path: /metrics
    alertmanager:
        enabled: true
        api_port: 19093
        cluster_port: 19094

• L’adresse d’écoute de ces composants est celle de la patte d’administration.
• Vous pouvez surcharger la valeur de certaines de ces varibales. Par exemple les numéros de ports d’écoute. Le path de l’API.
• Pour désinstaller ou désactiver un composant de la stack prometheus il suffiet de mettre la valeur de enabled à false
• Pour générer uniquement le fichier de configuration prometheus.yml à partir de l’inventaire de l’environnement en question, il suffit de spécifier le répertoire destination dans la variable prometheus_config_file_target_directory

Note

Si vous disposez d’un prometheus server et alertmanager déjà existants, vous pouvez juste installer node_eexporter

4.2.5.15.1. Commandes utiles

Veuillez vous référer à la documentation d’exploitation pour plus d’information.

• Installer prometheus seulement: ce playbook install le serveur prometheus et alertmanager

  ansible-playbook -i environments/hosts.local ansible-vitam-extra/prometheus.yml --ask-vault
  

• Générer du fichier de conf: cette commande génère dans le dossier prometheus_config_file_target_directory le fichier prometheus.yml

  ansible-playbook -i environments/hosts ansible-vitam-extra/prometheus.yml --tags gen_prometheus_config --ask-vault
  

4.2.5.16. Installation de grafana

Grafana server est un addon dans la solution VITAM. Il possible de l’installer/désinstaller via la configuration dans le fichier cots_var.yml. Voici à quoi correspond une configuration qui permettra d’installer ce serveur.

grafana:
    enabled: true
    check_consul: 10 # in seconds
    http_port: 13000

• L’adresse d’écoute de ces composants est celle de la patte d’administration.
• Vous pouvez surcharger le numéro de port d’écoute.
• Pour désinstaller ou désactiver un composant il suffiet de mettre la valeur de enabled à false

Note

Si vous disposez d’un grafana server déjà existants, vous n’avez pas à activer son installation.

4.2.5.16.1. Commandes utiles

Veuillez vous référer à la documentation d’exploitation pour plus d’information.

• Installer grafana seulement: ce playbook install le serveur grafana

  ansible-playbook -i environments/hosts.local ansible-vitam-extra/grafana.yml --ask-vault
  

4.2.5.16.2. Configuration

Dans le cas ou le serveur grafana est dernière un serveur proxy, vous devez apporter des modification au fichier de configuration grafana.conf.j2

Voici les variables modifiées par la solution vitam pour que ça marche derrière le proxy apache.

[server]
root_url = http://{{ ip_admin }}:{{grafana.http_port}}/grafana
serve_from_sub_path = true

[auth.basic]
enabled = false

Avertissement

Lors de la première installation, vous devez changer le mot de passe par defaut et configurer le datasource et créer/importer les dashboards manuellement.