Installation Guide

This document covers all aspects of installing an instance of the Catalog and Archive Service (CAS).

Install Software

TBD

Create Database

The next step of the installation requires a database to be created in a supported Database Management System (DBMS). The following DBMSs are currently supported:

• Oracle
• Sybase
• PostgreSQL

This section may be expanded in the future to include sizing and more detailed information, but for now just contact your local DBA to create a database with appropriate permissions.

Install Schema

The next step of the installation involves installing the CAS schema. If the user is installing the schema in a database where the schema currently resides, the user must drop the existing schema prior to re-installation. This can be accomplished by performing the drop action described below.

This step involves the execution of a Perl script that will prompt the user for necessary information. A prompt may include valid responses and a default response. Valid responses will be presented in square brackets [ ] separated by a vertical bar |. Default responses will be presented in curly braces {}. The information prompted for is a follows:

• Action
  The action to perform in the specified database. Either create , load , delete or drop .
  
  • create
    This action creates the tables, indexes, triggers and procedures that make up the schema.
    
  • load
    This action loads the generic policy into the schema like supported product item types and status values.
    
  • delete
    This action removes the generic policy from the schema.
    
  • drop
    This action removes everything that was created by the create action.
    
• DBMS
  The database management system for the specified database. Either oracle , sybase or postgres .
  
• Host or Server and Database
  The database specification based on the DBMS response. The prompt will be Host for oracle , Server and Database for sybase or Host and Database for postgres .
  
• Username and Password
  The username and password for the specified database's owner or an equivalent account.
  

During the script execution two f iles will always be generated. One will be a log file and the other will be a combined Structured Query Language (SQL) file. The naming convention for these files is as follows:

archive_schema_<YYMMDDhhmmss>.[log | sql]
         

If the drop action has been requested, a third file will be generated. This will be a SQL file containing DROP TABLE commands for the product tables specified in the policy. The naming convention for this file is as follows:

archive_schema_drop_product_tables_<YYMMDDhhmmss>.sql
         

This Perl script must be executed two times in order to complete the schema installation. The first time it must be executed with the create action. Perform the following command to create the schema:

% archive_schema.pl
         

The following is a sample execution of the archive_schema.pl script. The text inside the < > brackets indicates user input.

Executing script archive_schema.pl.

Action Selections
  create - Create the archive schema.
  load   - Load the general policy.
  delete - Delete the general policy.
  drop   - Drop the archive schema.

Action [create | load | delete | drop] {create}: <create>

DBMS [oracle | sybase] {oracle}: <oracle>

Host: <DTADEV>

Username: <dbowner>

Password: <secret>


Are these the correct parameters?
-----------------------------------
Action:           create
DBMS:             oracle
Host:             DTADEV
Username:         dbowner
-----------------------------------

Accept Parameters [y|n] {y}: <y>

Including: ./oracle_start.sql
Including: ./oracle_create_tables.sql
Including: ./oracle_create_procedures.sql
Including: ./oracle_create_triggers.sql
Including: ./oracle_stop.sql

Performing the archive schema operation.

The operation appears to have completed successfully.

View the log file, /home/user/classes/jpl/eda/archive/schema/
archive_schema_010123131149.log, for more information.

The archive_schema.pl script has completed.
         

For the second execution, the script must be executed with the load action. Perform the archive_schema.pl command again to load the generic policy into the schema.

Once the first command has completed successfully followed by the second command completing successfully, the CAS schema will be ready for policy installation.

Install Policy

The next step of the installation involves installing the CAS policy. This policy is specific to the target environment and must be generated for or by the user prior to performing this step. See the Developer Guide for more information on generating policy. If the user is installing the policy in a database where the policy currently resides, the user must delete the existing policy prior to re-installation. This can be accomplished by performing the delete action described below.

This step involves the execution of a Perl script that will prompt the user for necessary information. A prompt may include valid responses and a default response. Valid responses will be presented in square brackets [ ] separated by a vertical bar |. Default responses will be presented in curly braces {}. The information prompted for is as follows:

• Specific Policy Identifier
  The identifier as specified in the policy file name. For example, if test is the identifier, load is the action and oracle is the DBMS, then the policy file name must be oracle_test_load_policy.sql .
  
• Action
  The action to perform in the specified database. Either load or delete .
  
  • load
    This action loads the project specific policy into the schema.
    
  • delete
    This action removes the project specific policy from the schema.
    
• DBMS
  The database management system for the specified database. Either oracle , sybase or postgres .
  
• Host or Server and Database
  The database specification based on the DBMS response. The prompt will be Host for oracle , Server and Database for sybase or Host and Database for postgres .
  
• Username and Password
  The username and password for the specified database's owner or an equivalent account.
  

During the script execution two files will always be generated. One will be a log file and the other will be a combined SQL file. The naming convention for these files is as follows:

<DBMS>_<Identifier>_policy_<YYMMDDhhmmss>.[log | sql]
         

If the delete action has been requested, a third file will be generated. This will be a SQL file containing DROP TABLE commands for the product tables specified in the policy. The naming convention for this file is as follows:

archive_policy_drop_product_tables_<YYMMDDhhmmss>.sql
         

Perform the following command to load the policy:

% archive_policy.pl
         

The following is a sample execution of the archive_policy.pl script. The text inside the < > brackets indicates user input.

Executing script archive_policy.pl.

Specific Policy Identifier (i.e. test): <test>

Action Selections
  load   - Load the test specific policy.
  delete - Delete the test specific policy.

Action [load | delete] {load}: <load>

DBMS [oracle | sybase] {oracle}: <oracle>

Host: DTADEV

Username: <dbowner>

Password: <secret>


Are these the correct parameters?
-----------------------------------
Policy:            test
Action:            load
DBMS:              oracle
Host:              DTADEV
Username:          dbowner
-----------------------------------

Accept Parameters [y|n] {y}: <y>

Including: ./oracle_start.sql
Including: ./oracle_test_load_policy.sql
Including: ./oracle_stop.sql

Performing the test policy operation.

The operation appears to have completed successfully.

View the log file, /home/user/classes/jpl/eda/archive/schema/
oracle_test_policy_010123145238.log, for more information.

The archive_policy.pl script has completed.
         

Once the command has completed successfully, the CAS schema will be ready for product table creation.

Create Product Tables

The next step of the installation involves creating the product tables. A product metadata table and a product reference table should be created for each dataset that was defined in the policy. In order for this application to access the database and log messages, the appropriate properties must be specified on the command-line or in the local configuration file. See the Catalog and Archive Service section of the Operation Guide for more information regarding the database and logging properties. From any directory perform the following command with appropriate arguments to create the product tables:

% java jpl.eda.archive.server.ProductTable
         

Executing the command without arguments will return the argument list. See the ProductTable documentation for more information. Once the command has completed successfully, the CAS schema will be ready for operation.

Create Product Repository

The next step of the installation involves creating the product file repository. A product file repository should be created for each dataset that was defined in the policy if files will be archived for that dataset. The repository column of the dataset_policy table specifies the location for the product repository. Perform the following commands to change directories to the base directory for the repository and create a product repository for each dataset:

% cd <base_directory>/repository
% mkdir product_<dataset_id>
...
% mkdir product_<dataset_id>
         

The repository must be accessible by the service and preferably owned by the user account that launches the service. Once each of the commands have completed successfully, the CAS repository will be ready for operation.