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:
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 ...
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!
export VDT_ALLOW_UNSUPPORTED=1 pacman -get ...
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 /opt/vdt-1.10.1 > export OLD_VDT_LOCATION=/opt/vdt-1.3.11 # Note it is a full pathname > pacman -get http://vdt.cs.wisc.edu/vdt_1101_cache:VDT
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.
Before you can use the components in the VDT, you need to source one
of the setup scripts, either
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).
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:
$VDT_LOCATIONare stored in
$VDT_LOCATIONare stored in
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
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.