Shaking down the user issues

The upgrade to gLite 3.1 on the UI has brought a couple of surprises, which we're gradually working our way around.

* First, the version of grid-proxy-init supplied at part of VDT seems to behave rather differently. A proxy initialised with this looks like:

svr020:~$ grid-proxy-info
subject  : /C=UK/O=eScience/OU=Glasgow/L=Compserv/CN=graeme stewart/CN=892101086
issuer   : /C=UK/O=eScience/OU=Glasgow/L=Compserv/CN=graeme stewart
identity : /C=UK/O=eScience/OU=Glasgow/L=Compserv/CN=graeme stewart
type     : Proxy draft (pre-RFC) compliant impersonation proxy
strength : 512 bits
path     : /tmp/x509up_u218012
timeleft : 11:59:57

And the lcg-RB does not like this proxy at all.

Using voms-proxy-init (without VOMS extensions) gives a rather more normal proxy:

subject  : /C=UK/O=eScience/OU=Glasgow/L=Compserv/CN=graeme stewart/CN=proxy
issuer   : /C=UK/O=eScience/OU=Glasgow/L=Compserv/CN=graeme stewart
identity : /C=UK/O=eScience/OU=Glasgow/L=Compserv/CN=graeme stewart
type     : full legacy globus proxy
strength : 512 bits
path     : /tmp/x509up_u218012
timeleft : 11:59:58

This hits ganga particularly hard, which renews proxies for you, but uses grid-proxy-init.

The fix for this was to ensure that /opt/glite/bin appears higher in the path than /opt/globus/bin and then to create a soft link from /opt/glite/bin/voms-proxy-init to grid-proxy-init.

* Second problem was with UKQCD client software. Craig reported he was getting errors because of a missing globus rft library (libglobus_rls_client_gcc32dbgpthr.so.0). gLite 3.1 is compiled against VDT 1.6 (as opposed to VDT 1.2) and this library is no longer built. The first attempt at fixing it was to copy across the missing library into /opt/globus/lib. This failed, though, because then it became clear that the 1.2 and 1.6 VDT libraries are not compatible with one another, so the new libraries were missing symbols the QCD software needed. So, in the end, the old libraries were copied, lock, stock and barrel, into /opt/globus-glite30/lib and, with a suitable LD_LIBRARY_PATH, the qcd application would run.
There is a new version of QCDGrid software being built, so hopefully that will be compatible with the new VDT.

* Finally (or the last issue which has come to light), is Dan having trouble with g++. The default gcc-c++ (3.4.1) doesn't play well with his version of NLOJET++. He's going to try again with the old 3.2.3 g++ (a.k.a. g++32). Hopefully this will fix things.