Réglages avancés des paramètres système

Changer les 2 occurrences "512" en la quantité de mémoire (méga-octets) que vous voulez allouer à Tomcat. Par exemple "**4096**" allouera 4 Go de mémoire à Tomcat :

48

49

50

set JVMMS=4096

set JVMMX=4096

(% class="box errormessage" %)

55

(((

56

Important : Sur un Windows 64 bits il n'y a pas de limite autre que la mémoire physique de votre ordinateur. Si La valeur est trop haute, alors Tomcat ne démarrera pas.

57

)))

58

59

(% class="box infomessage" %)

60

(((

61

//Note pour Windows 32 bits //: Si vous avez une configuration 32 bits (machine/OS), ou si vous avez déployé la version 32 bits de DigDash enterpise sur votre machine 64 bits, alors vous êtes limité dans la quantité de mémoire que vous pouvez allouer à Tomcat. La limite dans ce cas est connue pour être approximativement 1,5Go. Cela dépend notamment de la fragmentation de la mémoire à cet instant. Nos tests montrent en général que nous pouvons allouer 1,4Go sur un Windows 32 bits. Pour cette raison, nous recommandons une combinaison machine/OS 64 bits.

62

)))

63

64

(% class="box infomessage" %)

65

(((

66

Note pour la mémoire « PermGen Space » : Si vous rencontrez une erreur dans les logs portant la mention de « PermGen Space » vous pouvez augmenter cette valeur via la variable JVMMPS (au même endroit que les JVMMS et JVMMX).

67

)))

68

69

(% class="box errormessage" %)

70

(((

71

Important : Lorsque vous installez Tomcat en tant que service Windows (voir document [[install_guide_windows_fr.pdf>>http://install_guide_windows_fr.pdf/]]), à l'aide de **servers_install_service.bat** ou **servers_install_service_64.bat**, c'est le paramétrage de **setenv.bat **qui sera appliqué //lors de l'installation du service//.

72

73

Ainsi si vous souhaiter changer la mémoire allouée à Tomcat, il est obligatoire de :

74

75

1. Désinstaller le service à l'aide de la commande **sc delete Tomcat7** (ou autre nom que vous auriez spécifié à l'installation)

76

1. Changer les variables JVMMS et JVMMX du fichier **setenv.bat**

77

1. Relancer** servers_install_service.bat **ou **servers_install_service_64.bat**

78

)))

79

80

== Changer les ports réseau Tomcat ==

81

82

Fichier modifié : **server.xml**

83

84

Si un des ports nécessaires à Tomcat est déjà utilisé par un autre processus, alors il ne se lancera pas. Il est nécessaire de vérifier la disponibilité des ports et si besoin de reconfigurer Tomcat. Par défaut les 3 ports suivants sont configurés : 8005, 8080 et 8009. Pour les modifier :

85

86

1. Ouvrez le répertoire **<install DDE>\apache-tomcat/conf** puis éditer le fichier **server.xml**

87

1. Chercher et remplacer les valeurs des ports 8005, 8080 et 8009**.**

88

par des numéros de port disponibles sur le système

89

90

== Changer la durée de vie des sessions inactives (timeout) ==

91

92

Fichier modifié : **web.xml** (configuration globale de Tomcat situé à l'emplacement <DDE Install>/apache-tomcat/conf/web.xml)

93

94

Trouvez les lignes suivantes dans le fichier :

<session-config>

<session-timeout>30</session-timeout>

</session-config>

Changer la valeur pour modifier la durée de vie en minutes d'une session inactive (timeout). Par défaut le timeout est de 30 minutes.

103

104

105

== Changer le nombre maximum de requêtes simultanées ==

106

107

Fichier modifié : **server.xml**

108

109

Par défaut Tomcat n’acceptera pas plus de 200 requêtes **simultanées**. Ce paramétrage peut se révéler limitant dans le cas d’un déploiement à un grand nombre d’utilisateurs (plusieurs milliers ou millions), ou lors d’un bench de performance (ex. jmeter) qui exécute des centaines ou des milliers de requêtes simultanées.

110

111

Pour augmenter cette limite, il faut ajouter un attribut **maxthreads** dans l’élément **Connector** correspondant au connecteur utilisé.

112

113

Exemple lorsque le connecteur utilisé est http (il n’y a pas d’Apache en front-end) :

Exemple lorsque le connecteur utilisé est AJP (il y a un Apache en front-end) :

== Activer la compression HTTP ==

126

127

Fichier modifié : **server.xml**

128

129

La compression HTTP permet de diminuer la consommation de la bande passante du réseau en compressant les réponses HTTP. Par défaut cette option n’est pas activée dans Tomcat, même si tous les navigateurs modernes la supportent.

130

131

Cette option permet d’économiser parfois jusqu’à 90 % la bande passante sur certains types de fichiers : HTML, Javascript, CSS. En consommant peu de CPU sur le serveur et le client.

132

133

(% class="box errormessage" %)

134

(((

135

Important : Cette option ne fonctionne que si Tomcat est utilisé directement en serveur front-end via le connecteur HTTP/1.1. S’il y a un Apache httpd en front-end, alors il faudra activer l’option équivalente dans Apache httpd lui-même (voir la documentation directement sur le site Apache httpd).

136

La compression HTTP n’est pas supportée sur le connecteur AJP, ni sur aucun autre connecteur que HTTP(S)/1.1.

137

)))

138

139

Dans le fichier **server.xml** ajouter les attributs **compression="on"** et **compressionMinSize="40000"** sur le connecteur HTTP/1.1:

Exemple :

L’attribut **compressionMinSize** définit une taille minimale de réponse (en octets) au dessous de laquelle la compression n’est pas utilisée. Il est conseillé de spécifier cet attribut à une valeur suffisante pour ne pas compresser des fichiers déjà très petits (icônes PNG…).

148

149

(% class="box infomessage" %)

150

(((

151

Note : Ce réglage n’a pas d’incidence si un navigateur utilisé ne supporte pas la compression HTTP. Tomcat décidera alors de ne pas compresser les réponses HTTP pour ce navigateur.

152

)))

153

154

= Paramètres de performance avancés =

155

156

Fichier modifié : **system.xml**

157

158

Exemple de syntaxe XML :

159

//{{code language="xml"}}<Property key="CORE_TP_EXECSIZE" value="64"></Property>{{/code}}//

160

161

== Threads utilisés pour l'exécution des flux programmés ==

162

163

Modifie le nombre de « threads » utilisés pour l'exécution des flux programmés (ordonnanceur).

164

165

Paramètres disponibles :

166

167

* //Nom// : **INIT_TP_EXECSIZE**

168

//Valeur// : entier >= 0 (défaut : 16)

169

//Description// : Nombre de threads créés au démarrage du serveur

170

* //Nom// : **CORE_TP_EXECSIZE**

171

//Valeur// : entier >= 0 (défaut : 16)

172

//Description// : Nombre de threads à garder quand le serveur est inactif

173

* //Nom// : **MAX_TP_EXECSIZE**

174

//Valeur //: entier > 0 (défaut : 16)

175

//Description// : Nombre de threads maximum lorsque le serveur fonctionne

176

177

== Threads utilisés pour l'exécution des flux interactifs ==

178

179

Modifie le nombre de « threads » utilisés pour l'exécution interactive des flux (console d'administration, tableau de bord, mobile, etc).

180

181

Paramètres disponibles :

182

183

* //Nom// : **INIT_TP_PLAYSIZE**

184

//Valeur// : entier >= 0 (défaut : 4)

185

//Description// : Nombre de threads créés au démarrage du serveur

186

* //Nom// : **CORE_TP_PLAYSIZE**

187

//Valeur// : entier >= 0 (défaut : 4)

188

//Description// : Nombre de threads à garder quand le serveur est inactif

189

* //Nom// : **MAX_TP_PLAYSIZE**

190

//Valeur //: entier > 0 (défaut : 4)

191

//Description// : Nombre de threads maximum lorsque le serveur fonctionne

192

193

== Délais de suppression des cubes en mémoire ==

194

195

Modifie la manière dont le Cube Manager supprime les cubes inutilisés en mémoire.

196

197

Les paramètres suivants modifient la manière dont les cubes non utilisés depuis un certain temps sont supprimés, même si la session est toujours active.

198

199

Paramètres disponibles :

200

201

* //Nom// : **CUBE_TIMEOUT_INTERACTIVE**

202

//Valeur// : minutes > 0 (défaut : 10 minutes)

203

//Description// : Durée de la période d'inactivité pour un cube chargé en mode interactif (navigation du cube sur le serveur)

204

* //Nom// : **CUBE_TIMEOUT_SYNC**

205

//Valeur// : minutes > 0 (défaut : 4 minutes)

206

//Description// : Durée de la période d'inactivité pour un cube chargé en mode programmé (génération d'un flux programmé)

207

* //Nom //: **CUBE_TIMEOUT_PERIOD**

208

//Valeur// : minutes > 0 (défaut : 2 minutes)

209

//Description// : Intervalle de vérification de l'inactivité des cubes, devrait être au moins **CUBE_TIMEOUT_SYNC** / 2

210

211

== Performance des cubes de données ==

212

213

A part la compression des cubes (CUBE_COMPRESSION), tous ces paramètres affecteront le traitement interactif des cubes de données (aplatissement en cubes résultats pendant l'affichage). Ces paramètres n'affectent pas la génération des cubes de données.

214

215

Paramètres disponibles :

216

217

* //Nom// : **CUBEPART_MAXSIZEMB**

218

//Valeur// : méga-octets > 0 (défaut : 100 Mo)

219

//Description// : Taille d'une part de cube en méga-octets. Une part de cube est une partie du cube de données qui peut être traitée (aplatie) en parallèle ou distribuée sur d'autres serveur DigDash Enterprise en mode cluster (voir chapitre "//Utilisation de plusieurs serveurs en mode cluster//" dans ce document).

220

* //Nom// : **TP_MCUBESIZE**

221

//Valeur// : threads > 0 (défaut : 64 threads)

222

//Description// : Taille de la file de threads utilisés pour le traitement en parallèle des parts de cube. Les gros cubes (ex: plusieurs millions/milliards de lignes) sont traités en parallèle par le serveur, et/ou par d'autres serveurs (en mode cluster). Ce paramètre est le nombre d'unités parallèle de traitement (thread) sur une machine. Chaque part de cube occupe une unité de la file le temps de son traitement, si la file est pleine les unités supplémentaires sont mises en attente.

223

* //Nom// : **MCUBE_ROWS_PER_THREAD**

224

//Valeur// : lignes > 0 (défaut : 100000)

225

//Description// : C'est la limite du nombre de ligne d'un cube de données au delà de laquelle le serveur DigDash Enterprise activera le traitement parallèle des parts du cube (s'il y a plus d'une part pour ce cube). En dessous de cette limite, le traitement du cube n'est pas parallélisé mais séquentiel.

226

* //Nom// : **CUBE_COMPRESSION**

227

//Valeur// : booléen (défaut : true)

228

//Description// : Contrairement aux autres paramètres de ce chapitre, celui-ci affecte la performance de génération d'un cube de données, mais pas celle de son traitement (aplatissement). Il (dés)active la compression du stockage des cubes de données sur le disque dur. Par défaut, DigDash Enterprise compresse le stockage des cubes de données (true), ce qui réduit l'espace disque utilisé par les cubes, mais ralentit aussi leur génération (notez que le temps de chargement n'est quasiment pas impacté par ce paramètre). Si vous souhaitez accélérer la génération des cubes (et que vous disposez d'un grand espace disque disponible), vous pouvez passer ce paramètre à false.

229

230

== Autres paramètres de performance ==

231

232

Les paramètres suivants servent à analyser ou optimiser les performances du système.

233

234

Paramètres disponibles :

235

236

* //Nom// : **LOW_MEMORY_THRESHOLD**

237

//Valeur// : pourcentage > 0 (défaut : 10%)

238

//Description// : C’est le seuil en pourcentage de mémoire libre restante au dessous duquel le système émettra une alerte de mémoire basse. Cette alerte est visible dans la page d’état du serveur pendant 24 heures. Elle est aussi enregistrée dans la base de données DDAudit si le service d’audit système est démarré.

239

Enfin, un événement DigDash est aussi déclenché lorsque le seuil est atteint : SYSCHECK_LOWMEM. Un exemple d’utilisation de cet événement est donné dans le document de déploiement du module DDAudit.

240

* //Nom// : **PRIORITY_POOL**

241

//Valeur// : booléen (défaut : false)

242

//Description// : Utilise un pool de threads de rafraîchissements avec gestion de priorité pour les rafraîchissements de flux et cubes. Ce paramètre doit être accompagné du paramètre **PRIORITY_FLOW** (voir ci-dessous).

243

* //Nom// : **PRIORITY_FLOW**

244

//Valeur// : booléen (défaut : false)

245

//Description// : Si le pool de threads de rafraîchissements utilise la gestion de priorité (**PRIORITY_POOL** = true), ce paramètre indique que la génération des vues de flux est prioritaire sur la génération des cubes. Cela permet de mieux répartir la charge mémoire lors des génération de nombreux cubes et flux. Les flux utilisant un cube sont rafraîchis juste après le rafraîchissement de ce cube (true), et non plus après le rafraîchissement de tous les autres cubes (false). Ce paramètre doit être accompagné du paramètre **PRIORITY_POOL** = true.

246

247

= Service de maintenance Automatique =

248

249

DigDash Enterprise fournit un service de maintenance composé :

250

251

* D’un nettoyeur de fichiers (connu aussi en tant que Files GC) nettoyant l'ensemble des fichiers inutilisés : vieux fichiers de l'historique, cubes et autres fichiers dépendant des flux.

252

* D’une sauvegarde automatique de la configuration

253

254

Nettoyeur de fichiers

255

256

Le nettoyeur nettoie les fichiers non utilisés par les portefeuilles des utilisateurs et des rôles.

257

258

Le nettoyage parcourt les index de tous les utilisateurs, ainsi que le disque, afin de trouver les fichiers qui ne sont plus liés aux index. Les fichiers identifiés sont supprimés. Les fichiers effacés sont les suivants : fichiers de cubes (.dcg), fichiers js des cubes (cube_data_id.js), modèles (cube_dm_id.js) et flux (cube_view_id_js).

259

260

Cette opération présente l'avantage de libérer de l'espace disque et potentiellement d'accélérer les recherches de fichiers js, qui peuvent devenir non négligeables sur des volumétries importantes (nombre de cubes personnels * nb historiques > 100000)

261

262

Selon l'âge du serveur et la volumétrie des fichiers concernés (nombre de rafraîchissements effectués...), l'opération peut prendre beaucoup de temps lors de sa première exécution (sur certains déploiements comportant beaucoup d'utilisateurs et beaucoup de cubes personnalisés, une à deux heures).

263

264

Ensuite, si le nettoyage est fait de manière régulière, le temps d'exécution sera moins long. Ce temps dépend énormément de la performance du système de fichiers et de la machine, ce qui le rend difficilement estimable.

265

266

Sauvegarde automatique

267

268

La sauvegarde automatique est effectuée avant le nettoyage des fichiers. Le fichier générés est copié dans le dossier de configuration **<digdash.appdata>/Enterprise Server/<domaine>/backups/<date du jour>.zip**

269

270

Par défaut, la maintenance se fait tous les jours à minuit.

271

272

(% class="box errormessage" %)

273

(((

274

Important : Par défaut le service de maintenance ne se lance que si aucune session utilisateur n'est active à ce moment. De plus, pendant son fonctionnement aucun utilisateur ne peut se connecter à DigDash Enterprise. Attention donc à bien le programmer pour qu'il n'interfère pas avec l'utilisation normale de DigDash Enterprise par les utilisateurs, ni par l'ordonnanceur. Selon les cas nous conseillons de programmer le service de maintenance la nuit, et à des plages horaires différentes des plages de l'ordonnanceur.

275

)))

276

277

Ce paragraphe décrit comment activer et programmer le service de maintenance.

278

279

== Activation, désactivation et/ou nettoyage au démarrage ==

280

281

L'activation du nettoyeur de fichiers peut se faire de deux manières :

282

283

=== 1- //Depuis la page état du serveur //: ===

284

285

La page Etat du serveur est accessible depuis la page d'accueil de DigDash Enterprise puis en cliquant successivement sur les liens **Configuration **et **Etat du serveur**.

286

287

Dans la rubrique Etat du nettoyeur de fichiers, cliquez sur la flèche verte figurant à côté de **Nettoyeur de fichier démarré** pour démarrer le nettoyeur :

288

289

[[image:serverstatus-filesgc.png]]

290

Le prochain nettoyage aura lieu à minuit. Pour démarrer le nettoyeur de fichiers immédiatement, cliquez sur l’icône .

291

292

=== 2- //Depuis le fichier web.xml// : ===

293

294

Fichier modifié : **web.xml / ddenterpriseapi.properties (ddenterpriseapi)**

295

296

Active ou non le module Files GC et/ou lance le nettoyage au démarrage du serveur

297

298

Paramètres disponibles :

299

300

* //Nom// : **startCleaner**

301

//Valeur// : booléen (défaut : false)

302

//Description// :

303

* true : nettoyage automatique des fichiers programmé.

304

//Note: l'heure du nettoyage est définie dans **system.xml**, par le paramètre **FILESGC_SCHEDXML**.

305

L'heure de nettoyage par défaut (si aucune n'est spécifiée dans system.xml, FILESGC_SCHEDXML) est tous les jours à 0:00//

306

* false (défaut) : pas d'utilisation du nettoyeur de fichiers

307

* //Nom// : **cleanOnStart**

308

//Valeur// : booléen (défaut : false)

309

//Description// :

310

* true : nettoie les fichiers inutilisés au démarrage du serveur (fichiers de l'historique, cubes, fichiers résultats,...)

311

* false (défaut) : ne nettoie pas les fichiers inutilisés au démarrage du serveur

312

* //Nom// : **autoBackup**

313

//Valeur// : booléen (défaut : false)

314

//Description// :

315

** ***. true : active la sauvegarde automatique programmée**

316

*** false (défaut) : n’active pas la sauvegarde automatique programmée

317

318

== Programmation et options de la maintenace automatique ==

319

320

Fichier modifié : **system.xml**.

321

322

Paramètres disponibles :

323

324

* //Nom// : **FILESGC_SCHEDXML**

325

//Valeur// : phrase XML (encodée) (défaut : aucune)

326

//Description// : Ce paramètre contient une phrase XML //encodée// décrivant la fréquence de programmation.

327

328

Exemple:

329

//{{code language="xml"}}<Property key="FILESGC_SCHEDXML"

330

value="<Schedule frequency="daily"

331

fromDay="11" fromHour="0"

332

fromMinute="0" fromMonth="7"

333

fromYear="2011" periods="1"

334

time="0:0"/>"></Property>{{/code}}//

335

336

Les attributs intéressants sont : **frequency** (**hourly**, **daily** ou **monthly**), **periods** (nombre d'heures, jours ou mois entre 2 nettoyages) et **time** (heure du nettoyage pour les fréquences daily et monthly). Cet exemple signifie tous les jours (frequency="daily" et periods="1") à 0:00 (time="0:0").

337

338

* //Nom// : **FILESGC_SESSIONSCHECK**

339

//Valeur// : true/false (booléen) (défaut : aucune, équivaut à true)

340

//Description// : Ce paramètre indique si le nettoyeur de fichiers doit vérifier les sessions actives avant de se lancer (true), ou s'il se lance qu'elle que soit l'état des sessions actives (false). Dans ce dernier cas, toutes les sessions seront déconnectées instantanément.

341

342

Exemple:

343

//{{code language="xml"}}<Property key="FILESGC_SESSIONSCHECK" value="false"></Property>{{/code}}//

344

345

* //Nom// : **USEAUTOBACKUP**

346

//Valeur// : true/false (booléen) (défaut : aucune, équivaut à false)

347

//Description// : Ce paramètre indique si le service de maintenance effectue aussi une sauvegarde complète de la configuration avant d’exécuter le nettoyage des fichiers.

348

349

= Utilisation de plusieurs serveurs en mode "Cluster" =

350

351

Pour gérer un plus grand volume de données (milliard de lignes), il est possible d'utiliser plusieurs serveurs en mode "Cluster". Chaque serveur devient un nœud de calcul du cluster. Ce dernier regroupe un serveur maître et des serveurs esclaves.

352

353

Le serveur maître s'occupe de gérer les modèles, les documents, les rôles, les utilisateurs, les sessions et de générer les cubes et les flux (rafraîchissement). A l'identique d'un serveur Digdash Enterprise en mode standard mono-machine.

354

355

Les serveurs esclaves additionnels ne sont utilisés que pour aider à l’aplatissement interactif des cubes de données volumineux, lors de l'affichage de flux, filtrage, drills, etc.

356

357

Il existe deux architectures de clustering dans DigDash Enterprise :

358

359

* Clustering interne : Décrit dans ce chapitre

360

* Cluster Apache Ignite : [[Module Cluster Apache Ignite>>doc:.ignite_cluster_guide.WebHome]]

361

362

== Installer DigDash Enterprise en mode "Cluster" ==

363

364

Pré-requis: plusieurs machines connectées entre elles par le réseau

365

366

=== Serveur maître (sur la machine la plus puissante du cluster): ===

367

368

1. Installation standard de DigDash Enterprise (voir la documentation).

369

1. Démarrer le serveur normalement avec **start_servers.bat**

370

371

=== Serveur esclave (sur chacune des autres machines du cluster): ===

372

373

1. Installation standard de DigDash Enterprise (voir la documentation).

374

La différence est qu'un serveur esclave n'a pas besoin de licence pour servir d'unité de calcul au cluster. Il n'a pas besoin non plus d'annuaire LDAP, ni de serveur de document SVN. Il n'a pas besoin non plus de l'application digdash_dasboard dont le war pourrait être accessoirement supprimé de Tomcat.

375

1. Démarrer uniquement le module Tomcat, avec **start_tomcat.bat**

376

377

== Configurer le cluster ==

378

379

Procédure à répéter sur chaque serveur du cluster

380

381

1. Avec un navigateur, se connecter à la page principale de DigDash Enterprise (ex: http:~/~/<serveur>:8080)

382

1. Cliquer sur **Configuration**, puis **Paramètres Serveur**

383

1. S'identifier en tant qu'administrateur de DigDash Enterprise (admin/admin par défaut) pour afficher la page des paramètres du serveur

384

1. Cliquer en bas de page sur le lien **Paramètres du cluster**

385

1. Remplir les différents champs en fonction de chaque machine serveur (voir explications ci-dessous)

386

387

=== Section Performance du système ===

388

389

[[image:1000000000000217000000B412D8076EC473E63D.png]]

390

La section **Performance du système** définit les capacités de la machine courante dans le cluster. Les paramètres **Nombre de CPU**, **Score CPU** et **Mémoire allouée** permettent de répartir au mieux la charge de calcul.

391

392

1. **Nombres de CPU **: le nombre de processeurs * nombre de cœurs sur chaque processeurs. Potentiellement multiplié par un facteur si les processeurs bénéficient d'une technologie type Hyper-threading. Par défaut -1, s'appuie sur les données renvoyées par le système d'exploitation

393

1. **Score CPU **: c'est une note entre 1 et 10 qui permet de relativiser la performance d'un noeud du cluster par rapport aux autres (cas d'un cluster hétérogène). Par défaut -1 donne une note moyenne (5).

394

1. **Mémoire allouée **: la fraction de la mémoire maximale autorisée dans le cadre d'utilisation du serveur comme unité de calcul. Cette valeur est inférieure ou égale à la mémoire allouée au serveur Tomcat. Par défaut -1 autorise toute la mémoire.

395

396

=== Section Clusters autorisés ===

397

398

[[image:1000000000000218000001054AF17D67C50C7D0C.png]]

399

La section **Clusters autorisés** permet de spécifier si la machine courante peut être utilisée comme esclave d'un ou plusieurs cluster(s), et si oui lesquels. En effet une machine peut servir à plusieurs clusters DigDash Enterprise. Cette section restreint cette utilisation en tant qu'esclave à seulement certains clusters (liste **Sélection**) ,

400

401

C'est également dans cette section que nous définissons le **Mot de passe** du serveur courante dans le cluster sélectionné. Sans mot de passe le serveur ne peut être esclave dans ce cluster.

402

403

Pour ajouter un cluster autorisé à utiliser ce serveur esclave:

404

405

1. **Nom **: nom du cluster (arbitraire)

406

1. **Adresse IP du serveur maître** : adresse IP du serveur maître du cluster autorisé à utiliser ce serveur comme esclave (ex: http:~/~/192.168.1.1)

407

1. **Mot de passe** : Mot de passe de l'esclave dans le contexte du cluster sélectionné

408

1. Cliquer sur le bouton **Ajouter** pour ajouter ce cluster à la liste des clusters autorisés

409

410

(% class="box infomessage" %)

411

(((

412

Note : Vous pouvez éditer ou supprimer des cluster autorisés en les sélectionnant dans la liste **Sélection**, puis en cliquant sur les boutons **Editer** ou **Supprimer**.

413

)))

414

415

=== Section Définition du cluster ===

416

417

A renseigner seulement sur le serveur Maître du cluster

418

419

[[image:10000000000002150000011E23A4AEFD25BECB14.png]]

420

La section **Définition du cluster** //ne concerne que le serveur maître// du cluster. C'est ici que nous créons un cluster en listant les serveurs esclaves du cluster ainsi que le maître lui-même (liste **Sélection**, champs **Nom**, **Adresse**, **Domaine** et **Mot de passe**). Le serveur maître est implicitement le serveur via lequel vous vous êtes connecté à cette page.

421

422

Pour ajouter une machine esclave au cluster:

423

424

1. **Nom **: nom de machine esclave (arbitraire)

425

1. **URL du serveur** : URL du serveur esclave (ex: http:~/~/192.168.1.123:8080)

426

1. **Domaine** : Domaine DigDash Enterprise (par défaut ddenterpriseapi)

427

1. **Mot de passe** : Mot de passe de l'esclave tel que vous l'avez précédemment tapé lors de la configuration de la machine esclave (section **Clusters autorisés**, champ **Mot de passe**)

428

1. Cliquer sur le bouton **Ajouter** pour ajouter cette machine à votre cluster.

429

430

(% class="box infomessage" %)

431

(((

432

Note : Vous pouvez éditer ou supprimer des machines du cluster en les sélectionnant dans la liste **Sélection**, puis en cliquant sur les boutons **Editer** ou **Supprimer**.

433

)))

434

435

Utilisation de plusieurs maîtres dans un cluster

436

437

Certain déploiements nécessitent l’utilisation de plusieurs serveurs maîtres au sein d’un même « cluster ». Par exemple dans le cas d’un load balancer HTTP en amont qui envoie les sessions utilisateurs sur l’une ou l’autre machine maître. Ce mode est supporté dans DigDash en définissant plusieurs clusters identiques (un par machine maître). La liste des machines (Section Définition du cluster) doit être strictement identique sur toutes les définitions des clusters. C’est pour cela qu’il est possible de changer l’ordre des machines dans cette liste.

438

439

Exemple : On souhaite définir un cluster qui consiste en deux machines A et B. Chacune des deux machines est maître et esclave de l’autre.

440

441

On doit définir non pas un mais deux clusters A et B :

442

443

Dans la définition du cluster A :

444

445

1. [[Digdash 2019R2.Guide avancé.Serveur courant.WebHome]] : machine A (maître de ce cluster)

446

1. machine B (esclave de ce cluster)

447

448

Dans la définition du cluster B :

449

450

1. machine A (esclave de ce cluster)

451

1. [[Digdash 2019R2.Guide avancé.Serveur courant.WebHome]] : machine B (maître de ce cluster)

452

453

On voit que dans le cluster B, le maître (B) n’est pas la première machine de la liste. Ce qui est important ici c’est que la liste machine A, machine B est bien la même sur les deux clusters (qu’elle que soit leur fonction propre au sein de leur cluster respectif).

454

455

== Paramètres avancés spécifiques au clusters ==

456

457

Fichier modifié : **system.xml**

458

459

Exemple de syntaxe XML :

460

//{{code language="xml"}}<Property key="CLUSTER_TIMEOUT" value="45000"></Property>{{/code}}//

461

462

Paramètres disponibles :

463

464

* //Nom// : **CUBE_UPLOAD_MODE**

465

//Valeur// : entier : 0, 1 ou 2 (défaut : 1)

466

//Description// : Spécifie si les parts de cube doivent être téléchargées du serveur maître vers les serveurs esclaves au moment ou un utilisateur interagit avec le cube (1), quand le cube est généré par le serveur maître (2), ou jamais (0). Voir également le chapitre suivant : "//Utiliser le cluster//".

467

* Nom : **CLUSTER_TIMEOUT**

468

Valeur : entier : (millisecondes, défaut: 30000)

469

Description : Spécifie le timeout de toutes les requêtes intra-cluster (entre le maître et les esclaves), à l’exception de la requête de vérification de disponibilité d’un esclave (voir ci-dessous)

470

* Nom : **CLUSTER_CHECK_TIMEOUT**

471

Valeur : entier : (millisecondes, défaut: 5000)

472

Description : Spécifie le timeout de la requête de vérification de disponibilité d’un esclave. Ce timeout est plus court pour empêcher de bloquer trop longtemps le maître dans le cas ou un esclave est déconnecté du réseau.

473

474

== Utiliser le cluster ==

475

476

Dans un déploiement simple en mode cluster il n'y a rien à faire de plus que ce qui a été écrit précédemment.

477

478

Malgré tout, il y a certains détails intéressants qui peuvent aider à améliorer la performance d'un cluster.

479

480

Le cluster est utilisé en fonction de la taille du cubes de données. En dessous d'un certain seuil, dépendant du cube, de la machine maître et des esclaves, il est possible que le cluster ne soit pas utilisé. Par contre si la taille d'un ou plusieurs cubes de données devient importante, par exemple au delà de plusieurs centaines de millions de lignes, ceux-ci seront découpés en plusieurs parties et leur calcul (aplatissement) sera réparti en parallèle sur tous les processeurs disponibles du cluster pour diminuer le temps de réponse global. Et ceci pour chaque aplatissement d'un gros cube par un utilisateur du tableau de bord, du mobile, etc.

481

482

Il est à noter que la génération des cubes est de la responsabilité du serveur maître. Les esclaves n'interviennent que lors des aplatissements interactifs de cubes déjà générés (ex: affichage d'un flux, filtrage, drill...)

483

484

Les morceaux de cubes sont envoyés aux esclaves à la demande (s'ils ne les ont pas déjà). Ceci peut induire un ralentissement du système sur un premier aplatissement demandé par un utilisateur, notamment si la bande passante du réseau est faible (< 1 gigabit).

485

486

Il y a toutefois différents moyens d'éviter cet encombrement du réseau. Voici quelques suggestions :

487

488

Un premier moyen est de disposer du dossier **cubes** (sous-dossier de Application Data/Enterprise Server/ddenterpriseapi par défaut) sur un disque réseau accessible à toutes les machines du cluster. Par exemple via un lien symbolique (Linux, NFS). Ce lien devra être établi pour toutes les machines du cluster. Le principe est que le serveur maître générera les cubes dans ce dossier réseau, et lors de l'interaction d'un utilisateur avec le système, maître et esclaves auront tous une vue //commune// des cubes. La lecture des cubes du disque n'étant faite qu'une fois dans le cycle de vie d'un cube (cube //in-memory//), l'impact du dossier réseau sur les performances est négligeable.

489

490

Un autre moyen, est d'utiliser un outil tierce de synchronisation automatique de dossiers entre plusieurs machines, qui pourra copier l'ensemble du dossier cubes du serveur, après leur génération, vers les machines esclaves. Le principe est que le serveur maître générera les cubes dans son dossier local, puis l'outil de synchronisation copiera ce dossier sur toutes les machines esclaves. Tout ceci en dehors des périodes d'activité du serveur. Maître et esclaves auront tous une vue //identique// des cubes.

491

492

= Autres réglages avancés =

493

494

== Changement du chemin des fichiers de données ==

495

496

Le chemin dans lequel DigDash Enterprise stocke les informations de configuration, les modèles de données, les portefeuilles d'information, les cubes, l'historique des flux et d'autres fichiers de travail se trouve par défaut dans le **dossier de l'utilisateur du système d'exploitation**, dans un sous dossier **Application Data/Enterprise Server/<domaine>**.

497

498

Par exemple sous Windows, ce dossier est :

499

500

C:\Users\<utilisateur>\AppData\Roaming\Enterprise Server\ddenterpriseapi

501

502

Dans certains cas il est souhaitable de modifier ce dossier, soit pour avoir plus d'espace de stockage disponible, soit pour des raisons d'organisation, de scripting, etc.

503

504

Il existe plusieurs moyen de modifier ce chemin.

505

506

=== Au niveau global (Tomcat): ===

507

508

Fichier à modifier : **setenv.bat**

509

510

La variable système optionnelle **digdash.appdata** permet de spécifier un dossier où DigDash Enterprise stockera ses fichiers de données.

511

512

Dans le fichier **<DDE Install>/configure/setenv.bat** ajouter la ligne:

513

514

515

@set CATALINA_OPTS=-Ddigdash.appdata=<chemin du nouveau dossier de données>

516

517

518

(% class="box errormessage" %)

519

(((

520

Important : Le chemin est interprété comme une variable Java, les séparateurs de dossiers doivent être des / et non des \ et ce même sous Windows. Il n'y a pas d'espace entre -D et digdash.appdata.

521

Cette méthode ne fonctionnera pas si Tomcat est installé en tant que service.

522

)))

523

524

Si ce dossier n'existe pas, DigDash Enterprise le créé. Les données ne seront pas stockées directement dans ce dossier, mais dans un sous dossier **<digdash.appdata>/Enterprise Server/<domaine>**

Exemple:

Pour stocker les données Digdash Enterprise sur un autre disque dur que le disque système:

529

530

1. Modifier **<DDE Install>/configure/setenv.bat** en ajoutant la ligne :

531

//{{code language="batch"}}@set CATALINA_OPTS=-Ddigdash.appdata=D:/digdashdata{{/code}}//

532

1. Relancer le serveur Tomcat

533

1. Un dossier **D:\digdashdata\Enterprise Server\ddenterpriseapi** se créé et contiendra toute l'arborescence des données de DigDash Enterprise

Avantage :

La configuration se faisant au niveau du script **setenv.bat**, elle ne sera pas écrasée lors de la mise à jour de DigDash Enterprise par déploiement de nouveaux fichiers WAR.

Inconvénient :

Cette configuration est globale au Tomcat de DigDash Enterprise, donc tous les domaine DigDash Enterprise de ce serveur sont concernés. Cependant les données des différents domaines DigDash Enterprise déployés dans ce Tomcat ont bien leur sous-dossier propre, il n'y a aucun risque d'écrasement des données.

542

543

=== Au niveau d'un domaine (web.xml du contexte concerné): ===

544

545

Fichier modifié : **web.xml** (ddenterpriseapi)

546

547

La variable **AppDataPath** définie dans ce fichier (valeur vide par défaut) a le même comportement que la variable système décrite ci-dessus.

548

549

La différence est que ce paramétrage est spécifique à un domaine DigDash Enterprise.

Avantage :

Configuration locale à un domaine

Inconvénient :

La mise à jour de DigDash Enterprise par déploiement d'un nouveau fichier WAR écrasera cette configuration (web.xml est écrasé lors du déploiement du WAR).

558

559

=== Au niveau d'un domaine (fichier externe ddenterprise.properties): ===

560

561

Fichier modifié : **ddenterpriseapi.properties**

562

563

Ce fichier n’existe pas par défaut : lire le [[chapitre V.5>>||anchor="V.5"]] pour plus d’information sur les fichier //properties.//

564

565

La variable **AppDataPath** définie dans ce fichier a le même comportement que la variable système ou contexte décrite ci-dessus.

566

567

La différence est que ce paramétrage est spécifique à un domaine DigDash Enterprise //et// externalisée dans un fichier //properties//, et donc, non impacté par lors du déploiement du WAR mis à jour.

Avantage :

Configuration locale à un domaine

572

573

Fichier externe au WAR

Inconvénient :

Il faut créer ce fichier.

578

579

== Règlages LDAP (adswrapper) : Port et nom d'instance ==

580

581

=== Port Réseau du serveur LDAP (adswrapper) ===

582

583

Fichier modifié : **web.xml** (adswrapper) ou **adswrapper.properties**

584

585

La variable **ads.ldap.port** (valeur par défaut : **11389**) défini le port réseau utilisé par le serveur LDAP intégré à DigDash Enterprise. Il faut changer cette valeur si elle est déjà utilisé par un autre process sur la machine, ou une autre instance LDAP (d'un autre domaine DigDash sur la même machine par exemple).

586

587

=== Chemin et nom d'instance LDAP (adswrapper) ===

588

589

Fichier modifié : **web.xml** (adswrapper) ou **adswrapper.properties**

590

591

La variable **ads.instance.name** (valeur par défaut : **ldapdigdash**) défini le chemin et le nom de l'instance de l'annuaire LDAP utilisé par DigDash Enterprise. Il faut changer cette valeur si deux domaines DigDash dans le même Tomcat veulent utiliser chacun leur propre instance LDAP.

592

593

(% class="box errormessage" %)

594

(((

595

Important : Cette variable sert aussi à définir le chemin du dossier contenant les données de l’instance LDAP. Si sa valeur est un chemin absolu sur le disque alors les données de l’instance seront stockées dans ce chemin.

596

597

Exemple : //ads.instance.name=/path/to/ldapdigdash//

598

)))

599

600

== Paramètres avancés de l'éditeur / viewer de tableaux de bord ==

601

602

=== Paramètres dashboard_system.xml ou digdash_dashboard.properties ===

603

604

Fichier modifié : **dashboard_system.xml** ou **digdash_dashboard.properties**

605

606

Ce fichier se trouve dans le dossier **<utilisateur>/Application Data/Enterprise Server/dashboard_system.xml**. Par défaut ce fichier n'existe pas, il faudra donc le créer. C'est un fichier XML au format suivant :

<Property key="<nom paramètre>" value="<valeur paramètre>"/>

611

<Property key="<nom paramètre>" value="<valeur paramètre>"/>

612

<Property key="<nom paramètre>" value="<valeur paramètre>"/>

</SystemProperties>

(% class="box infomessage" %)

617

(((

618

Note : Tous ces paramètres peuvent également être spécifié dans **<DDE Install>/apache-tomcat/webapps/digdash_dashboard/WEB-INF/web.xml** ou un fichier **digdash_dashboard.properties** si spécifié (voir chapitre V.5)

619

)))

620

621

Paramètres disponibles :

622

623

* //Nom// : **SERVERURL**

624

//Valeur// : URL du serveur DigDash Enteprise

625

//Description// : URL du serveur sur lequel le tableau de bord doit se connecter en priorité.

626

* //Nom// : **DOMAIN**

627

//Valeur// : Nom du domaine DigDash Enterprise

628

//Description// : Nom du domaine sur lequel le tableau de bord doit se connecter en priorité.

629

* //Nom// : **FORCESERVERURL**

630

//Valeur// : Booléen (défaut : false)

631

//Description// : Utilisé avec le paramètre **SERVERURL**. Force le serveur sur lequel le tableau de bord se connecte. L'utilisateur ne peut pas choisir un autre serveur.

632

* //Nom// : **FORCEDOMAIN**

633

//Valeur// : Booléen (défaut : false)

634

//Description// : Utilisé avec le paramètre **DOMAIN**. Force le domaine sur lequel le tableau de bord se connecte. L'utilisateur ne peut pas choisir un autre domaine.

635

* //Nom// : **GRIDSIZEEDITOR**

636

//Valeur// : Entier (défaut: 10)

637

//Description// : Taille en pixel de la grille magnétique d'édition du tableau de bord.

638

* //Nom// : **THEME**

639

//Valeur// : Nom du thème (défaut: vide)

640

//Description// : Nom du thème par défaut utilisé pour les utilisateur n'ayant pas de thème spécifique spécifié.

641

642

* //Nom //: **urlLogout**

643

//Valeur// : URL

644

//Description //: Spécifie une URL de sortie vers laquelle est redirigé l’utilisateur après une déconnexion du tableau de bord. Voir le paragraphe « //Redirection lors de la déconnexion du tableau de bord// ».

645

* //Nom //: **CANCHANGEPASSWORD**

646

//Valeur //: Booléen (défault : false)

647

//Description //: Permet l’activation d’un hyperlien « Mot de passe perdu » dans la page de login du tableau de bord. Cet hyperlien envoie un code de réinitialisation par émail à l’utilisateur. Voir paragraphe « //Activation de la fonctionnalité de réinitialisation du mot de passe// »

648

649

Exemple de fichier **digdash_dashboard.properties** :

650

651

652

SERVERURL=http://localhost:8080

653

FORCESERVERURL=true

654

DOMAIN=ddenterpriseapi

FORCEDOMAIN=true

GRIDSIZEEDITOR=15

THEME=Flat

CANCHANGEPASSWORD=true

659

660

661

Exemple de fichier **dashboard_system.xml** :

</SystemProperties>

=== Redirection lors de la déconnexion du tableau de bord ===

676

677

Vous pouvez spécifier une URL qui sera affichée dans le navigateur quand l'utilisateur se déconnecte du tableau de bord (bouton Déconnexion).

678

679

Fichier modifié : **web.xml **(digdash_dashboard), **digdash_dashboard.properties** ou **dashboard_system.xml**

680

681

Modifier la valeur du paramètre **urlLogout** comme dans l'exemple suivant. Par défaut la valeur est vide, signifiant un retour à la page d'authentification du tableau de bord :

682

683

Dans **web.xml** (digdash_dashboard) :

<init-param>

<param-name>urlLogout</param-name>

688

<param-value>http://www.digdash.com</param-value>

</init-param>

Les URLs relatives sont autorisées, par rapport à l'url de index.html de l'application digdash_dashboard :

<init-param>

<param-name>urlLogout</param-name>

697

<param-value>disconnected.html</param-value>

</init-param>

Si **digdash_dashboard.properties **([[chapitre V.5>>doc:||anchor="V.5"]]) est utilisé, il faudra écrire :

702

703

704

urlLogout=disconnected.html

705

706

707

Enfin, vous aussi pouvez modifier cette valeur dans le fichier **dashboard_system.xml :**

=== Activation de la fonctionnalité de réinitialisation de mot de passe ===

714

715

Vous pouvez activer la fonctionnalité de réinitialisation de mot de passe perdu. Cette fonctionnalité affiche un hyperlien « **Mot de passe oublié **» dans la page de login du tableau de bord qui envoie à l’utilisateur un émail contenant un code de réinitialisation de son mot de passe. Ensuite l’utilisateur est redirigé vers une interface de réinitialisation pour saisir ce code et un nouveau mot de passe.

716

717

Fichier modifié : **web.xml** (digdash_dashboard), **digdash_dashboard.properties** ou **dashboard_system.xml**, et page de Configuration des serveur DigDash

718

719

Prérequis sur le serveur DigDash :

720

721

* La fonctionnalité doit être aussi activée via la page de **Configuration des serveurs** / **Avancé** / **Divers** / **Autoriser la réinitialisation de mot de passe**

722

* Un serveur émail valide doit être configuré dans la page **Configuration des serveurs** / **Avancé** / **Serveur émail système**

723

* Les utilisateurs doivent avoir une adresse émail valide dans le champ LDAP **digdashMail**

724

725

L’activation de la fonction coté tableau de bord se fait en passant la variable CANCHANGEPASSWORD à la valeur **true**

726

727

Dans **web.xml** (digdash_dashboard) :

<init-param>

<param-name>CANCHANGEPASSWORD</param-name>

732

<param-value>true</param-value>

</init-param>

Si **digdash_dashboard.properties **(chapitre V.5) est utilisé, il faudra écrire :

737

738

739

CANCHANGEPASSWORD=true

740

741

742

Enfin, vous pouvez aussi modifier cette valeur dans le fichier **dashboard_system.xml :**

743

744

//{{code language="xml"}}<Property key="CANCHANGEPASSWORD" value="true"></Property>{{/code}}//

745

746

747

__Optionnel : Customisation de l’émail du code de réinitialisation__

748

749

Le sujet et le corps de l’émail du code de réinitialisation peuvent être customisés de la manière suivante :

750

751

1. Démarrer le Studio DigDash

752

1. Menu **Outils** / **Gestionnaire de traductions...**

753

1. Clic-droit sur la section **GLOBAL** puis **Ajouter…**

754

755

Nom de la clé : **LostPasswordMailSubject**

756

757

Saisir le sujet de l’émail dans les langues qui vous intéressent.

758

759

1. Clic-droit sur la section **GLOBAL** puis **Ajouter…**

760

761

Nom de la clé : **LostPasswordMailText**

762

763

Saisir le corps de l’émail dans les langues qui vous intéressent. Attention le corps de l’émail doit contenir au moins le mot-clé **${code}** qui sera substitué par le code de réinitialisation. Un autre mot-clé disponible est **${user}**.

764

Nous déconseillons d’indiquer trop d’informations dans cet émail, c’est pourquoi dans le message par défaut nous n’indiquons que le code de réinitialisation.

765

766

767

__Paramètres avancés spécifiques à la fonctionnalité de réinitialisation de mot de passe__

768

769

Fichier modifié : **system.xml**

770

771

Exemple de syntaxe XML :

772

//{{code language="xml"}}<Property key="PROP_RESET_PASS_HASH" value="dfrj65433lkloss!00"></Property>{{/code}}//

773

774

Paramètres disponibles :

775

776

* //Nom// : **PROP_RESET_PASS_HASH**

777

//Valeur// : Chaîne non vide (défaut : aléatoire)

778

//Description// : Spécifie le code sel à utiliser pour la génération du code de réinitialisation de mot de passe. Par défaut cette chaîne est aléatoire, générée au lancement du serveur. Vous pouvez spécifier une chaîne de caractère qui sera utilisée par l’algorithme de génération du code de réinitialisation. Ceci peut-être utile si vous avez plusieurs serveurs (load-balancing HTTP) et pour qu’un code généré sur un serveur soit utilisable sur un autre.

779

* //Nom// : **PROP_RESET_PASS_VALIDITY**

780

//Valeur// : entier positif (défaut : 1)

781

//Description// : Spécifie la durée de validité minimale du code par tranche de 10 minutes. Une valeur de 1 donne une validité du code entre 10 et 20 minutes, une valeur de 2 entre 20 et 30 minutes, etc. La validité est importante pour minimiser les risques de vol de code à postériori.

782

* //Nom// : **PROP_RESET_PASS_LENGTH**

783

//Valeur// : entier positif (défaut : 10)

784

//Description// : Spécifie la longueur du code de réinitialisation. Une valeur trop faible est sujette aux tentatives d’attaques dites de force brute. Une valeur trop importante est sujette à des erreurs de saisie de la part des utilisateurs.

785

786

== Réglages de sécurité internes ==

787

788

Différents mécanismes de protection sont intégrés à DigDash Enterprise pour contrer des attaques de type « injection de code serveur » (Ex. SSJS : Server Side JS Injection), « Cross-site scripting » (XSS), « Cross-Site Request Forgery » (CSRF) ou encore « Directory/Path traversal ».

789

790

Ces mécanismes sont actifs par défaut. Dans certains cas rares (et en environnement contrôlé), il peut être nécessaire de désactiver complètement ou partiellement certaines de ces protections, par exemple :

791

792

* Pour utiliser certaines fonctionnalités d’administrations ou de consultation en dehors des pages prévues à cet effet

793

* Pour utiliser des objets Java custom dans le cadre de mesures dérivées

794

* Intégrer de manière très poussée des pages de tableau de bord dans un portail existant.

795

796

Ce chapitre liste les propriétés permettant de configurer ou désactiver ces protections.

797

798

Tous les paramètres sont à saisir dans le fichier **system.xml**.

799

800

Exemple de syntaxe XML :

801

//{{code language="xml"}}<Property key="PROP_..." value="12345"></Property>{{/code}}//

802

803

=== Configurer la protection contre les attaques SSJS (Server Side JS Injection) ===

804

805

DigDash Enterprise s’appuie sur l’utilisation du langage Javascript pour un certain nombre de taches. Le Javascript utilisé coté navigateur ne pose en général pas de problème de sécurité (spécifique à DigDash). Par contre le Javascript évalué coté serveur présente un risque. C’est le cas pour les mesures dérivées, les formules en analyse ad-hoc (Self Service BI), les formules de hiérarchies, de filtres, etc. Ces éléments sont évalués coté serveur à l’aide d’un interpréteur Javascript exécuté par la machine virtuelle Java.

806

807

Dans DigDash Enterprise nous avons protégé cet interpréteur contre l’accès à des objets de la machine virtuelle Java qui ne sont pas nécessaires à son bon fonctionnement. Par exemple une mesure dérivée n’a jamais besoin d’accéder au système de fichier du serveur, ou n’a jamais besoin de lancer un exécutable sur le serveur.

808

809

Les classes Java accessibles par du code Javascript sont listées sur le principe de « liste blanche » pour permettre à DigDash Enterprise d’évaluer les scripts légitimes. Par contre tout appel à un objet non listé au sein d’une fonction maligne sera tracé dans les logs et provoquera une erreur.

810

811

Si besoin on pourra ajouter des classes Java à cette liste en utilisant le paramètre :

812

813

* //Nom// : **PROP_JS_SANDBOX_CLASSES**

814

//Valeur// : Chaîne (défaut : vide)

815

//Description// : Noms de classe java séparés par des virgules (ex : mon.package.MaClasse)

816

817

Un autre type d’attaque est de type DOS (« Denial-Of-Service ») qui consiste à rendre le système inopérant. Par exemple une attaque SSJS/DOS sera de saisir une formule : {{code language="javascript"}}while(true){};return 0;{{/code}}

818

819

Cette formule a pour effet de faire boucler de manière infinie l’interpréteur Javascript. Nous avons aussi une protection pour ce type d’attaque, mais pour des raisons d’optimisation elle n’est pas activée par défaut. Pour l’activer il faut créer les paramètres suivants :

820

821

* //Nom// : **PROP_JS_SANDBOX_TIMEOUT**

822

//Valeur// : Entier positif (millisecondes, défaut : 0 = aucun)

823

//Description// : Durée d’évaluation maximale de la formule JS en millisecondes. A moins d’une formule réellement très complexe ce genre de temps ne devrait pas excéder une seconde (1000)

824

* //Nom// : **PROP_JS_SANDBOX_TIMEOUT_EXPORT**

825

//Valeur// : Entier positif (millisecondes, défaut : 0 = aucun)

826

//Description// : Durée d’évaluation maximale d’un export de flux de type tableau en PDF, PPT, Excel (avec les styles) en millisecondes. Dans ce cas le temps peut-être assez long, en fonction de la taille du tableau, plusieurs dizaines de secondes,par exemple une minute (60000)

Débogage

Les erreurs liées à la protection SSJS sont tracées dans les logs avec le préfixe « SSJS Protection » et une explication de la source de l’erreur. Les erreurs liées à des temps d’exécution trop longs sont généralement tracés par une erreur de type « ScriptTooLongError ».

831

832

=== Configurer la protection contre les attaques CSRF (Cross-Site Request Forgery) ===

833

834

Nous ne décrirons pas ce type d’attaque complexe dans ce chapitre car ce sujet est largement documenté sur Internet. DigDash Enterprise fournit une protection contre les attaques CSRF à deux niveaux :

835

836

1. Vérification d’entête HTTP et de token aléatoire :

837

838

* **. Pour les opérations d’administration, un token aléatoire associé à la session courante doit nécessairement être envoyé par la page d’administration sur chaque soumission d’un formulaire (CSRFToken).**

839

** Pour les opérations effectuées via appel « Ajax » ou via une application cliente DigDash (Tableau de bord, Studio), nous vérifions un entête HTTP ajouté lors des appels légitimes. Il est à priori impossible à une attaque CSRF de spécifier des entêtes HTTP additionnels.

840

841

1. A chaque requête HTTP entrante nous vérifions la source de la requête qui doit être identique à la source de la requête qui a authentifié la session courante (principe de l’origine identique).

842

843

Les paramètres suivants permettent de désactiver complètement ou partiellement cette protection :

844

845

* //Nom// : **PROP_CSRF_CHECK**

846

//Valeur// : Booléen (défaut : true)

847

//Description// : Définit l’activation ou non de la protection CSRF.

848

849

* //Nom// : **PROP_CSRF_CHECK_ORIGIN**

850

//Valeur// : Booléen (défaut : true)

851

//Description// : Définit l’activation ou non de la vérification de l’origine de la requête HTTP.

852

* //Nom// : **PROP_CSRF_CHECK_TOKEN**

853

//Valeur// : Booléen (défaut : true)

854

//Description// : Définit l’activation ou non de la vérification d’un token aléatoire obligatoire pour les opérations d’administration.

855

* //Nom// : **PROP_CSRF_CHECK_XHR**

856

//Valeur// : Booléen (défaut : true)

857

//Description// : Définit l’activation ou non de la vérification de la valeur d’un entête HTTP spécifique pour les appels via un client DigDash (Tableau de bord, Studio).

**Débogage**

Les erreurs liées à la protection CSRF sont tracées dans les logs sous forme avec le préfixe « CSRF Protection » et une explication de la source de l’erreur. Ces erreurs sont également ajoutées à DDAudit / Securité (événement « HackAttempt »).

862

863

=== Configurer la protection contre les attaques XSS (Cross Site Scripting) ===

864

865

Il n’y a pas de protection intégrée à DigDash Enterprise contre les attaques XSS puisque c’est le rôle du navigateur d’interdire l’accès à des scripts malicieux ou non provenant d’autres domaines / sites. Cependant pour des besoins d’intégration avancée de DigDash Enterprise dans des portails d’entreprise existants, il peut être nécessaire d’autoriser ce genre d’accès. Pour cela nous renvoyons à Internet via les mot-clés : CORS (« Cross Origin Resource Sharing ») et tomcat.

866

867

=== Accès à la console d’administration H2 (base de données DDAudit et commentaires) ===

868

869

DigDash Enterprise utilise de manière interne la base de données H2 pour stocker les informations de DDAudit et les commentaires des utilisateurs sur les tableaux de bord.

870

871

Suite à la découverte d’une faille de sécurité sur la console d’administration de H2, non corrigée à ce jour par la communauté, nous avons décidé de supprimer l’accès à cette console (/ddenterpriseapi/ddh2console) par défaut.

872

873

Pour bénéficier à nouveau de cet outil d’administration des bases H2, il vous faudra réactiver la console ddh2console. Cela se fait supprimer les marqueurs de commentaires autour de **<servlet>** dans l’extrait XML suivant du fichier web.xml de ddenterpriseapi :

<!--

Due to a security issue with H2 console third party we are desactivating it by default.

878

If you intend to use this option, it is recommended to:

879

- change the default sa password for H2

880

- change the password used in DDAudit module's datasources

881

- make sure the URL is not publicly available on Internet

882

- uncomment the following block

-->

<!--

<servlet-name>H2Console</servlet-name>

887

<servlet-class>org.h2.server.web.WebServlet</servlet-class>

888

<init-param>

889

<param-name>webAllowOthers</param-name>

890

<param-value>1</param-value>

891

</init-param>

892

<load-on-startup>1</load-on-startup>

893

</servlet>

894

<servlet-mapping>

895

<servlet-name>H2Console</servlet-name>

896

<url-pattern>/ddh2console/*</url-pattern>

897

</servlet-mapping>

898

<servlet-mapping>

899

<servlet-name>H2Console</servlet-name>

900

<url-pattern>/ddh2console</url-pattern>

</servlet-mapping>

-->

(% class="box errormessage" %)

906

(((

907

Important : Il est fortement conseillé dans ce cas de changer le mot de passe par défaut, et de restreindre l’accès à cette console à un sous-ensemble du réseau, par exemple par des règles de pare-feu ou de routage.

908

909

Le mot de passe est définit dans ce même fichier via les paramètres **comment.db.password** et **audit.db.password**. Attention, pour DDAudit il faudra aussi mettre à jour le mot de passe dans les modèles de données.

910

)))

911

912

== Externalisation des paramètres dans des fichiers //properties// ==

913

914

Il est possible de spécifier les paramètres situés dans un fichier **web.xml** dans un fichier texte externe au format **properties**.

915

916

Ceci permet de pré-configurer des paramètres des applications web, parmi ceux listés dans ce document, avant de déployer les applications web. Ou encore de s’assurer que les paramètres ne seront pas écrasés lors d’une mise à jour des applications web de DigDash Enterprise.

917

918

Ces fichiers **.properties** sont ensuite mentionnés dans la ligne de commande de lancement de tomcat ou placés dans le répertoire de travail de tomcat.

919

920

Par exemple on peut créer un fichier **digdash_dashboard.properties** contenant les lignes suivantes :

921

922

923

SERVERURL=http://localhost:8080

FORCESERVERURL=true

Et un fichier **ddenterpriseapi.properties **:

928

929

//{{code language="properties"}}AppDataPath=/path/to/digdash_appdata{{/code}}//

930

931

(% class="box errormessage" %)

932

(((

933

Important : Le caractère anti-slash « \ » doit être doublé dans le fichier .properties. Exemple : //AppDataPath=C:~\~\path~\~\to~\~\digdash_data//

934

)))

935

936

Il y a deux manières existantes pour que ces fichiers soient pris en compte au lancement de tomcat :

937

938

* Implicite : Les fichiers **.properties** doivent être nommés de la même manière que les web application qu’ils concernent (Ex. **ddenterpriseapi.properties**, **digdash_dashboard.properties** ou **adswrapper.properties**). Ces fichiers doivent être placés dans le répertoire de travail de tomcat (qui dépend de votre installation tomcat)

939

* Explicite : La ligne de commande de tomcat doit contenir les paramètres :

940

//-Dddenterpriseapi.properties.path="/path/to/ddenterpriseapi.properties"

941

-Ddigdash_dashboard.properties.path="/path/to/digdash_dashboard.properties"

942

-Dadswrapper.properties.path="/path/to/adswrapper.properties"

943

-Dadminconsole.properties.path="/path/to/adminconsole.properties"//

944

945

Spécifier les paramètres de journalisation (//logging//) log4j.properties :

946

947

Les paramètres de //logging// sont définis dans un fichier **log4j.properties** disponible dans chaque application web déployée.

948

949

Nous avons ajouté des options sur la ligne de commande de tomcat pour permettre de spécifier des fichiers de paramétrage de //logging// externalisés :

950

951

952

-Dddenterpriseapi.ddlog4j.properties.path="/path/to/log4j.properties"

953

-Ddigdash_dashboard.ddlog4j.properties.path="/path/to/log4j.properties"

954

-Dadswrapper.ddlog4j.properties.path="/path/to/log4j.properties"

955

956

957

Vous pouvez aussi spécifier l’emplacement du fichier de log (global) sans avoir besoin de spécifier un fichier log4j.properties :

958

959

960

-Dlog4j.appender.R.File="/home/ddapi.log"

961

962

963

== Paramètres du Studio (JNLP + stand alone) ==

964

965

Le Studio DigDash Enterprise a aussi quelques paramètres optionnels spécifiés dans un fichier **adminconsole.properties** à placer au même endroit que les autres fichiers //properties// de DigDash Enterprise, ou à spécifier dans la ligne de commande Tomcat :

966

967

//{{code language="batch"}}-Dadminconsole.properties.path="/path/to/adminconsole.properties"{{/code}}//

968

969

970

Liste des paramètres :

971

972

* //Nom// : **ddserver**

973

//Valeur// : URL du serveur DigDash Enterprise (défaut : vide)

974

//Description// : Spécifie l’URL du serveur auquel le Studio se connectera. Si non spécifié, le Studio utilisera le serveur de l’URL du fichier JNLP.

975

* //Nom// : **domain**

976

//Valeur// : Nom du domaine DigDash Enterprise

977

//Description// : Spécifie le nom du domaine DigDash Enterprise auquel le Studio se connectera. Si non spécifié, le Studio utilisera le domaine spécifié dans la page d’accueil de DigDash Enterprise.

978

* //Nom// : **forceServerDomain**

979

//Valeur// : Booléen (défaut : false)

980

//Description// : Indique au Studio que l’URL du serveur et le domaine sont modifiables (false) ou non (true) via le bouton **Avancé** dans la fenêtre de login du Studio. Si ce paramètre est activé, il est conseillé de spécifier les paramètres **ddserver** et **domain**.

981

* //Nom// : **dashboard**

982

//Valeur// : Nom de l’application tableau de bord

983

//Description// : Permet de spécifier le nom du de l’application du tableau de bord. Si non spécifié, le Studio utilisera le nom d’application spécifié dans la page d’accueil de DigDash Enterprise, par exemple « digdash_dashboard ».

984

* //Nom// : **authMode**

985

//Valeur// : Mode d’authentification du Studio (défaut : « default »)

986

//Description// : Mode d’authentification spécifique du Studio. Il faut que le serveur DigDash Enterprise reflète un mode d’authentification compatible (variable **authMethod** dans la configuration du serveur) : Consulter les documentations des add-ons liés à l’authentification et au SSO. Les valeurs possibles sont : « default », « NTUser », « NTUserOrLDAP » et « NTUserOrLDAP,loginForm ».

987

* //Nom// : **sslNoPathCheck**

988

//Valeur// : Booléen (défaut : false)

989

//Description// : Utilisé dans le cadre d’une connexion HTTPS. Indique au Studio de ne pas vérifier le chemin de certification du certificat de sécurité. Utilisé pour tester une configuration SSL avec un certificat auto-signé.// Ce setting n’est pas conseillé en production.//

990

* //Nom// : **sslNoHostNameCheck**

991

//Valeur// : Booléen (défaut : false)

992

//Description// : Utilisé dans le cadre d’une connexion HTTPS. Indique au Studio de ne pas vérifier le nom de domaine Internet. Utilisé pour tester une configuration SSL avec un certificat auto-signé.// Ce setting n’est pas conseillé en production.//

993

994

* //Nom// : **maxHeapSize**

995

//Valeur// : Quantité mémoire (défaut : en fonction de la JVM du poste client)

996

//Description// : Spécifie la quantité de mémoire du poste client allouée au Studio. La syntaxe est <quantité><unité>, où l’unité est une lettre « m » (mégaoctets) ou « g » (gigaoctets). Exemple : //maxHeapSize=2048m//

997

998

(% class="box errormessage" %)

999

(((

1000

Important : Il est préférable de ne mettre dans le fichier adminconsole.properties que les paramètres dont vous voulez spécifier des valeurs différentes des valeurs par défaut.

1001

)))

1002

1003

== Dossiers de données DigDash Enterprise ==

1004

1005

DigDash Enterprise stocke les données dans différents dossiers. Ce chapitre résume ces dossiers et liste les moyens de les modifier.

1006

1007

=== Données de configuration ===

1008

1009

//Localisation (par défaut)// : Dossier « Application Data » de l’utilisateur qui lance Tomcat (Windows), ou dossier de l’utilisateur (linux).

1010

1011

//Contenu// : Sous-dossiers contenant les modèles de données, tableaux de bords, portefeuilles de flux, formats, formules, scripts, styles, chaînes de connexions, etc :

1012

1013

* config : données de configuration communes, données de configuration des rôles, sauvegardes, et dossiers web customisés

1014

* datasources : fichiers du serveur de document par défaut

1015

* **server : **données de configuration des utilisateurs : portefeuille, modèle de données et tableaux de bord personnels, et serveur de documents personnalisé

1016

1017

//Modification// : **web.xml** (ddenterpriseapi), **ddenterpriseapi.properties**, **setenv.bat** ou **ligne de commande Tomcat**

1018

1019

(% class="box infomessage" %)

1020

(((

1021

Note : La volumétrie des données générées peut-être importante notamment à cause des sous-dossiers **cubes** et **history**. Il est conseillé de placer ce dossier sur un disque disposant d’un quota d’espace important.

1022

)))

1023

1024

=== Données générées ===

1025

1026

//Localisation// : Sous dossiers **cubes** et **history** du dossier de **données de configuration**.

1027

1028

//Contenu// : Cubes, historiques de flux :

1029

1030

* **cubes **: sous-dossiers des cubes générés (un par modèle de données).

1031

* **history **: historique de tous flux, fichiers javascripts générés (modèle de données, vues de flux).

1032

1033

//Modification// : Impossible directement. Il faut modifier la localisation du dossier parent (**Données de configuration**), ou créer des liens.

1034

1035

(% class="box errormessage" %)

1036

(((

1037

Important : La volumétrie des données générées peut-être importante. Il est conseillé de placer le dossier parent (**Données de configuration**) sur un disque disposant d’un quota d’espace important.

1038

)))

1039

1040

(% class="box infomessage" %)

1041

(((

1042

Note : Les dossiers **cubes** et **history** peuvent être supprimés pour nettoyage (serveur Tomcat stoppé). Ils seront recréés et les données rafraîchies à nouveau par l’ordonnanceur, ou par l’envoi d’un événement de rafraîchissement.

)))

=== Données LDAP ===

//Localisation (par défaut)// : répertoire de travail de Tomcat (« workdir »).

1048

1049

//Contenu// : Fichiers de la partition LDAP contenant les définitions des utilisateurs, des rôles et des droits DigDash

1050

1051

//Modification// : **web.xml** (adswrapper), **adswrapper.properties** (voir le chapitre V.2) ou **ligne de commande Tomcat**

1052

1053

* **web.xml** : voir chapitre V.2

1054

* **adswrapper.properties** : voir chapitre V.2

1055

* **Ligne de commande Tomcat** : {{code language="batch"}}-Dads.instance.name="/path/to/ldapdigdash"{{/code}}

1056

1057

=== Base de données DDAudit ===

1058

1059

Localisation (par défaut) :

1060

1061

//Contenu// : Fichier de base de données (H2) contenant les tables des données DDAudit.

1062

1063

//Modification// : **web.xml** (ddenterpriseapi), **ddenterpriseapi.properties** ou **ligne de commande Tomcat** (Voir également la documentation de déploiement DDAudit)

1064

1065

* **web.xml** (ddenterpriseapi) :

<context-param>

<param-name>audit.db.url</param-name>

1070

<param-value>jdbc:h2:/path/to/DDAudit_${server.DomainName};AUTO_SERVER=TRUE</param-value>

</context-param>

* **ddenterpriseapi.properties** :

1075

1076

* **Ligne de commande Tomcat** :

1077

1078

Fichiers de journalisation (log)

1079

1080

//Localisation (par défaut)// : Fichier de log des modules de DigDash Enterprise (ddenterpriseapi, digdash_dashboard, adswrapper). Le nom est ddenterpriseapi.log par défaut.

1081

1082

//Contenu// : log applicatif

1083

1084

//Modification// : log4j.properties (toutes les webapps) ou ligne de commande Tomcat (voir chapitre V.5)

1085

1086

(% class="box infomessage" %)

1087

(((

1088

Note :Éditer le fichier log4j.properties permet aussi de changer le format des logs.

1089

)))

Code source wiki de Réglages avancés des paramètres système

Sommaire