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. 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.4.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.4.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.5. 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
    ---

### 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:
        log_level: WARN
        start_timeout: 150
        stop_timeout: 3600
        port_service_timeout: 86400
    # 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
    # syslog_facility
    syslog_facility: local0


### consul ###
# FIXME: Consul à la racine pour le moment à cause de problèmes de récursivité dans le parsing yaml
# TODO : consul_domain should be in inventory as choosable by customer
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...
vitam_secondary_site_components: [ "consul" , "logbook" , "metadata" , "functional-administration" , "storage" , "storageofferdefault" , "offer" , "elasticsearch-log" , "elasticsearch-data" , "logstash" , "kibana" , "mongoc" , "mongod" , "mongos" , "vitam-metadata-reconstruction.timer" , "vitam-logbook-reconstruction.timer" , "vitam-functional-administration-reconstruction.timer" , "library" , "cerebro" ]


### Composants Vitam ###

vitam:
    accessexternal:
        vitam_component: access-external
        host: "access-external.service.{{ consul_domain }}"
        port_admin: 28102
        port_service: 8444
        baseuri: "access-external"
        https_enabled: true
        secret_platform: "false"
    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: "functional-administration"
        https_enabled: false
        secret_platform: "true"
        cluster_name: "{{ elasticsearch.data.cluster_name }}"
    ingestexternal:
        vitam_component: ingest-external
        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"
    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"
    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
    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 }}"
        # Overlap delay (in seconds) for logbook operation & lifecycle traceability events.
        # Set it to a reasonable delay to cover max clock difference across servers
        operationTraceabilityOverlapDelay: 300
        lifecycleTraceabilityOverlapDelay: 300
        disablePurgeForTempLFC: false
    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 }}"
    processing:
        vitam_component: processing
        host: "processing.service.{{ consul_domain }}"
        port_service: 8203
        port_admin: 28203
        baseuri: "processing"
        https_enabled: false
        secret_platform: "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"
    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
    storageofferdefault:
        vitam_component: "offer"
        port_service: 9900
        port_admin: 29900
        baseuri: "storage-offer-default"
        https_enabled: false
        secret_platform: "true"
    worker:
        vitam_component: worker
        port_service: 9104
        port_admin: 29104
        baseuri: "worker"
        https_enabled: false
        secret_platform: "true"
    workspace:
        vitam_component: workspace
        host: "workspace.service.{{ consul_domain }}"
        port_service: 8201
        port_admin: 28201
        baseuri: "workspace"
        https_enabled: false
        secret_platform: "true"

# ingestexternal:
# 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)

  • 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
    ---
consul_remote_sites:
    # - dc2:
    #   domain_name: "dc2"
    #   wan: ["10.10.10.10","1.1.1.1"]
    # - dc3:
    #   domain_name: "site3"
    #   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
    data:
        host: "elasticsearch-data.service.{{ consul_domain }}"
        port_http: "9200"
        port_tcp: "9300"
        groupe: "data"
        baseuri: "elasticsearch-data"
        cluster_name: "elasticsearch-data"
        https_enabled: false

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:
    log:
        metrics:
            close: 5
            delete: 30        
        logstash:
            close: 5
            delete: 30
        metricbeat:
            close: 5
            delete: 30
        packetbeat:
            close: 5
            delete: 30
        
kibana:
    log:
        baseuri: "kibana_log"
        groupe: "log"
        port: 5601
        # pour index logstash-*
        metrics:
            shards: 5
            replica: 1
        # pour index metrics-vitam-*
        logs:
            shards: 5
            replica: 1
    # KWA FIXME : changing port doesn't work, yet (not taken into account in kibana configuration)
    data:
        baseuri: "kibana_data"
        groupe: "data"
        port: 5601
        shards: 10
        replica: 2

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

vitam:
    accessinternal:
        jvm_opts:
            # memory: "-Xms512m -Xmx512m"
            # gc: ""
            # java: ""
    accessexternal:
        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.