[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] condor-submit -remote
- Date: Fri, 1 Jun 2007 12:03:16 +0100
- From: "Matt Hope" <matthew.hope@xxxxxxxxx>
- Subject: Re: [Condor-users] condor-submit -remote
On 5/31/07, Kewley, J (John) <j.kewley@xxxxxxxx> wrote:
> It sounds like what you want is CLAIMTOBE authentication. This
> basically gives you host-based security for remote user
> SEC_DEFAULT_AUTHENTICATION_METHODS = FS, CLAIMTOBE
Hmm, from the manual:
"Claim To Be authentication accepts any identity claimed by the client.
As such, it does not authenticate. It is included in Condor and in the
list of authentication methods for testing purposes only."
And "the powers that be" suggest that I should use a single submission
point to improve security! Maybe I'll just get them to ssh onto it, but then
I suspect file transfer would be a pain.
The moment you start doing that sort of thing you might want to
consider wrapping the submission process in your own system. The
initial pain is swiftly offset by the ability to alter aspects of the
system (like multiple submission machines abstracted into one) or
adding useful tracing/log control and the like
Is there a section in the manual on remote submission (as opposed to
Grid submission)? I presume that files can be transferred if neccessary?
The docs for condor_submit list most parts - note some significant limitations:
1) You cannot make use of submitting on hold. the remote submission
makes use of the hold mechanism to ensure that the job does not start
before the relevant files have made it across. I find this a *real*
pain since we currently deliberately slow release jobs so there are no
more than about 40 idle jobs at once (with possibly thousands of held
If you are using a single submit point you may find the pain of not
being able to do this considerable.
2) At the moment multiple processes within a cluster seem to trigger
multiple file transfers - this is slow if you have large executable
or input files as well as using up much more space on the remote
3) the authentication you have already covered.
I reckon that abstracting the remote submission away by providing your
own mechanism for it is worthwhile if you have a sufficiently
restrictive set of possible jobs that this can be adequately
parametrised by a very small subset of the possibilities within
condor_submit and the mechanism to send executable and input files to
the submission host is something you can effectively manage via
straight file copying rather than reimplementing a file transfer
That last bit is just my opinion though. I have not yet had to do this
(though it is on my list of potential infrastructure changes so I have
given it some thought)