Bugzilla – Bug 3372
-self option on globusrun-ws not passed to subjobs
Last modified: 2005-08-03 17:12:56
You need to
before you can comment on or make changes to this bug.
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
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
on my machine (i.e., the whole job and all the subjobs use the same container
on my machine) globusrun-ws fails to start the subjobs because the -self flag
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
to extend the XML to allow individual jobs to specify whether or not they want
-self or not.
This is due to previous security configuration changes. It would work if the
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.
I comitted a fix for this in the trunk. I can't make it to the 4.0 branch
the interface is frozen for that branch. It's safest to just rebuild the
gt4-gram bundle to get the update.
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).