Bug 3372 - -self option on globusrun-ws not passed to subjobs
: -self option on globusrun-ws not passed to subjobs
Status: RESOLVED FIXED
: GRAM
general
: 4.0.0
: All All
: P3 normal
: 4.2
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-05-17 10:51 by
Modified: 2005-08-03 17:12 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-05-17 10:51:12
I installed GT4.0 and started a container on my machine.  I do NOT have host
certs for this
machine so when I submit jobs to this container with globusrun-ws I use the
'-self' option.
This works fine for "simple" (i.e., non-multijobs) jobs.

When I write an XML that is a multijob where everything in the XML is intended
to run
on my machine (i.e., the whole job and all the subjobs use the same container
running
on my machine) globusrun-ws fails to start the subjobs because the -self flag
is not
passed on to the subjobs.

In the short term it would be nice to have globusrun-ws to treat all the jobs
in the XML
file the same (i.e., either all -self or not).  In the longer term it probably
makes sense
to extend the XML to allow individual jobs to specify whether or not they want
-self or not.
------- Comment #1 From 2005-05-17 11:50:51 -------
This is due to previous security configuration changes.  It would work if the
"containerSecDesc" 
parameter could be commented out of the
$G_L/etc/globus_wsrf_core/server-config.wsdd file, but 
then there is no grid-mapfile setting to do authorization checks against (this
used to be set in each 
service's base security config file).  The MMJS code currently checks for the
existence of the 
global_security_descriptor.xml file and uses that as a limited heuristic to
determine what kind of auth 
to do.  Since this is always present now, the heuristic doesn't work.

The options seem to be 1) add a service config option to set what kind of auth
to do for all of the sub-
jobs, or 2) add an element to the job description schema to explicitly specify
the auth subject to use for 
that sub-job.  Either one would be about the same amount of work, so I think
I'll go with #2.  I should 
be able to start this work this week, but there are not guarantees.
------- Comment #2 From 2005-05-17 17:53:43 -------
I comitted a fix for this in the trunk.  I can't make it to the 4.0 branch
since
the interface is frozen for that branch.  It's safest to just rebuild the
entire
gt4-gram bundle to get the update.
------- Comment #3 From 2005-05-17 18:03:00 -------
I should explain better what I did.  I added a new job description element
"authSubject" that goes right after "factoryEndpoint".  The new element takes a
simple string which is the subject of the target container for that sub-job.  As
always, if you put it in the multi-job section then it will be the default for
any sub-job that does not specify it explicitly, so be careful if some sub-jobs
still need to do host auth (the default for no authSubject).