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
) sousenvironments/antivirus/
(norme : scan-<nom indiqué dans vitam-vars.yml>.sh) ; prendre comme modèle le fichierscan-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.