Re: [Condor-devel] Workfetch Architecture Questions

[Todd Tannenbaum <tannenba@xxxxxxxxxxx>]

Robert Rati wrote:
> To address issue #1 below, I've created a patch that will set the IWD to 
> be the temporary execute if the ClassAd does not specify the IWD.  Let 
> me know if you see any problems or think there should be modifications.
>
> Rob

Hey Rob -

Thanks for the contribution, we'd like to push it into the code.

All folks who make contributions need to sign a "Contributor License 
Agreement" (CLA) for the protection of both the project and the 
contributors.   The Condor CLA looks a lot like the Apache CLA; you'll 
recognize it if you ever made contributions to any Apache Foundation 
open source projects.

At any rate, the CLA can be found here:
  http://www.cs.wisc.edu/condor/licenses/CLA-PUBLIC.pdf

Could you please sign and return it (email to condor-admin@xxxxxxxxxxx 
or fax to 608-262-9777)?  You'll only need to do this once.

Thanks again for the patch!!!!!!

regards,
Todd



> Derek Wright wrote:
> > [Replying to the condor-devel list, which is the better place to 
> > discuss development questions like this, and which is also archived 
> > for posterity...]
> >
> > On May 9, 2008, at 6:57 AM, Robert Rati wrote:
> >
> > > 1) I brought up the issue with the IWD earlier, and found that if I 
> > > specify "." as the IWD then jobs will run.  While this will work I 
> > > suppose, it doesn't really feel right.
> >
> > Agreed.
> >
> > > I had a couple of ideas on how to solve this, but I think I should be 
> > > consistent with how IWD is handled for other condor jobs and want to 
> > > see which of these ideas is more consistent (or if there is a better 
> > > way).
> >
> > Right. ;)
> >
> > > A) Make IWD optional, and if IWD isn't provided in the ClassAd, then 
> > > set it to "."
> >
> >
> > More or less, yes.  I'd actually set it to the full path to the temp 
> > sandbox directory, but effectively that's the same thing.
> >
> > > B) Make the IWD relative to the temporary execute directory condor 
> > > creates for the job (and thus where the prepare_job hook is run).
> >
> > No.  That'd be confusing and inconsistent with how these things are 
> > handled in other cases.
> >
> > > The later seems to make more sense to me, but is that how IWD is 
> > > handled for ClassAds from other sources? Any better ways?
> >
> > I think (A) makes the most sense: just make the IWD optional and 
> > default to the temp sandbox directory if you don't define it.
> >
> >
> > > 2) Condor doesn't ensure that the execute bit is set on the file 
> > > listed in as the Cmd in the ClassAd.  I understand that condor 
> > > ensures this with work received in other ways?
> >
> > Only if Condor does the file transfer itself.
> >
> > > If so, should it be the responsibility of the prepare_work hook 
> > > script to ensure that the execute bit is set, or should condor do 
> > > that itself?  Again, I think the later from a consistency stand point.
> >
> > Personally, I'd vote that's your problem in prepare_work if you're not 
> > sure your executable is already executable and/or you just transfered 
> > it yourself.  From a security standpoint, I'd be very uneasy about 
> > having the starter going off and chmod'ing arbitrary paths on the 
> > filesystem that are coming in via job ClassAds and then trying to exec 
> > those.
> >
> > Granted, the starter should do a better job of propagating errors 
> > (#include "we-need-hook_starter_failure.h") including "duh, that file 
> > isn't executable", but I don't think the starter should be chmod'ing 
> > anything it didn't transfer itself.  This would also be a useful thing 
> > to mention in the hook documentation: "Note, if you transfer your own 
> > executable in hook_prepare_work, be sure to chmod it to 755 (or 
> > equivalent on windoze) so that the starter can execute it."
> >
> > Cheers,
> > -Derek
> >
> >
> > p.s. Sorry for the delayed reply, you sent this while I was out all 
> > last week sick, and it got buried in my overflowing inbox.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Condor-devel mailing list
> Condor-devel@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/condor-devel


--
Todd Tannenbaum                       University of Wisconsin-Madison
Condor Project Research               Department of Computer Sciences
tannenba@xxxxxxxxxxx                  1210 W. Dayton St. Rm #4257
Phone: (608) 263-7132                 Madison, WI 53706-1685