Installing the NetarchiveSuite software

This manual describes how to install and configure the NetarchiveSuite web archive software package. It includes description of how to obtain and install required libraries, how to install the software on separate machines, what command line options and configuration file changes are necessary, and how to start the programs. It then goes on to explain the other parameters available for tuning the behaviour of NetarchiveSuite. It does not explain how to extend the functionality of the system (see the DeveloperManual for this) or how to use the running system (see the UserManual for this).

The intended audience of this manual is system administrators who will be responsible for the actual installation and setup of NetarchiveSuite as well as technical personnel responsible for proper operation of NetarchiveSuite. Knowledge of Unix system administration is expected, and some familiarity with XML and Java is an advantage.

Choose a setup

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

• A. Single-machine setup. This corresponds to the setup used in the QuickstartManual, where all applications run on the same machine, and file transfer can be done simple by copying files locally. It is the simplest setup, but does not scale very well. Note that the scripts used in QuickstartManual resets the system at every restart, including deleting all harvested material. Obviously, this is not the intent for a running installation, so those scripts cannot be used in production environments as they are.

• B. Single-site setup. In this scenario, multiple machines are involved, necessitating file transfer between machines and multiple installations of the code. However, the machines are expected to be within the same firewall, so port setup should be no problem.
• C. Single-site setup with duplicate archive. This expands on the single-site setup in that more than one copy of the archives are used, using the concept of separate "locations" to indicate the duplicates.
• D. Multi-site setup. When more than one site is involved, separated by firewalls, extra issues of opening ports and specifying the correct site come into play. This is the most complex scenario, but also the more secure against systematic errors, hacking, and other disasters.

Setups C, and D involves having a distributed bitarchive. In these setups we have the the bitarchive distributed on two Locations, here called LocationA, and LocationB. These Locations must be written to the general settings.xml before deployment:

<arcrepository>
      ...
      <!-- The names of all bit archive locations in the
                 environment, e.g., "LocationA" and "LocationB". -->
      <location>
        <name>LocationA</name>
      </location>
      <location>
        <name>LocationB</name>
      </location>
      <!-- Default bit archive to use for batch jobs (if none is specified) -->
      <batchLocation>LocationA</batchLocation>
</arcrepository>

Choose JMS broker

The NetarchiveSuite requires the use of a JMS broker. The installation and startup of a JMSbroker is described in Appendix A. In the below extract of conf/settings.xml, the JMSbroker resides at machine1.domain, and listens for messages on port 7676. You must also select a JMS environmentName. This allows you have more than one running installation of the NetarchiveSuite, each with its own environmentName, and makes it easy to cleanup the JMS queues associated with a given environmentName. The NetarchiveSuite currently only supports one kind of JMS broker, so only the 'broker','port', and 'environmentName' can be changed.

<jms>
    <!-- Selects the broker vendor to be used. -->
            <class>SunMQ</class>
            <!-- The JMS broker host contacted by the JMS connection -->
            <broker>localhost</broker>
            <!-- The port the JMS connection should use -->
            <port>7676</port>
            <!-- The name of the environment in which this code is running, e.g.
                 PROD, RELEASETEST, NHC,... Common prefix to all JMS channels
                  -->
            <environmentName>PROD</environmentName>
        </jms>

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

When you have chosen your setup, you must decide on the number of machines, you want to use in the deployment of the NetarchiveSuite. For setup A, the answer is of course one. For the setup B-D, the answer is more complicated.

The NetarchiveSuite operates with 4 kinds of machines:

• - Admin machine (one server): Here we deploy one or more BitarchiveMonitorApplication's (one for each Location),

  • one ArcrepositoryApplication, and one HarvestDefinitionApplication (running the GUI, and scheduler). The latter application is the only application using a database.

  - harvester machines (one or more): Here we deploy the HarvesterControllerApplication's and their associated SideKick's

  - bitarchive machines (one or more): BitarchiveApplication

  - access servers (one or more): On these machines, we have the ViewerproxyApplication enabling us to browse in already stored webpages,

  • and the IndexServerApplication. The latter must/can only be installed on one of the accesservers.

In the standard setup used in our test-environment, we have 9 machines:

1 bitarchive server (on Location A)
2 bitarchive servers (on Location B)

1 admin machine (placed on Location A)
2 harvester-machines (placed on Location A)
2 harvester-machines (placed on Location B)

1 access server (placed on Location A)

Configure monitoring (allocating JMX and RMI ports)

Monitoring the deployed NetarchiveSuite relies on JMX (Java Management Extensions). Each application in the NetarchiveSuite needs its own JMX-port and associated RMI-port, so they can be monitored from the NetarchiveSuite GUI, and using jconsole (see below). You need to select a range for the JMX-ports. In the example below, the chosen JMX/RMI-range begins at 8100. Note: The RMI-ports for a certain JMX-port are assumed to be JMX-port-number + 100 Firewall Note: This requires that the admin-machine has access to each machine taking part in the deployment on ports 8100-8300.

You need to select a password for the JMX monitorRole, and replace the string "JMX_MONITOR_ROLE_PASSWORD_PLACEHOLDER" with the selected password in two files: the conf/jmxremote.password, and the settings file used When starting the application we define the path to the jmx passwordfile on the commandline:

• -Dsettings.common.jmx.passwordFile=INSTALLATION_DIR/conf/jmxremote.password

The JMX-ports are registered in the settings.xml used by the HarvestDefinitionApplication (GUI/Scheduler) in the deploy section of the settings.xml file:

<deploy>
<jmxMonitorRolePassword>SELECTED_PASSWORD</jmxMonitorRolePassword>
<numberOfHosts>NUMBER_OF_MACHINES_INVOLVED</numberOfHosts>
<host1>
<name>MACHINE_1</name>
<jmxport>8100</jmxport>
<jmxport>8101</jmxport>
</host1>
...
<hostX>
<name>MACHINE_X</name>
<jmxport>8100</jmxport>
<jmxport>8101</jmxport>
</hostX>
</deploy>

Other configurations

select a file datatransfer method

As mentioned in Appendix C, you can choose between FTP or HTTP as the filetransfer method. Correct: Both methods try to use to simple filesystem copying, whenever possible to optimize the filetransfer. The FTP method requires one or more FTP-servers installed. (Se Appendix A for further details) The xml-below is a extract of a settings.xml, which you have to replace serverName, userName, userPassword with proper values. [SKALRETTES] If you want to use more than one FTP-server, you must use different settings-files, or define the values when starting the applications on the commandline.

<remoteFile xsi:type="ftpremotefile">
            <!-- The class to use for RemoteFile objects. -->
            <class>dk.netarkivet.common.distribute.FTPRemoteFile</class>
            <!-- The default FTP-server used -->
            <serverName>hostname</serverName>
            <!-- The default FTP-server port used -->
            <serverPort>21</serverPort>
            <!-- The default FTP username -->
            <userName>exampleusername</userName>
            <!-- The default FTP password -->
            <userPassword>examplepassword</userPassword>
            <!-- The number of times FTPRemoteFile should try before giving up
                 a copyTo operation. We augment FTP with checksum checks. -->
            <retries>3</retries>
        </remoteFile>

Using HTTP as filetransfer method, you need to reserve a HTTP port on each machine pr. application for this usage. Note: The easiest way to set this port on application level is to set it on the commandline:  -Dsettings.common.remoteFile.port=5442 

See xml-below for the proper syntax:

 <remoteFile xsi:type="httpremotefile">
            <!-- The class to use for RemoteFile objects. -->
            <class>dk.netarkivet.common.distribute.HTTPRemoteFile</class>
            <!-- Port for embedded HTTP server -->
            <port>5442</port>
        </remoteFile>

Configure scheduling (schedule interval)

Configure job-generation

<hr> [[wiki:InstallationManualAppendices]