Service requirements

The different services has a common set of requirements:

An application server which to run on (Tomcat)
Bitrepository collection and reference settings files.
A PEM formatted certificate and key file for the service
Configuration files
Databases for storage

In the following a there's a general description of the above items.

Tomcat server setup

The application server that is used is Tomcat (it might be possible to use another application server, but that have not been tested). In the following a basic setup of Tomcat is given.

Install Tomcat as you see fit (package system or by downloading the server bundle from Tomcat's official website). Deployment of applications can be done in multiple ways, but to use the management web interface a single file needs changing.

Open the file "tomcat-users.xml" from $TOMCAT_ROOT/conf/ (Assuming $TOMCAT_ROOT is the base directory for the server, if installed through the yum packaging system on a Fedora box it would be /usr/share/tomcat) and add the following:

<role rolename="manager-gui" />
<user username="tomcat" password="something-secret" roles="manager-gui"/>

Naturally replacing "something-secret" with the proper password for the administration interface. The username can also be something else.

Following this the Tomcat server can be started. How this is done depends on how it was installed.

If it has been installed through the packaging system on a Fedora box, "service tomcat start" should do the trick. If it has been installed by unzipping the server bundle from Tomcats website, the "catalina.sh" script in the bin directory can be used: "./catalina.sh start"

Setup of configuration file locations

The different services has been written so that they expect to find the path to their configuration dir as a context parameter.

Context parameters can be specified in multiple ways, but the easiest way is to use context.xml.default. The file should reside in $TOMCAT_ROOT/conf/$ENGINE_NAME/$HOST/

Below is an general example of setting a context parameter in the context.xml.default file.

Sample context file

<Context override="true">
  <Parameter
    name="parameter-name"
    value="parameter-value"
    override="false"
  />
</Context>

The table below lists the current available services and their corresponding parameter-names

Service name	parameter name
Webclient	configurationDir
Alarm service	alarmServiceConfDir
Integrity service	integrityServiceConfDir
AuditTrail service	auditTrailServiceConfDir
Monitoring service	monitoringServiceConfDir

Configuration files

The needed configuration files should be placed in the directory indicated by the context parameter value.

The specific service page lists the needed configuration files.

The logging setup is done by the logback.xml file and is likely to be similar across the different services, probably only differing to which file the log is written to. Below is an example logback.xml file. The content of the <file>-tag should be altered to reflect the file that is to be logged to.

Sample logback.xml file

<configuration>
  <appender name="FILE">
    <file>/tmp/logfile.log</file>
    <append>true</append>
      <encoder>
        <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} \[%thread\] %-5level %logger{36} - %msg%n</pattern>
      </encoder>
  </appender>

  <root level="INFO">
    <appender-ref ref="FILE" />
  </root>

  <logger name="org.bitrepository" level="DEBUG" />
</configuration>

Certificate and keyfile

For collections where encryption, authentication, messagesigning etc is needed, the service needs to have access to its private key and certificate. For this a PEM formatted certificate is needed.

For making a PEM formatted file the attached script pkcs12topem can be used to convert a pkcs#12 formatted certificate and key file to the needed PEM format.

The placement of the PEM file is indicated to the individual service via a properties file located in the services configuration directory. See the individual service page for the properties file.

Browser not supported