4.2.4. Paramétrages supplémentaires

4.2.4.1. Tuning JVM

Note

Cette section est en cours de développement.

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 fichier 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.4.2. Paramétrage de l’antivirus (ingest-externe)

L’antivirus utilisé par ingest-externe 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 la télécharger ; il est donc nécessaire de renseigner dans l’inventaire la directive http_proxy_environnement.

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

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

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

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

consul_disabled: true

A l’issue, le déploiement n’installera pas l’agent Consul. Le composant ihm-demo appellera, alors, par l’adresse IP de services 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 de données sur « elasticsearch-log ».

4.2.4.5. Paramétrage de la centralisation des logs Vitam

2 cas sont possibles :

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

4.2.4.5.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.4.5.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.4.6. 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 :

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

### global ###

# TODO MAYBE : permettre la surcharge avec une syntax du genre vitamopts.folder_root | default(vitam_default.folder_root) dans les templates ?

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
    # 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

# Used in ingest, unitary update, mass-update
classificationList: ["Secret Défense", "Confidentiel Défense"]
# Used in ingest, unitary update, mass-update
classificationLevelOptional: true


### consul ###
# FIXME: Consul à la racine pour le moment à cause de problèmes de récursivité dans le parsing yaml
# 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" ]


### Composants Vitam ###

vitam:
    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
    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
    functional_administration:
        vitam_component: functional-administration
        host: "functional-administration.service.{{ consul_domain }}"
        port_service: 8004
        port_admin: 18004
        baseuri: "functional-administration"
        https_enabled: false
        secret_platform: "true"
        cluster_name: "{{ elasticsearch.data.cluster_name }}"
        # log_level: "DEBUG"
        metrics_enabled: true
    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
    batchreport:
        vitam_component: batch-report
        host: "batch-report.service.{{ consul_domain }}"
        port_service: 8015
        port_admin: 18015
        baseuri: "batch-report"
        https_enabled: false
        secret_platform: "false"
        # log_level: "DEBUG"
        metrics_enabled: true
    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"
        # 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
    ingestinternal:
        vitam_component: ingest-internal
        host: "ingest-internal.service.{{ consul_domain }}"
        port_service: 8100
        port_admin: 28100
        baseuri: "ingest-internal"
        https_enabled: false
        secret_platform: "true"
        # log_level: "DEBUG"
        metrics_enabled: true
    ihm_demo:
        vitam_component: "ihm-demo"
        host: "ihm-demo.service.{{ consul_domain }}"
        port_service: 8002
        port_admin: 28002
        baseurl: "/ihm-demo"
        static_content: "{{ vitam_defaults.folder.root_path }}/app/ihm-demo/v2"
        baseuri: "ihm-demo"
        https_enabled: false
        secret_platform: "false"
        # User session timeout in milliseconds (for shiro)
        session_timeout: 1800000
        secure_cookie: false
        # 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"
        metrics_enabled: true
    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
        # 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
    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
    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
    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
    storageengine:
        vitam_component: storage
        host: "storage.service.{{ consul_domain }}"
        port_service: 9102
        port_admin: 29102
        baseuri: "storage-engine"
        https_enabled: false
        secret_platform: "true"
        storageTraceabilityOverlapDelay: 300
        restoreBulkSize: 1000
        # log_level: "DEBUG"
        metrics_enabled: true
    storageofferdefault:
        vitam_component: "offer"
        port_service: 9900
        port_admin: 29900
        baseuri: "storage-offer-default"
        https_enabled: false
        secret_platform: "true"
        # log_level: "DEBUG"
        metrics_enabled: true
    worker:
        vitam_component: worker
        port_service: 9104
        port_admin: 29104
        baseuri: "worker"
        https_enabled: false
        secret_platform: "true"
        # log_level: "DEBUG"
        metrics_enabled: true
    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

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 :

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

consul:
    dns_port: 53

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"]

elasticsearch:
    log:
        host: "elasticsearch-log.service.{{ consul_domain }}"
        port_http: "9201"
        port_tcp: "9301"
        groupe: "log"
        baseuri: "elasticsearch-log"
        cluster_name: "elasticsearch-log"
        https_enabled: false
        # default index template
        index_templates:
            default:
                shards: 1
                replica: 1
    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"
        port_tcp: "9300"
        groupe: "data"
        baseuri: "elasticsearch-data"
        cluster_name: "elasticsearch-data"
        https_enabled: false
        # default index template
        index_templates:
            default:
                shards: 10
                replica: 2

mongodb:
    mongos_port: 27017
    mongoc_port: 27018
    mongod_port: 27019
    mongo_authentication: "true"
    host: "mongos.service.{{ consul_domain }}"

logstash:
    host: "logstash.service.{{ consul_domain }}"
    user: logstash
    port: 10514
    rest_port: 20514

# 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"
    log:
        baseuri: "kibana_log"
        api_call_timeout: 120
        groupe: "log"
        port: 5601
        default_index_pattern: "logstash-vitam*"
        # 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_*"
        # index template for .kibana
        shards: 1
        replica: 1

syslog:
    # value can be syslog-ng or rsyslog
    name: "rsyslog"

cerebro:
    baseuri: "cerebro"
    port: 9000

siegfried:
    port: 19000

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"

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.

  • environments /group_vars/all/jvm_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
    ---

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.