dCache Provider for the GIP

The OSG's dCache provider for the GIP auto-discovers all the storage-element related information for your dCache install. Currently, it does not integrate directly with the configure_gip script (we're working hard on this, we promise!), so a bit of hand-configuration is required.

The information provider requires access to:

• The dCache admin interface and
• The SRM postgres database.

Work for the Site admin to do.

Extra dependency installation

In order to access the SRM postgres database, you must additionally install the postgresql and postgresql-python RPMs on your system. These is available from the standard SL4 yum repository.

Notes:

• The Postgres 7.x client RPMs which come with SL4 are compatible with the Postgres 8.x servers.
• You will want to use yum to install these RPMs to resolve any dependencies; on SL5, the install of postgresql-python will require the compat-readline43 and mx RPMs to make this work.

SE Configuration.

You must be able to log into your SRM postgres database from the CE node. If you are unable to do this from the command-line using "psql", it's highly unlikely that you'll be able to get this done from the configuration script.

The following shows an example of how to connect to Postgres using the psql utility.

psql -U srmdcache -d dcache -h SRM_HOSTNAME.example.org -p 5432 -W

You must also be able to log in to the dCache admin interface via SSH from the CE node. The usual user name for the admin interface is "admin", the port is 22223, and cipher blowfish. This translates into the following command:

ssh -l admin -c blowfish -p 22223 DCACHE_HOSTNAME.example.org

Configuration (OSG 1.0.0 branch)

Run the $GIP_LOCATION/conf/configure_gip_dcache script. This will run you through the configuration options.

Here's a sample output:

The GIP can auto-configure dCache SEs by utilizing the admin interface and
the SRM Postgres database.  This allows your site to use the GIP advertising
to its fullest.  

It will also allow you report accurate space usage information to the OSG.

The CE will need access to the following resources:
   * dCache admin interface
   * Postgres server on the SRM node.
You may need to configure your database and/or firewall to allow this.

Would you like to continue (y/n) :
 y

We will now begin the configuration of the dCache admin interface connection.


What is the hostname of your dCache admin interface?
 [dcache-head.unl.edu] 

What port is the admin interface running on?
 [22223] 

What is the admin user name?
 [admin] 

What is the admin password?
 

We will now test the dCache admin interface.


Admin connection succeeded!


We will now begin the configuration of the Postgres DB connection.


What is the hostname of your SRM Postgres DB?
 [srm.unl.edu] 

What DB port should be used?
 [5432] 

What is the SRM database name?
 [dcache] 

What is the SRM database user?
 [srmdcache] 

What is the password for the SRM database?
 

We will now test the Postgres DB connection.


The DB connection succeeded.


Configuration is done.  Would you like to save the results (y/n)?
 y

Configuration saved.  If you would like to alter any choices without 
re-running this configuration script, you may find these answers in:

$VDT_LOCATION/gip/etc/dcache_storage.conf

OSG 1.0 BUG

The file created which contains the passwords is owned by root and chmod'd to 600. The file ownership should be changed to daemon, so the CEMon can use it:

chown daemon:root $VDT_LOCATION/gip/etc/dcache_storage.conf

OSG 1.0 WARNING

Large sites may run into timeout problems with these providers - basically, if every pool fails, each script can take 5 * (number of pools) seconds to run; these are also run sequentially. The default timeout is 60 seconds, which has in practice proven to be too small.

Adjust the timeouts for your site; edit the file $GIP_LOCATION/etc/osg-info-generic.conf to have the following two lines:

response = 300
timeout = 350

Both response and timeout must be changed!

Testing

The GIP providers are fairly straightforward to test. Make sure that $VDT_LOCATION (OSG 0.8.0) or $GIP_LOCATION (for OSG 1.0.0; should be $VDT_LOCATION/gip) is set in your environment and run the following (OSG 0.8.0):

$VDT_LOCATION/lcg/libexec/services_info_provider.py
$VDT_LOCATION/lcg/libexec/token_info_provider.py

OSG 1.0.0:

$GIP_LOCATION/libexec/services_info_provider.py
$GIP_LOCATION/libexec/token_info_provider.py

Examine the output of the above scripts for correctness; they will fail fairly visibly if you have an incorrect configuration (90% of the problems are an incorrect dCache admin interface login parameters). In fact, because they can generate so much output, it's often to redirect the stdout and just look at the stderr (add 1> /dev/null to the end of the command line) for problems.

Troubleshooting

What to do when things go wrong:

• Test the output by hand. Run token_info_provider.py and services_info_provider.py as user daemon. Suppress the stdout and report any error messages on stderr.
• Try adjusting the timeouts. By default, the information is ignored if the GIP takes longer than 60 seconds to run - and these two python scripts are run sequentially, not in parallel.
• Make sure any files in $GIP_LOCATION/var/tmp are owned by daemon; if in doubt, clear them out.
• Re-run configure-osg and/or configure_gip_dcache.
• Email the osg-gip@opensciencegrid.org to get help via email, or goc@opensciencegrid.org to get help via tickets. The ticket is less likely to get "lost", but the email response may be more immediate.
  • Include the stderr and stdout, separately, of the script which failed.
• If things go wrong intermittently, make sure to set the SRM fallback on. This allows the SRM storage element to appear as "up" even when something goes wrong with the dCache admin interface. In the gip.conf config file, under the [se] section, set srm_present=1. If you want the service to be published as "down" when the dCache admin interface fails, set publish_down=1 in the [se] section.

-- BrianBockelman - 21 Feb 2008