Description

The grid-env.sh written by yaim in glite-UI 3.2.10/3.2.11 is incompatible with the default version of zsh found on SL5. An error such as:

grid-env.sh:5: condition expected: =~

Workaround

 

Change grid-env.sh (usually found in /etc/profile.d/ or GLITE_EXTERNAL_ROOT/etc/profile.d/):

 

--- grid-env.sh.orig 2011-06-09 18:17:32.000000000 +0200

+++ grid-env.sh 2011-06-09 18:18:36.000000000 +0200

@@ -2,9 +2,9 @@

 . /gLite/external/etc/profile.d/grid-env-funcs.sh

 if [ "x${GLITE_UI_ARCH:-$1}" = "x32BIT" ]; then arch_dir=lib; else arch_dir=lib64; fi

 if [ -n "${GLITE_PYTHON_VERSION:-$2}" ]; then python=${GLITE_PYTHON_VERSION:-$2}; python=${python/:*}; else python=2.4; fi

-if [[ ":${GLITE_PYTHON_VERSION:-$2}:" =~ :2.4: ]]; then python2_4=python2.4; else python2_4=python$python; fi

-if [[ ":${GLITE_PYTHON_VERSION:-$2}:" =~ :2.5: ]]; then python2_5=python2.5; else python2_5=python$python; fi

-if [[ ":${GLITE_PYTHON_VERSION:-$2}:" =~ :2.6: ]]; then python2_6=python2.6; else python2_6=python$python; fi

+if (echo ":${GLITE_PYTHON_VERSION:-$2}:" | grep -q :2\\.4:); then python2_4=python2.4; else python2_4=python$python; fi

+if (echo ":${GLITE_PYTHON_VERSION:-$2}:" | grep -q :2\\.5:); then python2_5=python2.5; else python2_5=python$python; fi

+if (echo ":${GLITE_PYTHON_VERSION:-$2}:" | grep -q :2\\.6:); then python2_6=python2.6; else python2_6=python$python; fi

 gridpath_prepend     "PYTHONPATH" "/gLite/lcg/$arch_dir/python"

 gridpath_prepend     "PYTHONPATH" "/gLite/lcg/$arch_dir/$python2_6/site-packages"

 gridpath_prepend     "PYTHONPATH" "/gLite/lcg/$arch_dir/$python2_5/site-packages"

 

Release of glite-UI 3.2.8 uses c-ares 1.3.0-4. In particular it will not be possible to update/install the node to c-ares 1.6 due to unsatisfied dependencies. In case you have the slc5-updates repository enabled, which contains c-ares 1.6, c-ares will need to excluded e.g.

Update:

• Excluding when running the yum update command: yum update --exclude=c-ares
• Adding an exclude line to the .repo file, e.g. in /etc/yum.repos.d/slc5-updates.repo exclude=c-ares

Clean Install:

• Adding an exclude line to the .repo file, e.g. in /etc/yum.repos.d/slc5-updates.repo exclude=c-ares

Description

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

Known workaround

For UI tarball release 3.2.8 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 function config_crl has to be run separately, removing some outdated CRLs beforehand. e.g.

Run YAIM to install the CAs: 

cd ${INSTALL_ROOT}/glite/yaim/bin

./yaim -r -s site-info.def -n glite-UI_TAR

remove outdated CRLs:

rm $X509_CERT_DIR/*.r0

run the YAIM CRL configuration function

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

see also

https://twiki.cern.ch/twiki/bin/view/LCG/UiTarInstall#Handling_of_certificates

Description

This version of the User Interface is targeted to setup x86_64 machines in "compatibility" mode, i.e. both 32bit and 64bit libraries are provided. The YAIM tool configures the LD_LIBRARY_PATH variable accordingly.

In order to get both 32bit and 64bit libraries, both versions of certain rpms must be installed. On a x86_64 machine yum usually installs the 64bit rpm over the 32bit rpm but for certain rpms this seems not to be the case (for yet unknown reasons). However, this should not be a problem as 32bit binaries can be executed on a x86_64 machine.

Description

Using rfio on the UI fails.

Known woraround

Set the environment variable RFIO_PORT=5001.

Description

uberftp file:/etc/group gsiftp://ce.example.org/tmp/junk not working on SL5.

Description

Runtime error with LFC Perl API. Workaround is setenv MALLOC_CHECK_ 0.

Description

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

Known workaround

There are two possible workarounds:
1. Use lcg_util as data management client instead.
2. Install Java with "yum install java".

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