I'm not sure what changed, but I can offer you a better workaround
until someone else answers.
Set "logicalHost" to your DNS name and "disableDNS" to true in your
$GLOBUS_LOCATION/etc/globus_wsrf_core/server-config.wsdd as described
in http://www.globus.org/toolkit/docs/4.2/4.2.0/common/javawscore/admin/javawscore-configuring.html#javawscore-Interface_Config_Frag-overview
You should see, then, that when you start the container the list of
services has the DNS name listed rather than your IP. Also, EPRs like
the one globusrun-ws gets back will have the hostname rather than the
IP. Probably that will help.
Charles
On Sep 17, 2008, at 2:58 PM, Adam Bazinet wrote:
I'm having some trouble with authorization in 4.2 using globusrun-
ws. This all worked fine for us before. Here's an example:
[EMAIL PROTECTED]:/export/grid_files/247485890.3688919596866548>
globusrun-ws -status -j jobEPR.txt
globusrun-ws: Error querying job state
globus_xio_gsi: gss_init_sec_context failed.
GSS Major Status: Unexpected Gatekeeper or Service Name
globus_gsi_gssapi: Authorization denied: The name of the remote host
(lysine.umiacs.umd.edu), and the expected name for the remote host
(128.8.141.68) do not match. This happens when the name in the host
certificate does not match the information obtained from DNS and is
often a DNS configuration problem.
(For the record:
[EMAIL PROTECTED]:~> host lysine
lysine.umiacs.umd.edu has address 128.8.141.68)
OK, so the contents of jobEPR.txt might look something like this:
<ns1:GSBLResourceReference xmlns:ns1="http://cummings.umiacs.umd.edu/GSBL
"><ns2:Address xmlns:ns2="http://www.w3.org/2005/08/addressing";>https://128.8.141.68:8443/wsrf/services/ManagedExecutableJobService
</ns2:Address><ns3:ReferenceParameters xmlns:ns3="http://www.w3.org/2005/08/addressing
"><ns4:ResourceID xmlns:ns4="http://www.globus.org/namespaces/2008/03/gram/job
">bdace120-84df-11dd-97a1-a255e71cbe39</ns4:ResourceID></
ns3:ReferenceParameters></ns1:GSBLResourceReference>
Most likely, the relevant part to pay attention to is this:
https://128.8.141.68:8443/wsrf/services/ManagedExecutableJobService
As you can see, the service handle we used to submit the job
referenced the host by IP address (as we've always done it). The
host certs get issued using the host name (as we've always done it).
Our DNS is set up fine (forward and reverse lookups), and like I
said, we've never had a problem until 4.2.
If I add -subject to globusrun-ws and put in the full host
credential (like so: /O=Grid/OU=GlobusTest/OU=simpleCA-
leucine.umiacs.umd.edu/CN=host/lysine.umiacs.umd.edu), of course, it
works fine. I've implemented a hacky workaround for the time being
that maps IP addresses to the full host credentials, but I'd prefer
not to have to keep this information up to date and rely on it in
order to make job status checks.
I encounter the same authorization issue when I attempt to submit
jobs with globusrun-ws, but in our system we are submitting using
the GramJob class (again, referencing remote resource hosts by IP
address, and that works fine!) -- we only use globusrun-ws to check
on job status.
Something changed in 4.2, hopefully someone can tell me what!
thanks,
Adam
