Globus 2.2 Services
This section will give a more in-depth view of the installed services, for the purpose of understanding the servers well enough to understand both advanced service configuration, as well as sophisticated client usage. The clients themselves will be covered in the User's Guide, but this section provides useful background material.
Implementation of GRAM
The short story
The GRAM service is mainly provided by a combination of two programs: the gatekeeper, and the jobmanager.
The gatekeeper provides functionality which is similar to a secure inetd. It authenticates an inbound request using GSI, and determines how that user will be authorized locally by mapping it to a local user id. The incoming request specifies a particular local service to launch. That local service is usually a jobmanager.
The client composes its request in the Resource Specification Language (RSL), which is passed to the jobmanager by the gatekeeper. The jobmanager then parses the request, and translates it into the language of the local scheduler.
The jobmanger will then return a contact string which the client can use to check up on ongoing job status, or to cancel a job in progress.
GRAM also provides the ability to stage in data or executables, using a facility called Global Access to Secondary Storage (GASS). If you exercise this option, the jobmanager will contact your client before submitting the job in order to retrieve whatever files you wanted to stage in. The jobmanager also uses the GASS facilities to keep track of the output of your various jobs.
The long story
In more detail, the GSI authentication is performed using the X.509 public certificate standard. These are the public and private key that were generated by the grid-cert-request program covered in the verification section. Part of the trust of authentication is established by the Certificate Authority (CA) which signed your key.
By default, the Globus Toolkit(tm) is configured to trust the Globus CA, and requests certificates from that CA as well. This is setup mainly to provide an easy way to install and test the Toolkit without having to go through the infrastructure work of establishing a CA, if there were not a CA already available to you. However, for greater security, if you are a member of a Virtual Organization (VO), you should establish trust in a separate CA, and remove trust from the Globus CA. We will show you how to do this in the advanced configuration section.
The authentication does not use your certificate itself. Instead, it generate a proxy
certificate, signed by your original certificate, when you run grid-proxy-init.
This proxy has a limited lifetime, and its private key is protected by filesystem
permissions, not a key. This is similar to the generation of a Kerberos ticket, if you are
familiar with them. It is this proxy (located in /tmp) which you use to authenticate to
the gatekeeper.
Assuming that the gatekeeper has been configured to trust the CA which signed your
certificate, the next step is authorization. By default, the gatekeeper is looking for a
file called /etc/grid-security/grid-mapfile. This file should contain
mappings of certificate subject names to local user names, like the following:
"/O=Grid/O=Globus/OU=your.domain.edu/CN=Your Name" youruser
Assuming that your subject appears in the grid-mapfile, and translates to a valid user
id, the gatekeeper will then launch the jobmanager you requested under your mapped user
id. The set of configured jobmanagers is in $GLOBUS_LOCATION/etc/grid-services.
The advanced configuration section explains
how to add jobmanagers. By default, the "fork" jobmanager is setup, which simply
uses fork/exec to launch a job on the same machine as the gatekeeper is running on. Most
other jobmanagers interface to a scheduler in order to submit jobs.
With GRAM 1.6, the jobmanager scripts are written in perl, and sit under the $GLOBUS_LOCATION/lib/perl directory. See the configuration files section for more details.
During the gatekeeper's communication with your client, you also created a delegated
proxy from your user proxy (which was itself created by your original certificate). The
gatekeeper lets the jobmanager know where to find this delegate proxy by setting the X509_USER_PROXY
environment variable. If the jobmanager needs to communicate back to your client (to
retrieve a staged file, or to deliver stdout/stderr), it uses this delegated proxy to
authenticate itself to you.
While your job is running, the output is collecting into a GASS cache, located in your
home directory under .globus/.gass_cache by default. If you use an
interactive client, the jobmanager will deliver the output when the job is done, and clean
this cache up automatically. If you use a batch client, you can perform retrieval and
cleanup manually. See the user guide, under the
globus-job-run and globus-job-submit sections to see examples of both types of behavior.
Implementation of MDS
The Metacomputing Directory Service (MDS) is part of the information infrastructure of the Globus Toolkit. The MDS provides a framework for managing static and dynamic information about the status of a computational grid and all its components: networks, compute nodes, storage systems, instruments.
MDS consists of two main components: the local server (GRIS) and the aggregate server (GIIS).
The GRIS is responsible for collecting information about a resource. This can involve details such as amount of disk, amount of memory, number and speed of processors, etc. You can query a GRIS directly, but it is often more useful to search in an aggregate directory.
Any number of GRISes can report into an aggregate directory called a GIIS. A GRIS registers itself to a GIIS using the Grid Resource Registration Protocol (GRRP). Additionally, you can create a hierarchy of GIIS servers, which is useful for virtual organizations.
MDS 2.2 contains the following new features:
- Flexible handling of stale data via a new parameter in the grid-info-slapd.conf file.
- Improved GRIS/GIIS processing by allowing multiple GRISes in a slapd server.
See MDS 2.2 New Features for a complete description of these features.
Implementation of GridFTP
Our implementation of the GridFTP protocol takes the form of two APIs and corresponding libraries: globus_ftp_control and globus_ftp_client. Our libraries use high-performance I/O and security services provided by the Globus Toolkit.
Besides supporting the protocol features described above, our APIs also include interfaces for adding software "plug-ins". These plug-ins allow developers to add customized reliability and fault tolerance, performance monitoring, and extended data processing.
In addition to our software libraries, we have also implemented an API/library (globus_gass_copy) and a command-line tool (globus-url-copy) that integrates GridFTP, HTTP, and local file I/O to enable secure transfers using any combination of these protocols.
Finally, we have adapted a popular FTP server package (Washington University's wu-ftpd) to support a majority of the GridFTP protocol features (GSI security, parallel transfer, third-party transfer, partial file transfer).
Charles Bacon
Last modified: Wed Sep 27 14:32:22 CST 2002