Grid Service Tests

Hosts

The name of each host is a link to a status page that reconstructs the running of the tests for the host.  More detailed information, i.e. the output of the Globus tools, should be available for each failing test associated with the host.
 

Gatekeeper

Gatekeeper testing consists of a port connection test, a probe for job managers, and the submission of a simple echo job to each discovered jobmanager.  The port connection test simply attempts to establish a TCP connection for the given port on the service host.

Next, the globusrun command is used to probe the gatekeeper service to determine which of the following well-known jobmanagers are configured on the host:

For each discovered manager, a simple job submission using /bin/echo is used to see if the manager is functioning.  Given that most jobmanagers represent batch queueing systems, a 60 second timeout is imposed on each echo test.
 

GridFTP

GridFTP testing consists of a port connection test, a pair of transfers directly from the testing host to the service host and a pair of transfers between the service host and a third host. The port connection test simply attempts to establish a TCP connection for the given port on the service host.

The direct transfer test involves using the globus-url-copy program to copy a file from the testing host to the service host, copying the file back from the service host and inspecting the contents of the returned file.  If an error is detected during either transfer, the status listing will show the debug output of the globus-url-copy program.  This output can be verbose but it will provide better information as to what went wrong during the transfer.  The transfers use the /tmp directory on both hosts for the staging of the file.

The third party tests use an intermediate host to interact with the service host, but, behave in a similar manner to the direct transfer test mentioned above.  The test file is transferred from the testing host to the intermediate host, from the intermediate host to the service host, the file is then retrieved from the service host to the intermediate host and, finally, the file is retrieved from the intermediate host.  All transfers use globus-url-copy with debugging enabled

Third party transfers require particular entries in the ftpaccess file used by the in.ftpd released with the Globus Toolkit.  If the entries are missing then the globus-url-copy program will complain about an "Illegal PORT command".  Please note that in the version 2 beta release of the Globus Toolkit, the in.ftpd daemon will always use /etc/ftpaccess regardless of the configuration switches used to start the daemon.  This has been reportedly fixed in the final release.
 

MDS

MDS testing consists of a port connection test, an enquiry to determine available search bases (i.e. LDAP suffixes), and a consistency test for the entries returned in each search base. The port connection test simply attempts to establish a TCP connection for the given port on the service host.

Next, using grid-info-search the LDAP server is asked to report which LDAP suffixes are handled by the server. For each suffix, grid-info-search is used to request all the entries that contain the suffix.  The background color associated with the suffix name indicates the success or failure of obtaining the entries.  The number of entries is reported in the table cell.  The background color associated with the number of entries informs you if the entries form a consistent LDAP Directory Information Tree (DIT).

A consistent DIT is characterized, in this instance, by each entry having a parent entry.  In LDAP, entries are structural elements that are attached to parent entries to form a DIT.  The information providers used in a GRIS can generate entries that are not structurally bound to parent entries.  While the grid-info-search command will still report these entries, pure LDAP clients may drop the entries when connected to the MDS service.  A common cause of inconsistent entries on a RedHat 7.x system is the fact that the default information providers do not report the the FQDN of the host while other information providers, such as the GRAM reporter and PIPPY, generate the FQDN in the dn of their entries.
 

A sample report is displayed below for atlas000.uta.edu.  The table indicates that the Port Test was succesful, there were two LDAP suffixes available named: "Mds-Vo-name=site,o=grid" and "Mds-Vo-name=local,o=grid".  Since queries to atlas000 for each suffix were successful the suffixes are shown with a green status.  The "Mds-Vo-name=local,o=grid" shows that 44 entries were returned by a search.  The 44 entries returned do not form a consistent DIT and the red background indicates the failure.  For the other suffix, "Mds-Vo-name=site,o=grid", grid-info-search returned 0 entries. At the time this was written, this is the correct number of entries.  The color coding indicates that a consistency test was not run.
 
Port Test 
Mds-Vo-name=site,o=grid 0
Mds-Vo-name=local,o=grid 44