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