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.

VDT 1.10.1p24 Update

On 2009-08-27, the VDT team announced the release of VDT 1.10.1p24.

Note: We've changed our 1.10.1 version format because we've almost run out of letters. The new format is 1.10.1pN, where N is the number of the release since 1.10.1 was initially released, and the p stands for 'patch' (next release will be 1.10.1p25, etc).

Changes to VDT 1.10.1p24

Updated Java 1.5 and 1.6 to new versions which include security fixes. (VDT ticket 5644)
Updated Bestman to 2.2.1.2.i7.p3. This is a bug fix release. (VDT ticket 5503)
Additionally, fixed a Bestman installation problem which required a certificate to be present during installation time.
Upgraded Gratia Services/Reporting to 1.04.4. This update fixed a packaging problem with the previous version of Gratia Reporting in the VDT. Also, this includes a fix for PBS reporting, and other bug fixes. Most sites do not run a local Gratia collector, so this update will not affect them. (VDT ticket 5186)
Upgraded the Generic Information Provider from 1.1.2 to 1.1.3. This fixes a few minor bugs. (VDT ticket 5515)
Fixed the vdt-updater to update packages that have the same name in OSG and VDT caches. We know this problem occurred for Bestman, and there may have been other packages with a similar issue.
Fixed a bug in vdt-control that generated an incorrect permissions check in the environment file for xinetd services. (VDT ticket 5196)

Updating to VDT 1.10.1p24

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

Starting with VDT 1.10.1v, we strongly encourage users to update the VDT using the new VDT updater script. If you really want to do it the hard way, instructions are available on another page. Otherwise, continue below with the updater script.

Updating with the Updater Script

Please read through these instructions once before starting. They’re not long and it might help to understand how the process goes.

Also note that the actual updater script (second to last step) can run for quite a while, especially during the pacman updates themselves (step 4 in the script). We have observed step 4 taking 10–15 minutes for an OSG CE. Once that step begins, it is safe to ignore the updater for a while. But, do check back after a while, because there may be some wrap-up steps for which you need to answer questions.

And last, but hardly least: It is critical to have a backup of your VDT installation. But, it is equally important to the updater script that the backup include the updater package itself, so there is a step below for making your backup at the appropriate time.

Log in to the machine as the same user who installed the VDT
Change directories to your VDT_LOCATION
If needed, source a setup file (setup.sh or setup.csh)
Shut down all VDT services
```
vdt-control --off
```
Make sure all VDT processes are stopped before continuing. There’s no easy way for us to define exactly how to do this step. In a nutshell, use ps and look for processes that look like they come from your VDT install, then kill them.
If you do not yet have the updater script, then fetch it:
```
pacman -get http://vdt.cs.wisc.edu/vdt_1101_cache:VDT-Updater
```
If you already have the updater, update it:
```
pacman -update VDT-Updater
```
Note: If you are not sure if you have the updater, look for VDT_LOCATION/vdt/update/vdt-updater
Make a complete, exact backup
```
cp -pr $VDT_LOCATION BACKUP-LOCATION
```
or
```
rsync -a $VDT_LOCATION/ BACKUP-LOCATION
```
The updater script is going to verify the contents of your backup, so you should have a backup that is a file-level copy of the VDT installation. Do not use tar, for example, to make the backup or else the updater script will not be able to verify the backup for you.
Run the updater and follow its prompts
```
vdt/update/vdt-updater
```
If the update goes well, restart VDT services
```
vdt-control --on
```