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 deployment/environments/group_vars/all/main/jvm_opts.yml

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

  • memory: paramètres Xms et Xmx
  • gc: paramè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 deployment/environments/group_vars/all/main/main.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.

Éditer le fichier deployment/environments/group_vars/all/advanced/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 accesslog

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

Éditer le fichier deployment/environments/group_vars/all/advanced/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 :

  • Éditer la variable vitam.ingestexternal.antivirus dans le fichier deployment/environments/group_vars/all/advanced/vitam_vars.yml pour indiquer le nom de l’antivirus à utiliser.

  • Créer un script shell (dont l’extension doit être .sh) sous environments/antivirus/ (norme : scan-<vitam.ingestexternal.antivirus>.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

Il subsiste une limitation avec l’antivirus ClamAV qui n’est actuellement pas capable de scanner des fichiers > 4Go. Ainsi, il n’est pas recommandé de conserver cet antivirus en environnement de production.

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 ou de renseigner un miroir local privé).

4.2.5.4.1. Extra: Avast Business Antivirus for Linux

Note

Avast étant un logiciel soumis à licence, Vitam ne fournit pas de support ni de licence nécessaire à l’utilisation de Avast Antivirus for Linux.

Vous trouverez plus d’informations sur le site officiel : Avast Business Antivirus for Linux

À la place de clamAV, il est possible de déployer l’antivirus Avast Business Antivirus for Linux.

Pour se faire, il suffit d’éditer la variable vitam.ingestexternal.antivirus: avast dans le fichier deployment/environments/group_vars/all/advanced/vitam_vars.yml.

Il sera nécessaire de fournir le fichier de licence sous deployment/environments/antivirus/license.avastlic pour pouvoir déployer et utiliser l’antivirus Avast.

De plus, il est possible de paramétrer l’accès aux repositories (Packages & Virus definitions database) dans le fichier deployment/environments/group_vars/all/advanced/cots_vars.yml.

Si les paramètres ne sont pas définis, les valeurs suivantes sont appliquées par défaut.

## Avast Business Antivirus for Linux
## if undefined, the following default values are applied.
avast:
    # logs configuration
    logrotate: enabled # or disabled
    history_days: 30 # How many days to store logs if logrotate is set to 'enabled'
    manage_repository: true
    repository:
        state: present
        # For CentOS
        baseurl: http://rpm.avast.com/lin/repo/dists/rhel/release
        gpgcheck: no
        proxy: _none_
        # For Debian
        baseurl: 'deb http://deb.avast.com/lin/repo debian-buster release'
    vps_repository: http://linux-av.u.avcdn.net/linux-av/avast/x86_64
    ## List of sha256 hash of excluded files from antivirus. Useful for test environments.
    whitelist:
        - <EMPTY>

Avertissement

Vitam gère en entrée les SIPs aux formats: ZIP ou TAR (tar, tar.gz ou tar.bz2); cependant et d’après les tests effectués, il est fortement recommandé d’utiliser le format .zip pour bénéficier des meilleures performances d’analyses avec le scan-avast.sh.

De plus, il faudra prendre en compte un dimensionnement supplémentaire sur les ingest-external afin de pouvoir traiter le scan des fichiers >500Mo.

Dans le cas d’un SIP au format .zip ou .tar, les fichiers >500Mo contenus dans le SIP seront décompressés et scannés unitairement. Ainsi la taille utilisée ne dépassera pas la taille d’un fichier.

Dans le cas d’un SIP au format .tar.gz ou .tar.bz2, les SIPs >500Mo seront intégralement décompressés et scannés. Ainsi, la taille utilisée correspondra à la taille du SIP décompressé.

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/advanced/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/advanced/vitam_vars.yml, afin que ce composant ne tente pas d’envoyer des données sur « elasticsearch-log ».

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/main/main.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 deployment/environments/group_vars/all/advanced/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/advanced/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"
      StorageRule : "5 year"
      ReuseRule : "2 year"

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 anglais, 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. Augmenter la précision sur le nombre de résultats retournés dépassant 10000

Suite à une évolution d’ElasticSearch (à partir de la version 7.6), le nombre maximum de résultats retournés est limité à 10000. Ceci afin de limiter la consommation de ressources sur le cluster elasticsearch.

Pour permettre de retourner le nombre exact de résultats, il est possible d’éditer le paramètre vitam.accessexternal.authorizeTrackTotalHits dans le fichier de configuration environments/group_vars/all/vitam_vars.yml

Il sera nécessaire de réappliquer la configuration sur le groupe hosts_access_external:

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

Ensuite, si l’API de recherche utilise le type d’entrée de DSL « SELECT_MULTIPLE », il faut ajouter $track_total_hits : true au niveau de la partie « filter » de la requête d’entrée.

Ci-dessous, un exemple de requête d’entrée :

{
  "$roots": [],
  "$query": [
   {
     "$match": {
        "Title": "héritage"
     }
   }
  ],
  "$filter": {
    "$offset": 0,
    "$limit": 100,
    "$track_total_hits": true
  },
  "$projection": {}
}

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

  • deployment/environments/group_vars/all/main/main.yml, comme suit :

      1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
    ---

# TENANTS
# List of active tenants
vitam_tenant_ids: [0,1,2,3,4,5,6,7,8,9]
# For functional-administration, manage master/slave tenant configuration
# http://www.programmevitam.fr/ressources/DocCourante/html/installation/installation/21-addons.html#passage-des-identifiants-des-referentiels-en-mode-esclave
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

# GRIFFINS
# Vitam 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: []

# CONSUL
consul:
  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"]

# LOGGING
# vitam_defaults:
#   access_retention_days: 30 # Number of days for file retention
#   access_total_size_cap: "10GB" # total acceptable size
#   logback_max_file_size: "10MB"
#   logback_total_size_cap:
#     file:
#       history_days: 30
#       totalsize: "5GB"
#     security:
#       history_days: 30
#       totalsize: "5GB"

# ELASTICSEARCH
# 'number_of_shards': number of shards per index, every ES shard is stored as a lucene index
# 'number_of_replicas': number of additional copies of primary shards
# Total number of shards: number_of_shards * (1 primary + M number_of_replicas)
# CAUTION: The total number of shards should be lower than or equal to the number of elasticsearch-data instances in the cluster
# More details in groups_vars/all/advanced/tenants_vars.yml file
vitam_elasticsearch_tenant_indexation:
  default_config:
    # Default settings for masterdata collections (1 index per collection)
    masterdata:
      number_of_shards: 1
      number_of_replicas: 2
    # Default settings for unit indexes (1 index per tenant)
    unit:
      number_of_shards: 1
      number_of_replicas: 2
    # Default settings for object group indexes (1 index per tenant)
    objectgroup:
      number_of_shards: 1
      number_of_replicas: 2
    # Default settings for logbook operation indexes (1 index per tenant)
    logbookoperation:
      number_of_shards: 1
      number_of_replicas: 2
    # Default settings for collect_unit indexes
    collect_unit:
      number_of_shards: 1
      number_of_replicas: 2
    # Default settings for collect_objectgroup indexes
    collect_objectgroup:
      number_of_shards: 1
      number_of_replicas: 2

  collect_grouped_tenants:
  - name: 'all'
    # Group all tenants for collect's indexes (collect_unit & collect_objectgroup)
    tenants: "{{ vitam_tenant_ids | join(',') }}"

elasticsearch:
  log:
    index_templates:
      default:
        shards: 1
        replica: 1
  data:
    index_templates:
      default:
        shards: 1
        replica: 2
curator:
  log:
    metrics:
      close: 7
      delete: 30
    logstash:
      close: 7
      delete: 30

# PACKAGES
disable_internet_repositories_install: true # Disable EPEL or Debian backports repositories install

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.

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

      1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
    ---
### global ###

# Vitam deployment mode. Allowed values are :
# - "prod" (default): Enforces additional security checks (disallow development/debug tools, reverse proxy does NOT forward traffic to vitam service ports...)
# - "dev" (NOT for sensitive / production environments): Allow development/debug tools, reverse proxy forwards traffic to vitam service ports.
deployment_mode: prod

# 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_V109.xml"
droid_container_filename: "container-signature-20221102.xml"

# The global defaults parameters for vitam & vitam components
vitam_defaults:
  folder:
    root_path: /vitam
    folder_permission: "0750"
    conf_permission: "0440"
    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
    at_boot: false
  ### Trust X-SSL-CLIENT-CERT header for external api auth ? true | false (default)
  # Should only be enabled when accessing to vitam externals through a Reverse Proxy that does "SSL offloading"
  # NGINX configuration        : proxy_set_header X-SSL-CLIENT-CERT $ssl_client_escaped_cert;
  # Apache httpd configuration : RequestHeader set X-SSL-CLIENT-CERT "%{SSL_CLIENT_CERT}s"
  # Important : When enabled, special care must be taken to ensure firewall rules are properly set to ensure only
  #             reverse proxy can access vitam external applications through their respective port_service to avoid
  #             malicious header injection.
  trust_client_certificate_header: false
  ### Force chunk mode : set true if chunk header should be checked
  vitam_force_chunk_mode: false
  # syslog_facility
  syslog_facility: local0

  ################################################################################
  ### Default Components parameters
  ### Uncomment them if you want to update the default value applied on all components

  ### Ontology cache settings (max entries in cache & retention timeout in seconds)
  # ontologyCacheMaxEntries: 100
  # ontologyCacheTimeoutInSeconds: 300
  ### Elasticsearch scroll timeout in milliseconds settings
  # elasticSearchScrollTimeoutInMilliseconds: 300000

  ### The following values can be overwritten for each components in vitam: parameters.
  jvm_log: false
  performance_logger: false

  # consul_business_check: 10 # value in seconds
  # consul_admin_check: 10 # value in seconds


  ### Logs configuration for reconstruction services (INFO or DEBUG for active logs).
  ### Logs will be present only on secondary site.
  ### Available for the following components: logbook, metadata & functional-administration.
  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

# Request time check settings. Do NOT update except if required by Vitam support
# Max acceptable time desynchronization between machines (in seconds).
acceptableRequestTime: 10
# Critical time desynchronization between machines (in seconds).
criticalRequestTime: 60
# Request time alert throttling Delay (in seconds)
requestTimeAlertThrottlingDelay: 60

# Reconstruction config
restoreBulkSize: 10000

vitam_timers:
  # /!\ IMPORTANT :
  # Please ensure timer execution is spread so that not all timers run concurrently (eg. *:05:00, *:35:00, *:50:00..),
  # Special care for heavy-load timers that run on same machines or use same resources (eg. vitam-traceability-*).
  #
  # Quartz cron nomenclature
  #    minutely → 0 * * * * ?
  #    hourly → 0 0 * * * ?
  #    daily → 0 0 0 * * ?
  #    monthly → 0 0 0 1 * ?
  #    weekly →  0 0 0 ? * MON *
  #    yearly → 0 0 0 1 1 ?
  #    quarterly → 0 0 0 1 1/3 ?
  #    semiannually → 0 0 0 1 1/6 ?
  logbook: # all have to run on only one machine
    # Sécurisation des journaux des opérations
    frequency_traceability_operations: "* 05 0/1 * * ?" # every hour
    # Sécurisation des journaux du cycle de vie des groupes d'objets
    frequency_traceability_lfc_objectgroup: "* 15 0/1 * * ?" # every hour
    # Sécurisation des journaux du cycle de vie des unités archivistiques
    frequency_traceability_lfc_unit: "* 35 0/1 * * ?" # every hour
    # Audit de traçabilité
    frequency_traceability_audit: "0 55 00 * * ?"
    # Reconstruction (uniquement sur site secondaire)
    frequency_logbook_reconstruction: "0 0/5 * * * ?"
  storage:
    # Sécurisation du journal des écritures
    frequency_traceability_log: "0 40 0/4 * * ?" # every 4 hours
    # Sauvegarde des journaux d'accès
    vitam_storage_accesslog_backup: "0 10 0/4 * * ?" # every 4 hours
    # Sauvegarde des journaux des écritures
    vitam_storage_log_backup: "0 15 0/4 * * ?" # every 4 hours

  functional_administration:
    frequency_create_accession_register_symbolic: "0 50 0 * * ?"
    frequency_accession_register_reconstruction: "0 0/5 * * * ?"
    frequency_rule_management_audit: "0 40 * * * ?"
    frequency_reconstruction: "0 0/5 * * * ?"
    frequency_integrity_audit: "0 0 0 1 JAN ? 2020"
    frequency_existence_audit: "0 0 0 1 JAN ? 2020"
  metadata:
    frequency_store_graph: "0 10/30 * * * ?"
    frequency_reconstruction: "0 0/5 * * * ?"
    frequency_computed_inherited_rules: "0 30 2 * * ?"
    frequency_purge_dip: "0 0 * * * ?"
    frequency_purge_transfers_sip: "0 25 2 * * ?"
    frequency_audit_mongodb_es: "0 0 0 1 JAN ? 2020"
  offer:
    # Compaction offer logs
    frequency_offerlog_compaction: "0 40 * * * ?"

scheduler:
  job_parameters:
    integrity_audit:
      operations_delay_in_minutes: 1440
    existence_audit:
      operations_delay_in_minutes: 1440


### 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_folder_conf: "{{ vitam_defaults.folder.root_path }}/conf/consul"

# 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: [ "scheduler", "logbook" , "metadata" , "functional-administration" , "storage" , "storageofferdefault" , "offer" , "elasticsearch-log" , "elasticsearch-data" , "logstash" , "kibana" , "mongoc" , "mongod" , "mongos", "elastic-kibana-interceptor" , "consul" ]

# containers list
containers_list: [ 'units', 'objects', 'objectgroups', 'logbooks', 'reports', 'manifests', 'profiles', 'storagelog', 'storageaccesslog', 'storagetraceability', 'rules', 'dip', 'agencies', 'backup', 'backupoperations', 'unitgraph', 'objectgroupgraph', 'distributionreports', 'accessionregistersdetail', 'accessionregisterssymbolic', 'tmp', 'archivaltransferreply' ]

### Composants Vitam ###
vitam:
  ### All available parameters for each components are described in the vitam_defaults variable

  ### Example
  # component:
  #    at_boot: false
  #    logback_rolling_policy: true
  ## Force the log level for this component. Available logback values are (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"

  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"
    authorizeTrackTotalHits: false # if false, limit results to 10K. if true, authorize results overs 10K (can overload elasticsearch-data)
  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"
  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 }}"
    # Number of AccessionRegisterSymbolic creation threads that can be run in parallel.
    accessionRegisterSymbolicThreadPoolSize: 16
    # Number of rule audit threads that can be run in parallel.
    ruleAuditThreadPoolSize: 16
    # Reconstruction metrics cache in minutes (secondary site)
    reconstructionMetricsCacheDurationInMinutes: 15
  scheduler:
    vitam_component: scheduler
    host: "scheduler.service.{{ consul_domain }}"
    port_service: 8799
    port_admin: 28799
    baseuri: "scheduler"
    https_enabled: false
    secret_platform: "true"
    schedulerThreadSize: 8
  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 }}"
  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"
  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" # or avast
    #scantimeout: 1200000 # value in milliseconds; increase this value if huge files need to be analyzed in more than 20 min (default value)
    # 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"
    # 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)
  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"
  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
    allowedMediaTypes:
      - type: "application"
        subtype: "pdf"
      - type: "text"
        subtype: "plain"
      - type: "image"
        subtype: "jpeg"
      - type: "image"
        subtype: "tiff"
  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
    # Number of logbook operations that can be run in parallel.
    operationTraceabilityThreadPoolSize: 16
    # 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 delay between 2 lifecycle traceability operations.
    # A new unit/objectgroup lifecycle traceability is generated after this delay, even if tenant has no
    # new unit/objectgroups 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
    # LFC traceability timers run every hour +/- some clock delays)
    lifecycleTraceabilityMaxRenewalDelay: 690
    lifecycleTraceabilityMaxRenewalDelayUnit: MINUTES
    # Max entries selected per (Unit or Object Group) LFC traceability operation
    lifecycleTraceabilityMaxEntries: 100000
    # Reconstruction metrics cache in minutes (secondary site)
    reconstructionMetricsCacheDurationInMinutes: 15
  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 }}"
    # 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
    # DIP cleanup delay (in minutes)
    dipTimeToLiveInMinutes: 10080 # 7 days
    criticalDipTimeToLiveInMinutes: 1440 # 1 day
    transfersSIPTimeToLiveInMinutes: 10080 # 7 days
    unitsStreamThreshold: 1000000 # 1 million
    unitsStreamExecutionLimit: 3 # 3 times
    objectsStreamThreshold: 1000000 # 1 million
    objectsStreamExecutionLimit: 3 # 3 times
    workspaceFreespaceThreshold: 25 # when below use critical time to live when above use normal time to live
    elasticsearch_mapping_dir: "{{ vitam_defaults.folder.root_path }}/conf/metadata/mapping" # Directory of elasticsearch metadata mapping
    #### Audit data consistency MongoDB-ES ####
    isDataConsistencyAuditRunnable: false
    dataConsistencyAuditOplogMaxSize: 100
    # Reconstruction metrics cache in minutes (secondary site)
    reconstructionMetricsCacheDurationInMinutes: 15
    context_path: "/metadata"
  processing:
    vitam_component: processing
    host: "processing.service.{{ consul_domain }}"
    port_service: 8203
    port_admin: 28203
    baseuri: "processing"
    https_enabled: false
    secret_platform: "true"
    maxDistributionInMemoryBufferSize: 100000
    maxDistributionOnDiskBufferSize: 100000000
  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"
  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
    # Storage write/access log backup max thread pool size
    storageLogBackupThreadPoolSize: 16
    # Storage write log traceability thread pool size
    storageLogTraceabilityThreadPoolSize: 16
    # Offer synchronization batch size & thread pool size
    offerSynchronizationBulkSize: 1000
    offerSyncThreadPoolSize: 32
    # Retries attempts on failures
    offerSyncNumberOfRetries: 3
    # Retry wait delay on failures (in seconds)
    offerSyncFirstAttemptWaitingTime: 15
    offerSyncWaitingTime: 30
    # Offer synchronization wait delay  (in seconds) for async offers (synchronization from a tape-storage offer)
    offerSyncAccessRequestCheckWaitingTime: 10
    logback_total_size_cap:
      offersync:
        history_days: 30
        totalsize: "5GB"
      offerdiff:
        history_days: 30
        totalsize: "5GB"
    # unit time per kB (in ms) used while calculating the timeout of an http request between storage and offer.
    timeoutMsPerKB: 100
    # minimum timeout (in ms) for writing objects to offers
    minWriteTimeoutMs: 60000
    # minimum timeout per object (in ms) for bulk writing objects to offers
    minBulkWriteTimeoutMsPerObject: 10000
  storageofferdefault:
    vitam_component: "offer"
    port_service: 9900
    port_admin: 29900
    baseuri: "offer"
    https_enabled: false
    secret_platform: "true"
    logback_total_size_cap:
      offer_tape:
        history_days: 30
        totalsize: "5GB"
      offer_tape_backup:
        history_days: 30
        totalsize: "5GB"
  worker:
    vitam_component: worker
    host: "worker.service.{{ consul_domain }}"
    port_service: 9104
    port_admin: 29104
    baseuri: "worker"
    https_enabled: false
    secret_platform: "true"
    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
    # Batch size for bulk atomic update
    queriesThreshold: 100000
    # Bulk atomic update batch size
    bulkAtomicUpdateBatchSize: 100
    # Max threads that can be run in concurrently is thread pool for bulk atomic update
    bulkAtomicUpdateThreadPoolSize: 8
    # Number of jobs that can be queued in memory before blocking for bulk atomic update
    bulkAtomicUpdateThreadPoolQueueSize: 16
    # Dip/transfer threshold file size
    binarySizePlatformThreshold: 1
    binarySizePlatformThresholdSizeUnit: "GIGABYTE"
  workspace:
    vitam_component: workspace
    host: "workspace.service.{{ consul_domain }}"
    port_service: 8201
    port_admin: 28201
    baseuri: "workspace"
    https_enabled: false
    secret_platform: "true"
    context_path: "/workspace"
  collect_internal:
    vitam_component: collect-internal
    host: "collect-internal.service.{{ consul_domain }}"
    port_service: 8038
    port_admin: 28038
    baseuri: "collect-internal"
    https_enabled: false
    secret_platform: "true"
    transactionStatusThreadPoolSize: 4
    statusTransactionThreadFrequency: 5
  collect_external:
    vitam_component: collect-external
    host: "collect-external.service.{{ consul_domain }}"
    port_service: 8030
    port_admin: 28030
    baseuri: "collect-external"
    https_enabled: true
    secret_platform: "false"
    authorizeTrackTotalHits: false # if false, limit results to 10K. if true, authorize results overs 10K (can overload elasticsearch-data)
  metadata_collect:
    vitam_component: metadata-collect
    host: "metadata-collect.service.{{ consul_domain }}"
    port_service: 8290
    port_admin: 28290
    baseuri: "metadata-collect"
    https_enabled: false
    secret_platform: "true"
    cluster_name: "{{ elasticsearch.data.cluster_name }}"
    # 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
    # DIP cleanup delay (in minutes)
    dipTimeToLiveInMinutes: 10080 # 7 days
    criticalDipTimeToLiveInMinutes: 1440 # 1 day
    transfersSIPTimeToLiveInMinutes: 10080 # 7 days
    workspaceFreespaceThreshold: 25 # when below use critical time to live when above use normal time to live
    elasticsearch_mapping_dir: "{{ vitam_defaults.folder.root_path }}/conf/metadata-collect/mapping" # Directory of elasticsearch metadata mapping
    #### Audit data consistency MongoDB-ES ####
    isDataConsistencyAuditRunnable: false
    dataConsistencyAuditOplogMaxSize: 100
    context_path: "/metadata-collect"
  workspace_collect:
    vitam_component: workspace-collect
    host: "workspace-collect.service.{{ consul_domain }}"
    port_service: 8291
    port_admin: 28291
    baseuri: "workspace-collect"
    https_enabled: false
    secret_platform: "true"
    context_path: "/workspace-collect"

# http://www.programmevitam.fr/ressources/DocCourante/html/installation/installation/21-addons.html#durees-minimales-permettant-de-controler-les-valeurs-saisies
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.

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

      1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
    ---

consul:
    retry_interval: 10 # in seconds
    check_interval: 10 # in seconds
    check_timeout: 5 # in seconds
    log_level: WARN # Available log_level are: TRACE, DEBUG, INFO, WARN or ERR

# 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:
            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
        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:
        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
    # logs configuration
    logrotate: enabled # or disabled
    history_days: 30 # How many days to store logs if logrotate is set to 'enabled'

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:
        port: 9090
        tsdb_retention_time: "7d"
        tsdb_retention_size: "5GB"
    node_exporter:
        enabled: true
        port: 9101
        metrics_path: /metrics
        log_level: "warn"
        logrotate: enabled # or disabled
        history_days: 30 # How many days to store logs if logrotate is set to 'enabled'
    consul_exporter:
        enabled: true
        port: 9107
        metrics_path: /metrics
    elasticsearch_exporter:
        enabled: true
        port: 9114
        metrics_path: /metrics
        log_level: "warn"
        logrotate: enabled # or disabled
        history_days: 30 # How many days to store logs if logrotate is set to 'enabled'
    alertmanager:
        api_port: 9093
        cluster_port: 9094
        #receivers: # https://grafana.com/blog/2020/02/25/step-by-step-guide-to-setting-up-prometheus-alertmanager-with-slack-pagerduty-and-gmail/
        #- name: "slack_alert"
        #  slack_configs:
        #  - api_url: "https://hooks.slack.com/services/xxxxxxx/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
        #    channel: '#your_alert_channel'
        #    send_resolved: true

grafana:
    check_consul: 10 # in seconds
    http_port: 3000
    proxy: false
    grafana_datasources:
      - name: "Prometheus"
        type: "prometheus"
        access: "proxy"
        url: "http://prometheus-server.service.{{ consul_domain }}:{{ prometheus.server.port | default(9090) }}/prometheus"
        basicAuth: false
        editable: true
      - name: "Prometheus AlertManager"
        type: "camptocamp-prometheus-alertmanager-datasource"
        access: "proxy"
        url: "http://prometheus-alertmanager.service.{{ consul_domain }}:{{ prometheus.alertmanager.api_port | default(9093) }}"
        basicAuth: false
        editable: true
        jsonData:
          keepCookies: []
          severity_critical: "4"
          severity_high: "3"
          severity_warning: "2"
          severity_info: "1"
    grafana_dashboards:
      - name: 'vitam-dashboard'
        orgId: 1
        folder: ''
        folderUid: ''
        type: file
        disableDeletion: false
        updateIntervalSeconds: 10
        allowUiUpdates: true
        options:
          path: "/etc/grafana/provisioning/dashboards"

# Curator units: days
curator:
    log:
        metricbeat:
            close: 5
            delete: 10
        packetbeat:
            close: 5
            delete: 10

kibana:
    header_value: "reporting"
    import_delay: 10
    import_retries: 10
    # logs configuration
    logrotate: enabled # or disabled
    history_days: 30 # How many days to store logs if logrotate is set to 'enabled'
    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: 1
        replica: 1
        # pour index logstash-*
        metrics:
            shards: 1
            replica: 1
        # pour index metricbeat-*
        metricbeat:
            shards: 3 # 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
    # logs configuration
    logrotate: enabled # or disabled
    history_days: 30 # How many days to store logs if logrotate is set to 'enabled'

siegfried:
    port: 19000
    consul_check: 10 # in seconds

clamav:
    port: 3310
    # logs configuration
    logrotate: enabled # or disabled
    history_days: 30 # How many days to store logs if logrotate is set to 'enabled'
    freshclam:
        # frequency freshclam for database update per day (from 0 to 24 - 24 meaning hourly check)
        db_update_periodicity: 1
        private_mirror_address:
        use_proxy: "no"

## Avast Business Antivirus for Linux
## if undefined, the following default values are applied.
# avast:
#     # logs configuration
#     logrotate: enabled # or disabled
#     history_days: 30 # How many days to store logs if logrotate is set to 'enabled'
#     manage_repository: true
#     repository:
#         state: present
#         # For CentOS
#         baseurl: http://rpm.avast.com/lin/repo/dists/rhel/release
#         gpgcheck: no
#         proxy: _none_
#         # For Debian
#         baseurl: 'deb http://deb.avast.com/lin/repo debian-buster release'
#     vps_repository: http://linux-av.u.avcdn.net/linux-av/avast/x86_64
#     ## List of sha256 hash of excluded files from antivirus. Useful for test environments.
#     whitelist:
#         - xxxxxx
#         - yyyyyy

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"

# Backup tool on storage-offer
restic:
    snapshot_retention: 30 # number of snapshots to keep
    # default run backup at 23:00 everydays
    cron:
        minute: '00'
        hour: '23'
        day: '*'
        month: '*'
        weekday: '*'
    # [hosts_storage_offer_default] must be able to connect to the listed databases below to properly backup.
    backup:
        # mongo-offer
        - name: "{{ offer_conf }}"
          type: mongodb
          host: "{{ offer_conf }}-mongos.service.consul:{{ mongodb.mongos_port }}"
          user: "{{ mongodb[offer_conf].admin.user }}"
          password: "{{ mongodb[offer_conf].admin.password }}"
        # # mongo-data (only if mono-sharded cluster)
        # - name: mongo-data
        #   type: mongodb
        #   host: "mongo-data-mongos.service.consul:{{ mongodb.mongos_port }}"
        #   user: "{{ mongodb['mongo-data'].admin.user }}"
        #   password: "{{ mongodb['mongo-data'].admin.password }}"
        # # mongo-vitamui (only if vitamui is deployed)
        # - name: mongo-vitamui
        #   type: mongodb
        #   host: mongo-vitamui-mongod.service.consul:{{ mongodb.mongod_port }}
        #   # Add the following params on environments/group_vars/all/main/vault-vitam.yml
        #   # They can be found under vitamui's deployment sources on environments/group_vars/all/vault-mongodb.yml
        #   user: "{{ mongodb['mongo-vitamui'].admin.user }}"
        #   password: "{{ mongodb['mongo-vitamui'].admin.password }}"

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

  • deployment/environments/group_vars/all/advanced/jvm_opts.yml, comme suit :

      1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
    ---

# Default values if unset
# jvm_opts.memory: "-Xms512m -Xmx512m"
# gc: "-Xlog:gc*,gc+age=trace,safepoint:file={{ vitam_folder_log }}/gc.log:utctime,pid,tags:filecount=32,filesize=64m"
# java: ""

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: ""
    scheduler:
        jvm_opts:
            # memory: "-Xms512m -Xmx512m"
            # gc: ""
            # java: ""
    security_internal:
        jvm_opts:
            # memory: "-Xms512m -Xmx512m"
            # gc: ""
            # java: ""
    library:
        jvm_opts:
            memory: "-Xms32m -Xmx128m"
            # gc: ""
            # java: ""
    collect_internal:
        jvm_opts:
            # memory: "-Xms512m -Xmx512m"
            # gc: ""
            # java: ""
    collect_external:
        jvm_opts:
            # memory: "-Xms512m -Xmx512m"
            # gc: ""
            # java: ""
    metadata_collect:
        jvm_opts:
            # memory: "-Xms512m -Xmx512m"
            # gc: ""
            # java: ""
    workspace_collect:
        jvm_opts:
            # memory: "-Xms512m -Xmx512m"
            # 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.14. Paramétrage de l’Offre Froide ( librairies de cartouches )

Voir aussi

Les principes de fonctionnement de l’offre froide sont décrits dans la documentation externe dédiée (« Archivage sur Offre Froide »).

La librairie et les lecteurs doivent déjà être configurés sur la machine devant supporter une instance de ce composant (avec login automatique en cas de reboot).

La commande lsscsi -g peut permettre de vérifier si des périphériques sont détectés.

Note

Une offre froide est mono-instantiable uniquement. Elle ne peut être déployée en haut-disponibilité.

Le paramétrage de l’offre froide se fait via la configuration du fichier deployment/environments/group_vars/all/offer_opts.yml. L’ensemble des clés disponibles est listé dans le fichier deployment/environments/group_vars/all/offer_opts.yml.example

L’offre froide doit être configurée avec le flag AsyncRead défini à True dans la stratégie par défaut de Vitam via vitam_strategy ou dans une stratégie additionnelle other_strategies.

Exemple:

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

Une offre froide 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 section tapeLibraryConfiguration décrit le paramétrage général de l’offre froide.

  • maxTarEntrySize Taille maximale (en octets) au-delà de la laquelle les fichiers entrants seront découpés en segments. Typiquement 1 Go, maximum 8 Go.
  • maxTarFileSize Taille maximale (en octets) des tars à constituer. Typiquement 10 Go.
  • forceOverrideNonEmptyCartridges Permet de passer outre le contrôle vérifiant que les bandes nouvellement introduites sont vides. Par défaut à false. Ne doit être défini à true que sur un environnement de recette où l’écrasement d’une bande de test est sans risque.
  • cachedTarMaxStorageSpaceInMB Permet de définir la taille maximale du cache disque (en Mo) (Ex. 10 To pour un env de production)
  • cachedTarEvictionStorageSpaceThresholdInMB Permet de définir la taille critique du cache disque (en Mo). Une fois ce seuil atteint, les archives non utilisées sont purgées (selon la date de dernier accès). Doit être plus petit que la taille maximale cachedTarMaxStorageSpaceInMB. (Ex. 8 To pour un env de production)
  • cachedTarSafeStorageSpaceThresholdInMB Seuil « confortable » d’utilisation du cache (en Mo). Le processus d’éviction des archives du cache s’arrête lorsque ce seuil est atteint. Doit être plus petit que la taille critique cachedTarEvictionStorageSpaceThresholdInMB. (Ex. 6 To pour un env de production)
  • maxAccessRequestSize Définit un seuil technique du nombre d’objets que peut cibler une demande d’accès. Par défaut de 10000. À ne pas modifier.
  • readyAccessRequestExpirationDelay Valeur du délais d’expiration des demandes d’accès. Une fois une demande d’accès à des objets est prête, l’accès immédiat aux objets est garantie durant cette période.
  • readyAccessRequestExpirationUnit Unité du délais d’expiration des demandes d’accès (une valeur parmi « SECONDS » / « MINUTES » / « HOURS » / « DAYS » / « MONTHS »).
  • readyAccessRequestPurgeDelay Valeur du délais de purge complète des demandes d’accès.
  • readyAccessRequestPurgeUnit Unité du délais de purge complète des demandes d’accès (une valeur parmi « SECONDS » / « MINUTES » / « HOURS » / « DAYS » / « MONTHS »).
  • accessRequestCleanupTaskIntervalDelay Valeur de la fréquence de nettoyage des demandes d’accès.
  • accessRequestCleanupTaskIntervalUnit Unité de la fréquence de nettoyage des demandes d’accès (une valeur parmi « SECONDS » / « MINUTES » / « HOURS » / « DAYS » / « MONTHS »).

Note

maxTarEntrySize doit être strictement inférieur à maxTarFileSize

Note

cachedTarEvictionStorageSpaceThresholdInMB doit être strictement inférieur à cachedTarMaxStorageSpaceInMB

Note

cachedTarSafeStorageSpaceThresholdInMB doit être strictement inférieur à cachedTarEvictionStorageSpaceThresholdInMB

Note

Se référer à la documentation DAT pour les éléments de dimensionnement du cache.

Note

La durée de purge des demandes d’accès doit être strictement supérieure à leur durée d’expiration.

Note

Le monitoring de l’offre froide est for est fortement recommandé afin de s’assurer du bon fonctionnement de l’offre, et du dimensionnement du disque local. Un dashboard dédié à l’offre froide de Vitam est déployé avec les composants « extra » prometheus et grafana.

Exemple:

inputFileStorageFolder: "/vitam/data/offer/offer/inputFiles"
inputTarStorageFolder: "/vitam/data/offer/offer/inputTars"
tmpTarOutputStorageFolder: "/vitam/data/offer/offer/tmpTarOutput"
cachedTarStorageFolder: "/vitam/data/offer/offer/cachedTars"
maxTarEntrySize: 10000000
maxTarFileSize: 10000000000
ForceOverrideNonEmptyCartridge: false
cachedTarMaxStorageSpaceInMB: 1_000_000
cachedTarEvictionStorageSpaceThresholdInMB: 800_000
cachedTarSafeStorageSpaceThresholdInMB: 700_000
maxAccessRequestSize: 10_000
readyAccessRequestExpirationDelay: 30
readyAccessRequestExpirationUnit: DAYS
readyAccessRequestPurgeDelay: 60
readyAccessRequestPurgeUnit: DAYS
accessRequestCleanupTaskIntervalDelay: 15
accessRequestCleanupTaskIntervalUnit: MINUTES

topology:
  ...
tapeLibraries:
  ...

Le paragraphe topology décrit 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 une archive TAR peut rester ouverte (durée maximale d’accumulation des objets dans un TAR) avant que le TAR soit finalisé / planifié pour écriture sur bande.

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

Note

Tous les tenants doivent être affectés à un et un seul bucket.

Prudence

L’affectation d’un tenant à un bucket est définitive. i.e. Il est impossible de modifier le bucket auquel un tenant a été déjà affecté car les données ont déjà été écrites sur bandes. Il est possible cependant, lors de l’ajout d’un tout nouveau tenant à Vitam, d’affecter ce nouveau tenant à un bucket existant.

La section tapeLibraries permet de définir le paramétrage des bibliothèques de bandes pilotées par l’offre froide.

Note

Une offre de stockage Vitam ne peut manipuler qu’une seule bibliothèque de bandes. Afin de piloter plusieurs bibliothèques de bandes, il convient d’utiliser des offres Vitam différentes.

Une bibliothèque de bandes est composée d’un robot (bras articulé), et d’un ensemble de lecteurs.

Note

Seul un robot doit être configuré pour piloter une librairie de bandes. La configuration de plusieurs robots pour une même librairie de bandes n’est actuellement PAS supportée.

La commande ls -l /dev/tape/by-id/ permet de lister les chemins des périphériques (lecteurs et bras articulés) à configurer.

Exemple:

$ ls -l /dev/tape/by-id/
total 0
lrwxrwxrwx 1 root root  9 Mar  7 11:07 scsi-1HP_EML_E-Series_B4B0AC0000 -> ../../sg1
lrwxrwxrwx 1 root root  9 Mar  7 11:07 scsi-SHP_DLT_VS80_B4B0A00001 -> ../../st0
lrwxrwxrwx 1 root root 10 Mar  7 11:07 scsi-SHP_DLT_VS80_B4B0A00001-nst -> ../../nst0
lrwxrwxrwx 1 root root  9 Mar  7 11:07 scsi-SHP_DLT_VS80_B4B0A00002 -> ../../st1
lrwxrwxrwx 1 root root 10 Mar  7 11:07 scsi-SHP_DLT_VS80_B4B0A00002-nst -> ../../nst1
lrwxrwxrwx 1 root root  9 Mar  7 11:07 scsi-SHP_DLT_VS80_B4B0A00003 -> ../../st2
lrwxrwxrwx 1 root root 10 Mar  7 11:07 scsi-SHP_DLT_VS80_B4B0A00003-nst -> ../../nst2
lrwxrwxrwx 1 root root  9 Mar  7 11:07 scsi-SHP_DLT_VS80_B4B0A00004 -> ../../st3
lrwxrwxrwx 1 root root 10 Mar  7 11:07 scsi-SHP_DLT_VS80_B4B0A00004-nst -> ../../nst3

Prudence

Ne pas utiliser les chemins /dev/* dont l’index peut changer en cas de redémarrage. Utiliser les chemins /dev/tape/by-id/* (qui utilisent le numéro de série du device cible).

Prudence

Seuls les devices de lecteurs de type /dev/nstX (par exemple : /dev/tape/by-id/scsi-SHP_DLT_VS80_B4B0A00001-nst -> /dev/nst0) peuvent être utilisés dans Vitam. Les devices de lecteurs de type /dev/stX (par exemple : /dev/tape/by-id/scsi-SHP_DLT_VS80_B4B0A00001 -> /dev/st0) ne doivent PAS être utilisés (car ils causent à rebobinage automatique de la bande après chaque opération).

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

    • device: Chemin du fichier de périphérique scsi générique associé au bras. (ex. /dev/tape/by-id/scsi-1HP_EML_E-Series_B4B0AC0000)
    • 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. (ex. /dev/tape/by-id/scsi-SHP_DLT_VS80_B4B0A00001-nst)
    • mtPath: Chemin vers la commande Linux de manipulation des lecteurs.
    • ddPath: Chemin vers la commande Linux de copie de bloc de données.
    • timeoutInMilliseconds: timeout en millisecondes à appliquer aux ordres du lecteur.

  • fullCartridgeDetectionThresholdInMB Seuil de détection de bande pleine (en Mo) Permet pour détecter en cas d’erreur d’écriture sur bande, la cause probable de l’erreur :

    • Si le volume des données écrites sur bande > seuil : La bande est considérée comme pleine
    • Si le volume des données écrites sur bande < seuil : La bande est considérée comme corrompue

    Typiquement, 90% de la capacité théorique de stockage des cartouches (hors compression).

Exemple:

tapeLibraries:
  TAPE_LIB_1:
    robots:
      -
        device: /dev/tape/by-id/scsi-1HP_EML_E-Series_B4B0AC0000
        mtxPath: "/usr/sbin/mtx"
        timeoutInMilliseconds: 3600000
    drives:
      -
        index: 0
        device: /dev/tape/by-id/scsi-SHP_DLT_VS80_B4B0A00001-nst
        mtPath: "/bin/mt"
        ddPath: "/bin/dd"
        timeoutInMilliseconds: 3600000
      -
        index: 1
        device: /dev/tape/by-id/scsi-SHP_DLT_VS80_B4B0A00002-nst
        mtPath: "/bin/mt"
        ddPath: "/bin/dd"
        timeoutInMilliseconds: 3600000
      -
        index: 2
        device: /dev/tape/by-id/scsi-SHP_DLT_VS80_B4B0A00003-nst
        mtPath: "/bin/mt"
        ddPath: "/bin/dd"
        timeoutInMilliseconds: 3600000
      -
        index: 3
        device: /dev/tape/by-id/scsi-SHP_DLT_VS80_B4B0A00004-nst
        mtPath: "/bin/mt"
        ddPath: "/bin/dd"
        timeoutInMilliseconds: 3600000

    fullCartridgeDetectionThresholdInMB : 2_000_000

4.2.5.15. 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 user’s 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ébogage. 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.16. Installation de la stack Prometheus

Note

Si vous disposez d’un serveur Prometheus et alertmanager, vous pouvez installer uniquement les exporters souhaités.

Prometheus server et alertmanager sont des addons dans la solution VITAM.

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:
        port: 9090
        tsdb_retention_time: "7d"
        tsdb_retention_size: "5GB"
    node_exporter:
        enabled: true
        port: 9101
        metrics_path: /metrics
    consul_exporter:
        enabled: true
        port: 9107
        metrics_path: /metrics
    elasticsearch_exporter:
        enabled: true
        port: 9114
        metrics_path: /metrics
    alertmanager:
        api_port: 9093
        cluster_port: 9094
  • L’adresse d’écoute de ces composants est celle de la patte d’administration.
  • Vous pouvez surcharger la valeur de certaines de ces variables (Par exemple le port d’écoute, le path de l’API).
  • Pour générer uniquement le fichier de configuration prometheus.yml à partir du fichier d’inventaire de l’environnement en question, il suffit de spécifier le répertoire destination dans la variable prometheus_config_file_target_directory

4.2.5.16.1. Playbooks ansible

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

  • Installer prometheus et alertmanager
ansible-playbook ansible-vitam-extra/prometheus.yml -i environments/hosts.<environnement> --ask-vault-pass
  • Générer le fichier de conf prometheus.yml dans le dossier prometheus_config_file_target_directory
ansible-playbook ansible-vitam-extra/prometheus.yml -i environments/hosts.<environnement> --ask-vault-pass

–tags gen_prometheus_config ..

4.2.5.17. Installation de Grafana

Note

Si vous disposez déjà d’un Grafana, vous pouvez l’utiliser pour l’interconnecter au serveur Prometheus.

Grafana est un addon dans la solution VITAM.

Grafana sera déployé sur l’ensemble des machines renseignées dans le groupe [hosts_grafana] de votre fichier d’inventaire.

Pour se faire, il suffit d’exécuter le playbook associée :

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

4.2.5.17.1. Configuration

Les paramètres de configuration de ce composant se trouvent dans le fichier environments/group_vars/all/advanced/cots_vars.yml. Vous pouvez adapter la configuration en fonction de vos besoins.

4.2.5.17.2. Configuration spécifique derrière un proxy

Si Grafana est déployé derrière un proxy, vous devez apporter des modification au fichier de configuration ansible-vitam-extra/roles/grafana/templates/grafana.ini.j2

Voici les variables modifiées par la solution VITAM pour permettre le fonctionnement de Grafana derrière un proxy apache.

[server]
root_url = http://{{ ip_admin }}:{{ grafana.http_port | default(3000) }}/grafana
serve_from_sub_path = true

[auth.basic]
enabled = false

Avertissement

Lors de la première connexion, vous devrez changer le mot de passe par défaut (login: admin; password: aadmin1234), configurer le datasource et créer/importer les dashboards manuellement.

4.2.5.18. Installation de restic

restic est un addon (beta) de la solution VITAM.

restic sera déployé sur l’ensemble des machines du groupe [hosts_storage_offer_default] qui possèdent le paramètre restic_enabled=true. Attention à ne renseigner qu’une seule fois ce paramètre par offer_conf.

Pour se faire, il suffit d’exécuter le playbook associé :

ansible-playbook --vault-password-file vault_pass.txt ansible-vitam-extra/restic.yml -i environments/hosts.<environnement>

4.2.5.18.1. Configuration

Les paramères de configuration de ce composant se trouvent dans les fichiers environments/group_vars/all/advanced/cots_vars.yml et environments/group_vars/all/main/vault-cots.yml. Vous pouvez adapter la configuration en fonction de vos besoins.

4.2.5.18.2. Limitations actuelles

restic est fourni en tant que fonctionnalité beta. À ce titre, il ne peut se substituer à des vérifications régulières de l’état des sauvegardes de vos bases.

restic ne fonctionne pas avec les providers openstack-swift, openstack-swift-v2 et tape-library.

restic ne fonctionne pas avec un cluster mongo multi-shardé. Ainsi, mongo-data ne peut être sauvegardé via restic que dans de petites instances de Vitam.