Note: This web site is only kept up to date for OSG Software 1.2 (VDT 2.0.0). If you are looking for information for the most recent release, the RPM-based OSG Software 3.0, please see the OSG documentation web site

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.

Advanced Installation Tips

Installing on an unsupported platform

The VDT is only officially supported on some platforms, though it may work on more. Our system requirements documentation lists the supported platforms. By platform, we mean "operating system and CPU architecture combination".

When we say that we support a platform, we mean that we have a computer with that OS/architecture combination and it is passing our automated nightly test suite. It may work on other Linux releases (particularly RedHat Enterprise Linux clones), but we do not guarantee it because we have not tested it.

If you want to install on an unsupported platform, you should use Pacman's "-pretend-platform" flag with one of the appropriate Pacman name for a similar platform. For example, on CentOS 5, you could do:

pacman -pretend-platform linux-rhel-5 ...

The list of Pacman names you can use are listed on our system requirements documenation web page. Note that Pacman accepts multiple names for a platform, and we list just one of them. For example RHEL-5 can be used instead of linux-rhel-5.

One some platforms you will see a message from the VDT verifying that you wish to install. It will look something like this:

The VDT is unable to recognize your platform.  This version of the VDT
is supported on several Linux releases:

    AIX, PPC
    CentOS 5 x86, x86-64
    Debian 3.1 (Sarge) x86
    Debian 4 (Etch) x86, x86-64
    Mac OS X 10.4 x86
    Red Hat Enterprise Linux 3 AS x86, x86-64, IA-64
    Red Hat Enterprise Linux 4 AS x86, x86-64
    Red Hat Enterprise Linux 5 AP x86, x86-64
    ROCKS Linux 3.3 x86
    Scientific Linux Fermi 3 x86
    Scientific Linux Fermi 4 x86, x86-64
    Scientific Linux 4 IA-64
    SUSE Linux 9 x86-64, IA-64

The VDT may work on other platforms, but it's not guaranteed.  If you 
encounter problems and send mail to the VDT team for support please
mention that you are installing the VDT on an unsupported platform.

Answer yes and continue. Alternatively you can avoid this message completely by defining VDTSETUP_ACCEPT_PLATFORM in your environment. It should have the value 'y'. In Bourne shell:


Installing 32-bit software on a 64-bit platform

In some cases, you might want to install the 32-bit version of the VDT on a 64-bit platforms. This is most commonly done when some software is not supported on 64-bits. Historically that was commonly done for the VOMS server which was 32-bit only, but as of VDT 1.8.0 it became supported on 64-bit. You can see what software is supported on each platform by looking at our contents web page.

We support doing this on x86-64 (amd64) but not on IA-64. It will require that your system have 32-bit system libraries installed.

To do a 32-bit installation, define VDT_PRETEND_32 in your environment. It must be installed for any Pacman commands you run, including updates that you do at a later time. For example:

> export VDT_PRETEND_32=1
> pacman -get ...

Installing unsupported software

Some software is not supported on a platform that you are using. If you wish to attempt to install it anyway, defined VDT_ALLOW_UNSUPPORTED in your environment, and it might work. At least, the VDT won't refuse to try software that we have decided is unsupported on your platform. No guarantees though!


pacman -get ...

Preservation configuration from an old installation

If you have previously installed the VDT in a different location, you can have the new VDT pick up configuration information while you do the installation. Before you run the Pacman command to install the VDT, set OLD_VDT_LOCATION in your environment to point at the old installation. For example:

> pwd
> export OLD_VDT_LOCATION=/opt/vdt-1.3.11   # Note it is a full pathname
> pacman -get

We have added the ability to copy some configuration from an old VDT Currently, we preserve configuration for GUMS, VOMS, VOMRS, and EDG-MakeGridmap. We chose to focus on these because they are the hardest for most people to preserve by hand: GUMS and VOMS have MySQL databases in addition to configuration files. As time permits, we will expand the configuration that we can preserve. If you have any components that you think we should address first, please let us know.

Note that we also preserve the questions: your answers to all questions are copied from the old installation, and you are not asked any questions that you previously answered.

Modify Pacman's setup scripts

Before you can use the components in the VDT, you need to source one of the setup scripts, either or setup.csh, as appropriate for your shell. (We'll refer to both of these as setup.SHELL for convenience.) Some people like to modify the environment that is constructed, but you should not modify setup.SHELL. Instead, there are three other places that you can insert modifications, and they wil be picked up by setup.SHELL. In each case, you'll add or edit files, and you should make your edits for both Bourne shell (.sh) and C-Shell (.csh).

Understand VDT file backups

When the VDT is installed or vdt-control is executed, some configuration files may be edited, particularly system files like the xinetd configuration files in /etc/xinetd.d. Backups of these files are saved, but they are saved within $VDT_LOCATION. To be precise:

Understand VDT log rotation

The VDT installs the standard Unix logrotate program in $VDT_LOCATION/logrotate/sbin/logrotate, and it is run as a root-owned cron job regardless of what logrotation already exists on your system. Logs are not rotated for non-root installations.

The default log rotation policy is to rotate logs once a day and to keep the logs for seven days. You can see the list of logs that are rotated for your installation in $VDT_LOCATION/vdt/etc/vdt.logrotate. We do not list them here because it varies depending on what version and subset of the VDT you have installed.

We configure logrotate so that it can rotate files that are currently in use. (We use the copytruncate option.) This means that programs (such as Tomcat) that create a log file by simply by redirectiong standard output and/or standard error will continue to work because the file never disappears: logrotate works by copying the file then truncating it. However, between the copy and the truncate, more logging data might be written, and it will be lost.