Wiki source code of Déploiement du module d'audit

Last modified by jhurst on 2021/04/21 10:01
Show last authors
1 {{ddtoc/}}
2
3 **Audit Module Deployment For DigDash Enterprise**
4
5 This document explains how to deploy the audit module integrated into DigDash Enterprise. This module allows an administrator of the system to retrieve the list of data cubes and flows and the history of all user sessions.
6
7 = Module Installation =
8
9 The audit module is delivered as a zip file compatible with the DigDash Enteprise backup restore. Here is the process to deploy this module:
10
11 1. Connect to DigDash Enterprise home page with a web browser (default is http:~/~/localhost:8080/adminconsole)
12 1. Click on **Configuration**, then **Backup Management** and **Restore**
13 1. If not already done, login with the DigDash Enteprise super administrator user
14 1. Click on button **Browse File...**
15 1. In the file selector, browse to the folder <DD install>/add-ons/ddaudit and choose the file **ddaudit_module.zip**
16 1. Click on **Load** button
17 1. Confirm the import options by clicking on **Validate** button
18 1. Restart your server
19
20 At the end of the import operation, DigDash Enterprise has a new **DDAudit** role containing:
21
22 * Pre-defined data models to create visualizations on audit data
23 * Pre-defined flows: cubes lists, flows list and user sessions lists
24 * Pre-defined dashboard pages to display audit data
25
26 = Access to the DigDash Enterprise audit data =
27
28 To visualize this information, you must add the **DDAudit** role to your DigDash Enterprise administrator, or any other user you choose for this task.
29
30 From the **Server Status** page, start the audit services you want to use (Sessions, Cubes and Flows audit services).
31
32 The pre-defined reports are directly available in the **Server Status** page, or in the Information Wallet of users with DDAudit role.
33
34 You can also create your own flows based on the pre-defined data models, and new data models on the audit database.
35
36 = Managing DDAudit Database files =
37
38 == Migration from a previous version of the audit module ==
39
40 If you had deployed a the audit module in a previous DigDash Enterprise build (before the 2014B0603), the name of the audit H2 database was then //DDAudit//.
41
42 From version 2014B0603 this name has changed by default into //DDAudit_<DDE domain>// to accommodate multi-domains deployment on the same server. After this change the previous audit data are not available anymore in the new version of DigDash Enterprise.
43
44 To retrieve them, there are 2 possible migration scenarios :
45
46 * Option 1 (recommended): By renaming the old //DDAudit// database into //DDAudit_<DDE domain>// (by default the DDE domain name is //ddenterpriseapi),//
47 * Option 2 : By referencing the old //DDAudit// database name into the new DigDash Enterprise version (web.xml modification).
48
49 __Option 1 (recommended) : Renaming the old DDAudit database__
50
51 Choose this option if you did not modify the DDAudit data models, or if you do not want to keep these modifications. The modification of audit flows and/or audit dashboards is not significant for this option.
52
53 Migration procedure for option 1
54
55 1. Stop DigDash Enterprise servers
56 1. Find the files **DDAudit.h2.db** et **DDAudit.trace.db** on the server computer:
57
58 * On Windows these files can be found in the installation folder of DigDash Enterprise if the server is manually started using start_servers.bat, or <Windows>/System32 if the server is started as a Windows service.
59 * On Linux, depending on the system configuration, these files can be found in your Tomcat installation folder (usually at the same place than the logs).
60
61 (% start="3" %)
62 1. Process these files as below:
63
64 * Copy and rename **DDAudit.h2.db** into **DDAudit_<DDE domain>.h2.db** (example: **DDAudit_ddenterpriseapi.h2.db)**
65 * Copy and rename **DDAudit.trace.db** into **DDAudit~_~_<DDE domain>.trace.db** (example: **DDAudit_ddenterpriseapi.trace.db**)
66
67 (% start="4" %)
68 1. Start DigDash Enterprise servers
69 1. __Deploy the new audit module (chapter I)__ so the audit data models correctly access the new audit database.
70
71 __Option 2: Modification of web.xml to link to the old DDAudit database__
72
73 Choose this option if you modified the DDAudit data models. The modification of audit flows and/or audit dashboards is not significant for this option. Warning: If you have several ddenterpriseapi_xxxx on the same Tomcat, it is recommended to migrate only for one domain because the DDAudit database can not be used by different domains at the same time.
74
75 Migration procedure for option 2:
76
77 1. __If this is a first start after a DigDash Enteprise upgrade (new war files)__, start the Tomcat server and wait for the full deployment of the new war files. As soon as Tomcat has fully started (the message //Server startup in xxxx ms// shows in Tomcat console), stop DigDash Enterprise servers.
78 1. Edit the file <DigDash Enterprise install>/apache-tomcat/webapps/ddenterpriseapi/WEB-INF/web.xml.
79
80 * Change the value of parameter **audit.db.url** from **jdbc:h2:DDAudit_${server.DomainName};AUTO_SERVER=TRUE** into **jdbc:h2:DDAudit**
81
82 (% start="3" %)
83 1. Start DigDash Enterprise servers
84
85 == Changing the location of the DDAudit database files ==
86
87 By default, the DDAudit database files are stored in the Tomcat work directory. In some configurations this path may not be the default <DDE Install> folder.
88
89 For example, on Linux the location may be the Tomcat installation folder, and default user rights may prevent the server to write files in that folder. DDAudit would not work in this case.
90
91 Another example is for Windows, when Tomcat is started as a service, the DDAudit files could land in Windows/system32 folder.
92
93 You can change the location of the DDAudit database files with the following procedure:
94
95 1. Stop DigDash Enterprise server
96 1. Edit the file <DigDash Enterprise install>/apache-tomcat/webapps/ddenterpriseapi/WEB-INF/web.xml.
97
98 *
99 ** Change the value of parameter **audit.db.url** from **jdbc:h2:DDAudit_${server.DomainName};AUTO_SERVER=TRUE** into **jdbc:h2:**[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)**file:/home/audit/**>>path:../../../../../home/audit/DDAudit_$]](%%)[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)**DDAudit_$**>>path:../../../../../home/audit/DDAudit_$]](%%)**{server.DomainName};AUTO_SERVER=TRUE** (notice the “file:” inserted at the start of the URL)
100
101 1. Make sure this folder exists and move all the existing **DDAudit*.db** files to the new location
102 1. Start DigDash Enterprise server
103
104 (% class="box infomessage" %)
105 (((
106 //Note: The parameters audit.db.url, audit.db.user, audit.db.password and audit.db.tcpServer can be specified as JVM lauch parameters, for instance by adding them to the JAVA_OPTS variable (setenv.bat, setenv.sh…) or in catalina.properties: JAVA_OPTS=[…] -Daudit.db.url=jdbc:h2~://[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)//file:/home/DDAudit;AUTO_SERVER=TRUE//>>path:../../../../../home/DDAudit%3BAUTO_SERVER=TRUE]](%%)// [...]//
107 )))
108
109 Another alternative is to change the value of parameter **h2.baseDir**, which changes the behavior for all H2 bases (DDAudit but also DDComments):
110
111 1. Stop DigDash Enterprise server
112 1. Locate and edit the **catalina.properties** file on the server hard drive (ex: <DDE Install>/apache-tomcat/conf/**catalina.properties** on DigDash Enterprise Windows installation)
113 1. Add the following line:(((
114 **h2.baseDir=/the/new/db/path**
115
116 (% class="box infomessage" %)
117 (((
118 Note: This path can be relative to the initial Tomcat workdir (ex: h2.baseDir=./db)
119 )))
120 )))
121 1. Make sure this folder exists and move all the existing **DDAudit*.db** files to the new location
122 1. Start DigDash Enterprise server
123
124