DataStore Installation Notes

1. Requirements

DataStore depends at this stage on the Java runtime environment and some of the following relational databases: Postgresql, MySQL, DB2.

1.1. Java

The Java version recommended is 1.3, for this you have two choices: IBM and Sun Java implementation. In general we would recommend the IBM version of Java as it has better implementation of native threads which especially under Unix like operating systems do provide better performance.

The IBM version 1.3.x of Java can be downloaded from: http://www.ibm.com/developerworks/java/jdk/.

The Sun version 1.3.x of Java can be downloaded from: http://java.sun.com/products/j2se. We recommend the Standard Edition but the Runtime Environment should do it as well unless you want to build the DataStore sources.

If you plan to use transport layer security for server - client connection also the Java JSSE 1.0.2 security packets are recommended, which can be downloaded from the following address: http://java.sun.com/products/jsse/. Provided in this version!

1.2. Relational Database

Download and install one of the folowing:

• Postgresql version 7.0.3 from http://www.postgresql.org
• MySQL version 4.0.0 from http://www.mysql.org
• DB2 version 7.1.0 from http://www-4.ibm.com/software/data/db2/

2. The DataStore server installation

2.1. Create and install the databases required by DataStore

2.1.1. Create the Postgresql databases

Somewhere must be an Postgresql database installed and ready to work. The system with the database must not necessary reside on the same system with your DataStore server.

A postgresql user (and password) is requested in order to have DataStore connecting to the postgresql database. It is preferred (at least at installation) that the user name to correspond with your actual Unix user name, in order to be able to create the initial database and it's structure.

Make sure that Postgresql is configured to accept TCP/IP connections (-i). Under Mandrake Linux, that means that we have to add "-i" to the /var/lib/pgsql/data/postmaster.opts.default file.

DataStore use a specially created Postgresql database structure. In order to create the proper structure a shell script is provided with the DataStore distribution that does most of the job. The script name is installPGSQLDB.sh.

Edit the script, and set the DBNAME variable on the first line. This will set the name of the database. Run this script in order to create the database with the specified name.

The database initially have a given super user with logname root and password _root. Also a user guest is created with the password guest. In this database you will already have the root directory whose owner is the mentioned superuser with full rights. You may install more databases with different names.

2.1.2. Create the MySql databases

Somewhere must be an MySql database installed and ready to work. Download the JDBC client (tested with the: mm.mysql-2.0.8-bin.jar) for MySql and put in the DataStore library ($DATASTORE_HOME/lib/)

DataStore uses a specially created MySql database structure. In order to create the proper structure a shell script is provided with the DataStore distribution that does most of the job. The script name is installMySQLDB.sh.

Edit the script, and set the DBNAME variable. This will set the name of the database. Run this script in order to create the database with the specified name.

The database initially have a given super user with logname root and password _root. Also a user guest is created with the password guest. In this database you will already have the root directory whose owner is the mentioned superuser with full rights. You may install more databases with different names.

2.1.3. Create the DB2 databases

Somewhere must be an DB2 database installed and ready to work. Download the JDBC client (tested with the: db2java.zip) for DB2, rename this file to be a .jar extension and put in the DataStore library ($DATASTORE_HOME/lib/)

DataStore use a specially created DB2 database structure. In order to create the proper structure a shell script is provided with the DataStore distribution that does most of the job. The script name is installDB2DB.sh.

Edit the script, and set the DBNAME variable on the first line. This will set the name of the database. Run this script in order to create the database with the specified name.

The database initially have a given super user with logname root and password _root. Also a user guest is created with the password guest. In this database you will already have the root directory whose owner is the mentioned superuser with full rights. You may install more databases with different names.

2.1.4. Create the SAP DB databases

Somewhere must be an SAP DB database installed and ready to work. Download the JDBC client (tested with the: sapdbc-{version_name}.jar) for SAPDB, and put in the DataStore library ($DATASTORE_HOME/lib/)

DataStore use a specially created SAP DB database structure. In order to create the proper structure a shell script is provided with the DataStore distribution that does most of the job. The script name is installSAPDB.sh.

Edit the script, and set the DBNAME variable on this file. This will set the name of the database. Run this script in order to create the database with the specified name.

The database initially have a given super user with logname root and password _root. Also a user guest is created with the password guest. In this database you will already have the root directory whose owner is the mentioned superuser with full rights. You may install more databases with different names.

2.2. Set the JAVA_HOME environment variable

Even if shell scripts are provided (*.sh and *.bat) to ease the usage the scripts depends on the JAVA_HOME system variable to determine the location of the wanted Java runtime.

2.3. Security settings

Do not forgot to set the security provider into your java.security file. You can find this file:
- in case of Sun Java:

<JAVA-HOME>/lib/security/

- in case of IBM Java:

<JAVA-HOME>/jre/lib/security

To set the JSSE security provider add the following line into this file:

security.provider.n=com.sun.net.ssl.internal.ssl.Provider

where the character 'n' is the next provider number, you may have already in this file a provider with the number one in this case the next provider (with number two) will be the JSSE provider:

security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.net.ssl.internal.ssl.Provider

3. Starting the Avalon Framework (DataStore server)

To start the framework run the following script: bin/run.sh under Unix or bin\run.bat under Windows. The framework will start all the implemented blocks and servers. When starting, every block or server will display a message which shows his state.

4. Configuring the framework

Because it is based on a server framework in which servers are components and DataStore is exactly such a component, initially there will be no config directory. To have the proper directories you must start the server at least once. Disregard any error messages at this stage.

If you installed using the default values (sepstore) and you are running on the same machine the Postgresql server and DataStore that should be just enough to start the DataStore application server. Any other way you should only need to adjust the database section of the configuration file.

Enter the directory datastore_home/apps/datastore/SAR-INF/, here will be placed the config.xml file. Edit it and make the modifications for each block section you desire.

4.1. Configure the Beep Server

<beepserver>
  <connection port="10288" host="localhost"/>
  <sslprovider name="com.sun.net.ssl.internal.ssl.Provider"/>
  <loadprofile>
       <security profile="jsse"/>
       <onetimepassw profile="saslotp"/>
       <anonymous profile="saslanonymous"/>
       <beep_sep profile="sep"/>
       <echo profile="echo"/>

  <beepLog severity="debug" target="file" />

  <profiles>
         <jsse 
            class="org.beepcore.beep.profile.tls.jsse.TLSProfileJSSE"
            uri="http://iana.org/beep/TLS"/>
         <pure 
            class="org.beepcore.beep.profile.tls.pure.TLSProfilePureTLSPemInit"
            uri="http://iana.org/beep/TLS"/>
         <saslotp 
            class="org.beepcore.beep.profile.sasl.otp.SASLOTPProfile"
            uri="http://iana.org/beep/SASL/OTP"/>
         <saslanonymous 
            class="org.beepcore.beep.profile.sasl.anonymous.SASLAnonymousProfile"
            uri="http://iana.org/beep/SASL/ANONYMOUS"/>
         <sep 
            class="org.media.datastore.beepserver.SEPprofile"
            uri="http://spacemapper.sf.net/profiles/SEP"/>
         <echo class="org.beepcore.beep.profile.echo.EchoProfile"               
            uri="http://xml.resource.org/profiles/NULL/ECHO"/>
      </profiles>

      <pem>
         <ciphersuite type=""/>
         <privatekey filename="" type="RSA" password=""/>
         <certificates filename="" rootfilename=""/>
      </pem>     
  </beepserver>

• On the connection section you can specify the port and the host (defaults is: 10288, localhost)
• On the loadprofile section you can specify the profiles which you would like to be loaded by the framework.
• On the pem section you can specify the certificates, keys and their attributes, only if you want to use the PureTLS profile for transport security.

4.2. Configure the Scheduler

<schedulestore>
  <crontab>
    <cron at="* */2 * * *" trigger="lexiconManager"/>
     ...
  </crontab>
      
  <targets>
    <trigger name="lexiconManager" class="org.media.datastore.sepengine.LexiconManager"/>
    ...
   </targets>
  </schedulestore>

In the crontab section you can specify the cron tables and the trigger names. The cron table stores the timer attributes. These attributes are the following: min, hour, dayOfMonth, month, year, dayOfWeek. If you want to set timer with day of month then not specify the dayOfWeek argument (put the "*" there). If you want to set timer with day of week then the dayofMonth argument must be equal with "*"

The trigger name points to a target which will be started by the scheduler. On the targets section you can specify the trigger name and the class. The class have the method which will be started by the timer.

The structures of attributes:

• single number (eg.12), sets a concrete value.
• comma-separated list of numbers (eg.2, 7, 10, 25), sets each of these values.
• interval of numbers (eg.3-7), sets a every value of this interval.
• "*", sets all values for attribute.
• any interval or "*" followed by slash and a number eg.*/3 or 4-8/2, the number after the slash make the step of the interval.

The values of attributes:

• minutes: 0-59
• hours: 0-23
• dayOfMonth: 1-31
• month: 1-12
• dayOfWeek: 0-7 (0 and 7 is Sunday)

4.3. Configure the Xml-Rpc Server

<xmlrpcserver>
  <connection port="10300"/>
  <handlers>
    <handler name="sep" 
             class="org.media.datastore.xmlrpcserver.handlers.SepHandler"/>
    <handler name="url" 
             class="org.media.datastore.xmlrpcserver.handlers.UrlHandler"/>
  </handlers>
</xmlrpcserver>

On the connection section you can specify the port(default is: 10300); On the handlers section specify the friendly name of the handler class and the handler class itself.

4.4. Configure the Sep Engine

You can choose one of the database driver, in example is PostgreSQL. If you want to use other, simply make to be a comment the activ driver and clear comments from the wanted driver.

<sepengine>    
    <lexiconWriter startOnChange="true" />    
    <database>
      <dtd.dir       path="DTD" naming="auto" mode="flexible" tag_ignored="true" />
      <db.name       name="xmldb" />
      <db.driver     class="org.postgresql.Driver" />
      <db.connection uri="jdbc:postgresql:docustore"
                     user="admin"
                     passwd="" />
  	<ignored>
	    <item value="," />
            ...
	    <item value="|" />
	 </ignored>
    
	 <special.ignored>
	    <item value='.' />
            ...
	    <item value='@' />
	 </special.ignored>
  </database>
  ...
 <database>
  ...
 </database>
</sepengine>
    

There may be more database sections for each database you want to use. Where:

dtd.dir

The home of the DTD directory. DataStore uses DTD only in flexible mode (where a DTD is automatically generated based on the tags found in the documents from the same subtree) and in strict mode, where the XML documents are validated against a DTD document which must be provided from external sources.

mode

Sets the initial mode in which subtrees will be created (default mode), and can be flexible, strict or free.

naming

Sets the initial naming flag in which subtrees will be created (default mode), and can be auto or Manual.

tag_ignored

If DTD mode is free then the value can be true or false and as meaning represents the type of documents stored (with tags or not). This is important only at searches where the tags might not represent important value.

db.name

The symbolic name of the database, for clients access.

db.driver

The java database driver class

db.connection

The jdbc connection uri (jdbc:postgresql:r_db_name or jdbc:postgresql://host:port/r_db_name

ignored

The ignored list of characters and words at search time.

special.ignored

The ignored list of characters at the beginning and the end of the words