Verify installation of Globus Toolkit 2.4
At this point, you can check to see that all the components that you have installed are working. Here is the overview:
This step applies anytime you want to use commands from the Toolkit. First, make sure
you have set
GLOBUS_LOCATION to the location of your Toolkit installation.
There are two environment scripts called
$GLOBUS_LOCATION/etc/globus-user-env.csh. You should read in whichever
one corresponds to the type of shell you are using.
For example, in csh or tcsh, you would run
In sh, bash, ksh, or zsh, you would type
Security is at the heart of Globus, and as such, you will not be able to test your Globus configuration until you have obtained a certificate for yourself. You may use the Globus CA as described in the following instructions to obtain these certificates. Alternately, your site may already have a Certificate Authority which you can use. Check with your local system administrators.
If you plan on installing Globus on multiple hosts or want to have control over your own certificate-signing process, you can use the SimpleCA package to run your own CA. It provides a wrapper around the openssl ca commands, and is available from the Simple CA homepage.
Additionally, you will need certificates for the different services you plan to run. Currently, both GRAM and GridFTP use a host certificate, while MDS uses an ldap certificate. These certificates are persistent. Even if you need to reinstall Globus at a later date, you can keep and re-use your certificates until they expire.
NOTE: The Globus CA certificate has expired in January 2003 and will not be renewed, as announced in this message. These instructions have been changed to reflect that fact.
To request a user certificate, simply run "grid-cert-request".
grid-cert-request will ask for a password to protect your key, and give you a set of instructions for how to mail your request to the CA. Note: Do not email the request to "firstname.lastname@example.org". See this message for details. When you run the grid-cert-request command, it will generate three files. One is the request that you need to send to the CA, named usercert_request.pem. Another is the key that corresponds to that request, named userkey.pem. The last is usercert.pem, which will be a 0 byte file. This is not your certificate! It is merely a placeholder that helps to remind you where to put your certificate when the CA responds to your request.
If the OU= has localhost or localdomain in it, or does not match your DNS domain name, you will need to correct this, either in DNS, /etc/hosts, or with setup-gsi. If the CN= "(null)", grid-cert-request was not able to determine your name from finger. Get your name entered so that finger will print it, or use the -cn option.
When you retrieve your certificate, save it to ~/.globus/usercert.pem. In the end, you will have a userkey.pem and usercert.pem in your $HOME/.globus directory. Only you have a copy of your key file. Do not lose this file, and do not forget your password.
If you would like to run a gatekeeper or GridFTP server on your machine, you will also need a host certificate for your host. 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.
If you ran setup-gsi as root, run the following command as root to get a
gatekeeper certificate, replacing user.test.edu with the fully qualified hostname of your
machine. Replace the text
"your-hostname-here" with your fully-qualified
% grid-cert-request -service host -host <your-hostname-here>
When you retrieve your certificate, save it to /etc/grid-security/hostcert.pem. You will need to be root as this file should be owned by root with permissions 444. Again, don't worry about the 0 byte file named hostcert.pem that will be generated by the grid-cert-request-command. It is just a placeholder.
A server certificate is needed by the LDAP service in order to run. To request a server certificate, use the grid-cert-request command below.
% grid-cert-request -service ldap -host FQDN
Replace FQDN with the fully qualified domain name of the host that will run the ldap server.
When you retrieve your certificate, save it to /etc/grid-security/ldap/ldapcert.pem. This file must be owned by the user account that will run MDS. The file should have permissions 444. Also change the ownership of /etc/grid-security/ldap/ldapkey.pem to the user account that will run MDS. Make sure ldapkey.pem has the permissions 400.
Very Important Notice
Please, if you are going to install the services as root, just skip the next three sections.
The next three sections are designed to show you how a user can stand up a service using a user certificate, just to check that all the pieces are installed. This is not the way you will be using the toolkit in the future.
The mailing lists have shown that these tests can confuse people about how the services are supposed to work. Where possible, I have tried to note the differences.
Note: To run these tests on a single host, you will need both the Client and Server Resource Management bundles installed. If you want to test a client-only install, you will need to have a server available to test against, and if you want to test server-only, you will need a client available somewhere.
When you have a user certificate, you can use the following tests to verify a working installation. Don't forget to set your environment.
First launch a gatekeeper by running the following (as yourself, not root):
% grid-proxy-init -debug -verify % globus-personal-gatekeeper -start
This command will output a contact string like "hostname:4589:/O=Grid/O=Globus/CN=Your Name". Substitute that contact string for <contact> in the following command:
% globus-job-run <contact> /bin/date
You should see the current date and time. At this point you can stop the personal gatekeeper and destroy your proxy with:
% globus-personal-gatekeeper -killall % grid-proxy-destroy
Please note that the above instructions are just for testing, and do not install a fully functioning gatekeeper on your machine for everyone to use. Installing a system-level gatekeeper for everyone to use will be covered in the configuration section of this guide. In the future, you will not have to specify a full contact string for the gatekeeper. Just the hostname is sufficient, if it is being started through inetd/xinetd.
Don't forget to set your environment.
Configuration of the MDS 2.4 release requires the following basic steps:
Acquire LDAP certs
Start MDS 2.4 with the following command:
% GLOBUS_LOCATION/sbin/globus-mds start
This command starts the OpenLDAP 2.0 slapd server for the GRIS. It does not require environment variables $GLOBUS_LOCATION to be set.
Send a test query to GRIS on a local host, with the following command:
% GLOBUS_LOCATION/bin/grid-info-search -anonymous -L
Note that this test does not require you to wait for the LDAP certificate before performing the test, because it uses the '-anonymous' flag. If you want to disable anonymous access to MDS, see the configuration section of this guide.
If you have any questions, try the MDS FAQ.
Testing GridFTP consists of the following steps:
- Starting a GridFTP server
In this section, you'll start a GridFTP server running under the permissions of your user certificate.
First, create a proxy:
% grid-proxy-init -verify -debug
Then start the GridFTP server as yourself:
% $GLOBUS_LOCATION/sbin/in.ftpd -S -p 5678
-Sflag leaves the daemon in the background and the
-pflag specifies port. If that port is already in use, you can try another. You also need to create ~/.gridmap, and add an entry with your subject (which was output by the grid-proxy-init step) and username, as follows:
"/O=Grid/O=Globus/OU=your.domain/CN=Your Name" your-account
In the future, you will not be starting the in.ftpd daemon by hand. Follow the instructions in the next section to add it to inetd/xinetd.
- Moving a test file
Now, create a file named
/tmp/file1, and run the following command:
% globus-url-copy -s "`grid-cert-info -subject`" \ gsiftp://localhost:5678/tmp/file1 \ file:///tmp/file2
Check to make sure that /tmp/file2 now exists. Note that the -s flag is being used because the GridFTP server is running under your user proxy. In general, this is not required when transferring to/from a host-based GridFTP server. To repeat more strongly: if you are using a real gridftp server, started by inetd/xinetd, do not use the -s flag. You only need that to work with a server started as a user, which is not the normal case.
Last modified: Mon Feb 24 11:15:36 CDT 2003