The following commands were used during RLS development to install iODBC.

% cd $IODBCSRC % ./configure --prefix=$GLOBUS_IODBC_PATH --disable-gtktest --with-pthreads --disable-gui
    --with-iodbc-inidir=$ODBCINIDIR % gmake % gmake install 

where:

Create the odbc.ini file in $ODBCINIDIR:

The contents should include the path to where you intend to install the ODBC driver for your RDBMS (such as psqlodbc.so or libmyodbc3.so).

The following is an example that should work with psqlODBC. It assumes you will name your LRC and RLI databases lrc1000 and rli1000:

[ODBC Data Sources]
lrc1000=lrc database
rli1000=rli database


[lrc1000]
Description=LRC database
DSN=lrc1000
Servertype=postgres
Servername=localhost
Database=lrc1000
ReadOnly=no


[rli1000]
Description=RLI database
DSN=rli1000
Servertype=postgres
Servername=localhost
Database=rli1000
ReadOnly=no


[Default]
Driver=/path/to/psqlodbc.so
Port=5432 

Note: You do not need an RLI database if you plan to use Bloom filters for LRC to RLI updates (Bloom filters are kept in memory). In this case you can omit the RLI entries below.

Bug: psqlODBC will not find a Data Source Name (DSN) in the system odbc.ini file $ODBCINIDIR/odbc.ini. It will find DSNs in the user's odbc.ini file if it exists at $HOME/.odbc.ini.

One work around is to copy or symlink the system odbc.ini file to each user's home directory. psqlODBC does find system DSNs in a file called odbcinst.ini, which is looked for in the etc subdirectory where iODBC was installed, $GLOBUS_IODBC_PATH/etc/odbcinst.ini. So another option besides creating user .odbc.ini files is to copy or symlink the system odbc.ini file to $GLOBUS_IODBC_PATH/etc/odbcinst.ini. Someone who understands this better may have a better answer.

If you're using MySQL and have changed how MySQL clients connect to the MySQL server in my.cnf (e.g., the port number or socket name), then you should set the option to 65536 in odbc.ini for each database. This tells MyODBC to read the client section of my.cnf to find the changed connection parameters.

[lrc1000] option = 65536 
[rli1000] option = 65536 

If your relational database of choice is PostgreSQL, you need to install and configure both PostgreSQL and psqlODBC (the ODBC driver for PostgreSQL) as follows:

% cd $POSTGRESSRC % ./configure --prefix=$GLOBUS_LOCATION % gmake % gmake install 

initdb -D /path/to/postgres-datadir
postmaster -D /path/to/postgres-datadir -i -o -F 

createuser -P dbuser 

% cd $PSQLODBCSRC 
% setenv CPPFLAGS -I$(IODBC_INSTALLDIR)/include 
% ./configure --prefix=$GLOBUS_LOCATION --enable-pthreads 
% gmake 
% gmake install 

If your relational database of choice is MySQL, you'll need to install and configure both MySQL and the MyODBC (Connector/ODBC) packages as follows:

mysqld_safe [--defaults-file path to your my.cnf file ] 

mysql>  use mysql; 
mysql>  grant all on lrc1000.* to dbuser@localhost identified by 'dbpassword'; 
mysql>  grant all on rli1000.* to dbuser@localhost identified by 'dbpassword'; 

4.2.2. Installing MyODBC

	Important
	Recommended Version: 3.51.06 Please read the note under Section 3, “Installing iODBC”. If you cannot locate this version on a public site or mirror, you can find it here.

These instructions assume that iODBC was installed in $GLOBUS_LOCATION. This may be changed by changing the --with-iodbc-includes and --with-iodbc-libs options or the --with-iodbc option.

4.2.2.1. Running install commands

Install MyODBC in $GLOBUS_LOCATION (you may choose a different directory if you wish, by changing the --prefix option to configure below):

% cd $MYODBCSRC 
% ./configure --prefix=$GLOBUS_LOCATION 
     --with-mysql-libs=$GLOBUS_MYSQL_PATH/lib/mysql
     --with-mysql-includes=$GLOBUS_MYSQL_PATH/include/mysql
     --with-iodbc=$GLOBUS_LOCATION
     --with-odbc-ini=$ODBCINIDIR 
% gmake
% gmake install

where:

• $MYODBCSRC is the directory where you untarred the MyODBC sources.
• $ODBCINIDIR is the directory where you created the odbc.ini file.

Bug: There is a bug in MyODBC version 3.51.05 and earlier. The debug code is not thread safe, and the RLS server will get a segmentation violation and die if this code is enabled. In versions 3.51.05 and later the debug code can be disabled with the configure option --without-debug. In earlier versions it is disabled by defining DBUG_OFF, as in the following example:

setenv CFLAGS -DBUG_OFF 

You can now continue to instructions for installing the RLS Server. See Section 5, “Installing the RLS Server”.

Create a database user that the RLS server will use to connect to the DBMS.

The database user and password you pick must be specified in the RLS server configuration file, as well as the name of the database(s) you will create (see below).

db_user dbuser 
db_pwd dbpassword 
lrc_dbname lrc1000  # optional (if LRC server) 
rli_dbname rli1000  # optional (if RLI server) 

Decide which database(s) the RLS server will use (and that you will create in Section 6.4):

An RLI server can receive updates from LRC servers in one of two forms, as LFN lists (in which case the RLI database must be created) or as highly compressed Bloom filters. Since Bloom filters are so small, they are kept in memory and no database is required. An RLS server can be configured as both an LRC and RLI server.

Configure the schema file(s) for the database(s) you will create.

GT 4.0 installed the schema files for the LRC and RLI databases in $GLOBUS_LOCATION/setup/globus.

For PostgreSQL, use:

For MySQL , use:

Edit these files to set the name of the database user you created for RLS and the names of the databases configured in $GLOBUS_LOCATION/etc/globus-rls-server.conf.

By default the database user is dbuser, the LRC database name is lrc1000 and the RLI database name is rli1000.

Create the database(s) with the following commands (note once again that you do not need to create an RLI database if you are configuring an RLI server updated by Bloom filters):

For PostgreSQL, run:

createdb -O dbuser  -U dbuser  -W lrc1000 
createdb -O dbuser  -U dbuser  -W rli1000 
psql -W -U dbuser  -d lrc1000  -f $GLOBUS_LOCATION/setup/globus/globus-rls-lrc-postgres.sql 
psql -W -U dbuser  -d rli1000  -f $GLOBUS_LOCATION/setup/globus/globus-rls-rli-postgres.sql 

For MySQL, run:

mysql -p -u dbuser  < $GLOBUS_LOCATION/setup/globus/globus-rls-lrc-mysql.sql 
mysql -p -u dbuser  < $GLOBUS_LOCATION/setup/globus/globus-rls-rli-mysql.sql

	Important
	Before continuing, it is recommended that you first test the database configuration using the iodbctest utility provided with a typical iODBC installation.

Testing with iODBC, run:

% $GLOBUS_IODBC_PATH/bin/iodbctest "DSN=lrc1000;UID=dbuser;PWD=dbpassword"
iODBC Demonstration program
This program shows an interactive SQL processor
Driver Manager: 03.51.0002.0224
Driver: 03.51.06

SQL>show tables;
 
Tables_in_lrc1000
-----------------
t_attribute
t_date_attr
t_flt_attr
t_int_attr
t_lfn
t_map
t_pfn
t_rli
t_rlipartition
t_str_attr
 
 result set 1 returned 10 rows.

SQL>quit
 
Have a nice day.

Use the show tables command if you are using a MySQL database. Use the postgresql equivalent command if you are using a Postgresql database. Also the driver version number (03.51.06 above) will vary depending on the ODBC driver you are using.

	Warning
	If the the above test fails, then RLS will not run properly. You must have a valid database configuration before proceeding with RLS installation and configuration.

Please be advised (and advise other users responsible for bringing up the RLS) that the startup initialization may take a few minutes before the RLS may be accessible. The initialization involves two key operations that may consume significant resources causing the server to appear temporarily unresponsive. Users of RLS may mistakenly assume that RLS failed to startup and may kill the server and start over. Some users may fall into this in a repeated cycle, believing that the RLS is unable to startup properly.

If the RLS is configured to send compressed updates (Bloom filters) to other RLIs, the RLS startup will involve initialization of the Bloom filter representing the current contents of the local replica catalog (LRC). This step is a prerequisite before any additional operations may be allowed, therefore no client connections are permitted until the initialization is complete. In our test environment, we have seen over 30 seconds delay due to creation of the Bloom filter corresponding to 1 million LFN names on a system with Dual 1 GHz CPU and 1.5 GB RAM. You may experience greater delays at larger scales and/or when running RLS with more limited system resources.

If the RLS is configured to send uncompressed updates (LFN lists) to other RLIs, the RLS startup will not involve any additional initialization delay. However, the RLS will spawn an initial full catalog update to all RLIs it updates. Though these updates will take place on separate threads of execution after the initialization of the system, they will consume a great amount of processor activity. Depending on the volume of the local replica catalog (LRC), this processor activity may initially interfere with a client operation. In our test environment, we have seen our initial "globus-rls-admin ping..." operation may suffer a delay and timeout in 30 seconds, the second "ping" may delay for a few seconds but will successfully return, and the third and every subsequent "ping" operation will successfully return immediately throughout the duration of the update. The system exhibits the same behavior for any other client operation, such as a "globus-rls-cli query..." operation.

This seems to be due to a problem in the new kernel and thread libraries of RedHat 9. A problem in pthread_cond_wait() causes threads not to wake up correctly.

This problem has been seen with the following kernels and glibc packages:

The problems don't seem to arise when RLS is linked with older pthread libraries. This can be done as by adding a couple of lines to the RLS startup script in $GLOBUS_LOCATION/sbin/SXXrls, as shown:

<--- START --->
#!/bin/sh

GLOBUS_LOCATION=/opt/gt3.2
MYSQL=/opt/mysql
IODBC=/opt/iodbc

export GLOBUS_LOCATION

#RedHat 9 workaround
LD_ASSUME_KERNEL=2.4.1
export LD_ASSUME_KERNEL
<--- END --->

On i586 systems, set:

LD_ASSUME_KERNEL=2.2.5