Purdue Homepage | Purdue Search | Campus Map | Purdue Directories
Direct inquiries or comments to: rcac-info@purdue.edu
All content Copyright © 2007, Purdue University, all rights reserved.
An equal access/equal opportunity university.
Purdue offers several resources to TeraGrid users. This document provides information targetted to new or potential TeraGrid users about how to obtain an account and start using these. For more detailed information, refer to the complete user guide.
TeraGrid grants allocations to research projects that have been approved for a specified amount of compute cycles on TeraGrid resources. How to obtain a TeraGrid account will depend on whether you need a brand new allocation or if you only need to be added as a user of an existing allocation.
Regardless of the allocation, once your initial TeraGrid account has been approved and created, you will receive a start up package via regular mail. In this package will be your account information for all the sites to which you requested access. There is also a User Responsibility Form. The last page of this form must be signed and returned within 30 days. You may start using your account as soon as you receive this package. You should immediately login to all the sites to which you have been given access and change your password(s).
To request a new allocation on the TeraGrid, refer to the TeraGrid Allocation Guide and follow the process described there.
If your institute/research group already has a TeraGrid allocation, you may be added to this allocation. This is something your PI must do. They will need to fill out the "Add User" form. To access the form they must first login to the TeraGrid User Portal. Then click on the "My TeraGrid" tab and select "Add/Remove User". After the application has been reviewed and accepted, the new user(s) will receive a packet via conventional (postal) mail that contains their account information in about two weeks.
Refer to the TeraGrid Allocation Guide for more information.
To get an account on Purdue TeraGrid resources, you will need to either be a local user with an existing Purdue career account, or you will need a User Certificate. For more information about user certificates, refer to the Certificates section of the User Guide. Once you have a certificate or Purdue career account, send an email to the TeraGrid HelpDesk including your certificate DN or career account name and ask to be given access to Purdue TeraGrid resources.
In order to log in and interactively use a shell on any TeraGrid resource, you must use a GSI-SSH or SSH client. GSI-SSH client software such as "gsissh" may be installed on Linux, Mac OSX, or other Unix variants. GSI-SSH allows SSH access to machines using your user certificate for authentication instead of a password.
We strongly urge you to use a GSI-SSH client and a proxy grid certificate to log in to remote TeraGrid resources rather than a standard SSH client. However, if that is not possible, standard SSH may be used to some TeraGrid resources. Standard SSH clients will either require the password defined at each TeraGrid resource for your account there or may be accessed using an SSH key. If you find GSI-SSH is not available to you, we have more information on setting up SSH keys.
Email services are not supported on Purdue TeraGrid systems. Outgoing email will be delivered, but incoming email will be forwarded to the address supplied when your TeraGrid account was requested. If that address is incorrect, please send your correct forwarding address to the TeraGrid HelpDesk.
When your account is first activated, your shell will be set to tcsh, an enhanced version of the Berkeley UNIX C shell (csh). If you would like to use another shell (e.g. bash, the GNU Bourne-Again SHell), please send a request to have your shell changed to the TeraGrid HelpDesk.
TeraGrid resources primarily use certificate-based authentication. These certificates (X.509 certificates) are somewhat similar to how SSL/TLS and credit card transactions on the internet work. In this case, however, a certificate must be presented by you as proof you are who you claim to be. These user certificates are issued and signed by trusted Certificate Authorities (CAs). Not all CAs are trusted by TeraGrid sites.
You should receive instructions on obtaining an NCSA certificate with your introductory TeraGrid packet. Purdue affiliates may also obtain a Purdue certificate.
It is fairly easy to obtain an NCSA user certificate, so you may wish to start by getting one of those and using it to log in to systems in the future.
bash-3.00$ ncsa-cert-request
bash-3.00$ grid-cert-info -subject bash-3.00$ grid-cert-info -enddate
If you do not wish to obtain an NCSA user certificate, it is possible to use a user certificate from any TeraGrid-trusted Certificate Authority. To do so, place those certificate files in your ".globus" directory. Read the "File Transfer" section of the user guide for information on how to transfer your certificate (and other files) between sites.
You should confirm your certificate is approved by locating your user certificate's Distinguished Name (DN) in the gridmap file.
First, to extract your DN from your user certificate:
bash-3.00$ grid-cert-info -subject
Then search for this DN in the gridmap file:
bash-3.00$ grep <your_DN> /etc/grid-security/grid-mapfile
If you are not in the gridmap file, you may use "gx-request" on many of the sites to request your DN be added. See here for a list. If gx-request is not supported on a system, you will have to email your DN to the TeraGrid HelpDesk.
Proxy Certificates are temporary authentication credentials issued based on your user certificate. These proxy certificates may be used to authenticate to various TeraGrid resources in lieu of your user certificate. This is generally safer than using your actual certificate, as these proxy certificates are only good for a matter of hours, so should one fall into the wrong hands, it would be of limited impact.
There are two ways of obtaining a proxy certificate. One is to derive a proxy certificate from your existing user certificate in your .globus directory, as explained above. However, you may also obtain a proxy certificate without a local user certificate. This is possible using the automatic NCSA user certificate created for all TeraGrid users, and the TeraGrid MyProxy server. Either method may be used. You may already have a local user certificate, or you may find it easier to directly obtain proxy certificates whenever you need them from the TeraGrid MyProxy server.
Either method's proxy certificates may be used to run jobs at TeraGrid sites or login via gsissh, as described elsewhere.
If you have a local user certificate in place in your ".globus" directory, you may derive a proxy certificate from this by running "grid-proxy-init":
bash-3.00$ grid-proxy-init Enter pass phrase: <user_certificate_passphrase> A proxy has been received for user username in /tmp/x509up_u#####
By default, the proxy certificate is valid for 12 hours. If you wish to have it remain valid longer, this can be done using the "-valid" option:
bash-3.00$ grid-proxy-init -valid <hh:mm>
When your TeraGrid account was created, a user certificate and Distinguished Name (DN) was created on your behalf by the NCSA Certificate Authority (CA). This DN is stored in your profile in the TeraGrid account database and automatically propagated to all TeraGrid sites. A proxy certificate derived from this can be retrieved from the TeraGrid MyProxy certificate repository (myproxy.teragrid.org) while on any TeraGrid resource by using the command "myproxy-get-delegation", supplying your TeraGrid Portal user name with the "-l" option, and your TeraGrid Portal password as the MyProxy passphrase:
bash-3.00$ myproxy-get-delegation -l <portal_username> -s myproxy.teragrid.org Enter MyProxy pass phrase: <portal_password> A proxy has been received for user username in /tmp/x509up_u#####
By default, the proxy certificate is valid for 12 hours. If you wish to have it remain valid longer, this can be done using the "-t" option:
bash-3.00$ myproxy-get-delegation -t <hh:mm>
You can verify the status of your current proxy certificate at any time by running "grid-proxy-info":
bash-3.00$ grid-proxy-info
You may delete your current proxy certificate at any time by running "grid-proxy-destroy":
bash-3.00$ grid-proxy-destroy
If you are a Purdue affiliate and physically on campus, you may obtain a user certificate from the Purdue Certificate Authority. This is not necessary, as you only need a certificate from any one of the TeraGrid sites, and you can generate one yourself at NCSA. However, if you would like to obtain one, you may follow the instructions in Purdue CA User Certificate section of the user guide.
Purdue has two major TeraGrid compute resources, the Steele Cluster and the Condor Pool, as well as FPGA, file storage, data, and visualization resources. Detailed information about Purdue's resources is available on the "Resources" page.
Detailed information is available on Purdue filesystems and directory usage, as well as standard filesystem location variable names. Information on how to transfer files to and from grid resources is also available.
TeraGrid sites use several different local systems for managing jobs and queues. However, all support the Globus protocol for job submission, and by extension, Condor-G job submission. Following is specific instructions on how to use some of these to submit jobs either to Purdue resources or from Purdue to other TeraGrid sites.
Condor is one of several submission systems Purdue supports which you may use to run jobs on TeraGrid sites. Condor provides a framework for running programs on otherwise idle computers. While this has serious limitations for parallel jobs and programs with large I/O or memory requirements, Condor can provide a very large quantity of cycles for researchers who need to run hundreds or even thousands of smaller jobs. Condor may be used both to submit jobs to Purdue resources from outside Purdue as well as from Purdue hosts to submit jobs either locally or to other TeraGrid sites. For more information, refer to the Condor Section of the Complete User Guide.
Globus is one of several submission systems Purdue supports which you may use to run jobs on TeraGrid sites. Globus provides a framework for job submission and management over the Internet using certificate-based authentication credentials. This is the de facto standard means of issuing jobs over most Grids, including TeraGrid. However, Condor-G provides a front-end to the Globus protocol with some additional features and is generally found by users to be simpler to use. That said, users do have the option to use Globus directly instead. Globus may be used both to submit jobs to Purdue resources from outside Purdue as well as from Purdue hosts to submit jobs either locally or to other TeraGrid sites. TeraGrid supports Globus Toolkit 4.0, which also includes file transfer and resource description tools. For more information, refer to the Globus Section of the Complete User Guide.
PBS is one of several submission systems Purdue supports you may use to run jobs at Purdue. Note: It is only possible to submit jobs to Purdue resources via PBS from a Purdue host. While we encourage the use of Grid tools such as Globus and Condor-G, it may be useful to use PBS if you are currently having problems submitting jobs using Grid tools. For more information, refer to the PBS Section of the Complete User Guide.
To conduct a basic test of a remote system and retrieve some information about the environment there, save the following as the file "probe.sh" and then send a job to the remote system you wish to probe with this script as the executable:
#!/bin/sh # # probe.sh # Basic Environment Probe # echo "************************************************************" echo "Date/Time = `date '+%Y-%m-%d %T'`" echo "Machine = `hostname`" echo "User = `whoami`" echo "Working Directory = `pwd`" echo "Environment Variables =" echo "" echo "`env`" echo "************************************************************"
It will report the date and time (when it ran), machine name (where it ran), the user (who it ran as), the working directory (what directory it was run from), and the full set of environment variables. This information may prove useful in constructing your submissions or in locating a problem with another submission.