Note: This version of the VDT (1.10.1) is supported, but is not our latest stable release. The current stable release is 2.0.0.

Manual Update Instructions for VDT 1.10.1y

Below are instructions for updating from VDT 1.10.1x to 1.10.1y. We strongly recommend that you use the new VDT updater script to perform the updates, because it is simpler and more likely to be complete and correct, plus it can update any version of VDT 1.10.1 not just VDT 1.10.1x. If you want to use the updater instead of following the manual instructions here, see this page.

If you installed VDT 1.10.1 after VDT 1.10.1y was released on 2009-06-16, you do not need to do any of these update operations because you will have 1.10.1y.

The best way to do the manual update is to update the individual packages that have changed. To be clear, we do not recommend using pacman -update without specifying specific package names. Also note that you only need to update packages if you installed them. You can see what packages have been installed with:

pacman -lc

Pre-update directions

Before you do any of the update directions that follow, please run the following commands to stop services and take a backup of your installation. This applies for all of the updates.

cd $VDT_LOCATION
. setup.sh
vdt-control --off
cp -pr $VDT_LOCATION BACKUP-LOCATION

The copy command makes a complete backup of your VDT installation, in case something goes wrong. Do not skip this step!

NOTE: Updating CA-Certificates

Note: if you have not yet updated your CA-Certificates package (released on September 11th in VDT 1.10.1i), some of the following updates may automatically include this update for you. After this update, you will need to do a one-time configuration to re-install the certificates on your system. Many of the components installed by the VDT will not work until the certificates are re-installed. See the full instructions.

Fixing a Broken Condor Package

It is possible that a previous update silently failed on a Condor update and thus has left your pacman installation data in a broken state. It is possible to fix this problem.

To check for and possibly repair the broken Condor package:

  1. Look for an uninstalled Condor package:
    pacman -lc | grep Condor

    If you see an entry like this:

    [ ] Condor

    with a space between the square brackets, then go to the next step; otherwise, your install is fine and you are done with this section.

  2. Look for the following file in your install:
    $VDT_LOCATION/vdt/etc/condor-env.sh

    If it exists, your install is broken, go to the next step to fix it; otherwise, your install is fine and you are done with this section

  3. Fix the install:
    pacman -install Condor

    Be sure to use -install not -get; this step should fix your install for other update steps

Setting the Environment

If your install refers to a GUMS server on another machine, you must set an environment variable to refer to that GUMS server before doing updates. Here is a list of files that may be part of your installation and that would contain the GUMS server hostname:

If you find a GUMS server host in one or more of these files, then set the VDT_GUMS_HOST environment variable in your shell. For Bourne shell and variants (e.g., sh, bash):

export VDT_GUMS_HOST=HOSTNAME

For csh and variants (e.g., tcsh):

setenv VDT_GUMS_HOST HOSTNAME

Preserving Log Rotations

If the VDT-Logrotate package is installed and in use, you will have to preserve the list of packages to be preserved manually. Before running any updates, backup the logrotate configuration file:

cp -p $VDT_LOCATION/vdt/etc/vdt.logrotate $VDT_LOCATION/vdt.logrotate_BACKUP

After the update, go through the contents of vdt.logrotate_BACKUP, and add back into vdt/etc/vdt.logrotate any contents that are missing.

We plan to improve the update process for VDT log rotation in a future release.

Updating Bestman

Update the Bestman package if your installation includes it (look for the $VDT_LOCATION/bestman directory):

pacman -update Bestman   # see below for configuration

Preserving Bestman configuration: When Bestman is updated in 1.10.1y, the configuration is reverted to the default setup. If you have run configure_bestman manually in the past to provide custom configuration, you will need to re-run the script with all the necessary options.

The command below may be able to provide you a summary of arguments configure_bestman has been called with in the past:

cd $VDT_LOCATION
perl -n -e 'if($a) { $a=0; print} if(m|loaded by vdt/setup/configure_bestman|) { $a=1 }' vdt-install.log

Updating SRM-Client-LBNL

Update the SRM-Client-LBNL package if your installation includes it (look for the $VDT_LOCATION/srm-client-lbnl directory):

pacman -update SRM-Client-LBNL

Updating SRM-Tester-LBNL

Update the SRM-Tester-LBNL package if your installation includes it (look for the $VDT_LOCATION/srm-tester-lbnl directory):

pacman -update SRM-Tester-LBNL

Updating Generic-Information-Provider

Update the Generic-Information-Provider package if your installation includes it (look for the $VDT_LOCATION/gip directory):

pacman -update Generic-Information-Provider

Updating GUMS

Update the GUMS-Client package if your installation includes it (look for the $VDT_LOCATION/gums/scripts directory):

pacman -update GUMS-Client

Update the GUMS-Service package if your installation includes it (look for a $VDT_LOCATION/gums/gums-service-*.war file):

pacman -update GUMS-Service

After updating the GUMS-Service package, the gums-host-cron service will be disabled by default. If you had the gums-host-cron service enabled before the update, you can re-enable it with the following command:

vdt-control --enable gums-host-cron