wlcg-client

Introduction

WLCG-Client is a package containing client tools from OSG and gLite needed for interactions with storage and compute elements as well as the LFC file catalog. It is a Pacman package that can be installed in a self-contained directory tree also by non privileged users. It is tested for compatibility with the ATLAS software (especially Athena and ROOT).

wlcg-client is a collection of Grid client tools to use DQ2 Clients, Panda and also to submit pilots or custom jobs or to test a Compute Element. It includes a selection of packages from OSG-Client plus some additions useful for ATLAS.

In DQ2ClientsInOSG there are links to further documentation and a primer on DQ2-Clients Pacman installation and use with wlcg-client.

wlcg-client is an interactive client. If you are interested in Grid clients used by batch jobs (e.g. wn-client and ATLAS-wn) check AtlasWorkerNode.

Requirements

The wlcg-client package requires:

• a platform supported by VDT: check http://vdt.cs.wisc.edu/vdt/releases/2.0.0/requirements.html
• IMPORTANT! the LFC python binding support only RH5 based OSs (including SL5 and Centos5), both 32 and 64 bits. Other platforms will not include this package necessary to access the ATLAS file catalog (e.g. used by DQ2Clients)
• About 880MB of disk space

Getting started

The latest wlcg-client is v1.7 and it is based on VDT 2.0 and OSG 1.2.

To install wlcg-client you need Pacman.

• If you have it already, e.g. in /opt/pacman:

  source /opt/pacman/setup.sh
  

• Else, to install and setup Pacman, e.g. in /opt/pacman:

  cd /opt
  wget http://atlas.bu.edu/~youssef/pacman/sample_cache/tarballs/pacman-3.29.tar.gz
  tar --no-same-owner -xzvf pacman-3.29.tar.gz
  cd pacman-3.29
  source setup.sh
  cd ..
  ln -s pacman-3.29 pacman
  

Installation

Choose an installation directory, e.g. /share/wlcg-client, and install the package:

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).

Now install the Certification Authorities (CA) certificates and Certificates Revocation Lists (CRLs) (CA installation):

cd /share/wlcg-client
source setup.sh
vdt-ca-manage setupca --location local --url osg

This gives you self-contained installation with standard OSG certificates and no running update service. CA certificates need to be maintained because CRLs expire frequently (with expired CAs or CRLs your authentications will fail). No running services is fine for testing and local casual, but the certificates will not be automatically updated. You can update them manually by re-invoking vdt-ca-manage or by running vdt-update-certs, but requires labor and is not reliable because you may forget. See the automatic update section below to enable automatic updates.

For more options on the type and location of the certificates (e.g. to install the certificates in the system directory /etc/grid-security) see the section on alternatives for CA and CRLs below.

IMPORTANT: The default python from SL5 is python 2.4 whereas dq2 (production version as of 9/20) requires 2.5 or greater. To install and use python 2.6 see the Install and setup Python 2.6 section below.

Setup

Each time a user wants to use wlcg-client (e.g. installed in /share/wlcg-client), he/she must setup the environment:

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

This adds all the utilities to your PATH and defines VDT_LOCATION. You need to setup wlcg-client in order to use DQ2Clients.

Update

NOTE If your WLCG-Client is older than 1.0 you have to reinstall from scratch (see above), this update will not work. If you have already WLCG-Client 1.0 or newer (vdt-version should return 2.0.x) you can use this procedure, anyway a fresh install is recommended and cleaner if you have enough bandwidth for the download and can interrupt momentarily.

Fresh install (recommended)

• Turn off all the VDT services using a separate shell not to contaminate the environment:

  sh
  cd $VDT_LOCATION
  source setup.sh
  vdt-control --off
  

• Make sure to have a clean environment (e.g. Do not source the setup file of the old installation!)
• Backup the old installation:

  mv wlcg-client wlcg-client_old
  mkdir wlcg-client
  

• Proceed for the new installation (as explained above) in the wlcg-client directory

Incremental update (no fresh reinstall)

• Turn off the VDT services (in clients they are normally already off). vdt-control operations are possible/required only if the wlcg-client installation is shared and installed by root:

  cd $VDT_LOCATION
  source setup.sh
  vdt-control --off
  

• First update the included VDT packages with the VDT updater (then you can use Pacman for the rest):
  • get the latest updater:

    pacman -update VDT-Updater
    

  • NOTE: if you don't have the VDT-Updater, run the following command to get it:

    pacman -get http://vdt.cs.wisc.edu/vdt_200_cache:VDT-Updater
    

  • run the updater:

    vdt/update/vdt-updater      --skip-backup-check
    

  • answer yes when asked to accept the updates
  • answer no if asked to modify the certificate management
• Now update the rest (WLCG-Client) with Pacman:

  pacman -update
  

• End with post-install (probably it will tell you that nothing needs to be fixed):

  vdt-post-install

• Restart VDT services (if you have any):

  vdt-control --on
  

Advanced topics

These sections present special configurations, explain concepts in detail or describe special use case.

Automatic update of certificates and CRLs

If you want a reliable client you must update your certificates, either manually, or, better, automatically with vdt-control

• 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
  

Alternatives for CA certificates and CRLs

vdt-ca-manage allows to pick the desired CA certificates and install them in an arbitrary location, private or shared with other grid softwares. A complete reference on available certificate sets and where to put the certificates, including an arbitrary location, is available on the VDT site. The default installation above is self contained. This section covers two other common options to install the OSG CA certificates. You can use one of these instead of the CA installation in the instructions above.

Install in /etc/grid-security/certificates

You must install as root to use this system directory:

source /opt/wlcg-client/setup.sh
vdt-ca-manage setupca --location root --url osg
vdt-post-install

This installation by default enables the periodic update of certificates and CRLs.

Link an existing CA installation

You can use an existing CA installation (owned by an other package) on the host or mounted in a shared directory (e.g. via NSF). If several grid softwares share the same CA installation it is important that one is the owner and runs the services to update it and all the other only link to it (without changing the content). Let's assume that $CACERTDIR contains the path of the certificate directory, e.g. /your/cacertdir or /etc/grid-security/certificates. To link to the existing CA installation:

vdt-ca-manage setupca --location $CACERTDIR --no-update

Behind the scene this is doing something like:

source /opt/wlcg-client/setup.sh
ln -s $CACERTDIR $VDT_LOCATION/globus/TRUSTED_CA
ln -s $CACERTDIR $VDT_LOCATION/globus/share/certificates

Without correct certificates (included or linked, it doesn't matter) your wlcg-client may work only partially.

Select a different wlcg-client version: development or older versions

Unless you really need to do differently, please install always the latest wlcg-client production version:

• Older versions have been replaced because of problems or because of changes in VDT, OSG or ATLAS software.
• Latest production version has been tested to be compatible with the software releases supported in production.

The development version that can be used for testing, based on OSG's VTB cache, is available with =pacman -get http://www.mwt2.org/caches/vtb:wlcg-client= . Older versions are available with pacman -get "http://www.mwt2.org/caches:wlcg-client | version('X.Y')" (The use of older versions may lead to an installation with known and solved bug).

%NOTE% Version X.Y of wlcg-client may change over time. wlcg-client adds some customization but it is also a container of packages from the production VDT and OSG software cache. If the added customization or the package list change there will be a new version number. But VDT and OSG overwrite (in place) the existing caches when providing bug fixes or small updates. There is no way to refer the previous version after the update. So all wlcg-client new installation will be different as well (all versions based on that OSG/VDT cache). E.g. wlcg-client from 1.0 to 1.7 are all based on the OSG 1.2 production cache (version at the time of installation).

Historical - Different package sets (wlcg-addonclient and wlcg-client-lite)

Starting wlcg-client 1.0, wlcg-client is based on OSG 1.2 and VDT 2.0.0. Current wlcg-client 1.7 is a subset of OSG/VDT client with some ATLAS customizations.

In the past it has been sometime a superset of OSG client, sometime a smaller package and some other classes packages, wlcg-addonclient and wlcg-client-lite, had similar functions. For a complete descriptions of content depending on the release, see the history section in the development document.

Install and setup Python 2.6

The default python from SL5 is python 2.4 whereas dq2 requires 2.5 or greater. We suggest python 2.6 (and not 2.5 or 2.7) because it is available from EPEL. Site administrators are recommended to install python 2.6 from EPEL (preferred). You need to be root. Add the EPEL repository (if you don't use it already). Note that this will alter your system yum repositories!

rpm -Uvh http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm

Install python26:

yum install python26

And link atlasosgcompat/bin/python to pythonloader, so that it will become the default python in the users PATH once they source the wlcg-client setup:

ln -s $VDT_LOCATION/atlasosgcompat/bin/pythonloader $VDT_LOCATION/atlasosgcompat/bin/python

pythonloader is a script executing your python scripts with the first python (executable named python or python26) with version <=2.5 present in your PATH.

NOTE: If installing python26 from EPEL is not an option, then click here for instructions for possible alternatives that include a Pacman installation of Python 2.6.

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

wlcg-client and DQ2Client are fully compatible with both 64 or 32 bit Operation Systems. Normally wlcg-client matches the platform (OS) in the installation host. In mixed environments:

• A 64 bit OS can support both 64 and 32 bit applications and libraries
• A 32 bit OS supports only 32 bit applications and libraries
• Python compiled libraries (e.g. LFC binding included in wlcg-client) have to match the interpreter. E.g. 64bit Python requires 64bit bindings, 32bit Python requires 32bit bindings (therefore 32bit wlcg-client).

The LFC libraries are an exception. Since OSG 1.2.21 LFC libraries are selected at run time and a 64bit installation will work correctly with python 2.4/5/6 32 or 64 bit. So don't worry about this is you have all nodes with 64 bit OS and ATLAS sw is 32 bit. It will work correctly with a regular installation on a 64 bit node.

If one of the above is violated you get errors often difficult to identify. The simple solution for mixed environments (32/64bit OSes with a single shared wlcg-client installation) is to install everything in 32bit version:

• You need to install 32bit compatibility libraries on 64bit OSes (e.g. Here is a list for SLC5)
• During each Pacman installation add the option -pretend-arch i686 (e.g. pacman -pretend-arch i686 -get wlcg-client) to force a 32bit installation. Pacman is actually caching this setting, so it is important you use -pretend-arch i686 the first time you install something in that directory (Pacman cache). Here is VDT documentation about -pretend-arch i686.
• NOTE: the environment variable: export VDT_PRETEND_32=1 (that was set before the VDT installation) is not working anymore.
• If you need Python 32 bit you can install on your own or use: pacman -get http://www.mwt2.org/caches/:Python32bit26. The Python delivered is Python 2.6 (C API 1013 supported by _lfc.so) and it is compiled on a SL5.5 32bit. 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). If you wonder, no -pretend-arch i686 is needed because this package is only 32 bit, anyway it is fine if you added the option.

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 ... 

  .

Why voms-proxy-info behaves differently (explanation)

This is more an explanation than a description. voms-proxy-info in wlcg-client behaves differently from the default VDT 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
• (new) install the VOMS LSC files

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
• https://twiki.cern.ch/twiki/bin/view/LCG/VOMSLSCfileConfiguration

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