OpenText ™ InfoArchive ®
Version 4.3
Installation Guide
Legal Notice
This documentation has been created for software version 4.3.
It is also valid for subsequent software versions as long as no new document version is published.
Open Text Corporation
275 Frank Tompa Drive, Waterloo, Ontario, Canada, N2L 0A1
Tel: +1-519-888-7111
Toll Free Canada/USA: 1-800-499-6544 International: +800-4996-5440
Fax: +1-519-888-0677
For more information, visit https://www.opentext.com
Copyright 2017 Open Text. All Rights Reserved.
Trademarks owned by Open Text.
Adobe and Adobe PDF Library are trademarks or registered trademarks of Adobe Systems Inc. in
the U.S. and other countries.
Disclaimer
No Warranties and Limitation of Liability
Every effort has been made to ensure the accuracy of the features and techniques presented in this
publication. However, Open Text Corporation and its affiliates accept no responsibility and offer no
warranty whether expressed or implied, for the accuracy of this publication.
Table of Contents
Preface
Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
.................................................................................................................................
Introduction
7
................................................................................................. 11
InfoArchive Components and Folders ................................................................
InfoArchive Components ..............................................................................
InfoArchive Folders ......................................................................................
Storage Considerations .................................................................................
11
11
13
14
.............................................
Environment and System Requirements .............................................................
Demo Configuration .........................................................................................
Production Configuration .................................................................................
15
.....................................................
Install a Demo Configuration ............................................................................
Start the Components for a Demo Configuration ................................................
Install Sample Applications for a Demo Configuration ........................................
Verify the Demo Configuration ..........................................................................
17
19
Planning a Production Configuration ..........................................................
Installation Questionnaire .................................................................................
23
23
Load Balancing.................................................................................................
23
Component Passwords and Secret Tokens ..........................................................
Dedicated Retention Federation .........................................................................
24
24
Requirements and Supported Configurations
Quickly Installing a Demo Configuration
15
15
15
17
19
20
Windows Services ............................................................................................
25
Additional Performance Considerations .............................................................
25
.........................................................
Specify the Component Passwords and Secret Tokens .........................................
Install the xDB Server .......................................................................................
Installing the IA Server .....................................................................................
Specify How the IA Server Communicates with the xDB Server .......................
Install the IA Server ......................................................................................
Installing and Configuring Gateway / IAWA ......................................................
Installing the Audit Application ........................................................................
Configuring Retention in a Separate Federation ..................................................
Installing the Gateway / IAWA in Apache Tomcat ...............................................
27
Installing a Production Configuration
Using Generated Passwords with the Gateway / IAWA in Apache
Tomcat ........................................................................................................
Updating the Gateway Pointer ......................................................................
27
29
30
30
30
32
34
35
45
47
47
3
Table of Contents
Chapter 6
Chapter 7
Load Balancing with Apache .........................................................................
47
Uninstalling InfoArchive Services ......................................................................
48
Upgrading InfoArchive
................................................................................ 49
Upgrading Your InfoArchive Deployment..........................................................
Preparation ..................................................................................................
Migrating InfoArchive ..................................................................................
Testing the Migration ....................................................................................
49
50
53
59
.......................................................................................................
Password Generation ........................................................................................
Passwords on Multiple Servers ......................................................................
Working with In-Memory User Accounts ...........................................................
Enable the In-Memory User Accounts ............................................................
HTTPS Setup for IAS and Gateway / IAWA ........................................................
Setup SSL for IAS and Gateway / IAWA .........................................................
Assumptions Made In These Instructions ...................................................
Perform the SSL Setup with a Self-Signed Certificate ...................................
HTTPS Deployment of IAS and Gateway / IAWA on Separate Hosts ....................
Configuring Two-way TLS Authentication .........................................................
Generating Keystores and Truststores for SSL/TLS ..............................................
Optional Security Components for InfoArchive ..................................................
Configure LDAP (SSL) and NPA Support ...........................................................
Encrypted Passwords........................................................................................
SunJCE/Bouncy Castle (Local Keystore) .........................................................
Tools ........................................................................................................
Server ......................................................................................................
Gemalto Remote Keystore .............................................................................
Tools ........................................................................................................
Server ......................................................................................................
Change the Password and Encrypt it ..............................................................
ANT Tasks and Ciphered Values for Passwords ..............................................
Creating Decryption Configuration............................................................
61
Security
Enable Cipher-text Values in the ANT Tasks in the PhoneCalls
Application .............................................................................................
Chapter 8
Chapter 9
4
........................................................................................
Connecting to and Running xDB .......................................................................
Connecting to xDB Admin ............................................................................
Connection Ports ......................................................................................
Running the xDB Admin Console ..............................................................
JDBC Connection Setup ....................................................................................
Sample Applications .........................................................................................
Structured Data Archiving Samples ...............................................................
Compound Record (Data and Content) Samples .............................................
InfoArchive Connectors Samples ...................................................................
Using InfoArchive
...............................................
Terminology .....................................................................................................
Requirements ...................................................................................................
Last Resort Options ..........................................................................................
Other Considerations ........................................................................................
Disaster Recovery Scenario for InfoArchive
61
61
62
63
63
64
64
65
70
71
72
73
74
75
76
76
77
77
77
78
79
79
79
79
81
81
81
81
81
82
82
82
83
83
85
85
86
87
87
Table of Contents
Chapter 10
Disaster Recovery and Failover Steps .................................................................
88
Relevant Configuration .....................................................................................
89
Troubleshooting
.......................................................................................... 91
Error Messages .................................................................................................
91
Issues and Troubleshooting Steps ......................................................................
91
Appendix A
Command Line Installation Script Parameters
Appendix B
User Information for Sample Data Applications
Appendix C
In-Memory User Accounts
Appendix D
Security Files
............................................ 95
.......................................... 97
........................................................................... 99
............................................................................................ 101
5
Table of Contents
6
Preface
Intended Audience
This document is intended for system administrators who are responsible for installing InfoArchive.
To install InfoArchive, you must have:
• Administrative privileges on the computer(s) where you want to install InfoArchive components
• Working knowledge of the operating system that you want to install InfoArchive on
• Working knowledge of OpenText xDB deployment
• Working knowledge of Apache Ant and web application servers, such as Apache Tomcat
Document Conventions
This document uses the conventions shown below to aid formatting and readability.
Convention
Description
The \ newline character in code samples.
Some of the code samples shown in this guide
might contain \ newline characters that allow
the code to flow over several lines for readability
and formatting purposes. The \ newline
characters are not to be used as part of the code
shown, and you must manually remove them
prior to using the code.
<YOUR_PASSWORD>
A placeholder where you must enter a password.
<XDB_LICENSE_KEY>
A placeholder where you must enter the xDB
license key.
7
Preface
Path Conventions
This document uses the following path convention:
Path Variable
Description
<INFOARCHIVE_ROOT>
A variable that refers to the directory where you extract the
InfoArchive installation package run the installation script from. By
default, this folder has the same name as the distribution file, but
you can rename it before extracting it.
This document uses the <INFOARCHIVE_ROOT> variable to avoid
any confusion when referring to a directory or file path in this
documentation.
For example, when this document refers to the location of the
application.yml file that is located in the server folder, which is
located in the config folder, this document uses the following path
statement:
<INFOARCHIVE_ROOT>/config/server/application.yml
<IP_OF_xDB>
A variable that refers to the IP address of the xDB server.
<IP_OF_IAS>
A variable that refers to the IP address of the IAS server.
<IP_OF_IAWA>
A variable that refers to the IP address of the IAWA server.
Documentation
The following documentation provides information about InfoArchive:
• InfoArchive Release Notes
• InfoArchive Configuration & Administration Guide
• InfoArchive Command Line Tool Guide
• InfoArchive Installation Guide
• InfoArchive REST Development Guide
8
Preface
Revision History
Revision Date
Description
July 2017
The following sections were updated or moved:
• Introduction
• Requirements and Supported Configurations
• Quickly Installing a Demo Configuration
• Planning a Production Configuration
• Installing a Production Configuration
• Upgrading InfoArchive
• Preparation
June 2017
The following sections were added:
• Using Generated Passwords with the Gateway / IAWA in Apache
Tomcat
• Updating the Gateway Pointer
May 2017
Initial Publication
9
Preface
10
Chapter 1
Introduction
InfoArchive is an integrated product suite that is designed for application-agnostic information
management and archiving. This product suite preserves, maintains, and controls continuing access
to valuable enterprise information assets. With InfoArchive, your organization can extend the value
of information assets while reducing the costs associated with managing information.
Organizations that are seeking to reduce costs, optimize IT infrastructure, and improve information
governance can use InfoArchive as a low-cost information repository to store static information
and ensure that it is accessible and actionable.
For a complete overview of InfoArchive, see the InfoArchive Configuration & Administration Guide.
InfoArchive Components and Folders
InfoArchive Components
The InfoArchive distribution file includes the following components:
• InfoArchive Web Application, also known as IA Web UI, Gateway, IAWA, and the IA Web Server
This component is the main web application of InfoArchive and allows easy access to
configuration options and functionality.
• InfoArchive Server, also known as IA Server and IAS.
This component provides archiving services.
• InfoArchive XML Repository, also known as xDB, the xDB Federation, and the IA xDB
This XML database provides data storage services to IAS and stores metadata.
• InfoArchive Shell, also known as IAShell
This component provides a command line tool to perform administrative tasks, ingest data, and
manage or query objects.
• Framework for Data Ingestion
This component enables data ingestion using Ant scripts. Sample applications that demonstrate
how to work with data are available in the tools directory.
For more information, see Sample Applications.
11
Introduction
12
Introduction
InfoArchive Folders
The InfoArchive installation package is a single zip file, which includes the files and folders that are
required to install and run InfoArchive.
Note: There are two InfoArchive distribution files, one with cryptography called infoarchive.zip
and another without cryptography called infoarchive-nc.zip. Due to international restrictions
on encrypted technologies, one or the other distribution file is available.
infoarchive or infoarchive-nc: This is the root folder that contains the setup.bat
(Windows) and setup.sh (Linux) installation scripts. This root folder also contains the
Combined_TermsofUse_PP_Reg.htm file, and the xDB-IA-license.txt file.
The following folders are located within the above root folder:
• bin: Contains installation scripts for various components.
• config: Contains configuration related items.
• system: Contains system files for Linux and Windows.
• third-party: Contains third-party component licenses and documentation.
• lib: Contains program libraries for InfoArchive and xDB.
• tools: Contains utilities, such as the shell, migration, and password encryption tools. It also
contains the sample applications.
• data: Contains application data and is the folder where xDB stores its data. The data folder
might be empty until the set up has been completed.
• doc: Contains the javadocs with information on creating custom handlers and custom stores.
• extensions: Used for InfoArchive extensions and comes with a couple of sample extensions
included in it.
Note: The xDB-IA-license.txt file specifies a temporary xDB licence key, the license’s expiry
date, and how to get your permanent xDB license from OpenText technical support. This is the only
license key that you need to run InfoArchive. The xDB license key is a long string of numbers, letters
and symbols, and this string is referred to as <XDB_LICENSE_KEY> throughout this guide.
13
Introduction
Storage Considerations
InfoArchive supports several vendor neutral NAS storages solutions and it provides you with an
extensible storage API framework that you can use to integrate InfoArchive and an NAS storage
solution.
To see some of the storage options that are used in a sample application, have a look at
the resources folder of the PhoneCalls sample application. You can see some of the
file storage options in the XML files that are there. The resources folder is located in
<INFOARCHIVE_ROOT>/tools/applications/PhoneCalls/resources.
All of the XML files that have the same number as part of their file name are the files that contain
different file storage options.
For more information, see Sample Applications.
14
Chapter 2
Requirements and Supported
Configurations
Environment and System Requirements
Before you perform an installation, refer to the latest version of the InfoArchive Release Notes for
certified environment and system requirements, as well as known issues and workarounds.
Demo Configuration
You can quickly set up a demo configuration of InfoArchive so that you can test its features, set up
a proof of concept, give a short demonstration, or set up a basic development environment. In
a demo configuration, you install all of the InfoArchive components on one computer, and run
the InfoArchive Web Application as a Spring Boot application on the same computer. The demo
configuration includes some sample applications, data, and user accounts.
Production Configuration
For a production configuration, you should distribute InfoArchive components over separate
computers, including running the InfoArchive Web Application on a Tomcat server. How you choose
to distribute the components depends on your operational and security requirements, as well as
any concerns about network latency.
Throughout this guide, the storage systems shown in diagrams are a part of the overall InfoArchive
solution, but the storage systems themselves are not components of InfoArchive.
The following diagram illustrates three example configurations. In the first example, the default
configuration, all InfoArchive components are installed on the same computer. The third example,
where each component is installed on a separate computer, is a typical production configuration.
15
Requirements and Supported Configurations
16
Chapter 3
Quickly Installing a Demo Configuration
A demo configuration is a quick way to install all of the InfoArchive components on a single computer.
A demo configuration is not meant to be used in a production environment. It includes the following:
• Sample applications and data
• Auto-generated passwords for InfoArchive components
• No SSL, LDAP, or Microsoft Active Directory
• Sample user accounts for accessing InfoArchive
Caution: Do not use the sample user accounts in a production environment. Attackers can use
one of the sample user accounts to gain unauthorized access to your InfoArchive system and the
assets it contains. These out-of-the-box accounts are meant for demo purposes, and the default
password for each account is password. For more information about sample user accounts,
see Working with In-Memory User Accounts.
Install a Demo Configuration
After you acquire the latest InfoArchive distribution ZIP file, follow these steps to install a demo
configuration. The <INFOARCHIVE_ROOT> variable refers to the directory where you extract the
InfoArchive ZIP file and run the installation script.
The <INFOARCHIVE_ROOT>/xDB-IA-license.txt file specifies a temporary xDB licence key and
the license’s expiry date. The xDB license key is a long string of numbers, letters and symbols. The
file also includes information about how to contact OpenText technical support to get a permanent
xDB license key, which you need for a production environment.
Before you begin:
• Refer to the latest version of the InfoArchive Release Notes for certified environment and system
requirements, including the required version of JDK.
• Verify that your xDB license key has not expired.
• On a Linux computer, verify that you have root privileges. Also, to ensure that there is enough
entropy available for cryptographic applications, you should run the Haveged daemon.
17
Quickly Installing a Demo Configuration
To install a demo configuration:
1.
Extract the InfoArchive ZIP file to the <INFOARCHIVE_ROOT> directory.
2.
If you want to use the sample user accounts in your demo configuration, do the following:
a.
In a text editor, open the <INFOARCHIVE_ROOT>/config/webapp/application.yml
file.
b. Remove the # symbol from the following line:
active: #infoarchive.gateway.profile.AUTHENTICATION_IN_MEMORY
3.
If you want to change the password for a sample user account, do the following:
a.
In a text editor, open the <INFOARCHIVE_ROOT>/config/webapp/application
-infoarchive.gateway.profile.AUTHENTICATION_IN_MEMORY.properties file.
b. For each line that contains AUTHENTICATION_IN_MEMORY.user.users, change the word
password to the password that you want.
c.
If you changed the password of sue@iacustomer.com, then you must also open up the
<INFOARCHIVE_ROOT>/tools/build.properties file and update the password of this
account as follows:
# InfoArchive username
username=sue@iacustomer.com
# InfoArchive password
password=<YOUR_PASSWORD>
4.
Do one of the following:
• In Windows, open a command prompt, go to the <INFOARCHIVE_ROOT> directory, and
then run the setup.bat installation script.
• In Linux, open the Linux Command Shell, go to the <INFOARCHIVE_ROOT> directory, and
then run the setup.sh installation script.
5.
The following prompts appear:
a.
Install xDB server as a service?
(Y/n)
Type n.
b. Install InfoArchive Server as a service?
(Y/n)
Type n.
c.
Install InfoArchive Web App as a service?
(Y/n)
Type n.
d. Set up an xDB data node?
(Y/n)
Type y.
e.
Enter the xDB data node superuser password:
Type a password for xDB (for example, test).
f.
Enter the xDB license key:
Specify the xDB license key.
18
Quickly Installing a Demo Configuration
Start the Components for a Demo Configuration
Before you can use the demo configuration, you must start the components.
To start the components on a Windows computer:
1.
Open a command prompt, go to the <INFOARCHIVE_ROOT> directory, and then run the
following command:
bin\infoarchive-xdb.bat run-server --bootstrap data/xdb/xhive.bootstrap
--port 2910
Leave this command prompt open.
2.
Open a new command prompt, go to the <INFOARCHIVE_ROOT> directory, and then run the
following command:
bin\infoarchive-server
Leave this command prompt open.
3.
Open a new command prompt, go to the <INFOARCHIVE_ROOT> directory, and then run the
following command:
bin\infoarchive-webapp
Leave this command prompt open.
To start the components on a Linux computer:
1.
To ensure that there is enough entropy available for cryptographic applications, you should
run the Haveged daemon.
2.
Open the Linux Command Shell, and run the following commands:
• <INFOARCHIVE_ROOT>/bin/infoarchive-xdb-server.sh &
• <INFOARCHIVE_ROOT>/bin/infoarchive-server.sh &
• <INFOARCHIVE_ROOT>/bin/infoarchive-webapp.sh
Leave this Linux Command Shell open.
Install Sample Applications for a Demo
Configuration
Before you use a demo configuration, you should install some sample applications. You can use these
applications to understand how to create applications and work with data. There is also an audit
application that you can use to search all audit information in the InfoArchive repository.
The following applications are recommended for demo purposes:
Application
Description
Baseball
Serves as an example of archiving structured data
19
Quickly Installing a Demo Configuration
Application
Description
PhoneCalls
Serves as an example of archiving compound records, with
structured data and unstructured content
Audit
Enables you to search all audit information in the InfoArchive
repository
For more information about sample applications, see Sample Applications.
To install sample applications on a Windows computer:
1.
Open a command prompt, go to the <INFOARCHIVE_ROOT>\tools\applications
\Baseball directory, and then run the following command:
..\..\ant
2.
Go to the <INFOARCHIVE_ROOT>\tools\applications\PhoneCalls directory, and then
run the following command:
..\..\ant
3.
Go to the <INFOARCHIVE_ROOT>\tools\applications\audit directory, and then run the
following command:
..\..\ant
To install sample applications on a Linux computer:
1.
Open the Linux Command Shell, go to the <INFOARCHIVE_ROOT>/tools/applications
/Baseball directory, and then run the following command:
../../ant
2.
Go to the <INFOARCHIVE_ROOT>/tools/applications/PhoneCalls directory, and then
run the following command:
../../ant
3.
Go to the <INFOARCHIVE_ROOT>/tools/applications/audit directory, and then run the
following command:
../../ant
Verify the Demo Configuration
You can log into a demo configuration using any of the sample accounts, but you might want to log
on for the first time as connie@iacustomer.com, a Developer account. For more information about
performing a search in InfoArchive, see the InfoArchive Configuration & Administration Guide.
To verify the demo configuration:
1.
Open a supported browser, and go to localhost:8080.
2.
Log in using the user name and password of a sample user.
20
Quickly Installing a Demo Configuration
3.
To verify that InfoArchive ingested data from a sample application, perform a search.
21
Quickly Installing a Demo Configuration
22
Chapter 4
Planning a Production Configuration
By planning a production configuration of InfoArchive, you can help the installation process go
more quickly and smoothly. You can make decisions about which computers will host InfoArchive
components, how to manage application traffic, how to configure security, and so on. The following
questionnaire is meant to help you make these planning decisions, and the rest of this chapter
provides further detail about some of these questions.
Installation Questionnaire
Before you install InfoArchive, consider the following questions:
• How many computers do you want to use? Do you want to install multiple instances of
components? Do you want to set up load balancing?
• Do you want to specify passwords for the InfoArchive components, or do you want to use
automatically generated passwords?
• Do you want SSL to encrypt application traffic?
• Do you want to set up a dedicated retention federation?
• Do you want to use LDAP or Microsoft Active Directory to authenticate users?
• Do you want to encrypt the passwords that are stored in configuration files?
• Do you want to install InfoArchive components as Windows services? Or would you rather start
and stop the services manually using a command prompt?
Load Balancing
You can use load balancers to distribute traffic across multiple instances of IAWA and IAS that
are installed on separate computers. IAWA supports load balancing with or without the use of
sticky sessions. The following diagram illustrates a typical production configuration where IAWA
and IAS use load balancing:
23
Planning a Production Configuration
Component Passwords and Secret Tokens
By default, InfoArchive uses several passwords and secret tokens to secure access to its components:
Component
Passwords and secret tokens
xDB
• Password for data node superuser
• Admin password for each xDB database (for example, the
synchronization database)
InfoArchive Web Application
• Secret token for JDBC
• Secret token for CLI
InfoArchive Server and
InfoArchive Web Application
• Secret token for communication between InfoArchive Server
and InfoArchive Web Application
By default, these passwords and secret tokens are automatically generated when you install xDB.
In a production configuration, you should replace these passwords and secret tokens with your
own before you install the IA Server.
To change these passwords and tokens after you start running the IA Server, you must change the
passwords and tokens in the xDB admin client, manually specify the passwords and tokens in the
configuration files on each computer, and then restart the InfoArchive components.
For more information about security features, see Security.
Dedicated Retention Federation
If you have complex retention policy requirements, or require granular retention on a record, then
you might want to set up a dedicated retention federation for better performance when the database
gets large. This is a decision that you should make before you install InfoArchive because migrating
24
Planning a Production Configuration
from a deployment with one federation to a deployment with a dedicated retention federation is
not straightforward.
By default, InfoArchive installs with just one federation, and there are some specific tasks that you
need to perform to set up a dedicated retention federation. For more information, see Configuring
Retention in a Separate Federation.
Windows Services
In a production environment, you should install InfoArchive components as Windows services so
that Windows automatically tries to restart a service if it stops.
Additional Performance Considerations
For best performance, leave the working folders for each InfoArchive component on its local disk (for
example, the ingest folder, the receiver folder, and the Tomcat temp folder). Storing these folders on
network storage might cause performance and scalability issues. You should keep this in mind when
you install the InfoArchive Web Application and when you create and configure applications.
25
Planning a Production Configuration
26
Chapter 5
Installing a Production Configuration
This section describes the steps required to install and configure InfoArchive components on separate
computers that are all on the same network. When you install InfoArchive components on separate
computers, you should install each component as a Windows service.
When you install InfoArchive components as Windows services, some services might take up to five
minutes to start. If you are unable to access a URL or application, ensure that the service is running,
and then try to access the URL or application again.
If you want to run the installation script without answering a series of prompts, you can run the
script with parameters that specify the type of installation that you want. For more information, see
Appendix A: Command Line Installation Script Parameters.
Specify the Component Passwords and Secret
Tokens
Before you install InfoArchive components on separate computers, you must manually specify the
component passwords and secret tokens on each computer.
By default, when you install an InfoArchive component on a computer, the installation script
automatically generates passwords and tokens that are unique to that computer. However,
InfoArchive components on different computers can only communicate with each other if the
passwords and tokens for each component are the same. For example, the password for the data node
superuser must be the same on each computer.
You should use your own passwords and tokens rather than the automatically generated passwords
and tokens. But if you do want to use the automatically generated passwords and tokens, then you
must automatically generate the component passwords and secret tokens on one computer and then
copy the passwords and tokens to the other computers.
For more information about component passwords and secret tokens, see Component Passwords
and Secret Tokens.
Caution: If you do not use the same password or token for a component on each computer that
you install an InfoArchive component on, then the component will not function correctly.
27
Installing a Production Configuration
After you acquire the latest InfoArchive distribution ZIP file, follow these steps to specify the
component passwords. The <INFOARCHIVE_ROOT> variable refers to the directory where you
extract the InfoArchive ZIP file and run the installation script.
To specify your own component passwords:
1.
Extract the InfoArchive ZIP file to the <INFOARCHIVE_ROOT> directory on each computer that
you want to install an InfoArchive component on.
2.
On each computer, do the following:
a.
Open the <INFOARCHIVE_ROOT>/config/server/application.yml file in a text
editor.
b. For each line that contains #PASSWORD_<COMPONENT_PASSWORD_TYPE>_REFERENCE, type
your password before this text. For example:
keyStorePassword: <YOUR_PASSWORD> #PASSWORD_system_xdb_ssl
_keyStorePassword_REFERENCE
c.
Repeat steps (a) and (b) for each of the following files:
• <INFOARCHIVE_ROOT>/config/server/application-ssl.yml
• <INFOARCHIVE_ROOT>/config/webapp/application.yml
• <INFOARCHIVE_ROOT>/config/webapp/application-CLIENTS.yml
• <INFOARCHIVE_ROOT>/tools/build.properties
• <INFOARCHIVE_ROOT>/tools/application.properties
To specify automatically generated component passwords:
1.
Extract the InfoArchive ZIP file to the <INFOARCHIVE_ROOT> directory on each computer that
you want to install an InfoArchive component on.
2.
Automatically generate the component passwords on one computer by installing an InfoArchive
component on the computer.
3.
On the computer that you installed the InfoArchive component on, open each of the following
files in a text editor:
• <INFOARCHIVE_ROOT>/config/server/application.yml
• <INFOARCHIVE_ROOT>/config/server/application-ssl.yml
• <INFOARCHIVE_ROOT>/config/webapp/application.yml
• <INFOARCHIVE_ROOT>/config/webapp/application-CLIENTS.yml
• <INFOARCHIVE_ROOT>/tools/build.properties
• <INFOARCHIVE_ROOT>/tools/application.properties
4.
In each file, for each line that contains #GENERATED_PASSWORD_<COMPONENT_PASSWORD
_TYPE>_REFERENCE, copy the automatically generated password that appears before this
text and paste it into the corresponding file on the other computers that you want to install
InfoArchive components on.
Below is an example of a line that contains an automatically generated password:
28
Installing a Production Configuration
keyStorePassword: fddc03b8-2e19 #GENERATED_PASSWORD_system_xdb_ssl_keyStorePassword_REFERENCE
Install the xDB Server
After you install the xDB server, you should verify that it is running properly.
Before you begin:
• Refer to the latest version of the InfoArchive Release Notes for certified environment and system
requirements, including the required version of JDK.
• Verify that you have a permanent xDB license key. For more information about how
to contact OpenText technical support to get a permanent xDB license key, see the
<INFOARCHIVE_ROOT>/xDB-IA-license.txt file.
• If you want to install the xDB server on a Linux computer, verify that you have root privileges.
Also, to ensure that there is enough entropy available for cryptographic applications, you should
run the Haveged daemon.
To install the xDB Server:
1.
If you previously installed InfoArchive services on your computer, you can choose whether
to remove them with the following prompt:
Remove previously installed InfoArchive services?
2.
(Y/n)
The following prompt appears:
Install xDB server as a service?
(Y/n)
Type y.
3.
The following prompt appears:
Install xDB Server service using SSL? (y/N)
Type n.
4.
The installation script asks whether you want to install each of the other InfoArchive services
as a Windows service, and whether you want to set up SSL for each Windows service. Type n
for each prompt.
5.
The following prompts appear:
a.
Enter the xDB data node superuser password:
Specify a password for xDB.
b. Enter the xDB license key:
Specify the xDB license key.
To verify that the xDB Server is running:
1.
In Windows Services, confirm the InfoArchive xDB service is running.
2.
Do the following to open the xDB admin console and log in:
a.
In Windows, open a command prompt, go to the <INFOARCHIVE_ROOT>/bin directory,
and then run the infoarchive-xdb admin script.
29
Installing a Production Configuration
b. In Linux, open the Linux Command Shell, go to the <INFOARCHIVE_ROOT>/bin directory,
and then run the ./infoarchive-xdb admin script.
Installing the IA Server
After you install the xDB server, you must first specify how the IA Server communicates with the xDB
server, and then you can install the IA Server.
Specify How the IA Server Communicates with the xDB
Server
You must perform this task before you install the IA Server.
Before you begin:
• Verify that you have already installed the xDB server on a separate computer and the xDB server
is running.
To specify how the IA Server communicates with the xDB server
1.
On each computer that you want to run the IA Server on, open the <INFOARCHIVE_ROOT>
/config/server/application.yml file in a text editor.
2.
For each instance of the word bootstrap in the file, specify the IP address of the computer
that hosts the xDB Server as follows:
bootstrap: xhive://<IP_OF_xDB>:2910
Install the IA Server
After you specify how the IA Server communicates with the xDB server, you can install the IA Server.
Before you begin:
• Refer to the latest version of the InfoArchive Release Notes for certified environment and system
requirements, including the required version of JDK.
• Verify that you have specified the component passwords and secret tokens on this computer,
and that they match the passwords and tokens on the xDB server. If you do not use the same
password or token for a component on each computer that you install an InfoArchive component
on, then the component will not function correctly.
• Verify that you specified how the IA Server communicates with the xDB server.
• If you want to install the xDB server on a Linux computer, verify that you have root privileges.
Also, to ensure that there is enough entropy available for cryptographic applications, you should
run the Haveged daemon.
30
Installing a Production Configuration
To install the IA Server:
1.
Do one of the following:
• In Windows, open a command prompt, go to the <INFOARCHIVE_ROOT> directory, and
then run the setup.bat installation script.
• In Linux, open the Linux Command Shell, go to the <INFOARCHIVE_ROOT> directory, and
then run the setup.sh installation script.
2.
If you previously installed InfoArchive services on your computer, you can choose whether
to remove them with the following prompt:
Remove previously installed InfoArchive services?
3.
(Y/n)
The following prompts appear:
a.
Install xDB server as a service?
(Y/n)
Type n.
b. Install InfoArchive Server as a service?
(Y/n)
Type y.
c.
Install InfoArchive Server service using SSL? (y/N)
Type n.
d. Install InfoArchive Web App as a service?
(Y/n)
Type n.
e.
Set up an xDB data node?
(Y/n)
Type n.
To verify that the IA Server is running:
1.
In Windows Services, confirm that the InfoArchive Server service is running.
2.
Open a supported browser, and go to <IP_OF_IA_Server>:8765/services. The IA Server is
running if the browser returns either of the following results:
• Text that resembles the following:
{
"name" : "InfoArchive Home Resource",
"_links" : {
"self" : {
"href" : "http://localhost:8765/services"
},
"http://identifiers.emc.com/product-info" : {
"href" : "http://localhost:8765/product-info"
}
}
}
• A request for you to open or save a file of type application/hal+json.
31
Installing a Production Configuration
Installing and Configuring Gateway / IAWA
The IAWA must know the location of the IAS. You must specify the location of your IAS server in the
<INFOARCHIVE_ROOT>/config/webapp/application.yml file.
Make the following change to the application.yml file:
url: http://<IP_OF_IAS>:8765
1.
Login to the IAWA server.
2.
Unzip the infoarchive binaries to <INFOARCHIVE_ROOT>.
3.
Configure the IAWA:
a.
Open the application.yml file found in the <INFOARCHIVE_ROOT>/config/webapp
directory.
b. Change both the secure and non-secure zuul/routes/path/url to correspond to the
IAS IP address.
32
Installing a Production Configuration
c.
You must enable an authentication profile in order for IAWA to work. To make
your installation easier, you can enable the In-Memory user accounts as a temporary
authentication profile. To enable the In-Memory user accounts, uncomment the value for the
active property in the <INFOARCHIVE_ROOT>/config/webapp/application.yml
file as shown in this code snippet:
spring:
application:
name: infoarchive.gateway
profiles:
# The infoarchive.gateway.profile.AUTHENTICATION_IN_MEMORY is not recommended
# for production.
active: infoarchive.gateway.profile.AUTHENTICATION_IN_MEMORY
...
For more information, see In-Memory User Accounts and Working with In-Memory User
Accounts.
4.
Install the IAWA:
a.
In a command prompt (or from Windows Explorer), run setup (found in
<INFOARCHIVE_ROOT> directory).
b. Enter the following selections:
i.
Install the xDB server as a service?: N
ii. Install InfoArchive Server as a service?: N
iii. Install InfoArchive Web App as a service?: Y
iv. Install InfoArchive Web App using SSL?: N
v. Set up an xDB data node?: N
33
Installing a Production Configuration
5.
Open the IAWA and navigate to http://<IP_OF_IAS>:8080 on the web application server.
When IAWA is installed using SSL, navigate to https<IP_OF_IAS>:8080
If everything is configured properly, you should be able to successfully login to IAWA.
Installing the Audit Application
In this section we discuss the installation of the Audit sample application, however the
installation steps are the same for the other sample applications, with minor changes
to path statements as required. As long as the IP addresses for the IAS and Gateway /
IAWA hosts are configured to point to the hosts for those components, and the value of
the gatewaySecret secret key for IAS and the Gateway / IAWA are matching in the
<INFOARCHIVE_ROOT>/config/webapp/application-CLIENTS.yml file, then you can install
the sample applications from any node, not just the Gateway / IAWA node.
After you have confirmed that all of the above IP addresses and key or password values are correct,
proceed with the installation of the Audit sample application, which must be installed in order
to search the audits.
1.
While on the Gateway / IAWA server, open a command prompt.
2.
Navigate to the <INFOARCHIVE_ROOT>/tools/applications/Audit directory and open
the build.properties file for the Audit application.
3.
Confirm again that the services IP and the gatewaySecret secret key match for both the IAS
and Gateway / IAWA as mentioned earlier.
34
Installing a Production Configuration
From within the Audit application directory, run the ANT installation script with the following
command:
../../ant
For more information, see
Note: Once you are in a sample application’s directory, use the above command to run ANT from
the directory of the sample application to load its data.
4.
You can sign into the Gateway / IAWA as a Developer or a Retention Manager to confirm that
your configuration is correct.
If you encountered any errors while installing the Audit sample application, you can view the log
files in the <INFOARCHIVE_ROOT>/tools/applications/Audit/logs directory.
Configuring Retention in a Separate Federation
Configuring retention in a separate federation may be an option for you if you have a large number
of items that are aging independently. Whether or not to use retention in a separate federation is a
decision that must be made in advance because there is no way to reverse this configuration once
data has been ingested by the server.
Caution: Whether or not you decide to use a configuration where retention is done using a
separate federation is a decision that cannot be reversed once the server has ingested data. Please
consider all of your options and requirements before proceeding with this type of configuration.
Configuration of Retention in a Separate Federation (Optional)
1.
Start in your installation root directory. In this guide we refer to this directory as
<INFOARCHIVE_ROOT>. In the image below, <INFOARCHIVE_ROOT> represents this location
C;\InfoArchive4.3\inforarchive-demo but your root path may be different.
35
Installing a Production Configuration
2.
In the OpenText xDB Admin Client dialog, select Data node > Create data node
3.
Browse to (or enter) a directory path value for the Bootstrap path: in the Create data node dialog.
36
Installing a Production Configuration
By default, the OpenText xDB Admin Client dialog selects XhiveDatabase.bootstrap in the xdb
directory for the Bootstrap path: value. You must change this default value to another directory,
which must be different than the xdb directory.
You can create a new directory called xdb-retention and put it in the same location as the xdb
directory.
Enter the path to your new directory in the Bootstrap path: field as shown in the image below.
Write down the above bootstrap path because you will need it to start the dedicated xDB
retention server.
4.
Enter the license key and the superuser password in the appropriate fields. The license key,
bootstrap, and superuser password must match the values for these items that are defined for
the retention database in the server’s application.yml file.
5.
Click OK
Verify the Configuration of Retention in a Separate Federation
1.
Navigate to the (xdb-retention) directory that you specified above. It should look similar to the
image shown below.
37
Installing a Production Configuration
2.
Windows
Open the Administrator Command Prompt and run the following command:
setup.bat --dataNodeOnly --supasswd test --licensekey <license-key-value>
Linux
Open the Shell Command and run the following command:
setup.sh --dataNodeOnly --supasswd test --licensekey <license-key-value>
3.
Start the xDB servers.
First, start the main xDB server with the following (Windows or Linux) command using as an
example port 2910:
Windows
<INFOARCHIVE_ROOT>\bin\infoarchive-xdb.bat run-server --bootstrap
data/xdb/xhive.bootstrap --port 2910
Linux
<INFOARCHIVE_ROOT>/bin/infoarchive-xdb.sh run-server --bootstrap
data/xdb/xhive.bootstrap --port 2910
The following image shows the Windows command, within the Administrator Command
Prompt, to start the main xDB retention server.
38
Installing a Production Configuration
4.
Change the port (as an example) to 2911, and the bootstrap so they contain the values of the
retention database that you created earlier.
Caution: Make sure the bootstrap and directory path values match those that you created
earlier. Otherwise, this process will fail.
5.
Start the second xDB retention server. For example, if you created the xdb-retention directory,
the command would look like the following:
Windows
<INFOARCHIVE_ROOT>\bin\infoarchive-xdb.bat run-server --bootstrap
data/xdb-retention/xhiveDatabase.bootstrap --port 2911
Linux
<INFOARCHIVE_ROOT>/bin/infoarchive-xdb.sh run-server --bootstrap
data/xdb-retention/xhiveDatabase.bootstrap --port 2911
The following image shows the Windows command, within the Administrator Command
Prompt, to start the second xDB retention server.
39
Installing a Production Configuration
Caution: Ensure that all of the passwords that exist in the following two application.yml
files are correct:
• <INFOARCHIVE_ROOT>\config\server\application.yml
• <INFOARCHIVE_ROOT>\config\webapp\application.yml
The following image shows an application.yml file open for edit in a text editor. The
passwords section of the file is shown highlighted.
40
Installing a Production Configuration
6.
Start the InfoArchive server with the following command:
Windows
<INFOARCHIVE_ROOT>\bin\infoarchive-server.bat
Linux
<INFOARCHIVE_ROOT>/bin/infoarchive-server.sh
41
Installing a Production Configuration
The following image shows the InfoArchive server startup screen.
7.
42
Let the servers run for about 5 minutes. Look in the <INFOARCHIVE_ROOT>/data/xdb/
directory. You should not see the managedItemDatabase database file in this directory because
it should be in the new directory that you created earlier.
Installing a Production Configuration
8.
Connect to the port for the retention Xdb server.
9.
Open the Connect to database dialog and ensure that only one database is listed in the Database
name dropdown.
43
Installing a Production Configuration
10. Close the xDB Admin Console.
Caution: Ensure that the xDB Admin Console is closed.
11. Open the Select bootstrap URL dialog and select the other bootstrap URL, this is the one that
uses port 2910.
Check to see that the main database is listed in the Database name dropdown list.
44
Installing a Production Configuration
If you have the PhoneCalls sample application installed, then you should see some of its
managed items, as shown in the image below:
For troubleshooting information, see Troubleshooting.
Installing the Gateway / IAWA in Apache Tomcat
You can run the IAWA application as is or you can use Apache Tomcat to host the IAWA war file. The
following instructions demonstrate how to deploy the IAWA to Apache Tomcat.
45
Installing a Production Configuration
1.
Ensure that Tomcat is stopped. This step is only required if you want to change the configuration
files first. The WAR files are expanded when Tomcat is started or if it is running once the WAR
file has been copied to the Tomcat webapps folder.
2.
Copy the infoarchive-webapp.war file from the distribution’s lib directory to Tomcat’s
webapps folder, which is located:
…/apache-tomcat-8.5.11/webapps/infoarchive-webapp.war
When Tomcat is started, it picks up the WAR file and expands it into the following folder:
…/apache-tomcat-8.5.11/webapps/infoarchive-webapp
The configuration files that you may want to edit are located:
…/apache-tomcat-8.5.11/webapps/infoarchive-webapp/WEB-INF/classes
3.
Point the Gateway / IAWA to IAS, which is a machine named iashost, on port 8080. To do
this you must edit the application.yml file’s server section. The application.yml file
is located here:
…/apache-tomcat-8.5.11/webapps/infoarchive-webapp/WEB-INF/classes/application.yml
The changes that you must make to the server section are shown below:
:
server:
host: ${infoarchive.gateway.host}
port: ${infoarchive.gateway.port}
contextPath: ${infoarchive.gateway.contextPath}
:
zuul:
routes:
restapi:
path: /restapi/**
sensitiveHeaders: ""
url: http://iashost:8765/
:
:
4.
In addition to the above changes, when you are running the IAWA application and IAS in HTTPS
(SSL) mode, edit the url property at the end of the file as shown below:
--spring:
profiles: "infoarchive.profile.HTTPS"
server:
ssl:
keyStore: "classpath:ssl/keystore.jks"
keyStore-password: "<YOUR_PASSWORD>"
keyPassword: "<YOUR_PASSWORD>"
zuul:
routes:
restapi:
path: /restapi/**
sensitiveHeaders: ""
url: https://<IP_OF_IAS>:8765/
5.
46
Restart Tomcat.
Installing a Production Configuration
Using Generated Passwords with the Gateway / IAWA
in Apache Tomcat
InfoArchive generates passwords and secrets for authentication purposes. Complete the following
steps if you want to keep the generated passwords and secrets when Gateway / IAWA has been
deployed to an external Tomcat container:
1.
The following files contain the generated passwords and secrets and must be copied into the
files indicated:
a.
Copy the <INFOARCHIVE_ROOT>/config/webapp/application.yml file to the
infoarchive-webapp/WEB-INF/classes/application.yml file.
b. Copy the <INFOARCHIVE_ROOT>/config/webapp/application-CLIENTS.yml to the
infoarchive-webapp/WEB-INF/classes/application-CLIENTS.yml file.
Updating the Gateway Pointer
Whether you are deploying InfoArchive with Tomcat to the same machine or a different one, the
pointer in the tools/build.properties file must be updated.
For example, when Gateway/IAWA are deployed to an external Tomcat on a local machine, the
default setting is:
http://localhost:8080/infoarchive-webapp/ (HTTP Mode)
This must be changed to:
:
gateway = http://localhost:8080/infoarchive-webapp/
:
Load Balancing with Apache
The Apache HTTP Server can be used as the load balancing component. Apache can be configured to
work with load balancing by editing the httpd.conf file in the following manner: The critical line
of code is displayed below in bold.
:
:
Listen 8090
:
:
<IfModule mod_proxy_balancer.c>
ProxyPreserveHost On
ProxyPass /ia balancer://gateway/
ProxyPassReverse /ia balancer://gateway/
RequestHeader set X-Forwarded-Prefix "/ia"
<Proxy balancer://gateway>
BalancerMember http://<IP_OF_IAWA>:<PORT>/infoarchive-webapp loadfactor=1
</Proxy>
47
Installing a Production Configuration
<Location /balancer-manager>
SetHandler balancer-manager
</Location>
</IfModule>
To access the IAWA using the above configured load balancing:
http://<IP_OF_IAWA>:<PORT>/ia/
The trailing slash of the URL is required.
In addition to load balancing, Apache also provides a feature called sticky sessions. For
more information on load balancing and sticky sessions in Apache, see Apache Module:
mod_proxy_balancer.
Uninstalling InfoArchive Services
There are two methods to uninstall InfoArchive services:
• Run setup again. Indicate that you want to remove the previously installed InfoArchive services;
or
• Run the following command in the InfoArchive directory:
setup --remove
Neither method above removes existing xDB data nodes. If the components of your installation
have been distributed over multiple servers, hosts, or nodes, you must run remove each one of
those services separately.
Note: The uninstallation script does not remove services that are distributed over multiple servers,
hosts, or nodes. These services must be uninstalled on each server, host, or node as required.
48
Chapter 6
Upgrading InfoArchive
If you have an existing installation of InfoArchive version 3.x, and you want to upgrade to the latest
version of InfoArchive, please contact OpenText Global Support Services or an InfoArchive partner
for a migration assessment.
Caution: Do not install InfoArchive 4.x on the same Windows server as InfoArchive 3.x.
Upgrading Your InfoArchive Deployment
You can use the upgrade script to upgrade your current InfoArchive deployment to the latest version.
You must perform some steps manually during the upgrade process. Always follow industry
standard best practices to back up your environment before making any changes.
Caution: Before applying any changes to your production environment, it is a best practice
to thoroughly test all changes in a development, testing, or staging environment. It is also
recommended that you take a backup image of each of the servers on which InfoArchive is
running. In the event of a failure, server backup images give you ability to roll-back any changes
that have been made to your servers and their configuration files. These backups images can
help prevent data loss and can be used to restore your system in the event of failure.
You must have the following items to perform a successful upgrade:
• The latest version of the InfoArchive 4.3 distribution ZIP file
• A text editor to make adjustments to configuration files
Caution: You must backup any keystores that you have before attempting to do any work on
your system. If the keystore in your data directory gets corrupted, you will NOT be able to
view any of your encrypted data.
49
Upgrading InfoArchive
Preparation
Before attempting to create a system backup for migration purposes, you must ensure that your
system has an adequate amount of disk space to hold the xDB Server databases and the system
backup files. These xDB databases are not part of the storage used for unstructured data.
Caution: Do not attempt to backup your system if you are low on disk space. Doing so will
cause the xDB Server to stop and your backup will not be complete.
If you see an error message stating that the xDB Server has lost its connection, or a message stating
that a peer reset has occurred, the likely cause of these errors is an insufficient amount of disk space.
To remedy this situation, you must free up some disk space on the machine that is hosting the xDB
Server. Once you have a sufficient amount of disk space cleared, you must restart the xDB Server
before restarting the system backup procedure again. Restarting the IAS and the IAWA is optional.
1.
You have two backup options before upgrading:
a.
Option 1: Backup the InfoArchive directory
b. Option 2: Backup the database by completing the following steps:
i.
Ensure that the system is running (especially the xDB processes) and open the xDB
Admin Client dialog. Use the following command to open the Admin Client dialog:
Windows
<INFOARCHIVE_ROOT>\bin\infoarchive-xdb admin
Linux
<INFOARCHIVE_ROOT>/bin/infoarchive-xdb admin
ii. In the xDB Admin Client screen, navigate to Admin > Select bootstrap URL from the
menu as shown below.
Note: Do not connect to a specific database.
50
Upgrading InfoArchive
Caution: Depending on your setup configuration, multiple independent federations
may exist. Each federation must be backed up separately.
You can determine which federations to backup by looking at which xDB server
processes are running. You can also determine which federations to backup by
inspecting the <INFOARCHIVE_ROOT>/config/server/application.yml
configuration file and looking for any xDB URLs that are specified in the various
bootstrap properties of that file.
51
Upgrading InfoArchive
Caution: Using the contents of the application.yml file to determine your
backup requirements only works when the configuration of your system
federations, databases, or both is done using the application.yml file
exclusively, and not by using system properties, environment variables, etc.
Settings in the application.yml file may be overridden by system properties,
environment variables, etc., When your configuration is using system properties,
environment variables, etc., then you must look in those locations for federations
and databases to back up.
iii. In the xDB Admin Client, select Backup/Restore > Backup.
Caution: Two separate federations exist if you are upgrading from an InfoArchive
instance that was previously upgraded from InfoArchive version 4.0. Each
federations must be backed up independently, because in this case there are two
xDB servers running, one for each federation.
iv. In the Backup window:
a.
Specify the full name in the Output literal field.
b. Select Standalone.
c.
Click OK.
d. When prompted for the password, enter the xDB dataNode federation password.
Caution: This is not the license key.
Note: If you backup the xDB database, you must also make sure to backup the
<INFOARCHIVE_ROOT>/data/root folder to secure your unstructured content. Further,
if you have configured retention in a separate database (separate federation), you must
backup that federation separately.
2.
Verify that the backup was created in the specified location.
3.
Move the keystore files from your current version to the locations specified in the new version’s
application.yml file.
52
Upgrading InfoArchive
4.
The next step depends on how you plan to proceed with the migration:
• You can copy the data folder from your old installation, as long as the application.yml
file points to the correct locations of your configured server installation. If this is the case, you
can proceed with the migration.
If the locations do not match, then the files must be copied to the exact locations that are
defined in the application.yml file. Otherwise, InfoArchive will not be able to find its
components and it will not work.
• You can use the xDB Admin tool to create a backup. However, you must copy the following
keystore.jceks data into the location specified in the application.yml file:
crypto:
# KeyStore configuration
keyStore:
keyStoreFileLocation: "data/keystore/keystore.jceks"
keyStoreType: jceks
keyStorePass: <your-password>
Note: The following step only applies to the default infoarchive.zip distribution, which
uses cryptography. If you are using the infoarchive-nc.zip distribution, the following
step is not required and may be ignored.
When using the default encryption configuration (infoarchive.zip), copy the file that
matches the keyStoreFileLocation, which is relative to the <INFOARCHIVE_ROOT>
directory.
Migrating InfoArchive
When using the iashell to perform a migration you must manually create the
application.properties file within the <INFOARCHIVE_ROOT>/tools directory. You must
ensure that the gateway.clientSecret key value that is in the application.properties file
matches the clientSecret key value found in the application-CLINETS.yml file.
The following code snippet displays the gateway.clientSecret key in the
application.properties file and the matching value in the clientSecret property of the
application-CLIENTS.yml file. The value of the key is shown for demonstration only.
In the application.properties file:
...
gateway.clientSecret=eea28bc5-5ca9-47a6-aafb-811f27c9e9f2
...
In the application-CLIENTS.yml file:
...
clientId: "infoarchive.cli"
authorizedGrantTypes:
- "password"
- "refresh_token"
53
Upgrading InfoArchive
- "implicit"
authorities:
- "ROLE_TRUSTED_CLIENT"
clientSecret:eea28bc5-5ca9-47a6-aafb-811f27c9e9f2
#SECRET_CLIENTS_infoarchive-cli_clientSecret_DEFINITION
...
The following procedure updates your data, therefore you must complete this procedure only once.
When your software is distributed over multiple hosts, you must update each machine that has the
previous version of InfoArchive with the latest version.
1.
Ensure that all instances of the IAS are stopped, otherwise migration errors, such as the lib
folder not being updated, may occur.
Caution: When you are using multiple servers, ensure that the client of the previous
version’s of IAWA is not communicating with the InfoArchive 4.3 server.
2.
Choose the location where you want to store the InfoArchive upgrade and extract InfoArchive
into that directory.
We refer to the above directory as <INFOARCHIVE_ROOT> throughout this guide.
3.
You can use one of the following options to put your backup data into its new location:
Option 1: Create a New Directory and Keep Your Previous Data
a.
Create a new directory, name it InfoArchive 4.3, and extract the 4.3 infoarchive.zip
distribution file into this new directory.
Note: We will refer to this directory location as <INFOARCHIVE_ROOT> in this guide.
b. In your old InfoArchive 4.x installation folder, copy the contents of the previous
version’s data folder to replace the data folder in your new InfoArchive 4.3 directory
(<INFOARCHIVE_ROOT>).
Replacing the data in the data folder in this manner allows you to preserve the data from
your previous installation after the upgrade has been completed.
Ensure that you are able to modify the application.yml file that is found in the
<INFOARCHIVE_ROOT>/tools/config/migration folder.
Caution: If your initial deployment was version 4.0, then you must change the bootstrap
listed in the managedItemData section of the application.yml file to the following:
bootstrap: xhive://<IP_OF_xDB>:<PORT>
c.
Start the xDB server.
d. Ensure that the xDB server password is entered correctly.
e.
Ensure that the xDB server is running.
Change to your installation root (<INFOARCHIVE_ROOT> ) directory.
Use the following command to run xDBAdmin:
54
Upgrading InfoArchive
Windows
\bin\infoarchive-xdb admin
Linux
./bin/infoarchive-xdb admin
In the Admin client, connect to the xDB database server that was started in the previous
steps by clicking on the Bootstrap URL button, and then specifying the bootstrap:
xhive://<IP_OF_xDB>:2911 of the server (or servers) that you started.
Option 2: Restore from a Backup File
a.
In xDBAdmin, click Restore.
b. Select the backup file.
c.
Ensure that the Use original paths button is selected.
d. Ensure the Backup data version is set to Current.
e.
Click OK.
Note: If the retention database is in a separate federation, this procedure must be done for both
instances of InfoArchive.
Use a different port for each instance, and ensure that the bootstrap parameter matches the
bootstrap value for the retention federation.
4.
If you have made changes to the previous version’s application.yml file, and you want
to keep those changes for this installation, merge the changes into the current version of the
application.yml file.
The following new sections were added to the application.yml file in 4.3:
• tableArchiving
• pollingDelayForRestorationOfflineContent:
• orderItemRetentionDays:
900
1:
The following code snippets taken from the application.yml file display the new properties,
which are shown in bold below:
...
# Configuration of table archiving
tableArchiving:
# Maximum segment size in bytes after which a new segment is created if 0 then a
# segment grows indefinitely
maxSegmentSize: 10000000000
...
# Configuration for the order items
order:
pollingDelayForRestorationOfflineContent: 900
orderItemRetentionDays: 1
...
55
Upgrading InfoArchive
5.
If the retention database is stored in a separate federation, the application.yml file must
be modified to reflect this.
The application.yml file is found here: <INFOARCHIVE_ROOT>/tools/config
/migration, and these are some of the modifications that can be done:
managedItemData:
xdb:
dataNode:
name: mainFederation
# The following value '2910' for the port number must be the actual port
# number where the xDB server is located. Adjust it accordingly.
bootstrap: xhive://<IP_OF_xDB>:2911
superuser:
password: <Your-Password>
database:
name: managedItemDatabase
admin:
password: <Your-Password>
The above property values should match the values that were set for each of those same
properties in your previous InfoArchive 4.x application.yml file.
6.
The xDB server must be running. If it is not running, use the following command to start the
xDB server:
• For Windows
infoarchive\bin\infoarchive-xdb run-server --bootstrap data\xdb\xhive.bootstrap
--port 2910
• For Linux
infoarchive/bin/infoarchive-xdb run-server --bootstrap data/xdb/xhive.bootstrap
--port 2910
If you have multiple xDB servers, specify the bootstrap and port for each server to ensure that the
second instance is running.
To deploy the IAWA, IAS and xDB database to dedicated machines, the following properties
must be updated:
For the IAWA, update the <INFOARCHIVE_ROOT>/config/webapp/application.yml
property:
• zuul.routes.restapi.url
zuul:
routes:
restapi:
path: /restapi/**
sensitiveHeaders: ""
url: http://<IP_OF_IAS>:8080/
For the IAS, update the following <INFOARCHIVE_ROOT>/config/server/application
.yml properties:
• system.xdb.dataNode.bootstrap
• auditData.xdb.dataNode.bootstrap
56
Upgrading InfoArchive
• managedItemData.xdb.dataNode.bootstrap
• batchData.xdb.dataNode.bootstrap
system
xdb:
dataNode:
storeStackTraceInLock: false
name: mainFederation
bootstrap: xhive://<IP_OF_xDB>:<PORT>
auditData:
xdb:
dataNode:
storeStackTraceInLock: false
name: mainFederation
bootstrap: xhive://<IP_OF_xDB>:<PORT>
managedItemData:
xdb:
dataNode:
storeStackTraceInLock: false
name: mainFederation
bootstrap: xhive://<IP_OF_xDB>:<PORT>
batchData:
xdb:
dataNode:
storeStackTraceInLock: false
name: mainFederation
bootstrap: xhive://<IP_OF_xDB>:<PORT>
Note: If retention has its own federation and the retention federation is located on the same host
as the other components, then the port number used must be different for each bootstrap value.
When the retention federation is on a different host than the other components, then you can
use the same port number.
When separate federations for retention have been configured, then each xDB server within
each federation must be started separately. The command to start the xDB server is similar to
the one shown above except that a separate bootstrap file was created for retention, therefore
the port, that is used in this example, is 2911.
Before running migration, by default, the logging is set to the WARN level. This level can be
changed to DEBUG or INFO in the application.yml file, which is found in the following
directory: <INFOARCHIVE_ROOT>/tools/config/migration
Caution: The above statements assume that you are using the default configuration. If
you initial deployment was from InfoArchive 4.0, then you must set the port to 2911 for
the managedItemData property.
7.
In the tools directory:
• Windows, run migration
• Linux, run ./migration
If successful, the following is displayed after the Spring Boot logo:
2017-01-10 14:38:25.989 - Migration start
57
Upgrading InfoArchive
2017-01-10 14:38:42.691 - Migration finished
Any migration process messages, including errors and information, is printed to the console. In
addition to this, any errors are logged to the <INFOARCHIVE_ROOT>/tools/logs/migration
-errors.log file.
When the migration is successful, you should be able to open the <INFOARCHIVE_ROOT>/tools
/logs/ia.log file and see that the LibraryIndexCleaner has removed a number of indexes.
Note: You can run the migration (Windows), or the ./migration (Linux) command as many
times as you want. Each time the command is run, information about the process is stored in
the error.log file.
8.
Any changes from your existing configuration files should be merged into the new configuration
files with care. The settings in these files are needed in order for InfoArchive to operate as
intended.
• <INFOARCHIVE_ROOT>/config/server/application.yml
• <INFOARCHIVE_ROOT>/config/server/application-ssl.yml
• <INFOARCHIVE_ROOT>/config/webapp/application.yml
For more information on any existing or new settings of the <INFOARCHIVE_ROOT>/config
/webapp/application.yml file, see the Configuration and Administration Guide.
Note: With respect to the application-ssl.yml file, any configuration file prior to 4.2 may
contain property names that have dashes in them, such as keyStore. However, configuration files
for version 4.2 and later use camel casing instead of dashes, such as keyStore. Both property
name styles are acceptable.
The following section provides an overview of newly introduced properties in release 4.3 that are
found in the <INFOARCHIVE_ROOT>/config/server/application.yml file:
• New Configuration File Element
# Spring settings for multipart requests
# Changed since InfoArchive 4.3
http:
multipart:
enabled: true
maxFileSize: 1024MB
maxRequestSize: 1024MB
fileSizeThreshold: 0
...
— Description: The multipart setting has been moved under Spring and a file size
threshold has been added.
• New Configuration File Element
There is a new section under system.xdb for the following:
synchronizationDatabase:
name: synchronizationDatabase
admin:
58
Upgrading InfoArchive
password:
— Description: For an upgrade, set the password in the <INFOARCHIVE_ROOT>/config
/server/application.yml file and this database is automatically created when the
server starts.
• New Configuration File Element
# Configuration of table archiving
tableArchiving:
# Maximum segment size in bytes after which a new segment is created if 0 then a
# segment grows indefinitely
maxSegmentSize: 10000000000
Testing the Migration
1.
Ensure that all of the servers are running.
2.
Execute a search to ensure that the results are returned as expected.
3.
Login as Adam, and if you installed the Trades application, navigate to the Retention Sets tab to
ensure that the sets are displayed as expected.
59
Upgrading InfoArchive
60
Chapter 7
Security
The following sections discuss various aspects of security for InfoArchive and its components.
Password Generation
Historically, software manufacturers would provide default passwords to customers for the purposes
of proof of concepts and demonstration. These default passwords allowed customers to bypass the
configuration of their own secure passwords so they could temporarily use the system to perform
demonstrations. The software manufacturer expected customers to immediately change those default
passwords to secure their system from unauthorized access. However, time and time again, customers
would forget to reset or remove those passwords and would inadvertently leave their organization
open to attack by hackers who could use the default passwords to gain unauthorized access.
InfoArchive version 4.3 and later comes with a password generation feature, which automatically
generates passwords where needed in your configuration files. This feature helps secure InfoArchive
and simplify your Out-Of-The-Box experience.
A note of caution, the Password Generation feature is meant to be used for demonstration and
proof of concept purposes only, and does not address subsequent changes that are made to your
passwords, nor does it address the encryption of your passwords. Password policy mechanisms,
encryption features, and all of the other password and security features are not affected by the
Password Generation feature. Further, the password generation feature does not affect migration,
except that the generated passwords in new configuration files may be redefined when compared
with the existing configuration files before an upgrade is done. You are responsible for manually
editing existing configuration files that you intend to re-use as part of your upgrade to the latest
version of InfoArchive.
Password Generation is only meant to be used with a single machine deployment of InfoArchive in
HTTP mode. For HTTPS mode you must generate (or obtain) all of the truststore certificates required
by your network. In addition to this, you must manually set the passwords for your keystores and
truststores in your configuration files as needed.
Passwords on Multiple Servers
Password generation uses GUIDs to create unique passwords. In other words, each machine
generates unique GUIDs. Since all of the passwords for IAS, Gateway / IAWA, and xDB must match
61
Security
across machines, because these passwords cannot be automatically generated using the password
generation feature.
Caution: When you are deploying InfoArchive across multiple machines, you must manually
set matching keys and passwords for each machine in the configuration files.
If you are using the password generation feature to set the passwords, then you must generate
the passwords in one place (on one machine) and then manually copy the generated passwords
to each of the other machines. You must ensure that the passwords or keys, on each machine for
each component, match in all of the configuration files across machines in order for a multiple
machine deployment of InfoArchive to succeed.
Note: The directory where you installed InfoArchive is referred to as <INFOARCHIVE_ROOT>
throughout this guide.
Here is a list of configuration files that contain passwords:
• <INFOARCHIVE_ROOT>/config/server/application.yml
• <INFOARCHIVE_ROOT>/config/server/application-ssl.yml
• <INFOARCHIVE_ROOT>/config/webapp/application.yml
• <INFOARCHIVE_ROOT>/config/webapp/application-CLIENTS.yml
• <INFOARCHIVE_ROOT>/config/xdb/xdb.properties
• <INFOARCHIVE_ROOT>/config/xdb/xdb-server.properties
• <INFOARCHIVE_ROOT>/tools/build.properties
• <INFOARCHIVE_ROOT>/tools/application.properties
Check each configuration file shown above on each machine to be certain.
Working with In-Memory User Accounts
InfoArchive comes by default with a number of sample user accounts, which are also known as
In-Memory user accounts. You can use these accounts to perform demonstrations or use for proof of
concepts. Each In-Memory user account has specific access rights that allow you see how the system
is accessed by a user with those access rights. All of the In-Memory user accounts have the same
default password, which is simply the word password. If you decide to change this password, you
must update the password in the following file:
<INFOARCHIVE_ROOT>/config/webapp/application-infoarchive.gateway.profile
.AUTHENTICATION_IN_MEMORY.properties
Caution: The In-Memory user accounts are not meant to be used in a production environment,
and should be removed from your system or disabled as soon as possible. Otherwise, attackers
can use one of those In-Memory accounts to gain unauthorized access to your InfoArchive
system and the assets it contains.
For more information, see In-Memory User Accounts .
62
Security
Enable the In-Memory User Accounts
Before you can use any of the default In-Memory user accounts, you must explicitly enable the
AUTHENTICATION_IN_MEMORY profile. Once this profile is enabled, the In-Memory user accounts
are active.
One way to enable the In-Memory profile is by editing the <INFOARCHIVE_ROOT>/config
/webapp/application.yml file.
In the following code snippet we have enabled the AUTHENTICATION_IN_MEMORY profile by
removing the # character from the active parameter, which uncomments it as shown in bold below:
spring:
application:
name: infoarchive.gateway
profiles:
# The infoarchive.gateway.profile.AUTHENTICATION_IN_MEMORY is not
recommended for production.
active: infoarchive.gateway.profile.AUTHENTICATION_IN_MEMORY
include: CLIENTS
...
When you uncomment the code as shown above, you can also change the passwords from the value
password to something else, but this is not necessary if you are just performing a demonstration of
InfoArchive. However, if you decide to change the passwords of the In-Memory user accounts, you
must also update these passwords in the <INFOARCHIVE_ROOT>/tools/build.properties file.
Caution: All passwords must be correctly set in all of the configuration files, otherwise you
will not be able to access InfoArchive as expected. We recommend that you leave the default
In-Memory user account passwords as they are for the duration of your demonstration or
proof of concepts purposes, and then immediately disable the above profile to deactivate these
accounts.
Under no circumstances should the infoarchive.gateway.profile.AUTHENTICATION
_IN_MEMORY profile remain active in a production environment.
HTTPS Setup for IAS and Gateway / IAWA
Before you can run IAS and the Gateway / IAWA in SSL mode you must obtain a root certificate from
a certificate authority (CA), you can use your corporate CA root certificate, or you can generate your
own self-signed certificate.
Caution: A self-signed certificate should not be used in a production environment.
Note: The code samples shown in this guide may contain \ newline characters that allow the code to
flow over several lines for readability and formatting purposes. These \ newline characters are not to
be used as part of the code shown, and must be manually removed prior to using the code.
After you have a CA root certificate, follow these steps:
63
Security
General Overview of the Procedure
1.
Import the IAS certificate into the keystore.
2.
Edit the <INFOARCHIVE_ROOT>/config/server/application-ssl.yml file so it points to
the keystore and enter the keystore passwords.
3.
Run IAS with the following (OS specific) command:
Windows
<INFOARCHIVE_ROOT>/bin/infoarchive-server-ssl.bat
Linux
<INFOARCHIVE_ROOT>/bin/infoarchive-server-ssl.sh
4.
Import the IAS certificate into the Gateway / IAS keystore.
5.
Export the IAS and Gateway / IAWA public certificate, then import them both into the Gateway /
IAWA truststore.
This generates a file called server_public_cert.cert.
6.
Edit the <INFOARCHIVE_ROOT>/config/webapp/application.yml file to point to the
keystore and specify the keystore passwords.
7.
Run the Gateway / IAWA in SSL mode with the following command:
Windows
<INFOARCHIVE_ROOT>/bin/infoarchive-webapp-ssl.bat
Linux
<INFOARCHIVE_ROOT>/bin/infoarchive-webapp-ssl.sh
Setup SSL for IAS and Gateway / IAWA
We created self-signed certificates and added them to the keystores and truststores to run IAS and
Gateway / IAWA in HTTPS mode. This was done for demonstration purposes within this guide.
Note: Here we use the <INFOARCHIVE_ROOT>/config/server/https and
<INFOARCHIVE_ROOT>/config/webapp/https folders to store the keystores and truststores.
However, you can use any location you like for these keystores and truststores as long as you specify
their locations correctly in the appropriate configuration files.
Assumptions Made In These Instructions
We made the following assumptions in these setup instructions:
• The distribution has been extracted into: <INFOARCHIVE_ROOT>
• Both IAS and Gateway / IAWA are running on the same machine hence localhost works
everywhere. If IAS and Gateway / IAWA are running on different machines in your configuration,
then you must use their IP addresses in place of localhost.
• There is a strict requirement that IAS and Gateway / IAWA both be run in HTTPS mode. You
cannot run one in HTTP and the other in HTTPS mode.
64
Security
Perform the SSL Setup with a Self-Signed Certificate
This procedure displays the commands used to perform each step:
1.
Create the Directories
> cd <INFOARCHIVE_ROOT>
> mkdir config\server\https
> mkdir config\webapp\https
2.
Create the Self-Signed IAS Certificate
The following commands generate a file called serverCertStore.p12.
> cd <INFOARCHIVE_ROOT>\config\server\https
> keytool -export -noprompt -rfc -alias IA_SERVER_CERT -file server_public_cert.cert \
-keystore serverKeyStore.jks -storepass <YOUR_PASSWORD> -storetype JKS
3.
List the Self-Signed IAS Certificate
> cd <INFOARCHIVE_ROOT>\config\server\https
> keytool -list -v -keystore serverCertStore.p12 -storepass
<YOUR_PASSWORD> -storetype PKCS12
4.
Create the Keystore for IAS
> cd <INFOARCHIVE_ROOT>\config\server\https
> keytool -importkeystore -deststorepass <YOUR_PASSWORD> -destkeypass <YOUR_PASSWORD> \
-destkeystore serverKeyStore.jks -srckeystore serverCertStore.p12
-srcstoretype PKCS12 -srcstorepass <YOUR_PASSWORD>
-alias IA_SERVER_CERT
5.
Export the IAS Certificate
The following commands generate a file called server_public_cert.cert.
> cd <INFOARCHIVE_ROOT>\config\server\https
> keytool -export -noprompt -rfc -alias IA_SERVER_CERT -file server_public_cert.cert \
-keystore serverKeyStore.jks -storepass <YOUR_PASSWORD> -storetype JKS
6.
Import IAS Certificate into Gateway / IAWA
The following commands generate a file called gatewayTrustStore.jks
> copy <INFOARCHIVE_ROOT>\config\server\https\server_public_cert.cert \
<INFOARCHIVE_ROOT>\config\webapp\https
> cd <INFOARCHIVE_ROOT>\config\webapp\https
> keytool -import -noprompt -trustcacerts -alias IA_SERVER_CERT \
-file server_public_cert.cert -keystore gatewayTrustStore.jks \
65
Security
-storepass <YOUR_PASSWORD>
7.
List The Imported IAS Certificate
You can use the following commands to display and verify the certificate.
> cd <INFOARCHIVE_ROOT>\config\webapp\https
> keytool -list -v -keystore gatewayTrustStore.jks
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entries
Alias name: server_public_cert
Creation date: Jun 10, 2016
Entry type: trustedCertEntry
Owner: CN=localhost, OU=JavaSoft, O=Sun, L=Cupertino, ST=California, C=US
Issuer: CN=localhost, OU=JavaSoft, O=Sun, L=Cupertino, ST=California, C=US
Serial number: 357866c0
Valid from: Fri Jun 10 08:32:40 PDT 2016 until: Thu Sep 08 08:32:40 PDT 2016
Certificate fingerprints:
MD5: F1:05:E4:6A:F4:7C:C4:A7:8A:0E:B6:DE:A9:16:DF:AA
SHA1: CC:65:A3:74:85:C0:97:DA:95:AE:13:1F:CA:75:16:CA:66:F2:17:87
SHA256: 22:86:56:6B:16:A1:D5:C1:66:CE:2B:A7:F5:CA:EC:74:45:C5:A5:3E:00:DD: \
F1:28:8F:F3:F8:7D:2B:00:25:A4
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 5D 34 8D B8 34 CF 0B A0
64 05 20 93 E4 BA 92 28
0010: CD EB 20 64
]
]
8.
]4..4...d. ....(
.. d
Create Self-Signed Gateway / IAWA Certificate
The following commands generate a file called gatewayCertStore.p12.
> cd <INFOARCHIVE_ROOT>\config\webapp\https
> keytool -genkey -noprompt -trustcacerts -keyalg RSA -alias IA_GATEWAY_CERT \
-dname "CN=localhost, OU=JavaSoft, O=Sun, L=Cupertino, S=California, C=US" \
-keypass <YOUR_PASSWORD> -storetype PKCS12 -keystore gatewayCertStore.p12 \
-storepass <YOUR_PASSWORD>
9.
List the Self-Signed Gateway / IAWA Certificate
You can use the following commands to display and verify the certificate.
> cd <INFOARCHIVE_ROOT>\config\webapp\https
> keytool -list -v -keystore gatewayCertStore.p12 -storepass
<YOUR_PASSWORD> -storetype PKCS12
66
Security
10. Create the Keystore for Gateway / IAWA
> cd <INFOARCHIVE_ROOT>\config\webapp\https
> keytool -importkeystore -deststorepass <YOUR_PASSWORD> -destkeypass <YOUR_PASSWORD> \
-destkeystore gatewayKeyStore.jks -srckeystore gatewayCertStore.p12 \
-srcstoretype PKCS12 -srcstorepass <YOUR_PASSWORD> -alias IA_GATEWAY_CERT
11. Export the Gateway / IAWA Certificate
The following commands generate a file called gateway_public_cert.cert.
> cd <INFOARCHIVE_ROOT>\config\webapp\https
> keytool -export -noprompt -rfc -alias IA_GATEWAY_CERT -file gateway_public_cert.cert \
-keystore gatewayKeyStore.jks -storepass <YOUR_PASSWORD> -storetype JKS
12. Import the Gateway / IAWA Certificate into the Gateway / IAWA
The following commands generate a file called gatewayTrustStore.jks.
> cd <INFOARCHIVE_ROOT>\config\webapp\https
> keytool -import -noprompt -trustcacerts -alias gateway_public_cert \
-file gateway_public_cert.cert -keystore gatewayTrustStore.jks
-storepass <YOUR_PASSWORD>
13. List the Imported Gateway / IAWA Certificate
You can use the following commands to display and verify the certificate.
> cd <INFOARCHIVE_ROOT>\config\webapp\https
> keytool -list -v -keystore gatewayTrustStore.jks
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 2 entries
Alias name: gateway_public_cert
Creation date: Jun 10, 2016
Entry type: trustedCertEntry
Owner: CN=localhost, OU=JavaSoft, O=Sun, L=Cupertino, ST=California, C=US
Issuer: CN=localhost, OU=JavaSoft, O=Sun, L=Cupertino, ST=California, C=US
Serial number: 78b0bb1b
Valid from: Fri Jun 10 08:41:09 PDT 2016 until: Thu Sep 08 08:41:09 PDT 2016
Certificate fingerprints:
MD5: 21:21:12:82:77:83:06:B9:EC:87:93:D3:07:FD:50:22
SHA1: 56:1C:F2:D2:17:75:9A:4F:FB:F3:D9:C3:89:64:7D:29:52:4E:DC:1B
SHA256: 92:3D:F3:E3:83:98:61:6D:34:02:66:6E:2D:07:60:F6:E9:DD:3D:BA:AD:AC:31 \
:1C:91:39:76:85:9A:9F:C0:FD
Signature algorithm name: SHA256withRSA
Version: 3
Code sample continued on next page.
Code sample continued:
67
Security
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 3C 90 5E 2D CF 7E 2A 49
AB 20 DC E1 E5 2A 1E 71
0010: 4A 2A 83 A1
]
]
<.^-..*I. ...*.q
J*..
*******************************************
*******************************************
Alias name: server_public_cert
Creation date: Jun 10, 2016
Entry type: trustedCertEntry
Owner: CN=localhost, OU=JavaSoft, O=Sun, L=Cupertino, ST=California, C=US
Issuer: CN=localhost, OU=JavaSoft, O=Sun, L=Cupertino, ST=California, C=US
Serial number: 357866c0
Valid from: Fri Jun 10 08:32:40 PDT 2016 until: Thu Sep 08 08:32:40 PDT 2016
Certificate fingerprints:
MD5: F1:05:E4:6A:F4:7C:C4:A7:8A:0E:B6:DE:A9:16:DF:AA
SHA1: CC:65:A3:74:85:C0:97:DA:95:AE:13:1F:CA:75:16:CA:66:F2:17:87
SHA256: 22:86:56:6B:16:A1:D5:C1:66:CE:2B:A7:F5:CA:EC:74:45:C5:A5:3E:00:DD:F1:28 \
:8F:F3:F8:7D:2B:00:25:A4
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 5D 34 8D B8 34 CF 0B A0
64 05 20 93 E4 BA 92 28
0010: CD EB 20 64
]
]
]4..4...d. ....(
.. d
*******************************************
*******************************************
14. Import the Gateway / IAWA Certificate into IAS
The following commands generate a file called serverTrustStore.jks
> copy <INFOARCHIVE_ROOT>\config\webapp\https\gateway_public_cert.cert \
<INFOARCHIVE_ROOT>\config\server\https
> cd <INFOARCHIVE_ROOT>\config\server\https
> keytool -import -noprompt -trustcacerts -alias IA_GATEWAY_CERT \
-file gateway_public_cert.cert -keystore serverTrustStore.jks -storepass <YOUR_PASSWORD>
15. Configure IAS for HTTPS Mode
Open the <INFOARCHIVE_ROOT>\config\server\application-ssl.yml file for edit.
Enter the following into its server section:
server:
ssl:
key-store: "file:config/server/https/serverKeyStore.jks"
68
Security
key-store-password: <YOUR_PASSWORD>
key-password: <YOUR_PASSWORD>
keyStoreType: JKS
keyAlias: ia_server_cert
trust-store: "file:config/server/https/serverTrustStore.jks"
trust-store-password: <YOUR_PASSWORD>
trust-store-type: JKS
# Change the client-auth value from 'want', which provides
# one-way TLS authentication, to 'need', which provides
# two-way TLS authentication and is more secure.
client-auth: need
16. Run IAS in HTTPS Mode
> cd <INFOARCHIVE_ROOT>
> .\bin\infoarchive-server-ssl.bat
17. Configure the Gateway / IAWA for HTTPS Mode
spring:
application:
name: infoarchive.gateway
profiles:
active: infoarchive.profile.HTTPS,infoarchive.gateway.profile.AUTHENTICATION_IN_MEMORY
cloud:
config:
enabled: false
infoarchive:
gateway:
host: localhost
port: 8080
contextPath: /
token:
secret: secret
server:
host: ${infoarchive.gateway.host}
port: ${infoarchive.gateway.port}
contextPath: ${infoarchive.gateway.contextPath}
zuul:
routes:
restapi:
path: /restapi/**
sensitiveHeaders: ""
url: http://localhost:8765/
addProxyHeaders: true
host:
socket-timeout-millis: 60000
--spring:
profiles: "infoarchive.profile.HTTPS"
server:
ssl:
key-store: "file:config/webapp/https/gatewayKeyStore.jks"
key-store-password: <YOUR_PASSWORD>
key-password: <YOUR_PASSWORD>
keyStoreType: JKS
trust-store: "file:config/webapp/https/gatewayTrustStore.jks"
trust-store-password: <YOUR_PASSWORD>
69
Security
trust-store-type: JKS
zuul:
routes:
restapi:
path: /restapi/**
sensitiveHeaders: ""
url: "https://localhost:8765/"
18. Run the Gateway / IAWA in HTTPS Mode
> cd <INFOARCHIVE_ROOT>
> bin\infoarchive-webapp-ssl.bat
HTTPS Deployment of IAS and Gateway / IAWA
on Separate Hosts
You must set the host IP address in the IAWA infoarchive.gateway.host property.
The make-cert.bat command generates certificates using the SubjectAlternativeName (SAN)
extension node key / value pairs:
For example, "ip:10.64.155.231,ip:10.64.155.232,ip:10.64.155.233,ip:10.64
.155.234,ip:10.64.155.235"
Example 7-1. Deploy IAS and IAWA with HTTPS Mode on Separate Hosts
The following code sample displays the commands required to deploy IAS and IAWA with HTTPS
mode on separate hosts.
@echo off
@rem ##########################################################################
@rem
@rem make-cert.bat nodes password
@rem
@rem ##########################################################################
if not exist "server" mkdir server
if not exist "webapp" mkdir webapp
if not exist "jdbc" mkdir jdbc
cd server
keytool -genkeypair -noprompt -trustcacerts -keyalg RSA -alias IA_SERVER_CERT \
-dname "CN=IAS, OU=JavaSoft, O=Sun, L=Cupertino, S=California, C=US" -keypass %2 \
-storetype PKCS12 -keystore serverCertStore.p12 -storepass %2 -ext SAN=%1
keytool -importkeystore -deststorepass %2 -destkeypass %2 \
-destkeystore serverKeyStore.jks -srckeystore serverCertStore.p12 \
-srcstoretype PKCS12 -srcstorepass %2 -alias IA_SERVER_CERT
keytool -export -noprompt -rfc -alias IA_SERVER_CERT -file server_public_cert.cert \
-keystore serverKeyStore.jks -storepass %2 -storetype JKS
copy server_public_cert.cert ..\webapp
cd ..\webapp
keytool -import -noprompt -trustcacerts -alias IA_SERVER_CERT \
-file server_public_cert.cert -keystore gatewayTrustStore.jks -storepass %2
70
Security
keytool -genkeypair -noprompt -trustcacerts -keyalg RSA -alias IA_GATEWAY_CERT \
-dname "CN=IAWA, OU=JavaSoft, O=Sun, L=Cupertino, S=California, C=US" \
-keypass %2 -storetype PKCS12 -keystore gatewayCertStore.p12 -storepass %2 -ext SAN=%1
keytool -importkeystore -deststorepass %2 -destkeypass %2 \
-destkeystore gatewayKeyStore.jks -srckeystore gatewayCertStore.p12 \
-srcstoretype PKCS12 -srcstorepass %2 -alias IA_GATEWAY_CERT
keytool -export -noprompt -rfc -alias IA_GATEWAY_CERT -file gateway_public_cert.cert \
-keystore gatewayKeyStore.jks -storepass %2 -storetype JKS
keytool -import -noprompt -trustcacerts -alias gateway_public_cert \
-file gateway_public_cert.cert -keystore gatewayTrustStore.jks -storepass %2
copy gateway_public_cert.cert ..\server
Code sample continued on next page.
Code sample continued:
cd ..\server
keytool -import -noprompt -trustcacerts -alias IA_GATEWAY_CERT \
-file gateway_public_cert.cert -keystore serverTrustStore.jks -storepass %2
cd ..
copy webapp\gateway_public_cert.cert jdbc
cd jdbc
keytool -import -noprompt -trustcacerts -alias IA_GATEWAY_CERT \
-file gateway_public_cert.cert -keystore jdbcTrustStore.jks -storepass %2
keytool -genkeypair -noprompt -trustcacerts -keyalg RSA -alias IA_JDBC_CERT \
-dname "CN=IAS-JDBC, OU=JavaSoft, O=Sun, L=Cupertino, S=California, C=US" \
-keypass %2 -storetype PKCS12 -keystore jdbcCertStore.p12 -storepass %2 -ext SAN=%1
keytool -importkeystore -deststorepass %2 -destkeypass %2 \
-destkeystore jdbcKeyStore.jks -srckeystore jdbcCertStore.p12 -srcstoretype PKCS12 \
-srcstorepass %2 -alias IA_JDBC_CERT
keytool -export -noprompt -rfc -alias IA_JDBC_CERT -file jdbc_public_cert.cert \
-keystore jdbcKeyStore.jks -storepass %2 -storetype JKS
keytool -import -noprompt -trustcacerts -alias jdbc_public_cert \
-file jdbc_public_cert.cert -keystore jdbcTrustStore.jks -storepass %2
copy jdbc_public_cert.cert ..\webapp
cd ..\webapp
keytool -import -noprompt -trustcacerts -alias IA_JDBC_CERT \
-file jdbc_public_cert.cert -keystore gatewayTrustStore.jks -storepass %2
cd ..
Configuring Two-way TLS Authentication
When you choose to install IAS with SSL, by default TLS v1.2 is enabled. The following properties
must be set within the <INFOARCHIVE_ROOT>/config/server/application.yml file
71
Security
server:
ssl:
ciphers: AES # Supported SSL ciphers.
client-auth: need
# Whether client authentication is wanted ("want") or needed ("need").
# Requires a trust store.
key-alias= #certification alias
key-password= #certificate password
key-store= #key store location
key-store-password= #key store password
key-store-type= #key store type
trust-store= #trust store location
trust-store-password= #trust store password
trust-store-type= #trust store type
Generating Keystores and Truststores for
SSL/TLS
The InfoArchive server must import the trusted client’s public certificate, which are either self-signed
or they are signed by an external certificate authority, into the above trust store, using the alias and
truststore password that is set in the above configuration file.
Note: If the public certificate was signed by an external certificate authority, its public certificate must
also be imported and defined as trusted in order to maintain the certificate’s chain of trust.
After you have the public certificate and the password for IAS, you can use them to set up TLS
authentication.
Setup Two-way TLS Authentication
Using the public certificate, you are required to setup Mutual TLS authentication (mTLS) in order to
secure IAS. In two-way TLS authentication, the TLS client and TLS server authenticate themselves
and each other.
Follow these steps to setup two-way TLS authentication in IAS:
1.
Generate the self signed client certificate.
keytool -genkey -noprompt -trustcacerts -keyalg RSA -alias IA_CLIENT_CERT
-keypass <Keystore_Password> -storetype PKCS12 -keystore clientCertStore
.p12 -storepass <Truststore_Password>
2.
Display client certificates in the keystore.
keytool -list -v -keystore clientCertStore.p12 -storepass <Truststore
_Password> -storetype PKCS12
3.
Create the public client certificate for other applications.
keytool -export -noprompt -rfc -alias IA_CLIENT_CERT -file client
_public_cert.cert -keystore clientCertStore.p12 -storepass
<Truststore_Password> -storetype PKCS12
4.
72
Import the certificate into the server keystore.
Security
keytool -import -noprompt -trustcacerts -alias client_public_cert
-file client_public_cert.cert -keystore server_truststore.jks
-storepass <Truststore_Password>
5.
Add the following properties to the <INFOARCHIVE_ROOT>/config/server/application
.yml file.
server:
ssl:
key-store: "serverCertStore.p12"
key-store-password: <Keystore_Password>
key-password: <Key_Password>
key-store-type: PKCS12
key-alias: ia_server_cert
trust-store: "server_truststore.jks"
trust-store-password: <Truststore_Password>
trust-store-type: JKS
client-auth: need
For more information, see Using Encrypted Passwords in Configuration Files.
Optional Security Components for InfoArchive
You can choose the following installation components to extend InfoArchive:
Component
Description
NPA
Non Personal Account, which refers to an anonymous
account that can be used to access the active directory.
LDAP
Lightweight Directory Access Protocol (LDAP) is an
application protocol that aids in searching distributed
directory services over IP networks. LDAP is built on a
client-server model. LDAP features include access control,
support for Unicode, and other functionality that secures
resources over IP networks.
The IAWA supports the ability to lock a user whose login
attempts have failed multiple times. This ability has been put
in place to prevent brute-force attacks.
When the external LDAP has locked a user’s account, a
message asking the user to contact their Administrator to
get it unlocked is displayed. Enforcement of this security
feature depends on the configuration of the external LDAP
or Active directory (AD).
The following is the account lockout message:
[LDAP: error code 49 - INVALID_CREDENTIALS:
Bind failed: account was permanently locked]
73
Security
Component
Description
LDAPs
LDAP supports secure (SSL/TLS) access using the LDAPs
protocol.
You can use a Non Personal Account (NPA) to access the
active directory and acquire a list of groups etc.
AD
Active Directory (AD) is a directory service (database)
implemented by Microsoft. AD includes hierarchical
information about objects on the network where each object
can be a computer, printer, user, site, or other related item.
Objects have names and sets of attributes. For example,
a user inside of an organization can be represented as an
object with attributes: First Name, Last Name, Title, Email,
Country, etc.
Configure LDAP (SSL) and NPA Support
InfoArchive provides support for the Lightweight Directory Access Protocol (LDAP) and the
Lightweight Directory Access Protocol SSL (LDAPs), which are protocols that can be used to access
the active directory on a server.
Active Directory (AD) is Microsoft’s implementation of an LDAP-based directory server.
InfoArchive also provides support for the use of a Non Personal Account to anonymously access
the active directory.
To access LDAP repositories, you must use the ldap:// URL prefix, which provide non-secure
access.
To access LDAPs repositories, you must use the ldaps:// URL prefix, which provides secure access.
Support for the LDAPs Protocol
Follow these steps to enable support for LDAPs:
1.
Configure the keystore to enable SSL/TLS for your LDAP server.
For more information about keystores and truststore, see Generating Keystores and Truststores
for SSL/TLS.
2.
Export the certificate.
3.
Configure the truststore for the Gateway / IAWA in the <INFOARCHIVE_ROOT>/config
/webapp/application.yml file as shown here:
infoarchive:
gateway:
:
:
client:
ssl:
trust-store: "config/webapp/gatewayTrustStore.jks"
74
Security
trust-store-password: <User_Password>
trust-store-type: JKS
4.
Import the certificate for the LDAP server into the truststore.
5.
Enable the external LDAP profile in the config/webapp/application.yml file as shown
here:
spring:
profiles:
active:
infoarchive.gateway.profile.AUTHENTICATION_IN_MEMORY,
infoarchive.gateway.profile.AUTHENTICATION_EXTERNAL_LDAP
6.
Configure external LDAP access.
The following code sample demonstrates an Apache DS server running locally as a
service in LDAPs mode. If you have your own LDAP set up, it must be configured in the
<INFOARCHIVE_ROOT>/config/webapp/application-infoarchive.gateway
.profile.AUTHENTICATION_EXTERNAL_LDAP.properties file as shown here:
# External LDAP
# The following two are default administrator and password for Apache DS
AUTHENTICATION_EXTERNAL_LDAP.managerDn=uid=admin,ou=system
AUTHENTICATION_EXTERNAL_LDAP.managerPassword=secret
:
:
AUTHENTICATION_EXTERNAL_LDAP.url=ldaps://localhost:10636/dc\=infoarchive,dc\=emc,dc\=com
:
:
7.
Stop the Gateway / IAWA if it is running and restart it again.
8.
Login to the IAWA with an ADMINISTRATOR account.
9.
In IAWA, navigate to the Administration > Groups dialog and verify that the groups from
the external LDAP are shown there.
10. Assign roles to each group.
Encrypted Passwords
Caution: This section does not apply to the infoarchive-nc.zip distribution, which installs
a version of InfoArchive without encryption. If you are using the infoarchive-nc.zip
distribution, please skip this section of the guide.
Storing passwords that are not encrypted is a significant security risk. We recommend that you
encrypt all passwords before storing them to protect your system.
Caution: Before encrypting any passwords make sure to change the default generated
passwords. If the passwords are not known and the system is subsequently encrypted, there is
no way to get back the unencrypted passwords.
75
Security
The ability to store encrypted passwords within the configuration files has two phases:
• Using Tools: You can configure how encryption is performed and encrypt your passwords using
dedicated tools.
• Using the Server: You can take the generated encrypted passwords and store them within the
server’s application.yml file, configure how they were encrypted, and enter the relevant
passwords upon server start-up.
SunJCE/Bouncy Castle (Local Keystore)
This procedure stores the key used for password encryption in a local keystore. The keystore is
file-based and it is up to the customer to protect it.
Tools
1.
2.
Enter the following properties in the following configuration file: <INFOARCHIVE_ROOT>
/tools/config/password-encrypt/encryption.properties.xml:
Field
What to Enter
keySize
The size of the key being used for encryption.
securityProvider
The security provider used for encryption (SunJCE/Bouncy
Castle).
keyStoreLocation
The location of the key store where the encryption key will be
stored.
keyStoreType
The type of key store that will be used.
encryptionAlgorithm
The algorithm used for encryption.
encryptionMode
The encryption mode used.
paddingScheme
The padding scheme used during encryption.
keyID
The ID of the key being used for encryption (when it does not
already exist in the keystore, it is created).
Enter the following command:
<INFOARCHIVE_ROOT>/tools/password-encrypt
3.
Enter the password to be encrypted. Enter the password again for verification purposes.
4.
Enter the keystore password.
If this is the first time you are running the tool, this will set the keystore password. Subsequent
executions of the password-encrypt tool should use that same password.
An encrypted password is outputted, which is the same password entered in step 3.
5.
76
Repeat the process for all of the passwords that need to be encrypted.
Security
Server
1.
In the <INFOARCHIVE_ROOT>/config/server/application.yml file, replace the clear text
(unencrypted) passwords with the encrypted passwords.
2.
Enter the following values in the in the passwordEncryption section of the
<INFOARCHIVE_ROOT>/config/server/application.yml file:
Field
What to Enter
keyStorePath
The location of the key store where the encryption key will be
stored.
keyStoreType
The type of key store that will be used.
keyID
The ID of key being used for encryption.
enabled
Set to ’true’.
encryptionAlgorithm
The algorithm used for encryption.
encryptionMode
The encryption mode used.
paddingScheme
The padding scheme used during encryption.
securityProvider
The security provider used for encryption (SunJCE/Bouncy
Castle).
keySize
The size of the key being used for encryption.
3.
Start the IAS.
4.
When prompted, enter the key store password.
Gemalto Remote Keystore
Caution: This section does not apply to the infoarchive-nc.zip distribution, which installs
a version of InfoArchive without encryption. If you are using the infoarchive-nc.zip
distribution, please skip this section of the guide.
This procedure stores the key used for password encryption in a Gemalto remote KeySecure
appliance. The KeySecure appliance is then used to encrypt the password. The process is similar to
the local keystore with some additional steps.
For more information about Gemalto, see the gemalto website.
Tools
1.
Enter the following properties into the <INFOARCHIVE_ROOT>/tools/config/password
-encrypt/encryption.properties.xml file:
77
Security
Field
What to Enter
gemaltoPropertiesFileLocation
The location of the Gemalto client properties
file.
gemaltoUsername
The KeySecure appliance username.
gemaltoClientCertificate
The KeySecure client certificate ID.
gemaltoGroup
The KeySecure group in which the key will be
created (if not available).
2.
Put the Gemalto client jars in the following directory:<INFOARCHIVE_ROOT>/tools/lib
/password-encrypt/
3.
Enter one of the following commands:
• For Windows: <INFOARCHIVE_ROOT>\tools\password-encrypt
• For Linux: <INFOARCHIVE_ROOT>/tools/password-encrypt
4.
Enter the password for encryption.
5.
Enter the password again for verification purposes.
6.
Enter the KeySecure password.
7.
Enter the password of the key store that contains the KeySecure client certificate.
An encrypted password is outputted.
8.
Repeat the process for all of the passwords that need to be encrypted.
Server
1.
In the <INFOARCHIVE_ROOT>/config/server/application.yml file, replace the original
passwords with the encrypted passwords.
2.
Enter the following values in the in the passwordEncryption section of the
<INFOARCHIVE_ROOT>/config/server/application.yml file:
Field
What to Enter
gemaltoUserName
The KeySecure appliance username.
gemaltoClientCertificate
The KeySecure client certificate ID.
gemaltoPropertiesFile
The location of the Gemalto client properties
file.
3.
Start the IAS.
4.
When prompted, enter the KeySecure password.
5.
When prompted, enter the password of the key store that contains the KeySecure client certificate.
78
Security
Change the Password and Encrypt it
1.
Stop the IAS.
2.
Update the <INFOARCHIVE_ROOT>/tools/config/password-encrypt/encryption
.properties.xml file with new values, if needed (new key ID, larger key size, different
encryption algorithm, etc.).
3.
Re-encrypt the passwords using the dedicated tool.
4.
Update the <INFOARCHIVE_ROOT>/config/server/application.yml file with the new
values (including keyID if it was changed).
5.
Start the IAS.
6.
When prompted, enter the relevant passwords.
ANT Tasks and Ciphered Values for Passwords
Cipher-text values can be used in the configure command. However, additional steps must be
taken to ensure it works correctly.
Creating Decryption Configuration
Create a file named decryption.properties in an application folder (such as the PhoneCalls
folder):
passwordEncryption.keyStorePath=../../keystore.jceks
passwordEncryption.keyStoreType=jceks
passwordEncryption.keyID=IA_PASSWORD_ENCRYPTION_KEY
passwordEncryption.enabled=true
passwordEncryption.encryptionAlgorithm=AES
passwordEncryption.encryptionMode=CBC
passwordEncryption.paddingScheme=PKCS5PADDING
passwordEncryption.securityProvider=SunJCE
passwordEncryption.keySize=256
passwordEncryption.gemaltoUserName=
passwordEncryption.gemaltoClientCertificate=gemaltoClientCertificate
passwordEncryption.gemaltoPropertiesFile="./IngrianNAE.properties"
passwordEncryption.gemaltoGroup=
Check the password encryption tool to ensure that the keyStorePath property is referring to
your keystore file.
Enable Cipher-text Values in the ANT Tasks in the PhoneCalls
Application
You can place ciphered passwords in the build.properties file in the application folder:
federationPassword=qC4jw1RQXJiOJyPjwuFQETWcVvcvRaZ4yVu1l5IA4oc=
79
Security
xdbPassword=YrChf+rX884kiQNcvpjbUghO6l2XfYyMQH9FGW8zuGo=
After that check the 040-xdb-federation.xml file:
<ia-task self="fedSelf">
<object typeAlias="federation" checkExistSpEL="?[name=='${xdbFederation}']">
<create>
<name>${xdbFederation}</name>
<bootstrap>${federationBootstrap}</bootstrap>
<superUserPassword encrypted="true">${federationPassword}</superUserPassword>
</create>
</object>
</ia-task>
Then check the 050-xdb-database.xml file:
<ia-task self="dbSelf">
<object typeAlias="xdb-database" checkExistSpEL="?[name=='${xdbDatabase}']">
<create>
<name>${xdbDatabase}</name>
<adminPassword encrypted="true">${xdbPassword}</adminPassword>
</create>
</object>
</ia-task>
Every attribute to be encrypted should have the XML attribute: encrypted="true".
Then, when you use the ANT script, the system prompts you to enter the keystore password when it
encounters the first value with the attribute encrypted="true".
80
Chapter 8
Using InfoArchive
Connecting to and Running xDB
Connecting to xDB Admin
There are no minimal privileges necessary to run the IAS, the IAWA, or the xDB server.
For Linux, root permissions are necessary to install the system services.
For Windows, Administrator permissions are necessary to install the system services.
Connection Ports
Note: You should always connect to the xDB server using a specific port.
Here are some examples of the ports that you can use to connect to the xDB server:
• 2910 – Default port to connect to the main system
• 2911 – When using a distinct system for retention (this is not the default)
• 2920 – When using a replica for RollForward operations
Running the xDB Admin Console
Note: The following instructions assume that the xDB server is running on the same machine as the
other InfoArchive components. In the instructions below, replace <IP_OF_xDB> with the hostname
(or IP address) of where your xDB server is running.
1.
• Windows
Open a command prompt window and run the following command:
bin\infoarchive-xdb admin
• Linux
Within the command shell, execute the following command:
./bin/infoarchive-xdb admin
2.
Under the Admin menu, select bootstrap URL.
81
Using InfoArchive
3.
Enter the following: xhive://<IP_OF_xDB>:2910
Note: In the above statement, replace <IP_OF_xDB>:2910 with the IP address of where your
xDB server is running.
Caution: If you cannot connect to the xDB server, make sure the correct xDB server is running
and listening on port 2910. The admin client can only be run against a server that is running.
JDBC Connection Setup
For instructions on setting up a JDBC connection for the xDB server, refer to the InfoArchive JDBC
Driver section of the Configuration & Administration User Guide.
Sample Applications
The applications directory contains sample application data sets and configurations that you can
load to view examples of functionality.
Use the following steps to load these data sets:
1.
Navigate to the directory of the desired application in <INFOARCHIVE_ROOT>/tools
/applications
2.
Run the Ant script.
Additionally, the following Ant targets can be invoked:
• install: This target can be used for installing and updating configurations.
• receive: This target can be used for the reception process where packages are queued for
ingestion.
• ingest: This target can be used for ingesting packages and associated records according to
a set package ingestion priority.
Tip: You can use the —projecthelp or the —p option to view Ant help, which contains information
on all of the commands that are available in Ant.
Structured Data Archiving Samples
The following sample applications are examples of structured data application archiving, broadly
representing an application decommissioning use case. Running just the Ant command for these
applications will start the configuration and ingestion process:
• Baseball
• Order_Management
82
Using InfoArchive
• Patent
• Tickets
Note: The default configuration assumes that xDB is running on the localhost (127.0.0.1). When
xDB is installed on a different machine other than where the Ant script is running, the properties
file must be modified to accommodate this configuration.
Compound Record (Data and Content) Samples
The following sample applications are examples of compound record (data and content) application
archiving, broadly representing an active archiving use case. The default Ant target is all for these
applications. Invoking Ant starts the configuration and data ingestion process:
• PhoneCalls
• PhoneCallsGranular
• Certificates
• Invoices
• SEPA
• Trades
InfoArchive Connectors Samples
These are sample applications that were created using the InfoArchive connectors:
• Documentum: These SIPs are created using the Documentum connector for InfoArchive.
• SharePoint: These SIPs are created using the SharePoint connector for InfoArchive.
• SAP Connector: These SIPs are created using the SAP connector for InfoArchive.
Additionally, a pre-configured application called Audit is available. This application can be used to
search all audit information (known as audits) that is in an InfoArchive repository. After installing
the Audit application, you can run the Archive Audits job to search the audits.
It is recommended that you start the schedule to run the Archive Audits job. By default, the
Archive Audits job runs once a day.
Note: In a Linux environment, the default ulimit value is 1024. This value must be increased when
you are ingesting a large number of SIP files to avoid ZIP file errors. After resetting the ulimit
value, restart the server.
83
Using InfoArchive
84
Chapter 9
Disaster Recovery Scenario for
InfoArchive
The following is the supported disaster recovery setup for InfoArchive 4.3.
Terminology
• Data node and Federation
xDB 11 introduces the cluster, with data nodes, where each data node corresponds to an xDB
server. In xDB 10, there were no clusters, just the federation. In that case, the each federation
corresponds to an xDB server.
InfoArchive only uses single data nodes. Therefore, InfoArchive treats a single xDB data node the
same as an xDB federation, and the terms can be used interchangeably. You can think of a data
node or federation as a server, serving up database pages from a volume of data files.
An xDB federation can contain multiple databases, which use the same transactional scope as xDB,
therefore a transaction is only "transactional" on the data in the database in which it was opened.
• Retention Data and ManagedItems
85
Disaster Recovery Scenario for InfoArchive
These two terms are interchangeable, and they refer to the metadata that InfoArchive stores to
keep track of retention related items such as:
— Hold Applications
— Policy Applications (For example, on a table or an individual AIU). This data must be stored
in a database that is separate from the system data. However, it can be stored within the
same federation.
• Batch Data
This is system data that requires its own transaction scope and its own separate database.
• Audit data
This is the xDB database where the audit records are stored. Audit data requires its own
transaction scope and its own separate database.
Requirements
The following is required for successful failover to the disaster recovery site:
• Asynchronous xDB data-node replication for:
— System data (including audit and batch data)
— The server address (bootstrap URL) of the replica must be configured in the
system/xdb/replicas section of the application.yml file.
This yml file is used to let InfoArchive know where to replicate the most important actions
before actually executing them. Doing this allows those actions to be replayed on the
disaster recovery site on failover.
— Retention data (ManagedItems)
— Structured data (metadata) : optional, see below
Note: You can map system, audit, and batch data to different xDB data nodes or servers. For
simplicity, we recommend using the same data node (or server) for your system, audit, and
batch data.
If you decide to map your system, audit, and batch data to the same data node, you must
nevertheless store your data in different databases within that data node.
Note: When no excessive granular retention is planned, retention data can be stored with System
data (and it can be replicated and backed up with it too). Alternatively, it can also be mapped
to a different data node or server, but in InfoArchive 4.3, it must be fully replicated for disaster
recovery and it must also be backed up (see backups below).
• File system replication for everything else that is stored on a FileSystem.
86
Disaster Recovery Scenario for InfoArchive
For example:
— Content
— Backups (of structured data and retention data)
• The following items must be seamlessly accessible on the disaster recovery site:
— Mount points (the paths of FileSystemRoots)
— CAS endpoints (connection strings of ContentAddressedStorage objects)
— Custom Storage end points (property bags of CustomStorage objects)
— ECS/S3/ For example, end points and credentials (StorageEndPoint and
StorageEndPointCredential objects)
Caution: File system storage replication must preserve file system paths.
Last Resort Options
Here are some last resort recovery options to consider:
• Regular backups of the system data including the System, Audit, and Batch data. A repository
must be made for this data. How you approach this option is dependent upon your setup.
• Regular backups of the retention data. This option only applies when the retention data is
mapped to a different server than the system data. Otherwise the retention data is automatically
backed up with the system data.
Other Considerations
InfoArchive makes and stores backups of structured data (metadata) libraries. For example, each
xDB library created for an AIP is immediately backed up, and the backup is also recreated after
each partial disposition on that AIP.
This process supports:
• Cache-in/Cache-out
• Recovery (see below)
Retention (ManagedItem) data libraries. For example, each xDB library created to store the holding
applications for the AIUs in one AIP can be backed up, and the backup is also recreated after each
change. The Administrator can do this by configuring a ManagedItem store for a holding or database.
This can be considered an incubating feature, because:
• InfoArchive does not have Cache-in/Cache-out yet for ManagedItem data libraries
• No CLI support to restore these partial backups after failover. This is planned tor the next
InfoArchive release.
87
Disaster Recovery Scenario for InfoArchive
Disaster Recovery and Failover Steps
As mentioned before, the requirement for failover is that you replicate the system and retention
federations, and optionally the structured (meta)data federations. How to do this is documented in
the xDB documentation, but here are some convenient commands:
• To create a replica of a federation with a server running on <IP_OF_xDB>:2910:
infoarchive-xdb create-replica --federation xhive://<IP_OF_xDB>:2910
--replicaid ia_rep --replicabootstrappath /data_rep/xhive.bootstrap
--password <YOUR_PASSWORD>
Be sure to set values for the superuser password, and also for the replicaid. The replicaid
contains the path where the database files on the disaster recovery site are stored.
• To start the server on the replica you just created:
infoarchive-xdb run-server --master xhive://<IP_OF_xDB>:2910
--replicator ia_rep --port 2950 --bootstrap /data_rep/xhive.bootstrap
This starts the replica server on port 2950, using the server on port 2910 as its master.
Complete the following procedure to perform failover on the disaster recovery site:
1.
Turn any replicas into masters.
For example, assuming that the replica server runs at my.dr.host on port 2950. Then from
<INFOARCHIVE_ROOT>/bin, you can run the following command:
infoarchive-xdb turn-replicator-into-master --bootstrap xhive://my.dr.host:2950
2.
Start the new xDB servers of these master copies on the desired hosts and ports:
• System (<INFOARCHIVE_ROOT>/audit/batch) data xDB server
• Retention data xDB server (if different from system data above)
• Any structured data (or metadata) xDB servers
If necessary, create new replicas of these servers, configure the system data replica bootstrap on
the disaster recovery site in your <INFOARCHIVE_ROOT>/system/xdb/replicas yml file.
3.
Modify the yml file to include the proper xDB server IP addresses along with any other settings
regarding the environment, such as the keystore location:
• System (<INFOARCHIVE_ROOT>/audit/batch) data xDB server
• Retention data xDB server (if different from the system data one)
4.
Start an IAS that cannot be accessed publicly.
5.
Start the IAShell from the <INFOARCHIVE_ROOT>/tools folder, connect it to the IAS, and
execute the following sequence for any structured data that is configured in your system with
xDB server metadataFederation:
ia-shell>select federation --where "?[name=='metadataFederation']"
(fill in the proper name)
88
Disaster Recovery Scenario for InfoArchive
ia-shell/federation>var-set --name myFederation --value #{ID_1}
ia-shell/federation>update --id #{myFederation} --properties "{'name':
'metadataFederation', 'bootstrap' : 'xhive://127.0.0.1:2910',
'superUserPassword' : '<Your_SU_Password>'}"
Fill in the proper bootstrap address. The other values are not important but need to be provided
for validity of the underlying REST commands.
6.
Run:
ia-shell>recover
For InfoArchive 4.3, the "report" of this recovery is only available in the server logs.
AIPs that have become inconsistent are invalidated. In the worst case scenario, this may imply
that a previously committed AIP was demoted.
After this, the various components, repositories, or both of InfoArchive should be consistent
again.
7.
Start all necessary servers to resume production.
Relevant Configuration
The yml file has comments over most of its entries that contain brief explanations. The comments
relevant for failover include:
The bootstrap of the System data server:
xdb:
dataNode:
storeStackTraceInLock: false
name: mainFederation
bootstrap: xhive://<IP_OF_xDB>:2910
This must be set to where the server runs on the disaster recovery site on failover.
The bootstrap of the replica on the DR site (IA must know this for the
replication of special objects, relevant for recovery):
# replicas:
# #
bootstrap: xhive://<IP_OF_xDB>:2920
The bootstraps of the audit, batch and retention (ManagedItem) repositories, for example:
auditData:
xdb:
dataNode:
storeStackTraceInLock: false
name: mainFederation
bootstrap: xhive://<IP_OF_xDB>:2910
This is typically the same as the system data server’s address, with the possible exception of the
retention data (see above).
89
Disaster Recovery Scenario for InfoArchive
Pre-configured file system roots:
fileSystemRoots:
name: defaultFileSystemRoot
description: Default FileSystemRoot
path: data/root
The path on the disaster recovery site should match the original path. In other words, this entry
cannot be changed on failover (same as any of the file system roots that are configured outside of
the yml file, such as those that were configured using the GUI).
Crypto:
crypto:
# KeyStore configuration
keyStore:
keyStoreFileLocation: "data/keystore/keystore.jceks"
Caution: The path to the disaster recovery copy of the key store must be configured here on
failover.
90
Chapter 10
Troubleshooting
The command prompt window displays installation status messages, including errors that may
occur during the installation. You can also find status listings in the log files, which are saved in the
<INFOARCHIVE_ROOT>/logs folder.
InfoArchive collects errors automatically in the error.log file. A more detailed log is written to
the ia.log file.
Note: You can locate errors by searching for occurrences of the word error or BUILD FAILED
in the log file entries.
Error Messages
Error Message
Troubleshooting Steps
The running Ant version is too
old. Ant version <xxx> or later is
required.
Use a supported version of Apache Ant (1.9.6 or
later). You can find a supported version in the
InfoArchive installation directory Tools folder.
Issues and Troubleshooting Steps
• Issue
Unable to install the sample applications in InfoArchive.
— Troubleshooting Steps
1.
Ensure that the IAS, IAWA, and xDB servers are running.
2.
If the default passwords were changed, check that the passwords in the
build.properties file (in the root of the tools directory) matches the passwords that
are in the application.yml file.
91
Troubleshooting
3.
Check that the secret key between the iawa.yml file and the application.yml file
match. If those passwords have been changed, they must always match.
4.
Check for the data root directory.
If the data root directory is missing, create an empty directory called root in the
<INFOARCHIVE_ROOT>/xdb/data directory.
• Issue
Unable to run the sample applications in InfoArchive.
— Troubleshooting Steps
1.
Ensure that both the IAS and IAWA servers are running.
2.
If you are using the default setup, ensure that the In-Memory profile has been configured
on IAWA. You may have to restart if configuration changes are made.
If the In-Memory profile cannot be turned on, open the build.properties file under
the <INFOARCHIVE_ROOT>/tools directory and enter the username and password of
a user that is included in all of the roles.
3.
Check for the data root directory.
If the data root directory is missing, create an empty directory called root in the
<INFOARCHIVE_ROOT>/xdb/data directory and try to run the samples again.
• Issue
The Server does not start after a new installation, or displays an authentication error for Spring
Batch.
— Troubleshooting Steps
The installation process for InfoArchive version 4.3 gives you the option to generate
password values, which are then automatically set in the <INFOARCHIVE_ROOT>/config
/application.yml file for you.
If you are upgrading from a previous version, then the existing passwords in the
<INFOARCHIVE_ROOT>/tools/config/migration directory must be match the
passwords that are set in the <INFOARCHIVE_ROOT>/config/application.yml file. You
must manually set these passwords yourself.
When you are using a configuration where a separate federation for retention is used, then you
must check that both xDB servers are running, and that the matching data node passwords are
set in the application.yml file for each of the xDB servers.
• Issue
Configuring a retention data node (federation) for IAS Server is not working.
— Troubleshooting Steps
Here are some items to consider if your configuration of a separate data node (federation) for
retention is not working:
— Be careful not to confuse the data node password with the database password.
— If you got the password wrong, then you must reset the superuser (data node password) in
the xDB configuration file.
92
Troubleshooting
— Do not forget to specify the xDB license key when you are creating the data node.
— Ensure that you have specified the correct password in the <INFOARCHIVE_ROOT>
/server/application.yml file.
93
Troubleshooting
94
Appendix A
Command Line Installation Script
Parameters
The following table shows the installation parameters that are supported in both the setup.bat and
setup.sh installation scripts, along with a brief explanation of each parameter’s function.
Parameter
Description
--user=
System user to run the services (required).
This is a required parameter
--supasswd=
The xDB superuser password (required).
This is a required parameter
This password must be updated in the
application.yml file before running the
setup script. It must also be changed in the
sample application build scripts.
--licensekey=
The xDB license key (required).
This is a required parameter
--services=
The system services to install. This parameter
defaults to xdb,server,webapp.
For example, --services= xdb,server.
--noDataNode
A flag that instructs the system not to set up an
xDB data node.
Parameter
Description
--ssl=
Install the IAS service using SSL. This parameter
defaults to none.
Caution: Remove the InfoArchive services
and modify the configuration files before
setting this parameter.
When this flag is set, the services that are
being setup will call the SSL startup scripts
instead of the regular startup scripts.
95
Command Line Installation Script Parameters
Parameter
Description
However, those SSL scripts can only work
when the corresponding component (IAS,
xDB, or IAWA) have been configured to
use SSL.
The --ssl parameter accepts the same values
as the services parameter.
For example, xdb, server, webapp or any
subset of those values.
--remove
96
A flag that can be used to remove the
InfoArchive services.
Appendix B
User Information for Sample Data
Applications
Use the following default users to log in to the InfoArchive sample data applications. Each user’s
Role defines what is presented at the top and second level navigation, and ultimately their level of
access to InfoArchive.
Note: These users are sample In-Memory users that have been created for demonstration purposes
only. They must not be used in production environments.
Information about the In-Memory users is defined in the infoarchive.gateway.profile
.AUTHENTICATION_IN_MEMORY.properties file. The passwords for the In-Memory user
accounts are defined in the following files:
• <INFOARCHIVE_ROOT>/tools/build.properties
• <INFOARCHIVE_ROOT>/tools/application.properties
97
User Information for Sample Data Applications
98
Appendix C
In-Memory User Accounts
When you are installing sample applications that have been previously configured
for InfoArchive 4.2, it is better to copy your applications into the InfoArchive 4.3
<INFOARCHIVE_ROOT>\tools\application folder and use the default build.properties
file for InfoArchive 4.3.
If previously you were using a login token with InfoArchive 4.2, OpenText strongly recommends
that you refrain from using a token for login.
If you are performing a demonstration (or proof of concepts) and you chose not to enable and use the
in-memory user accounts, then you must setup a user account (with a user name and password),
that has access to all roles. If you do not want to set up a user account as mentioned above, then you
can enable and use the in-memory user accounts, which are meant to be used for demonstration
and proof of concepts only.
For more information, see Working with In-Memory User Accounts.
Login Username
Default Login Password
User Role
User Name
adam@iacustomer
.com
password
ADMINISTRATOR
Adam
bob@iacustomer
.com
password
BUSINESS OWNER
Bob
connie@iacustomer
.com
password
DEVELOPER
Connie
emma@iacustomer
.com
password
END USER
Emma
imran@iacustomer
.com
password
IT OWNER
Imran
rita@iacustomer
.com
password
RETENTION MANAGER
Rita
99
In-Memory User Accounts
Login Username
Default Login Password
User Role
User Name
erica@iacustomer
.com
password
EDISCOVERY
ADMINISTRATOR
Erica
sue@iacustomer
.com
password
ADMINISTRATOR
Sue
BUSINESS OWNER
DEVELOPER
END USER
IT OWNER
RETENTION MANAGER
EDISCOVERY
ADMINISTRATOR
100
Appendix D
Security Files
The following files have references that are used for securing the system, which includes references to
the trust stores and key stores. The values in these files are used to generate the secret authentication
token as needed:
• <INFOARCHIVE_ROOT>/config/server/application.yml
• <INFOARCHIVE_ROOT>/config/server/application-ssl.yml
• <INFOARCHIVE_ROOT>/config/webapp/application.yml
• <INFOARCHIVE_ROOT>/config/webapp/application-CLIENTS.yml
• <INFOARCHIVE_ROOT>/config/xdb/xdb-server.properties
• <INFOARCHIVE_ROOT>/config/xdb/xdb.properties
101