GT 3.9.4: System Administrator's Guide

Introduction

This guide is the starting point for everyone who wants to install Globus Toolkit 3.9.4. It will take you through a basic installation that installs WSRF Java Core and the following Base Services: a security infrastructure (GSI), the index service, and GridFTP.

Once you have this basic setup, you'll be referred to the component of your choice for any further installation and configuration information specific to that component.

Before you begin

Before you start installing the Globus Toolkit 3.9.4, there are a few things you should consider. The toolkit contains many subcomponents, and you may only be interested in some of them.

There are non-webservices implementations of Security, GridFTP, Resource Management (GRAM), Replica Location Service, and Information Services (MDS2). These all run on Unix platforms only.

Additionally, there are WSRF implementations of Security, Resource Management (GRAM), Reliable File Transfer (RFT), and Information Services (Index). All the Java clients to these services run on both Windows and Unix. The WSRF GRAM service requires infrastructure that only runs on Unix systems.

Therefore, if you are new to the toolkit and want to experiment with all of the components, you may want to use a Unix system. If you are interested in the Windows development, you may restrict yourself to the Java-based software.

Software Prerequisites

Required software

  • JDK 1.4.2+ from Sun or IBM.
  • Ant 1.5+. Do not use the ant distributed with Fedora Core 2.
  • C compiler. If gcc, avoid version 3.2. 3.2.1 and 2.95.x are okay.
  • GNU tar
  • JDBC compliant database. For instance, postgres 7.1+
  • gpt-3.2autotools2004 (shipped with the installers, but required if building standalone GPT bundles/packages)

Optional software

Platform notes

The platform notes page contains more in-depth information about building Globus on certain platforms.

Installing GT 3.9.4

First, download the required software. Be aware that apache ant will use the java referred to by JAVA_HOME, not necessarily the first java executable on your PATH. Be sure to set JAVA_HOME to the top-level directory of your java installation before installing.

If you want to build RLS, install IODBC. If you do not, the build of RLS will be skipped. See "Optional Bundles" for more details about installing RLS.

Create a user named "globus". This non-privileged user will be used to perform administrative tasks such as starting and stopping the container, deploying services, etc. Make sure this account has read and write permissions in the destination directory.

As the globus user, run:

globus$ ./configure --prefix=/path/to/install
globus$ make

If you do not specify a prefix, "/usr/local/globus-3.9.4" will be used. If you do not create a user named "globus", be sure to run the installation as a non-root user.

Optional extras

If you are installing on a machine that has the submission software for PBS, LSF, or Condor already installed, you may install the corresponding scheduler packages. Add the following to your configure line:

--enable-wsgram-condor
--enable-wsgram-lsf
--enable-wsgram-pbs

If you installed IODBC for RLS, add the following two items:

--enable-rls --with-iodbc-path=/path/to/iodbc

If you want to enable internationalization, say:

--enable-i18n

There are also Makefile targets for contributed code:

"make myproxy" to build MyProxy.
"make gsi_openssh gsi_openssh_setup postinstall" to build GSI-OpenSSH.
"make gt4-webmds" to build WebMDS.

Configuring

Required configuration

You will be required to have certificates. To obtain low-trust certificates, you may use the online certificate service, or you may install a simpleCA according to the instructions below.

Setting environment variables
In order for the system to know the location of the Globus Toolkit commands you just installed, you must set an environment variable and source the globus-user-env.sh script.
1

As globus, set GLOBUS_LOCATION to where you installed the Globus Toolkit.

This will either be export GLOBUS_LOCATION=/path/to/install or setenv GLOBUS_LOCATION /path/to/install.

2

Source $GLOBUS_LOCATION/etc/globus-user-env.{sh,csh} depending on shell.

  • .sh for Bourne shell
  • .csh for C shell
Certificate Authority (CA) options

Your best option is to use an already existing CA. You may have access to one from the company you work for, or an organization you are affiliated with. Some universities provide certificates for their members and affiliates. Contact your support organization for details about how to acquire a certificate. You may find your CA listed in the TERENA Repository.

If you do not have an existing CA, you can set up a CA for your own use with the Globus SimpleCA package. SimpleCA provides a wrapper around the openssl CA functionality and is sufficient for simple Grid services. Alternatively, you can use openssl's CA.sh command on its own. Instructions on how to use the SimpleCA can be found here.

You can also use an online certificate service. However, this option should only be used as a last resort because it does not fulfill some of the duties of a real Certificate Authority. If you must use this option, please see the following link for instructions: http://gcs.globus.org:8080/gcs.

  • If you do not have access to an existing CA and want to use SimpleCA, read this before continuing the Admin guide..
  • If you already have a CA, you will need to follow their configuration directions. If they include a CA setup package, follow the CAs instruction on how to install the setup package. If they do not, you will need to create an /etc/grid-security/certificates directory and include the CA cert and signing policy in that directory. See Configuring a Trusted CA for more details.

The rest of this guide assumes that you have access to a CA.
Requesting host certificate

You must have a host certificate in the appropriate directory for secure services. The certificate must be for a machine which has a consistent name in DNS; you should not run it on a computer using DHCP where a different name could be assigned to your computer.

3

For most CAs (SimpleCA and the Globus Certficate Authority included) you can request a host certificate using the grid-cert-request program: As root, run:

grid-cert-request -host 'hostname'

This creates the following files:

  • /etc/grid-security/hostkey.pem
  • /etc/grid-security/hostcert_request.pem
  • (an empty) /etc/grid-security/hostcert.pem

Note: If you are using your own CA, follow their instructions about creating a hostcert (one which has a commonName (CN) of your hostname), then place the cert and key in the /etc/grid-security/ location.

4 Get your host certificate signed.
5

Once you receive the signed host certificate from the CA, as root, move the signed host certificate to /etc/grid-security/hostcert.pem.

The certificate should be owned by root, and read-only for other users.

The key should be read-only by root.
Making the host credentials accessible by the container
The host key (/etc/grid-security/hostkey.pem) is only readable to root. The container will be running as a non-root user (probably the globus user) and in order to have a set of host credentials which are readable by the container, we need to copy the host certficiate and key and change the ownership to the container user. Note that this step assumes you have obtained a signed host certficate from your CA.
6

As root, run:

$ cd /etc/grid-security
$ cp hostkey.pem containerkey.pem
$ cp hostcert.pem containercert.pem
$ chown globus.globus containerkey.pem containercert.pem

At this point the certificates in /etc/grid-security should look something like:

rynge@ned-0:/etc/grid-security$ ls -l *.pem
-rw-r--r-- 1 globus globus 1785 Oct 14 14:47 containercert.pem
-r-------- 1 globus globus  887 Oct 14 14:47 containerkey.pem
-rw-r--r-- 1 root   root   1785 Oct 14 14:42 hostcert.pem
-r-------- 1 root   root    887 Sep 29 09:59 hostkey.pem
Add Authorization
Add authorizations for users:
7

Create /etc/grid-security/grid-mapfile as root.

You need two pieces of information - the subject name of a user, and the account name it should map to.

The syntax is one line per user, with the certificate subject followed by the user account name.

Run grid-cert-info to get your subject name, and whoami to get the account name:

bacon$ grid-cert-info -subject
/O=Grid/OU=GlobusTest/OU=simpleCA-mayed.mcs.anl.gov/OU=mcs.anl.gov/CN=Charles Bacon
bacon$ whoami
bacon

The corresponding line in the grid-mapfile:

"/O=Grid/OU=GlobusTest/OU=simpleCA-mayed.mcs.anl.gov/OU=mcs.anl.gov/CN=Charles Bacon" bacon

The quotes around the subject name are important, because it contains spaces.

Troubleshooting

org.oasis.wsrf.lifetime.ResourceUnknownFaultType

This error can be seen on both the client side and on the server side.

Sometimes a container may emit an error message of the form: 

[Thread-3] ERROR container.ServiceThread [doFault:628] HTTP server fault
AxisFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.generalException
 faultSubcode:
 faultString:
 faultActor:
 faultNode:
 faultDetail:
        {http://xml.apache.org/axis/}exceptionName:org.oasis.wsrf.lifetime.ResourceUnknownFaultType
        {http://xml.apache.org/axis/}hostname:myhost.isi.edu

This indicates that a client has attempted to access a resource that does not exist in the container.

This can occur harmlessly when a container running an index service is restarted, as each registrant attempts to renew its registration from the previous instance of the container. In this case, the error message is harmless. Registrations will be automatically recreated by the registration client when they detect this condition.

In other cases, it may be because an incorrect endpoint reference (EPR) is being used by a client. In general, the client causing the error will also output a similar ResourceUnknownFaultType error message.

On the client side, this error often occurs if the EPR given to the client is incorrect (for example, due to cut-n-paste error).

Related Docs