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
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 Ubuntu 9, you could do:
pacman -pretend-platform Debian-5 ...
The list of Pacman names you can use are listed on our system requirements documentation 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 5 x86, x86-64
Mac OS X 10.4 x86
Red Hat Enterprise Linux 4 AS x86, x86-64
Red Hat Enterprise Linux 5 AP x86, x86-64
Scientific Linux Fermi 4 x86, x86-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:
export VDTSETUP_ACCEPT_PLATFORM=y
VDT 2.0.0 does not officially support Ubuntu (as of 2009-10-16), however you may be able to use Debian binaries on your Ubuntu machine.
cat /etc/debian_version
pacman -pretend-platform Debian 5
OR
If your Ubuntu version is based on Debian 4 (etch), use the following pacman command to tell Pacman to fetch the Debian 4 binaries:
pacman -pretend-platform Debian 4
pacman -get commands to install the packages
that you want.
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. Notably, the VDT require the 32 bit libraries from these RPMs installed:
To do a 32-bit installation on an x86_64 system, pass the "-pretend-arch i686" argument to pacman the first time you install. This can be combined with the "-pretend-platform" flag if desired. For example:
> pacman -pretend-arch i686 -get ...
The VDT no longer uses the VDT_ALLOW_UNSUPPORTED option.
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-2.0.0 > export OLD_VDT_LOCATION=/opt/vdt-1.10.1 # Note it is a full pathname > pacman -get http://vdt.cs.wisc.edu/vdt_200_cache:VDT
We have added the ability to copy some configuration from an old VDT installation. 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.
| Component | Versions preserved | What is preserved? | |
| EDG-Make-Gridmap | All | edg-mkgridmap.conf is preserved and pathnames are updated, if appropriate. Also the grid-mapfile-local. | |
| Gratia Probes | All | All probe configuration | |
| GUMS | VDT 1.3.9 and later | gums-client.properties for the client. GUMS configuration and database for server installations. | |
| Squid | VDT 1.8.1 and later. | squid/etc is copied, squid/etc/squid.conf has pathnames updated if necssary | |
| VOMS | VDT 1.3.7 and later | Configuration and database for server | |
| VOMRS | VDT 1.6.1 and later | Configuration and database | |
| LFC (Server) | ALL | Preserve configuration and database | |
| RSV | ALL | RSV Configuration |
Before you can use the components in the VDT, you need to source one
of the setup scripts, either setup.sh 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).
$VDT_LOCATION/pre-setup/ and
put any number of .SHELL files into it. These will be sourced before
anything else in setup.SHELL. Note that this only works with Pacman
3.19 and later.
$VDT_LOCATION/post-setup/ and
put any number of .SHELL files into it. These will be sourced after
anything else in setup.SHELL. Note that this only works with Pacman
3.19 and later.
$VDT_LOCATION/vdt/etc/vdt-local-setup.SHELL.
This is sourced somewhere in the middle of setup.SHELL. It's not as
useful as the previous two options, but it remains for historical
purposes.
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_LOCATION are stored in
$VDT_LOCATION/backup/vdt.
$VDT_LOCATION are
stored in $VDT_LOCATION/backup/root.
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.