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
