Version 14 (modified by 18 years ago) (diff) | ,
---|
Release Notes for gLite3 Templates
TracNav
Table of Contents
Releases
Date | Release | Description |
24/7/2006 | Creation of branch gLite-3.0.0 All LCG machine types (except VO Box) available LCG RB, Classic SE, DPM SE not yet tested | |
26/7/2006 | First release of QWG templates for gLite 3.0 All LCG machine types (except VO Box) available Preliminary work on VOMS server | |
26/7/2006 | First release of QWG templates for gLite 3.0 Addition of VOBOX templates, Update of CA RPMs |
Known Problems
LCMAPS error after upgrading from LCG 2.7.0
This is caused by VOMS related libraries having been moved from /opt/edg
to /opt/glite
.
ncm-ldconf
, ran as part of the upgrade, is updating shared libraries cache (/etc/ld.so.cache
) only if the contents of /etc/ld.so.conf
has been changed. Unfortunatly this is not the case between LCG 2.7 and gLite 3.0. It just happens that some libraries have been moved from one path to another...
To fix this problem, log on the machine and run :
ldconfig
No service restart is needed.
DPM upgrade from LCG 2.6/2.7
gLite 3.0 DPM (1.5) includes integration with VOMS and requires a database schema upgrade. This must be done manually on the DPM master node. The following steps are needed :
- Create a script to call the upgrade procedure (replace by value for your sites) :
#!/bin/sh requires () { echo "requires : nothing done" } # Edit to match your site export MY_DOMAIN='your.dom.ain' export DPM_HOST='dpm.your.dom.ain' export DPM_DB_USER='AdminDbUser' # Generally root export DPM_DB_PASSWORD='AdminDBPwd' . /opt/glite/yaim/functions/config_DPM_upgrade config_DPM_upgrade
- Check that AdminDBUSer/AdminDBPwd has full privileges on your database server
- Run the script
- Restart all DPM daemons. The easiest is to delete
/etc/shift.conf
and run the following command :ncm-ncd --configure dpmlfc
- Run the command in
/etc/cron.d/lcgdm-mapfile-update.ncm-cron.cron
Condor RPM name not matching internal name
RB, VOBOX, WMS normally require Condor RPM condor-6.7.10-linux-x86-glibc23-dynamic-1.i386.rpm
. Unfortunatly the internal name of this RPM is condor-6.7.10-1.i386
. This doesn't work with SPMA that use internal name to know if a RPM is already installed.
To workaround this problem, templates load condor-6.7.10-1.i386.rpm
, which also exists (but seems different) in gLite 3.0 distribution (external packages). This requires the following step are required for loading the right RPM :
- In RPM repository for gLite external packages, rename
condor-6.7.10-1.i386.rpm
to something else. - Create a symlink called
condor-6.7.10-1.i386.rpm
tocondor-6.7.10-linux-x86-glibc23-dynamic-1.i386.rpm
.
This problem has been logged to GGUS, ticket 10567.
LCG RB upgrade
gLite 3.0 includes a new version of Condor that is no longer installed in /opt/condor
but /opt/condor-version
. Also default name for Condor configuration file is now condor_config
instead of condor.conf
.
Condor relies on CONDORG_INSTALL_PATH and CONDOR_CONFIG environment variables to know where it is installed and where is the configuration file. Unfortunatly, the script starting Condor (/etc/init.d/edg-wl-jc
) relies on /opt/edg/etc/profile.d/edg-wl-config.sh
to get these variables defined in the context of the script (from /etc/sysconfig/globus
, the actual place where they are defined). But this script doesn't take care of exporting these variables when tehy are defined in /etc/sysconfig/globus
. As a consequence, Condor master doesn't see them. This has been logged into GGUS as ticket 10628.
In the meantime, before the problem is fixed, you need a patched version of edg-wl-config.sh
. It is provided as part of LCG RB configuration, by QWG templates. But there is no way to ensure that a further reinstallation of the RPM will not overwrite this patched version.
If CondorG refuses to start, complaining that CONDOR_CONFIG is not defined, you should use the following command to reinstall the patched version :
ncm-ncd --configure filecopy
fetch-crl
gLite templates requires the most fetch-crl version released by EUGRID PMA laste spring 2007 (2.6.0-1). Before gLite-3.0.0-3, RPMs list provided only version 2.0-1 that is not working properly with the configuration set up by templates. As a result, you quickly reach expiration of CRL and nothing works anymore...
Starting with gLite-3.0.0-3, RPMs list requires the right version. But this version is not yet part of gLite distribution, so you need to get it directly from EUGRID PMA site and put it the RPM repository for gLite 3.0 updates.
Change Log
ChangeLog build from repository commit messages...
Changelog not available