HTCondor Project List Archives



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-devel] Workfetch Architecture Questions



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