wlcg-client

Introduction

wlcg-client is a software package that contains the WLCG client tools (from OSG and gLite packages) needed to interact with OSG compute and storage elements, and to transfer data to/from LCG storage elements. It is a Pacman package that can be installed locally in a self-contained directory tree. It is simply the OSG client with some modification to improve compatibility with the ATLAS software (especially Athena, ROOT). OSG client includes a package of LCG utilities (LCG-Utils) and the python APIs to interact with LFC (which is used by DQ2-Client).

This page includes also information about other middleware software used by ATLAS interactive users (DQ2-Client). If you are interested in Grid middleware used by batch jobs (wn-client and ATLAS-wn) check AtlasWorkerNode. If you are interested in server installation please refer to OSG CE in the OSG documentation.

Usage

Suppose the wlcg-client client has been installed (see below) in /share/wlcg-client. To setup the environment:

> source /share/wlcg-client/setup.sh
> voms-proxy-init -voms atlas:/atlas

Requirements

The wlcg-client package requires:

• a platform supported by VDT: check http://vdt.cs.wisc.edu/vdt/releases/2.0.0/requirements.html
• About 1G of disk space (big, but includes OSG-client that has a lot of stuff)

Installation

The latest WLCG-Client is v1.0 and it is based on VDT 2.0 and OSG 1.2

Preliminaries:

• Install Pacman, example into /opt/pacman.
• cd /opt/pacman; source setup.sh
• Then:

    mkdir /share/wlcg-client
    cd /share/wlcg-client
    pacman -get http://www.mwt2.org/caches/:wlcg-client

• Answer yes (or yall) to the initial questions during configuration (trust cache, accept licenses).

Then continue with one of the following. There are three typical installation cases.

Non-root:

• Wait for the installation to complete.
• Now you have to install the CE certificates: after sourcing the setup file, install the OSG certificates by running:

source setup.sh
vdt-ca-manage setupca --location local --url osg

• This gives you a private, self-contained installation. This is fine for testing and local casual, but the certificates will not be automatically updated. However, you can update them at a later time by returning to this directory and invoking vdt-ca-manage.

As root, on a host which already has grid certificates installed and maintained in /etc/grid-security/:

• Wait for the installation to complete.
• Link the certificate directory:

source ./setup.sh; ln -s /etc/grid-security/certificates $VDT_LOCATION/globus/TRUSTED_CA

NB It is important to link correctly the certificate directory. The default system wide location in Globus and VDT is /etc/grid-security/certificates but you may have a different one. Local installations normally are in $VDT_LOCATION/globus/share/certificates (and $VDT_LOCATION/globus/TRUSTED_CA is linked to it).

As root, on a host without grid certificates:

• Wait for the installation to complete.
• Now you have to install the CE certificates: after sourcing the setup file, install the OSG CA certificates and run the post-install:

source setup.sh
vdt-ca-manage setupca --location root --url osg
vdt-post-install

• You can enable and start a service to maintain updated your certificates and CRLs:

vdt-control --enable vdt-update-certs
vdt-control --on vdt-update-certs

• Now you can use vdt-control to control the services running on the machine (e.g. to list, start and stop the services):

vdt-control --list
vdt-control --on
vdt-control --off

These answer are conservative to limit the number of cron jobs. If you want any of those services you can always turn them on later with vdt-control

Upgrade

Update requires a new installation from scratch. WLCG-Client 1.0 is fundamentally different from the previous version, WLCG-Client 0.16. It is based on a new VDT with different major version. pacman -update will not work.

In the future you will be able to use pacman -update to update to the last path version (WLCG-Client 1.0.x).

Host Certificate

You need to request and install a host certificate in order to interact with LCG servers. You can do this using scripts that come with the wlcg-client package.

• Setup the package: source /share/wlcg-client/setup.sh, then follow instructions below:
• how to request a host certificate
• how to retrieve and install a host certificate

DQ2-Client

WlcgClient is frequently used in conjunction with DQ2-Clients. In DQ2ClientsInOSG you can find a primer on its Pacman installation to use it with WlcgClient and links to further documentation.

Obsolete packages

This section is here only as historic reference. Previous software that is still available but no more supported include:

• DQ2 End-user tools (the dq2_* commands)
• wlcg-client_dev: as of 10/7/2008 with VDT 1.10.1-k the WLCG-Client versions have been unified (wlcg-client 0.14). FLC-Client is in VDT and there is no more need for LFC-min. The command wrappers have been eliminated as well, they may be reinserted in a later version.
• old wlcg-client based on LFC-min (up to version 0.13). If you still use it, please install a new one. There were some known issues connected with that version of LFC-Client
  • In order to setup some alternative Globus libraries only when needed, WLCG-Client included a python executable that sets the environment correctly before invoking your Python interpreter
    • if you setup a different Python interpreter after setting up wlcg-client the dq2 programs my not work correctly
    • during the execution of dq2-AAA and dq2_AAA clients these alternative Globus libraries are in the LD_LIBRARY_PATH and allow LFC interaction
• old installations of wlcg-client (nstallations including vdt-version older than 1.10.1e) should be updated as well. There is a known issue with Fermi SRM:
  • srmcp, Fermi SRM included in OSG 1.0 (Storage Resource Manager (SRM) implementation version 2.0.3) has a bug
    • transfers from regular gridftp servers (e.g. dCache doors) may fail
  • The SRM team fixed the problem (Storage Resource Manager (SRM) Client version 2.0.8) and the fixed version is included in VDT 1.10.1e
  • An alternative fix (if you cannot update) is to specify a different SRM client (add it to your path)

Previous DQ2 End-user tools installation

Check here for some information about DQ2 Enduser Tools

Known Issues

Install on 64bit OS (Full 32bit installation and Python 32bit)

As of August 2009 all the software in wlcg-client and DQ2Client works fine with both 64 or 32 bit Operation Systems. Older DQ2Client included only the 32bit version of some libraries (MySQL python bindings) therefore there may be 'library not found' errors with a 64bit Python if the binding is not installed in the system. The newer DQ2Client is not using MySQL access to the catalogs anymore. A 32bit installation may still be of interest in mixed environments (32/64bit OSes with a single shared wlcg-client). The simple solution is to install everything in 32bit version:

• You need to install 32bit compatibility libraries, at least the ones suggested in https://twiki.cern.ch/twiki/bin/view/Atlas/RPMcompatSLC4
• Before any VDT installation set the environment variable: export VDT_PRETEND_32=1
• Then install the package with Pacman (e.g. wlcg-client)
• If you need Python 32 bit you can install on your own or use: pacman -get http://www.mwt2.org/caches/:Python32bit. The Python delivered is Python 2.4 (C API 1012 required by _lfc.so) and it is compiled on a SL4.7. The Pacman installation can be in its own directory or on top of WLCG-Client (recommended if you installed it 32 bit and you will need Python 32 bit only for it)

Transferring files from BNL

• Whenever using srmcp to copy files out of BNL with dq2-get (or also the older dq2_get), or directly srmcp, SRM streams have to be limited to 1. Due to the BNL site firewall configuration, multiple-stream SRM copies will not work. E.g.:

dq2_get -rv --srmstreams 1 ... 

.

curl-ca-bundle.crt error

cURL has a set of default locations where it is looking for certificates. These are set at compilation. An old version of VDT was pointing to a file in the compilation directory and causing an error like:

Error: [(py)CURL][FATAL] DQ2 internal exception [
(77, 'error setting certificate verify locations:\n CAfile: /home/condor/execute/dir_7315/userdir/curl/share/curl/curl-ca-bundle.crt\n CApath: /share/wlcg-client/globus/TRUSTED_CA\n') 

There are 2 solution:

• As of 2008-11-24 the VDT team fixed the problem pointing to the system OpenSSL? ca-bundle instead of the one in the compilation directory (ticket: http://crt.cs.wisc.edu/Ticket/Display.html?user=guest&pass=guest&id=3940)
• A patch has been submitted to dq2 (can be used by any program) to set explicitly the cURL option (csec) without keeping the compilation default (ticket: https://savannah.cern.ch/bugs/?41502): csec.unsetopt(pycurl.CAINFO) (in DQ2 it is in in init of DQPycurl)

voms-proxy-info behaves differently

This is more an explanation than a problem. voms-proxy-info in wlcg-client behaves differently from the default installation. Historically "voms-proxy-info -e" changed its default behavior between updates. The current one requires cryptographic verification of the issuer of the certificate extensions. This is not a control necessary in a client forwarding the certificate. The old behavior can be obtained setting VOMS_PROXY_INFO_DONT_VERIFY_AC to 'true'. This is done for you in wlcg-client.

There are 2 other alternatives to have a successful proxy verification:

• use the command line option --dont-verify-ac (e.g. voms-proxy-info --all --dont-verify-ac)
• install the certificates in /etc/grid-security/vomsdir

For more information you can check:

• http://vdt.cs.wisc.edu/releases/1.10.1/release-a.html
• http://crt.cs.wisc.edu/Ticket/Display.html?id=3493

References

• https://twiki.grid.iu.edu/twiki/bin/view/ReleaseDocumentation/PacmanInstall
• OSG Client installation guide.
• See the Pacman section in OSG wiki if you encounter an 'unsupported' platform message.
• https://twiki.cern.ch/twiki/bin/view/Atlas/UsingDQ2
• The LFC API included in wlcg-client is now provided by VDT (LCG-Utils package). For more information you can check the page about the now obsolete package LFC-min that offered similar functionalities: http://twiki.mwt2.org/bin/view/DataServices/PackageLFCmin

-- MarcoMambelli - 23 May 2008