Note: This version of the VDT (1.8.0) is no longer supported. Feel free to look through the documentation and install it, but we cannot guarantee support for it. The current stable release is 2.0.0.

Post-install Configuration

Congratulations! You've installed the VDT. That wasn't so hard now, was it? If it was, please let us know. We're always working to make the VDT easier to install and your feedback is essential.

Post-installation steps for server administrators

After the VDT install completes there are still a few server components left unconfigured. Take a quick look at this list and handle anything that applies to you. You almost certainly do not need to do everything in this list--just do the ones that are relevant to you.

To learn more about the software you've just installed take a look at the documentation for VDT 1.8.0.

Configure sudo for web services GRAM

In order to use web services GRAM, sudo must be installed and configured. The web services run as the globus user, but need to submit jobs as different users. Configuring sudo for this is more secure than allowing GRAM to run as root. The configuration is also documented in the post-install/README file, and it will differ in one or two ways from what we show below, so you should use that file as a reference:

If you install as non-root (which is perfectly allowable): there should be a different user name instead of 'globus'.
The pathnames to the Globus executables will be different.

Runas_Alias GLOBUSUSERS = user1, user2
globus ALL=(GLOBUSUSERS) \ 
       NOPASSWD: /opt/vdt/globus/libexec/globus-gridmap-and-execute \ 
       -g /etc/grid-security/grid-mapfile \ 
       /opt/vdt/globus/libexec/globus-job-manager-script.pl *
globus ALL=(GLOBUSUSERS) \ 
       NOPASSWD: /opt/vdt/globus/libexec/globus-gridmap-and-execute \ 
       -g /etc/grid-security/grid-mapfile \ 
       /opt/vdt/globus/libexec/globus-gram-local-proxy-tool *

Note that you must replace 'user1, user2' with a list of comma-separated user id names. If you prefer, you can allow Globus to sudo to all users except root by substituting the following Runas_Alias line for the one above:

Runas_Alias GLOBUSUSERS = ALL, !root

Set up the web services Globus gatekeeper for your batch system

In order to work with your batch system, the web services Globus gatekeeper (GRAM) must have additional packages installed that are specific to your batch system. To set up any of these, first make sure the batch system's command line tools are in your path. Next, install the appropriate package.

> pacman -get http://vdt.cs.wisc.edu/vdt_180_cache:Globus-WS-Condor-Setup
    or
> pacman -get http://vdt.cs.wisc.edu/vdt_180_cache:Globus-WS-LSF-Setup
    or
> pacman -get http://vdt.cs.wisc.edu/vdt_180_cache:Globus-WS-PBS-Setup

Set up the pre-web services Globus gatekeeper for your batch system

In order to work with your batch system, the pre-web services Globus gatekeeper (GRAM) must have additional packages installed that are specific to your batch system. To set up any of these, first make sure the batch system's command line tools are in your path. Next, install the appropriate package.

> pacman -get http://vdt.cs.wisc.edu/vdt_180_cache:Globus-Condor-Setup
    or
> pacman -get http://vdt.cs.wisc.edu/vdt_180_cache:Globus-LSF-Setup
    or
> pacman -get http://vdt.cs.wisc.edu/vdt_180_cache:Globus-PBS-Setup
    or
> pacman -get http://vdt.cs.wisc.edu/vdt_180_cache:Globus-SGE-Setup

Configure MonaLisa

During installation the VDT configures MonaLisa with workable, yet inaccurate information. If you plan on running a MonaLisa server you'll want to run $VDT_LOCATION/vdt/setup/configure_monalisa.sh first.

Get a host certificate

If you plan on running any grid services you'll need a host certificate for your machine. See our instructions for more information.

Get service certificates

If you use authenticated MDS, you will need an 'ldap' service certificate. If you use DRM or a service that depends on Apache (VOMS or jClarens) you will need an 'http' service certificate. These are stored in subdirectories of /etc/grid-security/. For instance:

> ls -l /etc/grid-security/ldap
total 12
-rw-r-----    1 daemon   daemon       1194 Feb  2 13:34 ldapcert.pem
-rw-r-----    1 daemon   daemon       1351 Feb  2 13:34 ldapcert_request.pem
-r--------    1 daemon   daemon        887 Feb  2 13:34 ldapkey.pem

> ls -l /etc/grid-security/http
total 12
-rw-rw-r--    1 daemon   daemon       1193 Feb  2 13:34 httpcert.pem
-rw-r--r--    1 daemon   daemon       1379 Feb  2 13:34 httpcert_request.pem
-r--------    1 daemon   daemon        887 Feb  2 13:34 httpkey.pem

Set up a Globus gridmap file

The gridmap file -- located at /etc/grid-security/grid-mapfile -- is also required to run any grid services. It contains a mapping of users' certificate subjects to local UNIX accounts. A user must be in your gridmap file in order for them to take advantage of any grid services you're running. See the Globus documentation for more information.

Set up Simple CA

Most people do not need to set up a certificate authority because they already have access to one. However, you might want to set up a CA for testing purposes and you can use the Globus Simple CA included in the VDT. You will need to run a couple of commands in order to set it up:

$GLOBUS_LOCATION/setup/globus/setup-simple-ca
(This will ask you several questions, including the name of your CA
and your passphrase)

$GLOBUS_LOCATION/setup/globus_simple_ca_HASH_setup/setup-gsi -default
(The HASH will be replaced with the hash for your CA--the first 
command will print it out)

For more details, see: Globus's Simple CA directions

Adding VDT services to TCP wrappers

The VDT runs several services via inetd/xinetd. If you're running TCP wrappers you'll need to modify your access policies to include these new servers. See our TCP wrappers documentation for more details.

Try out Nest

If you want to try out Nest, just install the Nest package. Note that it will reconfigure the GridFTP server to use Nest for access to all storage. You can disable this by editing GridFTP's configuration file.

Configure the Generic Information Provider

The VDT includes the Generic Information Provider (GIP), which can provide information via MDS (the GRIS) that matches the GLUE Schema. If you don't understand this, you can probably skip it. If you want to have your site be able to accept LCG jobs or be part of Open Science Grid, you almost certainly want it. The VDT and VDT-Gatekeeper packages install the GIP by default. If you don't use those packages or the OSG installation, then install the Generic-Information-Provider package. In either case, run the configure_gip script to set them up.

Working with PBS and LSF queues

If you are running PBS or LSF and your site has multiple queues, user's can specify which queue they wish to use when they submit jobs. For GRAM 2 (pre-web services) jobs, they specify it in their RSL with a string like:

...(queue=longjobs)...

Globus verifies that users specify correct queue names and rejects jobs if they do not. If you add or delete queues, you need to tell Globus to rebuild its list of queues.

For PBS:
You can rebuild the list of queues with the following commands:

> cd $VDT_LOCATION
> . setup.sh
> globus/setup/globus/setup-globus-job-manager-pbs

You can verify that the queues are listed by looking at:

$VDT_LOCATION/globus/share/globus_gram_job_manager/pbs.rvf

You do not need to restart any processes after you do this.

For LSF:
You can rebuild the list of queues with the following commands:

> cd $VDT_LOCATION
> . setup.sh
> globus/setup/globus/setup-globus-job-manager-lsf

You can verify that the queues are listed by looking at:

$VDT_LOCATION/globus/share/globus_gram_job_manager/lsf.rvf

You do not need to restart any processes after you do this.