Bug 3372 – -self option on globusrun-ws not passed to subjobs

Bug 3372 - -self option on globusrun-ws not passed to subjobs

Summary:

-self option on globusrun-ws not passed to subjobs

Status:	RESOLVED FIXED

Product:	GRAM
Component:	general
Version:	4.0.0
Platform:	All All

Importance:	P3 normal
Target Milestone:	4.2
Assigned To:	Peter Lane

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2005-05-17 10:51 by Nick Karonis
Modified:	2005-08-03 17:12 (History)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

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

Description From Nick Karonis 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 Peter Lane 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 Peter Lane 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 Peter Lane 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).