Sure, it's bug 6331: http://bugzilla.globus.org/globus/show_bug.cgi?id=6331
Charles
On Sep 18, 2008, at 10:55 AM, Adam Bazinet wrote:
Thanks, yes, this worked as you said it would. I'll make it a
standard practice at least until automatic DNS resolution is added.
If there is a pointer to that bugzilla entry, as someone else
already asked for, please post it so we can be notified. I don't
mind an extra couple of config steps in the meantime.
Thanks,
Adam
On Wed, Sep 17, 2008 at 4:41 PM, Charles Bacon <[EMAIL PROTECTED]>
wrote:
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
