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:
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.
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