Proposal Shared Executables Ickpts In The Spool

Not logged in

• Browse
• Help
• Home
• Login
• Reports
• Search
• Timeline
• Wiki

• Contents
• No-Diff
• Text

 
 {section: The problem: }
 
-We have actual users using Condor-C submit to submit hundreds or thousands of jobs with the same executable.  For Condor-C copy_to_spool must be true.  Furthermore, for Condor-C, we can't use clusters to share an executable; each job becomes a new cluster.  You end up with one copy of the executable per job.  Given a moderately large executable, you can end up with gigabytes of duplicate executables.  This is a waste of disk space and bandwidth.
+We have actual users using HTCondor-C submit to submit hundreds or thousands of jobs with the same executable.  For HTCondor-C copy_to_spool must be true.  Furthermore, for HTCondor-C, we can't use clusters to share an executable; each job becomes a new cluster.  You end up with one copy of the executable per job.  Given a moderately large executable, you can end up with gigabytes of duplicate executables.  This is a waste of disk space and bandwidth.
 
 
 {section: The goal: }
@@ -80,7 +80,7 @@
 
 {section: Escaping algorithm:}
 
-The CmdHash is a ClassAd, or at least a partial ClassAd serialized into a string. The resulting string must be a valid ClassAd string, and a valid file name on every operating system Condor supports (forbidden characters include, but are not limited to: ":/\").  We'll also need to reserve one or more characters to indicate escaped characters and to delimit between fields and records.  Furthermore, the resulting CmdHash should be reasonably short, to avoid path limits and to keep sysadmins happy.  It would be nice if it could also not look too much like line noise.  No two different ClassAds should ever generate the same CmdHash, however, two identical ClassAds must generate the same CmdHash.  Reversability of the CmdHash would be nice, but isn't required.  We might want to avoid spaces for the sake of naive scripts.
+The CmdHash is a ClassAd, or at least a partial ClassAd serialized into a string. The resulting string must be a valid ClassAd string, and a valid file name on every operating system HTCondor supports (forbidden characters include, but are not limited to: ":/\").  We'll also need to reserve one or more characters to indicate escaped characters and to delimit between fields and records.  Furthermore, the resulting CmdHash should be reasonably short, to avoid path limits and to keep sysadmins happy.  It would be nice if it could also not look too much like line noise.  No two different ClassAds should ever generate the same CmdHash, however, two identical ClassAds must generate the same CmdHash.  Reversability of the CmdHash would be nice, but isn't required.  We might want to avoid spaces for the sake of naive scripts.
 
 To meet these goals, we'll err on the side of caution and use a whitelist; anything not in the whitelist will be escaped.
 
@@ -90,7 +90,7 @@
 
 To escape a portion, take each part in turn.  For each part, for each character not matched by the regex [A-Za-z0-9_.] will be escaped.  To escape a portion, replace it with an "%AA" where "AA" is the hexidecimal ASCII value of the character replaced.  So + will map to %2B.  This is very similar to URL escaping.
 
-This is woefully non-Unicode ready, but neither is the rest of Condor.
+This is woefully non-Unicode ready, but neither is the rest of HTCondor.
 
 Open issues:
 
@@ -103,15 +103,15 @@
 
 This is insecure in the face of CLAIMTOBE, ANONYMOUS, or any other situation in which multiple users map to the same Owner.  Don't do that.  Even without this behavior, that's very insecure and users can mess with each other using condor_qedit, condor_rm and more.
 
-There is the specific case where a users use a front end, maybe a web interface, to Condor, and behind the scenes their jobs all map to the same user.  These users don't have direct access to the schedd, so they can't mess with each others jobs in the queue.  Even without this behavior, these jobs can mess with each other; two jobs scheduled on the same machine can mess with each other.  (Dedicated run accounts can protect against this, at the cost that jobs don't run as the Owner.)  Two jobs scheduled one after the other on the same machine can mess with each other by the earlier process sneaking a rogue process out.  (Again, dedicated run accounts solve this.)  If this is the situation, shared executable functionality should be disabled.  This seems likely to be a very unusual situation.
+There is the specific case where a users use a front end, maybe a web interface, to HTCondor, and behind the scenes their jobs all map to the same user.  These users don't have direct access to the schedd, so they can't mess with each others jobs in the queue.  Even without this behavior, these jobs can mess with each other; two jobs scheduled on the same machine can mess with each other.  (Dedicated run accounts can protect against this, at the cost that jobs don't run as the Owner.)  Two jobs scheduled one after the other on the same machine can mess with each other by the earlier process sneaking a rogue process out.  (Again, dedicated run accounts solve this.)  If this is the situation, shared executable functionality should be disabled.  This seems likely to be a very unusual situation.
 
-The default hash will be at least as secure as MD5 or SHA-1.  This means the chance of an _accidental_ collision is 2^128.  That's basically never. If it's good enough for digital signatures, it's plenty good enough for Condor.
+The default hash will be at least as secure as MD5 or SHA-1.  This means the chance of an _accidental_ collision is 2^128.  That's basically never. If it's good enough for digital signatures, it's plenty good enough for HTCondor.
 
 That said, there are known attacks on MD5, and similar attacks likely soon against SHA-1.  This is (partially) why we're segregating files by user.  A user can only attack his own jobs, and if he wants to do that there are simplier ways.  We are not expecting to try and defend a user against his own malice.
 
 {section: General notes:}
 
-If someone downgrades, everything will still work fine, but lots of exe-username-MD5-asdfasdfasdf files will be left behind.  The admin can safely remove all of them without harm!  Of course, no one would ever downgrade Condor.
+If someone downgrades, everything will still work fine, but lots of exe-username-MD5-asdfasdfasdf files will be left behind.  The admin can safely remove all of them without harm!  Of course, no one would ever downgrade HTCondor.
 
 If an exe-username-MD5-asdfasdfasdf file is erroneously deleted, the system keeps working.  Duplicate copies of the file may later be made, but existing jobs will never notice.  (Removing the ickpt file for a given job will break it, but that's the existing situation.)
 

This work is supported by NSF under Cooperative Agreement OAC-2030508 as part of the PATh Project. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the NSF. Site built using CVSTrac.