The following gLite releases1 have been tested.
The installation and setup of the gLite I/O client was successful in both cases, however, the setup of gLite I/O server failed as the server did not start. This may be due to a release-specific bug or a site misconfiguration. Another attempt at configuring the server will be made as the releases mature.
Source code of the GFAL-client was retrieved from the CERN Central CVS repository on 13th January 2005. The following api functions were successfully tested
on both Red Hat Linux release 7.3 (Valhalla) and Scientific Linux SL Release 3.0.3 (SL) machines. In both cases a file was successfully passed and retrieved to/from the SRM interface of the Storage Element using the library.
As the current version of the library requires a BDII (Berkely Database Information Index) server a simple LDAP server was installed to act as one with the following entries.
dn: GlueSEUniqueID=gppse01.gridpp.rl.ac.uk,mds-vo-name=local,o=grid
objectClass: GlueSETop objectClass: GlueSE objectClass: GlueInformationService objectClass: GlueKey objectClass: GlueSchemaVersion GlueSEUniqueID: gppse01.gridpp.rl.ac.uk GlueSEName: RAL_LCG2:srm_v1 GlueSEPort: 8443 GlueForeignKey: GlueSLUniqueID=gppse01.gridpp.rl.ac.uk GlueSchemaVersionMajor: 1 GlueSchemaVersionMinor: 1 GlueServiceURI: srm://gppse01.gridpp.rl.ac.uk:8443 |
dCache has been successfully tested with the same GFAL version as SE as described in section 2.1 both on Red Hat Linux release 7.3 (Valhalla) and Scientific Linux SL Release 3.0.3 (SL) machines.
Environment variable LCG_GFAL_INFOSYS was set to ldap://lcgbdii02.gridpp.rl.ac.uk:2170.
There is a major pitfall in making GFAL support the dCache dcap protocol. As the GFAL library uses a C function to dynamically load the dcap library (dlopen()), the path to libdcap.so must be set either in /etc/ld.so.conf or LD_LIBRARY_PATH. For standard dCache rpms LD_LIBRARY_PATH=/opt/d-cache/dcap/lib.
GFAL (as of current version 1.5.6) does not pass local files through to kernel open and it does not provide gfal_fopen function either. Thus it might be necessary to preload another library that maps open to gfal_open.
The following table summarises access to local files using GFAL.
Function | Status | Suggested solution |
open | works | -- |
fopen | works | -- |
gfal_open | unimplemented | preload library or refactor GFAL |
gfal_fopen | unimplemented | preload library or refactor GFAL |
The following table summarises access to remote files when using GFAL.
Function | Status | Suggested solution |
open | unimplemented | preload library to call gfal_open |
fopen | unimplemented | preload library or refactor GFAL |
gfal_open | works | -- |
gfal_fopen | unimplemented | preload library or refactor GFAL |
Similar tables could be created to show the behaviour of other file-access functions.
Please refer to a simple howto on how to use lcg commands at http://www.gridpp.ac.uk/deployment/users/datamanagement/howtolcg.html.
Simple examples on how to use those commands can also be found in the d-cache-ral RPM package.
Gzipped postscript /PDF version of this document.