Contents

Choose a platform

NetarchiveSuite can be installed in a number of different ways, with varying numbers of machines on different sites. There is a number of separate applications in play, most of which can be put on separate machines as needed. To keep clear what is necessary for which setups, we will consider the following types of setup:

Choose Repository

Scenario A and B from section Choose a platform involves having a local arcrepository without means of bitarchive replicas. This is configured by a plug-in (please refer to Configure PlugIns in the Configuration Manual).

Scenarios C and D from section Choose a platform involves having a distributed bitarchive replicas. In these scenarios we have at least two bitarchive replicas. The Replica information must be configured before deployment either in the local settings file or included in the deploy configuration file for your system (please refer to Configure Repository in the Configuration Manual).

Choose the type of database

The !NetarchiveSuite can use three types of database:

By default, the NetarchiveSuite uses an external Derby. Note that from release 3.14.* the choice of an embedded Derby database has been removed to allow several applications to access the database simultaneously. The choice of the database is further described in the section on Plugins.

Besides the configuration of the plug-in (where Derby database is the default), there are additional installations and configurations that must be done as described below.

Note that <deployInstallDir>, <deployDatabaseDir> and <deployMachine> will be used as reference to items corresponding deploy settings. The meaning of them are described in the Deploy Settings.

Derby Database

If you want to use a Derby database, you have to make it run as a separate process.

  1. Start Derby separately
  2. cd "directory with the extracted database" (e.g. <deployInstallDir>/<deployDatabaseDir>)
  3. export CLASSPATH=<deployInstallDir>/lib/db/derbynet-10.4.2.0.jar:<deployInstallDir>/lib/db/derby-10.4.2.0.jar
  4. java org.apache.derby.drda.NetworkServerControl start -p port

The default port is 1527.

For the NetarchiveSuite to use this kind of external database, you need to

Firewall note: You will need to allow the GUIApplication and the !HarvestTemplateApplication to be able to access port 1527 on the server where you run the database.

More details on using Derby as a server are available on http://db.apache.org/derby/docs/dev/adminguide/cadminov825266.html the derby pages.

MySQL Database

If you want to use a MySQL database, you have to:

Firewall note: You will need to allow the GUIApplication and the !HarvestTemplateApplication to be able to access port 3306 on the server where you run the database.

This jar must then be added to the classpath for the applications, that accesses the database: GUIApplication and HarvestTemplateApplication

You can do this manually, when starting these applications. Alternatively, you can add the mysql-connector-java-5.0.X-bin.jar to the lib/db directory, and modify build.xml accordingly:

You can then generate a new !NetarchiveSuite zipball with

ant releasezipball

.

This assumes, that you have downloaded the source distribution of the NetarchiveSuite.

PostgreSQL Database

To be written.....

Choose a JMS broker

NetarchiveSuite requires a JMS broker to run. The only type of JMS broker supported at this time is the SunMQ broker and its open source counterpart Open Message Queue.

The installation and start-up of a JMS broker is described in Appendix A.

For description of how to configure the JMS broker, please refer to the Configure JMS Broker.

Firewall note: The machine that runs the JMS broker must be accessible from all machines in the installation on not only port 7676, but also port 33700 (from RMI).

Java

All machines must run Java version 1.6.0 or higher.

Choose the set of machines taking part in the installation/deployment

When you have chosen a scenario, you must decide on the number of machines, you want to use in the deployment of the !NetarchiveSuite. For scenario A, the answer is of course one. For the scenarios B, C, and D, the answer is more complicated.

An extra complication is added by installing the system at two different physical location (here referred as EAST and WEST). The distinction between different physical location are relevant if the system is installed at two different institutions with firewalls between them.

At the Danish installation, we operate with 4 kinds of machines:

Apart from the !HarvestControllerApplications, there is no requirement that the applications are placed like this, but we will use it as an example throughout the rest of the manual. In the standard set-up used in our test-environment, we have 9 machines:

Choose other plug-ins

Except from the plug-ins described in this section, the installation of plug-ins only consist of the configuration of them.