GLite on SC4

From GridPP Wiki
Revision as of 11:38, 13 September 2007 by Peter love (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Workarounds for installing gLite3 on SL4 64-bit

  • Information on this page was supplied by Michel Jouvin of LAL
  • Package info for glite 3.1 can be found on SL4 additional packages

Below is the recipe we used at LAL to run plain gLite3 on SL4 64-bit. On 32-bit some of the steps described here are not necessary. Again, I'd like to insist there is no modification required to what's provided in the standard distribution, just additions (mainly RPMs from SL3 to install on SL4 to satisfy dependencies).

gLite3 on SL4 has been tested at LAL only for WN, UI and BDII. It probably works for other machine types but this is untested by us. The BDII requires almost nothing special. The UI requires some additional RPMs, compared to the WN and this is mentioned explicitly below.

At the end of this note you can find a few tips for LHC VO applications. In fact, they run smoothly with this configuration and the tips here are just for old versions of the software already installed, mainly for Atlas.

The configuration described here is in production for 6 months at LAL, where 2/3 of the workers are running with this configuration, in the same CE as SL3 nodes (CE is advertised SL3 in BDII).

And last but not least, if you are using Quattor, the support for SL4 is integrated in the standard LCG QWG templates (http://trac.lal.in2p3.fr/LCGQWG).


Middleware installation

Before being able to install and run gLite3 on SL4 64-bit, you need to install a standard OS configuration (as described in gLite installation notes) + compat-arch-development RPMs group (compat-arch-support is enough for the MW but some components could be missing if an application need to be rebuild from a job).

To this basic installation, you need to explicitly add the following RPMs from the SL4 distribution (most of them are not included in any group or are in groups where just one RPM is needed).

In addition to this base installation, you need to install from the OS distribution the following RPMs (and with the native arch of the OS you install, unless noted) or insure you don't use the version provided with the MW :

sharutils (not required by the MW itself but by some VO SW, noticeably Atlas) tkinter tix lam libaio libaio-devel words xorg-x11-xdm compat-libstdc++-33, i386 python, i386 (required by LFC Python interface) j2sdk (1.4.2_10-fcs) ORBit (0.5.17-14) # For UI only

and remove the following RPMs normally installed as part of the OS installation as they cause conflicts with gLite RPMS :

compat-libstdc++-296, 2.96-132.7.2 perl-Crypt-SSLeay, 0.51-1 perl-XML-SAX, 0.12-7 perl-XML-LibXML perl-LDAP boost-devel, 1.32.0-1.rhel4, x86_64


You also need to install the following RPMs coming from SL3, i386 :

commons-logging (1.0.2-12) compat-libstdc++ (7.3-2.96.128) ElectricFence (2.2.2-15) junit (3.8.1-1) libgcj-ssa (3.5ssa-0.20030801.48) redhat-java-rpm-scripts (1.0.2-2, noarch) itcl (3.2-92.2) # For UI only


You will also require some RPMs we made at LAL to workaround a few problems. The first ones can be downloaded from http://quattorsrv.lal.in2p3.fr/packages/os/sl430-x86_64/updates/, the last one (perl-TermReadKey) from http://quattorsrv.lal.in2p3.fr/packages/site. For theses RPMs, I can provide the src rpm if you want to rebuild them with another name...

  1. Provides 32-bit python binary not installed if not on native architecture. Binary provided as python32
  2. Required by LCG Python API (used by Atlas)

lal-python-bin-2.3.4-14.2-1.0.0-1.i386.rpm

  1. Provides version 8.3 of tcl and tk libraries

lal-tcl-tk-lib-8.3-1.0.0-1.i386.rpm

  1. Provides libcurl.so.2 (UI only)

curl-compat-7.10.6-6-1.0.0-1.i386.rpm

  1. Provides libldap.so.2 (UI only)

openldap-compat-2.0.27-1.0.0-1.i386.rpm

  1. Provides libcom_err.so.3 (UI only)

libcom_err-compat-krb5-1.2.7-1.0.0-1.i386.rpm

  1. Define feature libstdc++ as installed, as the RPM has been renamed compat-libstdc++
  2. Provides no file

lal-libstdc++-3.2.3-1.i386.rpm

  1. Make perl-TermReadKey i386 appeared as installed, even if this is the 64-bit
  2. version that is actually installed. Provides no files.

lal-perl-TermReadKey-2.20-12.i386


And you need to be sure not to install the following RPMs from gLite distribution (but to use OS provided version)

perl-Crypt-SSLeay perl-TermReadKey

To install a UI on SL4.3 i386, we had to add/remove the following RPMs but we are not sure if this is really required :

add binutils (2.15.92.0.2-18) remove xorg-x11-Xvfb remove xorg-x11-Xnest remove gcc4 remove gcc4-c++ remove gcc4-gfortran


Configuring gLite

After the successful installation, you need to create /etc/java.conf, defining JAVA_HOME as /usr/java/j2sdk1.4.2_10 (instead of _8).


VO Applications

After the few problems indentified in the first few days, we had no problem with VO software : we are supporting quite a lot of them, not only HEP.

The main things the apps should take care of are : 

* If they need a 32-bit python they need to use python32. This is important for LFC Python API that uses a 32-bit library.
* Default gcc is gcc 3.4. gcc 3.2 (SL3) is named gcc32 (that has nothing to do with 32-bit).
* VO should not try to use their own 32-bit version of a compiler on a 64-bit machine, it will not work.
* If you want to build a 32-bit app on SL 64-bit, you need to add option -m32

The main problems we had were with Atlas SW. Support for 64-bit is now in the Atlas distribution but if your version was installed in the past, you may have to manually fix the CMT requirements for a few packages. Below is the detail (use ‘find’ command to find where the file is sitting as it differs fromone version to another) :

- In AtlasCxxPolicy/.../requirements, looks for macro cpp definition and add the following line in the already existing list of definitions : 

   x86_64&gcc&32 "g++32 -m32" \

- In AtlasCxxPolicy/.../requirements (same as previously), after macro cpp definition, add the following line :

macro_append shlibbuilder "" x86_64&gcc&32 " -m32"

- In External/ExternalPolicy/..../requirements, look for slc3 related tag definitions (there is a section with an explicit comment) and look for the following tag definition : 

  tag i686-slc3-gcc323-opt

Add '32' at the end of the line (as one more tag to define when tag i686-slc3-gcc323-opt is defined).


In addition to these CMT requirements changes, To be complete on Atlas, you need to ensure there is a symlink 'Linux-x86_64' defined and targeting 'Linux-i686' in release directory (prod/releases/RELNUM) CMT/version.

Last, on each WN, you need to define a symlink /usr/lib/libg2c.so targeting /usr/lib/libg2c.so.0 as it is no defined by libf2c RPM in SL4.3 (buggy RPM ?).


Links

Information here comes from what is in the Quattor QWG templates for gLite. If you want to refer to the content of these templates, look at the following URLs :

Base system configuration (RH/SL feature groups installed) https://trac.lal.in2p3.fr/LCGQWG/browser/templates/branches/gLite-3.0.0/os/sl430-x86_64/os/pro_os_glite_base.tpl

RPM tweakening : https://trac.lal.in2p3.fr/LCGQWG/browser/templates/branches/gLite-3.0.0/os/sl430-x86_64/os/pro_os_glite_postconfig.tpl

Retrieved from "https://www.gridpp.ac.uk/w/index.php?title=GLite_on_SC4&oldid=1661"