Known Issues for glite-WN

Only the known issues for gLite 3.2 have been migrated. Please check the old 3.1 known issues page if you don't find the solution here.

32bit LFC/DPM applications fail to run on glite-WN 3.2.10 3.2 sl5_x86_64

Description

On glite-WN 3.2.10 attempting to run 32bit applications which need libdpm.so, liblfc.so or liblcgdm.so (i.e. LFC or DPM applications) will fail. This because of missing symbolic links to the relevant libraries.

 

Known workaround

For glite-WN 3.2.10 from an RPM installation this problem can be resolved by the addition of certain packages after the installation or upgrade:

rpm -ivh http://eticssoft.web.cern.ch/eticssoft/repository/org.glite/LCG-DM/1.8.0/sl5_ia32_gcc412/dpm-devel-1.8.0-1sec.sl5.i386.rpm

rpm -ivh http://eticssoft.web.cern.ch/eticssoft/repository/org.glite/LCG-DM/1.8.0/sl5_ia32_gcc412/lfc-devel-1.8.0-1sec.sl5.i386.rpm

rpm -ivh http://eticssoft.web.cern.ch/eticssoft/repository/org.glite/LCG-DM/1.8.0/sl5_ia32_gcc412/lcgdm-devel-1.8.0-1sec.sl5.i386.rpm

 

For the glite-WN 3.2.10 tarball installation run the following:

ln -s libdpm.so.1.8.0 ${INSTALL_ROOT}/lcg/lib/libdpm.so

ln -s liblfc.so.1.8.0 ${INSTALL_ROOT}/lcg/lib/liblfc.so

ln -s liblcgdm.so.1.8.0 ${INSTALL_ROOT}/lcg/lib/liblcgdm.so

 

being sure that INSTALL_ROOT is defined in your environment or making the appropriate substitution in the above commands.

glite-WN_tar configuration error with "/usr/local/share/saga does not exist" 3.2 sl5_x86_64

Description

To configure the tarball installation with the glite-WN_tar 3.2.10 node type the following function should be removed from ${INSTALL_ROOT}/glite/yaim/node-info.d/glite-wn_tar: config_glite_saga to avoid an error during configuration.

Fresh install or update problems with RPM based glite-WN 3.2.10 3.2 sl5_x86_64

Description

As usual, to upgrade correctly to this new version you need to use yum groupupdate glite-WN. However with release 3.2.10 there are problems during a clean install, and potentially during an update, for which special action is needed.

Known workaround

As always, to correctly install or upgrade glite-WN you need to use yum groupupdate glite-WN. However with release 3.2.10 there are problems during a clean install and potentially during an update for which special action is needed:

A number of packages from any previous installation need to be removed and some 32bit packages need to be excluded during the update or installation. For example use the following yum commands:

yum -y remove dpm dpm-devel lcgdm-devel lfc lfc-devel perl-dpm perl-lfc

yum -y --exclude=dpm.i386,dpm-devel.i386,lcgdm-devel.i386,lfc.i386,lfc-devel.i386,perl-dpm.i386,perl-lfc.i386 groupupdate glite-WN

CA/CRL installation for the WN tarball

Description

When using YAIM to setup the CAs for the WN tarball for release 3.2.10 or earlier, there is a known issue. The EGI repository for the IGTF/EGI/WLCG trust anchors is not set as the default repository for YAIM to use and also the CRL cron job is not created.

Known workaround

For WN_tar 3.2.10 or earlier the new repository must be configured by setting CA_REPOSITORY like this:

CA_REPOSITORY="rpm http://repository.egi.eu/sw/production cas/1/current production"

changing the existing definition in ${INSTALL_ROOT}/glite/yaim/defaults/site-info.pre or adding the new setting to your site-info.def. In order to successfully create the CRL update cron job the YAIM functions config_certs_userland and config_crl have to be run separately, removing some outdated CRLs in between. e.g.

Run the YAIM function to install the CAs: 

cd ${INSTALL_ROOT}/glite/yaim/bin

./yaim -r -s site-info.def -n glite-WN_TAR -f config_certs_userland

remove outdated CRLs:

rm $X509_CERT_DIR/*.r0

run the YAIM CRL configuration function

./yaim -r -s site-info.def -n glite-WN_TAR -f config_crl

see also

https://twiki.cern.ch/twiki/bin/view/LCG/WnTarInstall#Installation_of_certificates

RFIO in SL5 3.2 sl5_x86_64 (Tracker Url)

Description

Using rfio on the WN fails.

Known workaround

Set ithe environment variable: RFIO_PORT=5001

dCache client doesn't work in SL5 3.2 sl5_x86_64 (Tracker Url)

Description

There is a bug in the dCache client in SL5 that prevents it from working properly.

Known workaround

Use lcg_util as data management client instead.

YAIM known issues

For an up to date documentation on configuration known issues, please check also the YAIM known issues page.