Sections

About GridPP

Documents

Activities

Management

Wiki

Help Pages

Upgrading an Existing Testbed Site Using LCFG

This insructions on this webpage are for upgrading a site to EDG v1_4_8. The method has been tested for sites installed using the GridPP LCFG network installation. The LCFG Installation Guide gives a step-by-step guide to installing a Testbed site from scratch using LCFG. It is anticipated that frequent updates to the EDG Software will be released, requiring regular upgrades of an existing site between EDG versions. It should not be necessary to reinstall a site from scratch each time an EDG version upgrade is released. This page, therefore, gathers together a simple recipe for upgrading an existing site to a newer EDG Version, using the GridPP Installation tools and LCFG, with the minimum of changes.

Summary

LCFG configuration files are stored in the two directories 

/var/obj/conf/profile/sources
/opt/local/linux/6.2/rpmcfg
Some of these files must be edited to provide site specific alterations to the default LCFG configuration.

By modifying the node configuration files, the site specific files can be stored in subdirectories 


/var/obj/conf/profile/sources/local
/opt/local/linux/6.2/rpmcfg/local
so they will not be overwritten when a new version of EDG software is installed.

Downloading an installing a new EDG version can then either use the latest gpp-install.sh script, or can by performed manually.

Preparing the LCFG Server for upgrade

Site Specific Files

When setting up a Testbed site, it is necessary to customise a number of files away from their defaults, to site specific values. We do not want to lose these site specific changes when making an upgrade. The steps in this section supplement the LCFG and Post LCFG notes on setting up the initial Testbed site. They do not need to be performed for each site upgrade.

LCFG Source Files

In the directory
/var/obj/conf/profile/source
there are two sets of files that need changing to site specific values:
  • site-cfg.h site configuration information
  • testbed001 to testbed005 node configuration information
These files will be overwritten during the upgrade, so the site-specific files should not keep these names.

NB. The node configuration files must be given the same names as their nodes. It might be considered a bad idea, therefore, for sites other than the main sites to name their testbed nodes as testbed00X.

We will assume the site specific files are named site-cfg.local.h and localX.

These node configuration files must be stored in
/var/obj/conf/profile/source
It is a good idea to create a subdirectory
/var/obj/conf/profile/source/local
and store any site specific *.h files in this directory, including site-cfg.local.h. The node configuration files should now replace
#include "site-cfg.h"
with
#include "local/site-cfg.local.h"
Site specific configuration files can now be named like local-filename.h, placed in the local subdirectory, and included by adding the line
#include "local/local-filename.h"
to the appropriate node configuration files.

RPM lists

The initial RPM lists are stored in the directory /opt/local/linux/6.2/rpmcfg as files of the form XX-rpm, where XX stands for WN, CE, SE etc. These files will also be overwritten each time the EDG version is updated.

To prevent local, site specific modifications to these files being overwritten, create a subirectory
/opt/local/linux/6.2/rpmcfg/local
and populate it with files XX-local-rpm which consist of the lines 


/* This is the default EDG RPM list */
#include "../XX-rpm"

/* Add any site specific additions after this line*/
for each XX-rpm file.

Any site specific include files for rpm lists, local-rpm.h, should also be placed in the local subdirectory and included in the XX-local-rpm file by the line 

#include "local-rpm.h"

To use the modified files for a particular node, simply add the lines 


+update.rpmcfg           XX-local-rpm
+updaterpms.rpmcfg       XX-local-rpm
+update.rpmcfgdir        /export/local/linux/6.2/rpmcfg/local
+updaterpms.rpmcfgdir    /export/local/linux/6.2/rpmcfg/local

to the end of the node configuration file in
/var/obj/conf/profile/source

With these changes, we are in a position to install a new EDG Version over an existing site, with a minimum of re-configuration.

Upgrading the EDG Version

First, as a precaution, it is sensible to copy the old EDG version configuration. 

cp -r /var/obj/conf/profile/source	 /var/obj/conf/profile/old.source.version
cp -r /opt/local/linux/6.2/rpmcfg 	/opt/local/linux/6.2/old.rmpcfg.version

Using gpp-install.sh

The installation script gpp-install.sh can also be used to upgrade to a new version:

# lynx -source http://www.gridpp.ac.uk/gpp-install/v1_4_8_1/gpp-install.sh | sh

This will download the new EDG configuration files to 


/var/obj/conf/profile/source
/opt/local/linux/6.2/rpmcfg
overwriting the previous EDG default files. It will also upgrade the LCFG server, installing any rpms to manage updated LCFG objects.

This script can be examined first.

The site specific files, in the subdirectories 


/var/obj/conf/profile/source/local
/opt/local/linux/6.2/rpmcfg/local
will be unchanged.

Running gpp-install will turn off the httpd, nfs and portmap services on the LCFG server, for security reasons.

After gpp-install.sh runs, the LCFG node will be left without running the services necessary to act as an LCFG server. To correct this simply restart the portmap, nfs and then httpd services.

Without using gpp-install.sh

The gpp-install.sh script is designed to install an LCFG server with the latest EDG version, from scratch. While it can be used to download the latest EDG version onto an existing LCFG server, it will perform a number of unnecessary steps in doing so. The steps performed by gpp-install.sh relevant to upgrading a site to $EDG_RELEASE are:
  • List available releases, then check out EDG Release $EDG_RELEASE to /tmp
    /usr/bin/gpp-fetch-edg-release.sh -l
rm -rf /tmp/edg-release
/usr/bin/gpp-fetch-edg-release.sh -o /tmp -r $EDG_RELEASE
  • Copy latest updaterep.conf and update the RPM repository
    cp -f /tmp/edg-release/updaterep/updaterep.conf /etc/updaterep.conf
/usr/sbin/updaterep -v
  • Copy the latest LCFG files to their correct locations 
    cp -f /tmp/edg-release/rpmlist/* /opt/local/linux/6.2/rpmcfg
cp -f /tmp/edg-release/source/* /var/obj/conf/profiles/source
  • Update the rpm's on the LCFG server 
    cd /opt/local/linux/6.2/rpmcfg
wget http://www.gridpp.ac.uk/gpp-install/$VERSION/LCFG-rpm
/usr/bin/gpp-testrpms.sh -i -l LCFG-rpm -r /
    where $VERSION is usually ${EDG_RELEASE}_1 (the exact name of the latest version can be found by mailing the TB-Support mailing list).

New EDG Version Configuration

Check that no significant changes have taken place in the format of the LCFG configuration files 

diff source/site-cfg.h   old.source.version/site-cfg.h
diff source/testbed00X   old.source.version/testbed00X
If there have been changes, then modify the site configuration file
local/site-cfg.local.h
and the node configuration file
localX
appropriately.

In the local/site-cfg.local.h file, the SITE_EDG_VERSION should always be updated to the latest EDG version. The line SITE_INSTALLATION_DATE_ should also be updated (in "YYYYMMDDHHMMSSZ" format, where Z denotes GMT)

The LCFG and Post LCFG pages should contain an up-to-date list of all the configuration details necessary for the latest EDG Version. Where changes occur in the site or node configuration files, consulting these pages should give some indication of the necessary steps to include these changes. A history of changes between versions is given here.

If the site nodes were given the names testbed00X, then their configuration files will have been overwritten by the update. Once it has been confirmed that no significant changes have occurred to the node configuration files, the old site specific node configuration files should be copied from the old.source.version subdirectory to the source subdirectory.

NB. if the GridPP VO (or any other non-default VO) has been added according to the recipe in the GridPP VO page, then all the relevant configuration files should be in the gridpp subdirectory and so will also be unchanged by the upgrade. The GridPP VO page should be checked in case the configuration of a new VO has changed.

Test, and update, the new configuration for all nodes using

/usr/sbin/mkxprof -v -A localX

This should be performed for all nodes, even if the diff command showed no changes, as *.h files included may have changed.

New RPM Lists

Test the new RPM lists are consistent by
/usr/bin/gpp-testrpms.sh -l local/XX-local-rpm -r /tmp/XX

If all node profiles compile and all RPM lists are consistent, the nodes can be updated.

Otherwise, the updating can take place either by automatic update procedures, or forced immediately by issuing 


rdxprof
/etc/rc.d/init.d/lcfg.init stop
/etc/rc.d/init.d/lcfg.init start
commands on the node.

Post LCFG Configuration

Most of the Post LCFG Configuration steps given in the Post LCFG and GridPP VO pages will not need repeating after an upgrade, either because the relevant changes were made in the site specific files, or because the changes made on the individual nodes were not overwritten. These pages should still be checked, in case new steps are required for the new EDG Version. A list of incremental changes in the testbed is given here.

If Everything Goes Wrong

If at any point the upgrade process appears to have broken down for some reason, it is always possible to return to the original working configuration by deleting the directories and replacing them with the original configuration 

\rm -r /var/obj/conf/profile/source
\rm -r /opt/local/linux/6.2/rpmcfg
cp -r /var/obj/conf/profile/old.source.version    /var/obj/conf/profile/source
cp -r /opt/local/linux/6.2/old.rpmcfg.version    /opt/local/linux/6.2/rmpcfg
then, if necessary, forcing a profile update by issuing: 

/etc/rc.d/init.d/lcfg.init stop
/etc/rc.d/init.d/lcfg.init start
commands on the nodes. Post-LCFG configuration steps above may also then be required.

Version changes

A history of changes to the installation/upgrade procedures, from EDG v1_4_0 onwards, is here.
Testbed Support Mailing List, Testbed Installation Notes

Last modified Mon 21 April 2008 . View page history
Switch to HTTPS . Website Help . Print View . Built with GridSite 1.4.3
For more about GridPP please contact Neasan O'Neill