Page tree
Skip to end of metadata
Go to start of metadata


To set up this application we will assume that you have the following tools installed on the target instance:

  1. git
  2. Maven 3+
  3. Tomcat7 (with the manager turned on)
  4. Mysql 5.5+

Download and build the source code

You can download the source from

git clone

Setup Bridge Root Directory

The application needs a directory of sufficient size (depending on your expected load) for storing application state files as well as receiving space data both from the DPN node as well as from DuraCloud.  The tomcat user must have read/write access to the directory. 

Create log directory

The bridge application will attempt to write logs to /var/log/duracloud. To make this possible, create that directory, and set permissions to allow the bridge application to write to it.

sudo mkdir /var/log/duracloud
sudo chown tomcat7 /var/log/duracloud

Setup Tomcat

  1. Set up tomcat server credentials for automatic deployment on build
    1. in your settings.xml file (~/.m2/settings.xml)  add the following to the servers element:


Set up environment variables

These variables are picked up by the application:

  1. duracloud.bridge.root.username - the username used for initializing the instance (default root).
  2. duracloud.bridge.root.password - the password used for initializing the instance (default rpw).
  3. - an email associated with the root account that will send email regarding bridge server events.
  4. duracloud.bridge.root.dir - a directory that will receive data as well as store non-database application state and settings.
  5. duracloud.bridge.threads-per-job - max threads per job, recommended number is available CPU processors minus 1 (or fewer).

Add the parameters to your JAVA_OPTS environmental variable

JAVA_OPTS="$JAVA_OPTS -Dduracloud.bridge.root.username=<your username> -Dduracloud.bridge.root.password=<your password><your email> -Dduracloud.bridge.root.dir=<your root dir>"

Create a System environment variable to allow the AWS client to know your preferred region 

export AWS_REGION=us-east-1

Build and deploy the source

Run a build of the Bridge software, which will perform a deployment. Alternatively, perform the build and copy the generated WAR file to your Tomcat webapps directory.

cd snapshot
mvn clean install

Create the database

Using a mysql client create a database: 


Create the database tables using the SQL script found in the DuraCloud baseline. After downloading this file, run the following: 

mysql --user [username] --password [password] snapshot --execute set @saved_cs_client='utf8'; source snapshot_create-mysql.sql;

Create a DuraCloud User

You will need to create a duracloud user with ROLE_ADMIN permissions on the DuraCloud account which is being connected to the bridge in order for the bridge to read data from and write data to DuraCloud.  This can be done by your DuraCloud account administrator through

Initialize the application

First you'll need to create an init.json file using the values you setup in previous steps. See the Bridge App REST API for a copy of the init JSON file.

Then execute the following curl command to pass the initialization params to the bridge.

 curl -v -X  POST -d @/path/to/init.json \ 
                 -H "Content-Type: application/json"  \
                 -H "Accept:application/json" \
                 "https://<your bridge host:port>/bridge/init" \
                 -u <duracloud.bridge.root.username>:<duracloud.bridge.root.password> 

NB: The "clean" parameter should be set to true the very first time init is called, as this creates all the needed database tables. It should be set to false in all other situations.


If you wish to change any of your initialization parameters,  you must  first remove the persistent initialization params on the server by deleting the following file:  

<duracloud.bridge.root.dir>/duracloud-bridge-init.dat. This encrypted file contains the credentials you used to initialize the app. It will be read as soon as tomcat starts up in order to allow the service to start up without needing further intialization (as in the case of, for example, an unexpected server restart).

  • No labels